Category: <b>Nintendo DS</b><br><br>Pate has posted a new release of his Dos Emulator for the DS and those with the Supercard DSTwo Flash Cart which enables more ram for the emulator and thus makes supporting more Dos Games much more likely:
This version has a lot of new protected mode opcodes supported, based on the debug logs you have been sending. Thanks again for those! This version might now run a few more 386-specific games, for example I have been able to make Warcraft: Orcs & Humans start up into the actual game. Every now and then it fails with an unsupported I/O port, which seems to be caused by the game sometimes detecting the SoundBlaster as using DMA channel 3, while in reality it uses DMA channel 1. I suspect there are still some rather serious problems in my audio handling.
I have also made some minor performance improvements, the things mentioned in my previous blog post, and I also moved the temporary variables used by the Mode-X graphics mode opcodes into the small data segment which is accessed by the GP register. This makes the Mode-X graphics handling (as used in Doom, for example) slightly faster.
While making the performance improvements, I again ran into the weird keyboard reading problem I originally fought with at the beginning of this year. After various tests I was able to determine that when I used the new improved Mode-X code (which was slightly smaller), the keyboard behaved very erratically, but going back to the original slightly larger Mode-X code got rid of the problem! The weird thing is that this problem happens immediately in the 4DOS prompt, when none of the changed Mode-X routines have even been run yet!
So, in the end I had to add 1000 bytes of filler at the end of the Mode-X graphics code to make the keyboard reading work properly! This obviously makes absolutely no sense, and I will remove the extra filler bytes as soon as I can figure out what the real problem is. It seems like some sort of alignment problem in the DS2 SDK code that handles the communication between the ARM side and the MIPS side, but that is just a theory and without knowing the internals of the communications code I have no way of properly testing this theory.
I haven't been able to handle all the issues mentioned in the debug logs yet, but many games should at least progress further. Please send me the new debug logs again for this version, and I'll again try to implement as many fixes as possible to the next version.
This version has a lot of new protected mode opcodes supported, based on the debug logs you have been sending. Thanks again for those! This version might now run a few more 386-specific games, for example I have been able to make Warcraft: Orcs & Humans start up into the actual game. Every now and then it fails with an unsupported I/O port, which seems to be caused by the game sometimes detecting the SoundBlaster as using DMA channel 3, while in reality it uses DMA channel 1. I suspect there are still some rather serious problems in my audio handling.
I have also made some minor performance improvements, the things mentioned in my previous blog post, and I also moved the temporary variables used by the Mode-X graphics mode opcodes into the small data segment which is accessed by the GP register. This makes the Mode-X graphics handling (as used in Doom, for example) slightly faster.
While making the performance improvements, I again ran into the weird keyboard reading problem I originally fought with at the beginning of this year. After various tests I was able to determine that when I used the new improved Mode-X code (which was slightly smaller), the keyboard behaved very erratically, but going back to the original slightly larger Mode-X code got rid of the problem! The weird thing is that this problem happens immediately in the 4DOS prompt, when none of the changed Mode-X routines have even been run yet!
So, in the end I had to add 1000 bytes of filler at the end of the Mode-X graphics code to make the keyboard reading work properly! This obviously makes absolutely no sense, and I will remove the extra filler bytes as soon as I can figure out what the real problem is. It seems like some sort of alignment problem in the DS2 SDK code that handles the communication between the ARM side and the MIPS side, but that is just a theory and without knowing the internals of the communications code I have no way of properly testing this theory.
I haven't been able to handle all the issues mentioned in the debug logs yet, but many games should at least progress further. Please send me the new debug logs again for this version, and I'll again try to implement as many fixes as possible to the next version.