The next version will have at least one major improvement: No need for the LOADFIX command any more! Or at least I hope it won't be needed. I'll still leave the command available in case some game works better with it, for some reason. This would be rather strange, though.

While debugging Moonstone a couple of weeks ago I noticed that the reason it hangs after the intro was that the MAIN.EXE it tries to run after the intro suffered from the "Packed file corrupt" problem. Usually running LOADFIX before running such a game will help, however with Moonstone it did not improve the situation, MAIN.EXE still did not launch but this time complained "Not enough memory". I stopped working on it for a while, but began thinking of ways to get rid of the need for the LOADFIX feature completely (see my Jan 17th, 2010 entry for more info about the LOADFIX problem, if you are interested).

The solution suddenly occurred to me last Friday, and yesterday I spent the whole morning reorganizing the internal memory emulation in DSx86 to use my new idea. Since the problem is caused by buggy EXEPACK decoders that wrap the segment address below zero (to 0xFFF0 and such), I thought that what about if I move the emulated BIOS segment (0xF000..0xFFFF) of DSx86 before the actual RAM memory area (0x0000..0x9FFF)! That way the segment wrap would not cause any problems, as addresses like 0xFFF0:0xFF00 will then automatically point to the correct place in the DOS RAM area without any need for a special handling for such a situation! Gotta love such sudden coding ideas that both make the code simpler than before and automatically handle difficult situations. :-)

I had earlier had the BIOS 0xF000 segment as a separate data block of exactly 64KB in size, with various BIOS tables and other static data already located in the "final" locations within the block. The DOS RAM in turn is a bss block of 640KB. So, implementing this new idea meant that I had to copy all the BIOS static data into the bss memory block after DSx86.nds has been loaded, and it also means that the memory footprint of DSx86 will increase somewhat (as the static data is in memory twice, once in the data area and once in the bss area). However, as I don't have the extra blank space in the 64KB data block taking space from the DSx86.nds file itself, the file size got smaller. This change also will improve the DSx86 internal reboot, as the BIOS area will be recreated during a soft reboot, so it won't get corrupted as easily.

This was a rather extensive and a little bit scary change, so there is a chance that some games that need something specific from the BIOS (that I had forgotten to copy to the new BIOS area) might not work in the upcoming version. I hope I remembered to copy everything (and did not make any typos!), though.

EGA smooth scrolling fixed
The EGA horizontal smooth scrolling issue will also be fixed in the upcoming version. Late last Sunday I already thought I got it fixed, after I changed my code so that the EGA starting address values that the game sets up will only get used after one full frame has passed. With that change both Supaplex and Heimdall scrolled very smoothly. However, on Monday I then tested Commander Keen 4, which had always scrolled smoothly (even though it does not sync to the vertical retrace signal), but it scrolled now so badly it was actually nauseating! So, back to the drawing board..

The actual problem is caused by the fact that on the real EGA/VGA card, the screen start position (which scrolls by 8 pixels at a time) can be setup whenever the display is active, and it will take effect after the next vertical retrace time. The pixelwise smooth scrolling register however takes effect immediately, so it needs to be set during the vertical retrace period. Both Supaplex and Heimdall used a system where they first wait for a vertical retrace period, then wait for the screen active period to start, then set the coarse start position, then wait for the screen retrace period to start, and then set the pixelwise scrolling register.

However, in DSx86 I need to use the current values of both of those registers when I start blitting the screen, and this happens during the vertical blank time of the NDS display. It finally occurred to me, that from the PC game's point of view, the vertical blank period when I blit the screen is actually the active display time! So, perhaps if I simply swap the VBlank bit of the NDS display status register when reporting the current status to the PC game... And voilà, that fixed the scrolling in all the games! Ha, yet another simple and clean fix, I just needed to do some thinking to figure it out. :-)

Game-specific fixes
Here is a short list of games that should run in the next version, and a description of the fixes I have made to DSx86 to make them run properly.

Moonstone will start the actual game, thanks to the LOADFIX removal.
Wizardry games had a problem opening the *.dsk files. At least in Wizardry 1 this was caused