wraggster
December 27th, 2009, 16:54
Pate has posted more WIP news concerning his DOS emulator for the DS:
Well, this last week has been somewhat slow progress with DSx86, with the Christmas and all. I have however managed to code some necessary enhancement that are needed for the release, like configuration file handling (with the possibility to have game-specific key mapping and screen update methods) and crash logging to a file on the SD card. I have also added a lot of opcodes needed by the 4DOS help system and the example btm file. This still needs some work, though.
Solar Winds has been a real trouble maker recently. The first major problem was that it seemed to jump into a memory address that did not contain code (the area was full of zeroes) occasionally. When I later noticed that this happens every time I tried to fire the weapon, I began debugging this problem to see what was happening.
Pretty soon I discovered that the problem is that one of the SoundBlaster driver jump addresses point to non-existing code, but what was strange was that it pointed there even at the very start of the game, and no code ever changed this address! I ran Solar Winds in a debugger inside DOSBox to see what is going on, and in there the jump address is the same invalid address at the start of the game, but then when I fire a cannon the address has magically changed into a valid address!
It was pretty difficult (and took me two days) to find out what was really happening here, but I finally noticed (in DOSBox) that the jump address changes when a certain byte is written to the SoundBlaster DSP Command port! After some more studying I found out that Solar Winds uses a rather poorly documented SoundBlaster DSP command, that DOSBox sources call "Weird DMA identification write routine". As good a name as any, I suppose. This command uses the SB DMA channel to write one byte to the PC RAM, which is calculated in a complex way from the byte that is written to the DSP. Solar Winds SB driver uses this method to update the invalid jump address in it's jump table to a valid value! Why it does this, I have no idea. Perhaps just to make life hard for emulator coders!
I managed to code a similar routine to DSx86, and now the jump table gets a correct address and firing the weapon works. But, it only took me a few minutes of testing further to find the next big problem. When firing at another ship, Solar Winds uses an ADPCM -packed sound file that it tries to send to SB for playing. The problem is, DSx86 does not support ADPCM sound files yet. This is yet another big new feature that I need to add for Solar Winds.
I'm not yet sure when I get the first DSx86 alpha version released, but I still have a week of vacation time left, so we shall see whether that is enough time for me to finish the most important enhancements still remaining. There are also quite a few bugs still in the code, but I doubt I will be able to fix all the bugs in the next couple of days, so the first release will be buggy. Isn't this actually the way Alpha releases should be? :-)
http://dsx86.patrickaalto.com/
Well, this last week has been somewhat slow progress with DSx86, with the Christmas and all. I have however managed to code some necessary enhancement that are needed for the release, like configuration file handling (with the possibility to have game-specific key mapping and screen update methods) and crash logging to a file on the SD card. I have also added a lot of opcodes needed by the 4DOS help system and the example btm file. This still needs some work, though.
Solar Winds has been a real trouble maker recently. The first major problem was that it seemed to jump into a memory address that did not contain code (the area was full of zeroes) occasionally. When I later noticed that this happens every time I tried to fire the weapon, I began debugging this problem to see what was happening.
Pretty soon I discovered that the problem is that one of the SoundBlaster driver jump addresses point to non-existing code, but what was strange was that it pointed there even at the very start of the game, and no code ever changed this address! I ran Solar Winds in a debugger inside DOSBox to see what is going on, and in there the jump address is the same invalid address at the start of the game, but then when I fire a cannon the address has magically changed into a valid address!
It was pretty difficult (and took me two days) to find out what was really happening here, but I finally noticed (in DOSBox) that the jump address changes when a certain byte is written to the SoundBlaster DSP Command port! After some more studying I found out that Solar Winds uses a rather poorly documented SoundBlaster DSP command, that DOSBox sources call "Weird DMA identification write routine". As good a name as any, I suppose. This command uses the SB DMA channel to write one byte to the PC RAM, which is calculated in a complex way from the byte that is written to the DSP. Solar Winds SB driver uses this method to update the invalid jump address in it's jump table to a valid value! Why it does this, I have no idea. Perhaps just to make life hard for emulator coders!
I managed to code a similar routine to DSx86, and now the jump table gets a correct address and firing the weapon works. But, it only took me a few minutes of testing further to find the next big problem. When firing at another ship, Solar Winds uses an ADPCM -packed sound file that it tries to send to SB for playing. The problem is, DSx86 does not support ADPCM sound files yet. This is yet another big new feature that I need to add for Solar Winds.
I'm not yet sure when I get the first DSx86 alpha version released, but I still have a week of vacation time left, so we shall see whether that is enough time for me to finish the most important enhancements still remaining. There are also quite a few bugs still in the code, but I doubt I will be able to fix all the bugs in the next couple of days, so the first release will be buggy. Isn't this actually the way Alpha releases should be? :-)
http://dsx86.patrickaalto.com/