DCEmu Featured News Articles

DSx86 fixes
Last week I did not have any time to work on DSx86, as I had various work-related things to do and also other "real life" issues that I had postponed during my summer vacation. Yesterday I finally began working on DSx86 again, and found the bug that caused the memory error in Maupiti Island. I had coded a shortcut for the memory allocation routines when launching an EXE program, and my shortcut did not handle the EXE header MaxAlloc field properly, it always allocated the maximum amount of memory. Normally all programs want the maximum amount of memory, but the TSR program in Maupiti Island was the first program that had the required amount of memory in the EXE header and did not adjust the memory allocation itself. After I fixed that routine the game loaded fine and seems to work.


I was also requested via email to look into a screen resolution problem in a game called Mahjong Fantasia. I noticed that it went to 640x200 screen mode, but still wanted to display 400 lines. There is no screen mode preset for 640x400 resolution, so the game accessed the CRTC registers directly. I enhanced my VGA emulation so that the vertical resolution is no longer tied to the current screen mode, but instead it is determined by the CRTC register values (like in DOSBox). This might cause problems in some games, but most likely it will work better than the mode-based resolution detection. At least Mahjong Fantasia began to display a correct resolution, and also Gods (another game that accesses CRTC registers directly) still works.

I have also added some simple missing EGA and Mode-X opcodes based on the debug logs I have received, again thanks for those! Other things on my TODO list I have not yet looked into, but at least the above mentioned improvements will be in the upcoming 0.23 version.

SuperCard DSTwo SDK betatesting
Several DSx86 users sent me email letting me know that SuperCard are giving a beta version of their DSTwo SDK to selected homebrew coders. So, I decided to contact SuperCard and request the beta version of the SDK. They accepted me to their beta test program (thanks SuperCard!) and sent me the SDK. I don't have the actual DSTwo card itself (which they also will send me) yet, so I can not properly test the SDK until I receive the card as well. However, I can start porting DSx86 to it immediately, and this is what I began doing yesterday.

The first problem was that the SDK (or rather the mipsel-linux toolchain that it uses) is meant to be run on Linux, and I have only Windows machines. This turned out to not be a major problem, though, as running VirtualBox on my Windows XP machine and installing Ubuntu Linux on it allowed me to install the SDK and compile the libraries and examples fine. I am familiar with the Linux command line tools, but I have actually never used the Linux graphical UI, which however seems to be reasonably similar to Windows so I am not totally lost with it. :-)

There does not seem to be any major problems compiling the C and C++ source codes, but obviously I need to write the ASM parts pretty much from scratch for the MIPS architecture. It will be interesting to study another new hardware architecture, and the MIPS architecture seems to be very different from ARM, even though they both are RISC processors. What little I have found out so far about the MIPS architecture compared to ARM is this:

MIPS has 32 general-purpose registers (while ARM has only 16). This will make it easy to keep all the x86 general purpose registers (only 8 of them) in the CPU registers, and still have a lot of extra registers for the emulator-specific stuff.
MIPS is luckily little-endian, same as ARM (as used in Nintendo DS) and the x86 architecture.
There are no CPU flags in MIPS! This is a bit strange, and will force me to use the "lazy flags" method of handling the emulated flags. This will slow down the code, but on the other hand it will allow me to emulate the Parity and Auxiliary Carry flags of x86 properly.
No free shifts and rotates in MIPS. This has been a cool feature in the ARM processor, so now I have to un-learn all these tricks with shifted register values. MIPS has 16-bit immediate values, though, so many ARM tricks are not actually needed on MIPS.

My working on the MIPS port of DSx86 will of course take time away from improving the current DSx86, but I think DSx86 is already working reasonably well as it is. Many games still need fixing and there are many general improvements that could be made, but I can continue working on these even while I concentrate on the DSTwo SDK testing. SuperCard probably expects me to actually work with their SDK, or they would not have sent it to me. I think I owe it to them to test it properly and report the possible problems and enhancement ideas I find when trying to port DSx86 to run on DSTwo.

With the DSTwo version of DSx86 (currently named "DS2x86" :-) I plan to support 386