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

It’s been a while since we’ve said much about what’s going on behind the scenes in terms of general progress and development, so here we are, filling you all in on what we’ve been working on.

In terms of WiiSX progress, we’re nearing the beta 2 milestone we have had in mind for a few months now. The majority of features and bug fixes we have had planned are nearing completion. To be specific, WiiSX beta 2 will encompass a feature rich graphical user interface much like that seen in Wii64 and in the preview video posted below. Some other important features to note include newly ported CDR, Sound and input plugins, boasting features such as dual shock, configurable controllers, clear crisp audio and a good range of CD image support, including subchannel data. Most of the features have been implemented, but we are currently ironing out some show stopping bugs such as seen in certain Capcom fighter games.

On the Wii64 front, we managed to finish migrating the private SVN commits to the public googlecode repository up to Beta 1.1 Honey, so now you can see all of the individual commits and work that went into the last version. Since the last release, we’ve made some progress with bugfixes in the code, but we have larger plans ahead of us for the next beta in order to increase speed and compatibility. Once WiiSX beta 2 is out, we are looking forward to giving Wii64 some more of the TLC it deserves.

Here’s one last juicy tidbit for you all… There’s yet another emulator that the Wii64Team has been longing to see on the GC/Wii, so we’ve started working on a port in our spare time, and we’re hoping that it will arrive in all of your Homebrew Channels later this year. Kudos to anyone who can guess the platform (although we’re not promising to confirm if you’re right…)

It’s been a while since we’ve said much about what’s going on behind the scenes in terms of general progress and development, so here we are, filling you all in on what we’ve been working on.

In terms of WiiSX progress, we’re nearing the beta 2 milestone we have had in mind for a few months now. The majority of features and bug fixes we have had planned are nearing completion. To be specific, WiiSX beta 2 will encompass a feature rich graphical user interface much like that seen in Wii64 and in the preview video posted below. Some other important features to note include newly ported CDR, Sound and input plugins, boasting features such as dual shock, configurable controllers, clear crisp audio and a good range of CD image support, including subchannel data. Most of the features have been implemented, but we are currently ironing out some show stopping bugs such as seen in certain Capcom fighter games.

On the Wii64 front, we managed to finish migrating the private SVN commits to the public googlecode repository up to Beta 1.1 Honey, so now you can see all of the individual commits and work that went into the last version. Since the last release, we’ve made some progress with bugfixes in the code, but we have larger plans ahead of us for the next beta in order to increase speed and compatibility. Once WiiSX beta 2 is out, we are looking forward to giving Wii64 some more of the TLC it deserves.

Here’s one last juicy tidbit for you all… There’s yet another emulator that the Wii64Team has been longing to see on the GC/Wii, so we’ve started working on a port in our spare time, and we’re hoping that it will arrive in all of your Homebrew Channels later this year. Kudos to anyone who can guess the platform (although we’re not promising to confirm if you’re right…)

A new batch of 50 FlashBoys will be available later this summer, approximately late August. The Price will remain the same at 90 Euro, more details about the package here.

We are currently getting everything we need together, and will keep you informed on the forums. Might even have some surprises up our sleeves.

You can (and should, as demand is high!) preorder yours now by sending your name and email using this form.