Pate has posted some new WIP News of his excellent Dos emulator for the Nintendo DS, heres whats posted:
The past week I have been focusing on fixing bugs that make some games behave erratically. I have also added many missing opcodes based on the debug logs you have been sending, thanks for those! I have downloaded various games that seem to have some more severe problems, and have been debugging and testing those. Oh, and I also noticed that my version of Windows 2.03 had been hacked to run on DOS versions above 4.00, which is why it runs fine here, but if you use the original version it won't run in your DSx86. Sorry about that.
The next version of DSx86 will have several new built-in commands:
VER command can have a parameter to change the reported DOS version number, like "VER 4.00" or "VER SET 4".
SETVER command works like VER command with a parameter.
LOADFIX command can be used to launch games that otherwise would give "Packed file corrupt" problems. This still does not seem to work for games that consist of several executables. I hope to get this working as well. However, this fixes also the unsupported opcode problem in Jimmy White's Whirlwind Snooker.
DEBUG command can be used to start the game and immediately go to the debugger. That is mainly for my own use.
So, Windows 2.03 should run properly in the next version if you give "VER 4" command before "WIN". Or, if you want to make Windows 2.03 run in the current DSx86 0.12, you can also hack it yourself. This is what the DOS FC /B command reports for my hacked version:
Comparing files WIN200.BIN and ..\WIN2\WIN2\WIN200.BIN
0000A926: EB 76
That is, if you replace the byte 0x76 at offset 0xA926 with byte 0xEB, Windows 2.03 will run on DOS versions above 4.00.
Last Thursday was a holiday, so I spent it working on DSx86. I had gotten Microsoft Flight Simulator 3 mostly working, but it had a problem where it never cleared the previous position of the instrument panel needles, so that the instruments got full of the needle images after a little while. I debugged and debugged this problem, compared the drawing between DSx86 and DOSBox for hours! At some point it looked like the EGA Read Mode 1 was not working properly, but I had just fixed this in the previous version, so I ignored that and looked for the problem elsewhere. After almost 6 hours(!) of debugging, I finally got to a point where the problem could not sensibly be anywhere else than in the EGA Read Mode 1 handling. And when I finally figured it out, it was one of those hit-your-head-with-your-palm moments: When I did the Read Mode 1 handling fix, I had fixed the 8-bit version, but forgot that I had a separate 16-bit code version, which also had the same problem! So, if you are a programmer, don't copy the same code for two different routines like I did, but make it a separate function, or at least a macro!
Well, after this fix FS3 seems to be working fine now. It is one of the nostalgic games for me, as way back when I had an Amstrad PC1640 (which was not quite fast enough to run it) my father had a laptop with a 286 processor, so I used to play FS3 on his machine whenever he did not need his PC for something more useful. :-)
This weekend I have continued studying games that behave erratically. I know I have sort of promised to improve the mouse features and possibly implement better scaling functions for the next version, but I have been somewhat distracted by these misbehaving games. I find it more interesting finding problems in my core emulation code than adding or improving features that already mostly work. I'll try to focus on these mouse and scaling issues during the next weekend before I release the next version.
Couple of other games that had mostly graphics problems are Star Control 2 (which had a wrong palette) and God of Thunder which displayed a garbled title screen and had graphics issues in the game itself (after I had added the missing graphics opcodes). The palette problem in SC2 was caused by it using the VGA Palette Read Index register to setup the VGA Palette Write Index! I only noticed from the DOSBox sources that the read index actually affects the write index as well. So, now the palette is OK in SC2 intro.
God of Thunder in turn used several different Mode-X modes, for example the title image uses mode 320x400, for which I hadn't coded support for the VGA Offset register (as the game actually sets the screen up as 328x400 pixels). The main game screen uses 320x240 mode, where I had a bug in the VGA Line Compare Register handling so that the split screen handling (the lower part with the health etc) did not work properly but showed a copy of the top of the actual game area. These both will be fixed in the next version. To keep the aspect ratio somewhat sensible I actually prescale the 320x400 screen down to 320x200 when displaying it (which is why the title screen image below is smaller than the game image).
I am currently looking into problems in Abandoned Places and Jumpman 2, which both attempt to execute data instead of code. I haven't yet figured out the problem, but as this type of a problem is pretty severe and can affect various games, I really want to get this fixed. After those fixes I'll probably start working on the mouse support and scaling stuff.
http://dsx86.patrickaalto.com/DSblog.html
