wraggster
December 20th, 2009, 14:40
Pate has posted more exciting news of his Dos Emulator for the Nintendo DS:
The last week I have been working on making the old Epic MegaGames game Solar Winds to work in DSx86. I've had some problems with it, but currently it looks very promising, and I can most likely get it to work properly already in the first released version.
Since SW consist of a lot of files I could not run it in No$GBA emulator, and thus debugging it has been somewhat slow (as I need to build a new version, copy it to the SD card and put the SD card into my real DS Lite to test every little change). That also meant I could not get a screen copy from No$GBA to show it here. However, today it occurred me that I could take a screen copy directly from the VRAM of DS Lite, save it as a BMP to the SD card, and then copy this file to my PC. And thus I quickly coded such a feature to DSx86, and here is the screen capture of Solar Winds running in DSx86. Note that this shows the whole 320x200 screen, as it is taken directly from the VRAM. The NDS 256x192 screen shows this either scaled or zoomed, depending on the configuration options (which aren't coded yet, though).
The problems I have had with Solar Winds were the following:
For some peculiar reason Solar Winds copies data from normal RAM to VRAM using the source and target indices and segments opposite to the standard convention. So, instead of the usual x86 way of copying data:
mov cx,<number_of_bytes_to_copy>
rep movsb
which uses CX register as a counter, copies data from DS:SI (Data Segment:Source Index) to ES:DI (Extra Segment:Destination Index), and increments the SI and DI registers automatically, Solar Winds does the copying like this:
loop:
mov al,es:[di]
mov [si],al
inc di
inc si
cmp di,4380
jne loop
That is, Solar Winds copies data FROM destination index TO source index, and then explicitly increments the indices, until the destination index (which means the source position) is at a specified location.
This makes the code run an order of magnitude slower on DSx86 than the REP MOVSB code (which has been optimized to use the ARM block copies), and it also breaks my direct screen access checking (where I only check the ES segment address). Instead of trying to find a workaround to the latter problem, I just switched back to my original blit screen update method (where the real NDS VRAM is updated by copying the whole virtual PC 0xA000 segment data once every VSync (or every other or every fourth). This will be a game-specific configuration option, as it depends on the game whether direct screen access or this blitting method works better.
I suspect Solar Winds uses the SoundBlaster SDK directly for it's music support, especially for the SoundBlaster detection. The detection routine in Solar Winds was VERY thorough, it tested every possible test register and DSP version register before it believed a SoundBlaster exists on the system! I had to code quite a bit of new emulation to make DSx86 pass all these tests. I'll eventually need to revisit this code, as currently it is a bit too Solar Winds -specific.
Solar Winds also used the PC timer differently to all the previous games I have emulated, so I had to add support for the less common timer modes as well.
And obviously there were a lot of new opcodes to support, and still are, as the screen copy above is pretty much as far as I can get in the game currently. But adding new opcodes is much easier than changing an existing hardware emulation.
My Xmas vacation is just starting, so after I get Solar Winds to run properly, I'll concentrate on making the first alpha release version available. DSx86 is still missing quite many features that I think are essential before I can release it, but hopefully I have time to add them all during this two week vacation.
http://dsx86.patrickaalto.com/
The last week I have been working on making the old Epic MegaGames game Solar Winds to work in DSx86. I've had some problems with it, but currently it looks very promising, and I can most likely get it to work properly already in the first released version.
Since SW consist of a lot of files I could not run it in No$GBA emulator, and thus debugging it has been somewhat slow (as I need to build a new version, copy it to the SD card and put the SD card into my real DS Lite to test every little change). That also meant I could not get a screen copy from No$GBA to show it here. However, today it occurred me that I could take a screen copy directly from the VRAM of DS Lite, save it as a BMP to the SD card, and then copy this file to my PC. And thus I quickly coded such a feature to DSx86, and here is the screen capture of Solar Winds running in DSx86. Note that this shows the whole 320x200 screen, as it is taken directly from the VRAM. The NDS 256x192 screen shows this either scaled or zoomed, depending on the configuration options (which aren't coded yet, though).
The problems I have had with Solar Winds were the following:
For some peculiar reason Solar Winds copies data from normal RAM to VRAM using the source and target indices and segments opposite to the standard convention. So, instead of the usual x86 way of copying data:
mov cx,<number_of_bytes_to_copy>
rep movsb
which uses CX register as a counter, copies data from DS:SI (Data Segment:Source Index) to ES:DI (Extra Segment:Destination Index), and increments the SI and DI registers automatically, Solar Winds does the copying like this:
loop:
mov al,es:[di]
mov [si],al
inc di
inc si
cmp di,4380
jne loop
That is, Solar Winds copies data FROM destination index TO source index, and then explicitly increments the indices, until the destination index (which means the source position) is at a specified location.
This makes the code run an order of magnitude slower on DSx86 than the REP MOVSB code (which has been optimized to use the ARM block copies), and it also breaks my direct screen access checking (where I only check the ES segment address). Instead of trying to find a workaround to the latter problem, I just switched back to my original blit screen update method (where the real NDS VRAM is updated by copying the whole virtual PC 0xA000 segment data once every VSync (or every other or every fourth). This will be a game-specific configuration option, as it depends on the game whether direct screen access or this blitting method works better.
I suspect Solar Winds uses the SoundBlaster SDK directly for it's music support, especially for the SoundBlaster detection. The detection routine in Solar Winds was VERY thorough, it tested every possible test register and DSP version register before it believed a SoundBlaster exists on the system! I had to code quite a bit of new emulation to make DSx86 pass all these tests. I'll eventually need to revisit this code, as currently it is a bit too Solar Winds -specific.
Solar Winds also used the PC timer differently to all the previous games I have emulated, so I had to add support for the less common timer modes as well.
And obviously there were a lot of new opcodes to support, and still are, as the screen copy above is pretty much as far as I can get in the game currently. But adding new opcodes is much easier than changing an existing hardware emulation.
My Xmas vacation is just starting, so after I get Solar Winds to run properly, I'll concentrate on making the first alpha release version available. DSx86 is still missing quite many features that I think are essential before I can release it, but hopefully I have time to add them all during this two week vacation.
http://dsx86.patrickaalto.com/