|
August 1st, 2011, 23:01 Posted By: wraggster
via http://dsx86.patrickaalto.com/DSblog.html
This is mainly just a quick fix version, to fix some issues in the 0.20 version with a few more FPU opcodes implemented. The new FPU opcodes are fsincos, fptan, fprem, fyl2x, f2xm1 and fscale. The first three I have not tested properly yet, so those might have some bugs. The last three I have tested so they at least should work properly.
At least two new games seem to be runnable (or at least startable) in this version, Abuse and Comanche. Abuse needed just a few more FPU opcodes implemented to start running. Comanche however had some more problems:
It went into a weird 640x240 graphics mode. This turned out to actually be a 320x240 tweaked Mode-X, but the game went into this mode by first going into the VGA 640x480 16-color mode, and then just setting the bit in the mode register that selects between 256-color and 16-color modes. My graphics mode detection code did not check for this bit after the original mode change had occurred, so it stayed in 16-color mode and thus the graphics were completely corrrupt. I added a check for this bit into the 640x480 16-color mode handling, so now Comanche uses the correct graphics mode.
Comanche also took a very long time to start (while it started immediately in DOSBox) and ran very slowly. This was caused by a broken PC timer #2 handling in DS2x86. The normal interrupt timer #1 worked correctly, but the secondary timer (which is rarely used for other things besides the PC beeper sounds, which are not yet supported in DS2x86) only worked with the default 18.2Hz speed, all other speed options caused weird behaviour. I fixed that (for at least the most common timer modes), and now Comanche starts up properly. This might have caused weird slowdowns in some other games as well.
There were also some very rare opcodes missing and some VGA palette issues with Comanche, which I also fixed. The problem with the palette was caused by the game being in 16-color mode while it sets up the 256-color mode palette. Hopefully my change to this behaviour did not break any real 16-color games.
I also found that the old Wing Commander Armada CD-version game I have on my bookshelf is actually the DOS version, so I installed that using DOSBox and copied it to my SD card and tested running it in DS2x86. I got an error message "EMS driver is not VCPI compliant", so I will probably next add the VCPI features to the emulated EMS driver, if that turns out not to be a big issue. Even though the game recommends using a 486/33 machine, it has the option to only play the turn-based strategy parts of the game, which should work fine even on a slower machine.
The bigger issue I need to work on pretty soon is the virtual memory support. I need to figure out a way to implement this in such a way that it does not slow down all existing memory access. This is the most difficult part of implementing the virtual memory, and this is why I haven't implemented it yet. I do have some ideas, so I'll start experimenting with this issue in the near future.
My summer vacation ends today, so I will get back to the normal two-week release cycle, as I don't have all that much time to work on DS2x86 (or DSx86) during workdays. Thanks again for your continued interest in this project, and for the debug logs and other bug reports you have been sending!
Download Via Comments
For more information and downloads, click here!
There are 0 comments - Join In and Discuss Here
|
|