via http://dsx86.patrickaalto.com/

Version 0.25 Release Notes

First off, sorry for the stupid bug that crept into the previous version. I copied some paging-enhancements to several string opcodes, and forgot to change the jump address in one of the code clips I copied, so that when the game tries to move unaligned 16-bit values in memory, it actually jumps to a code that moves 32-bit values. This means that too much data is copied, overwriting something in memory, which in turn causes either erratic behaviour or in many cases a blue screen crash. I use Doom as my sanity-check game, and always test that I haven't broken the code completely before release by running it for a while. However, Doom did not happen to use this unaligned memory copy, so I did not find this problem before the release.

All in all, this version is mostly just a maintenance version and has the following improvements:
  • Fixed a copy-paste bug in REP MOVSW string opcode (as mentioned above). This fixes the BSOD in Heretic, Hexen, and various problems in many other games.
  • Implemented INT10 calls AX=1008 (READ OVERSCAN (BORDER COLOR) REGISTER), AH=12/BL=34 (ALTERNATE FUNCTION SELECT (VGA) - CURSOR EMULATION), AH=F1/DX=0020 (EGA Register Interface Library - WRITE ONE REGISTER - Miscellaneous Output register), AH=F1/DX=0028 (EGA Register Interface Library - WRITE ONE REGISTER - Feature Control register).
  • Implemented missing 66-prefix variations for LFS and LGS opcodes (NORM).
  • Implemented missing RCL and RCR opcodes using 32-bit registers (SWS).
  • Implemented read/write to/from CPU debug registers (RAYMAN).
  • Enabled directory access using the alias of a long directory name. I had to hack into the DSTwo SDK directory.c source to enable this. I compared the source with the current NDS libFAT sources (which it is based on), and found a difference. In the DSTwo SDK version the check if the directory alias (the short 8.3 version of the long name) matches the requested directory name was simply commented out. I have no idea why, and hopefully my re-enabling this feature does not cause any new problems in file and directory handling. It is always rather scary changing the low-level file access library functions.
  • Ignore writes to I/O ports 0x140..0x14F (DESCENTR).
DSTwo SDK v1.2 released, with full source!

I got a very interesting email early Saturday morning, letting me know that SuperCard has released DSTwo SDK v1.2! This turned out to be a major thing, as they have now finally released the full source code, including the Nintendo DS side! This opens a lot of new possibilities when working with the SDK, the most imediately interesting to me is the possibility of moving my AdLib emulation from the MIPS side to the ARM7 side. This would make the actual CPU emulation run faster, and would also decrease the amount of data that needs to be transmitted between the processor. In the long term it might also be possible to move the bottom screen (keyboard) handling to the ARM9 side, or perhaps even moving everything besides the CPU emulation away from the MIPS processor! It would be very cool if the ARM9 would handle the full VGA emulation and ARM7 the full SoundBlaster emulation, with the MIPS side simply feeding them data in the original format of the x86 hardware!
However, there is a problem in compiling this source code, as it looks to have been built with an ancient DevKitPro r17 (the current version is r36). I haven't been able to locate this old version, so if you happen to know where to get it please let me know! Of course it would be best to update the SDK parts so that it could be compiled with the latest DevKitPro, but even to do that it would be very important to have the r17 source code to be able to distinguish between differences in the DevKitPro versions and the actual code needed by the DSTwo SDK.
The source code is not very well commented either, so it will take a while to decipher what each of the function does and how the data is actually transferred, but I am very much looking forward to changing the DS2x86 architecture to take advantage of the new possibilities. This is so interesting that I will probably put the paging features and such on hold and switch my focus to taking better advantage of the SDK. This might mean a few week's break until I release the next version, but hopefully this 0.25 version has no major new problems.