MiSTer FPGA Forum

Topic says it all: How to debug in/the AO486 ?

I think my interest lays mainly in the 486/DOS-side of things not the core itself, but I assume there is an overlap
So lets say a program does not run in AO486, but does in DOSBox, and lets pretend in this scenario its something easy.

How would I go about solving that issue ?

I usually start with a search engine, many problems aren’t new and have been solved before. Solved by people who probably spent many many hours to come up with the answer. No reason to spend 40 hours (or 200 hours) investigating a problem you could solve with one hour of research.

The practical answer is to learn. General problem solving skills will go a long way, and you can learn the ins and outs of the PC as you go. The better mental picture you have about how the big pieces of the system fit together the easier it will be theorize where things might break down and cause problems. A lot of what I’ve learned has come from reading source code. With everything being open sourced there’s so much information at your fingertips. I may be biased because my background is in software development, but having a working knowledge of programming languages is like having a super power when it comes to learning. The entire AO486 core is open source, the BIOS is open source, you can even read the MS-DOS source code: https://github.com/Microsoft/MS-DOS

Once you’ve identified a problem you want fix you may need to experiment, run tests, collect data. Knowledge will help you chose good experiments (but I do a lot of blind guessing too).

You mentioned DOSBox, which can be a method to experiment and learn how a specific piece of software works. DOSBox has a nice debugger that let you step through CPU instructions, read memory, log to the console what the system peripherals are doing. Disassembling code, and stepping through instructions is one tool we can use to track down problems. ScummVM has a wiki that lists some other tools: https://wiki.scummvm.org/index.php/HOWT ... ngineering

When your investigating a new problem, keep it simple. Ask the easy questions first: Is it plugged in, have I configured the software correctly, is it compatible with the system. Reverse engineering is not the first thing to try.

There are other emulators to learn and experiment with: DOSBox, PCem, Qemu, Bochs. These emulators have large communities with a lot of like minded and helpful people.

YouTube is a great learning resource. Find something that interests you about PC architecture, MiSTer, MS-DOS, old video games, retro hardware and just learn. You will start to build that foundation that will help you solve problems.

If it were me I would focus on learning C/C++. This will give you the knowledge to understand the code you may be trying to fix, it gives you the skills to create new tools you may need to investigate problems.

Thank you for that elaborated explanation, that must have taken some time to write.
But I was hoping on a more practical solution

Like pitching DOSBox versus AO486 to see where the software breaks in the core. I'm no stranger to x86 assembler, although I'm not great at it, I can find my way. So I was thinking of stepping through the software until I find the problem. Unfortunately that seems to be a bit more complicated on the AO486. I don't even know what a good approach looks like. Is there a way to do remote debugging, so I'm not bound to the location of the MiSTer ?

held wrote: ↑Fri Apr 22, 2022 3:26 pm Unfortunately that seems to be a bit more complicated on the AO486. I don't even know what a good approach looks like. Is there a way to do remote debugging, so I'm not bound to the location of the MiSTer ?

Think of ao486 as real hardware; how would you debug in that case? You'd need debugging tools that can run directly in the core, and for remote debugging you could try to get networking running for it (e.g. see viewtopic.php?t=896 ).

I haven't tried it but probably cheat TSR programs such as the old Game Wizard might work to freeze and inspect memory contents.

In addtion, MiSTer does support SSH (into its linux layer) but I don't know how much can be controlled for a running core from there; probably not much at the moment. In theory one could modify the core to expose more tools, but that would require HDL knowledge and would be a major undertaking on its own.

Speaking of debugging. If someone felt like a challenge then Kings Quest VII no longer works in the core and the Top 300 pack but used to back in 2020 when I built the Top 300 pack: https://youtu.be/-Y4wqaFUNhs?t=12990

This is back in Nov 2020 and you can see it made it passed the Title screen but now in the current core it will lock after the Sierra screen when it gets to the title screen. You will never get to the menu. I tried all 4 memory options, FreeDOS and MS-DOS and it seems to just stick. Might be a good challenge for someone.

flynnsbit wrote: ↑Sat Apr 23, 2022 3:24 am Speaking of debugging. If someone felt like a challenge then Kings Quest VII no longer works in the core and the Top 300 pack but used to back in 2020 when I built the Top 300 pack: https://youtu.be/-Y4wqaFUNhs?t=12990

This is back in Nov 2020 and you can see it made it passed the Title screen but now in the current core it will lock after the Sierra screen when it gets to the title screen. You will never get to the menu. I tried all 4 memory options, FreeDOS and MS-DOS and it seems to just stick. Might be a good challenge for someone.

the last version that works is from October 10 2021
viewtopic.php?p=35222#p35222

All cores after that fails.


also Mt32 is not used even if selected. And the resource file states mt32, checked using list.

I won't be able to test this for a few days, maybe someone els can.

Go to the resours.cfg, in the kinds quest folder, and change the sound setting to Soundblaster.drv

Exact name can be found in the same folder as the cfg file.

This can all be done using list. To use list press esc to a black screen saying that the second drive is missing.

Type list and press enter.

I think most can take it from there.

When you find the file, press F3 and then e (for edit)

My guess is this broke KQ VII based on your testing:

ao486:
- sound: Add busy wait to write port status on DSP (user7182).

Issue regarding kings Quest has been crated.
https://github.com/MiSTer-devel/ao486_MiSTer/issues/117

flynnsbit wrote: ↑Fri Apr 29, 2022 2:44 pm My guess is this broke KQ VII based on your testing:

ao486:
- sound: Add busy wait to write port status on DSP (user7182).

I'll make a build with the latest core with just those changes rolled back and see if the problem goes away. Should be straightforward to see if that change broke it.

After rolling back that change KQ7 does get to the main menu.

Looking at the logic traces for the sound_dsp the game is polling to see if the DSP busy, and (apparently) never getting the answer it expects. This game uses 16-bit audio and auto init DMA, but nothing stands out to me where that would make a difference.

I'll run some more tests and see if I can narrow down what is happening.

Here's a thread with a list of 16-bit audio games: https://www.vogons.org/viewtopic.php?f=62&t=54670
And a thread on the hanging note bug with a fix: https://www.vogons.org/viewtopic.php?f=24&t=77392

I pushed up a test build to address the KQ7 problem if anyone wants to give it try.

https://github.com/user7182/ao486_MiSTe ... 6_20220430

This build works for me with Monkey Island and Kings Quest VII. I tried a couple other games (DOOM, and Wolfenstein 3D so far) and haven't seen any other regression.

The problem with the change I made before was it resulted in always telling KQ7 the sound DSP was busy. The led to the game to wait forever and not reach the menu. I updated the logic to work nicer with auto-init DMA, and it made the logic simpler.

yeah, that fixed it for me.