Last week I decided to finally look into the INT03 anti-debugger technique used by games like Castle Master. It took a lot of debugging and comparing the emulation progress opcode by opcode between DOSBox and DSx86, but I finally figured out the problem in DSx86. The major issue was that I did not support the Trap Flag properly, and after I added that (which was not all that simple), there still remained some issues with the possible hardware IRQ happening in the middle of a trap interrupt etc, but I finally managed to implement all the features that anti-debugger trick needs to work. Thus, Castle Master should be running in the next version, same as many other games that have so far given "Unsupported Opcode" errors where the opcode is "INT 03".

This weekend was spent fixing various bugs and adding missing graphics opcodes and some INT functions. Nothing major, but a lot of minor fixes. I did start work on supporting VGA 640x480x16 mode, though, and I remembered that my earlier tests with Windows 2.03 halted when it wanted to use that graphics mode. So, I coded just the essentials for that mode and used the 640x200 -mode screen refresh routine (so only the top part of the 640x480 screen will be visible) and then tested how far I can get with Windows 2.03. Somewhat to my surprise, after adding a couple of new EGA graphics opcodes I got Windows to load!


It was interesting that Windows did not actually need any more files than what you see in the picture above (the TEST.COM is my own small tester program that I use with the actual test programs), so I could test it in No$GBA with the bundled version of DSx86. I doubt Windows will run in any usable way yet in the next version, but it should start at least. Certainly it sounds funny to state that "I can run Windows on my Nintendo DS"! :-)

After I got Windows to start I decided to study the SB digital audio problems in Master of Orion. I got the audio to play correct data instead of noise (I had assumed a certain order of the DMA commands that start the SB digital audio DMA transfer, and MOO used a different order, so the start address got corrupted) and I also spent quite a bit of time getting the Port I/O problem fixed. The game actually reads the DMA ports to determine how far the current DMA transfer has progressed, so after some thought I decided that it might be best if I use the FIFO to send that information from ARM7 (which actually performs the the SB DMA audio transfer emulation) back to ARM9 at some suitable intervals. That was a bit difficult to get working reliably, but now it seems to work. There is still a strange problem where MOO stops the animation in DSx86 waiting for the complete audio to finish, while in DOSBox it starts new digital audio playing as soon as the animation reaches the suitable phase. I suspect it has something to do with the DMA progress check, but that works fine now as far as I can tell. This I still need to debug further.

I have also received many new debug logs, thanks for those! Many of the issues will be fixed in the next version, but some will still remain for future versions.