DSx86 version 0.43 released!

[Alastor]

DSx86 is a PC emulator for Nintendo DS. It's purpose is to allow you to run old DOS games on your Nintendo DS game console. DSx86 is the winner of GBATemp's Homebrew Bounty 2011 competition.

http://dsx86.patrickaalto.com/

July 1st, 2012 - DSx86 version 0.43 released!

Okay, here is the new fixed version of DSx86, which has the problems I mentioned in the previous blog post fixed. A couple of the problems were actually not in DSx86 but in the tester program, so this list is a little bit different to the list in the previous blog post. Anyways, here are the changes:

-Opcode adc used ARM assembler adc operation instead of add in address calculations. This was a simple copy-paste bug. When I originally (almost three years ago!) implemented the adc opcode, I simply copied the whole already existing add opcode handler, pasted it, and used find-replace to rename it to adc. This of course then also replaced the add opcode I used in the address calculation! However, this was just a cosmetic problem, as all the addresses are shifted right 16 bits after the addition, and the low 16 bits are originally zero, so this minor problem has not caused any actual errors.
-BCD opcodes (daa, das, etc) did not work properly. Now they should work better, however since DSx86 does not support the Adjust Flag, they still probably do not work exactly correct.
-Oveflow flag handling fixed in ADC and SBB opcodes. See my previous blog post for more information about this issue.
-Fixed flags handling in opcodes repne cmpsb and repne scasb when CX == 0. My code for repne prefix is a bit different to the repe prefix, but I had not taken this into account when the input CX register value is zero (meaning that those opcodes should not do anything). In the repe version the caller has saved the flags, but in the repne version the opcodes themselves need to save/restore the flags, but this code was missing. If the opcodes actually did anything (CX != 0), then they behaved correctly as the flags will always change in that situation.
-Fixed [bp+di+disp8] address calculation in several protected mode opcodes. This was probably the most serious issue I found. It affected many protected-mode-specific opcodes, like lldt, ltr, verr, verw, sgdt, sidt, lgdt, lidt, smsw, lmsw, and also the protected mode versions of les, lds, call and jmp. So, this fix might actually make some protected mode games/software (like Windows) work better.
-Opcodes lidt and lgdt did not clear the highest byte of the 32-bit base address. Since the 80286 processor can access only 16MB of RAM, these opcodes should clear the higher bits when they load a 32-bit memory address into some DSx86 internal variables. This probably caused no harm as the highest byte should have been clear anyways.
-Opcodes lar and lsl did not handle selector type 0 correctly. The case for selector type 0 was simply missing from the different cases for various selector types. This again probably caused no harm, but now all cases are handled properly.
-The Lords of Doom game seems to push EGA VRAM values directly to stack (based on some crash reports I had received). I had tried to implement this some time ago, but now I noticed that I had made a mistake in the register saving/restoring, so that the opcode handler wrote the value in some completely different memory area, possibly even crashing DSx86. This is now fixed.
-Fixed mouse scaling in proportional font 80x25 text mode. This is an additional last minute fix, thanks to sverx for pointing out this problem!

My summer vacation is starting now, so I should now have more time to work on DSx86 and DS2x86. I am still working on getting Windows 3.11 running in DS2x86, but I am somewhat stuck with it. I need to compare the behaviour to DOSBox, which is rather tedious and time-consuming work. But, I hope to now finally get some progress done with that, as I can focus on it properly. In any case, thanks again for your interest in DSx86 and DS2x86!