DS2x86 version 0.30 released!

It is again time to start a new blog page, as I like to have my blog pages not contain more than half a year's worth of blog posts. Makes it faster for you to read/download the latest entries as well.

DS2x86 v0.30 release notes
This is the first DS2x86 version to use my own completely rewritten transfer system between the MIPS and ARM processors for the DSTwo flash cart. Pretty much nothing in the new transfer code is copied directly from the SuperCard SDK sources. I have used the ideas from their sources, but the actual code is quite completely rewritten. The main differences are that now it is the ARM side that controls when and what data to transfer, the graphics are transferred in the native format of the emulated PC graphics memory and drawn on the ARM9 side, and the AdLib sound is fully generated on the ARM7 side.

I have not had time to implement all the features I had coded for the original transfer system, so not everything is fully working yet. Also, note that there are no compatibility improvements in this version, so if a game did not work in version 0.25, it most certainly will not work in this version either. Rather the opposite, if a game did work on 0.25, it might not work in this version! Here below is a list of features still missing from this version, so any game that needs one or more of these might not work properly:

Exiting to DSTwo menu is not yet supported, so you will need to power off to stop DS2x86. The exit code in the SDK was based on some obsolete devKitPro features, and I haven't studied how to do that with the latest devKitPro yet.
Smooth scaling is not implemented yet. However, the Jitter scaling mode uses the improved jittering algorithm by Sverx, so in the low-resolution modes it will give a result that is very close to the Smooth mode quality.
Graphics transfer in high-resolution modes (640xsomething) will take more time than in the original SDK, and thus the framerate will drop and some tearing might be visible. Improving this would require some extra work on the MIPS side, which would in turn affect the CPU emulation speed.
Hardware mouse cursor is missing, so any game needing that will be unplayable. Also mouse support in general is very poorly tested and might not work correctly.
Some EGA/VGA graphics tricks are not yet supported, so some games might show corrupt graphics.
SoundBlaster digitized audio support is still limited and quite buggy. It works fine in Doom, but that's about it.
AdLib audio buffers all data (notes and tone commands) up to 1/30th of a second, so timing of the music might be somewhat off.

However, there are obviously also some advantages in using the new transfer system. Here is a list of the current advantages, and as I get around to improving the still missing and buggy features, this list will hopefully get longer and the above list will get shorter:

Overall emulation performance is better than with the old transfer system. For example Doom takes only 87% of the time it used to take with the old transfer system (when running the first demo game).
AdLib audio is created on the ARM7 at 32kHz, so it has much better audio quality and also has some (though artificial) stereo effect.
PC Speaker audio is supported, so you will get error beeps etc.
The lower screen (virtual keyboard) is handled fully on the ARM side, so updating it (for example with the blinkin "HDD" indicator) is much faster and does not affect the actual game framerate.
The plugin size is much smaller, as all the graphics blitting code has been moved from MIPS (which needs about two times the amount of code to perform the same task) to the ARM side.
The internal architecture is cleaner, as now there is a clear role for each of the processors.

DS2x86 v0.30 screen blitting speed
The original SDK transfer system always transferred the graphics data using 16-bit color video buffers, so that transferring one screen frame needed 256x192x2 = 98304 bytes to get transferred. Since the card interface runs at 4.2MHz speed, transferring this much data took 23.4 milliseconds, and the frames could be transferred at a maximum speed of 42.7 fps. These numbers are the theoretical maximum, the real speed was somewhat less because of the need to transfer also audio data and various commands.

In the new system I transfer only as much data as is needed, so the amount is usually much less than in the original system, except in the high-resolution modes like 640x480, where I might need to transfer more data per frame than in the original SDK. Also, since the data needs to be transferred in 1024-byte blocks without direct random access, I can not currently skip bytes that are outside of the visible area if the game has set up the graphics memory to have a logical screen width larger than the visible screen width. For example, Commander Keen 4 uses a logical screen width of 1260 pixels in the EGA 320x200 mode during the intro scroller, so that I need to transfer almost 1000 extra pixels for each screen row! This will drop the blitting framerate down to 24 fps, which will cause visible tearing of the screen image. Luckily the game itself uses the normal 320x200 mode.

Here below is a table showing the most common graphics modes, and the maximum (theoretical) frame rate in each of them using the new transfer method:

Mode Original SDK New method Max FPS Notes
80x25 Text 23.4 ms 0.8..4.5 ms >200 fps Depending on changed characters
320x200 CGA 23.4 ms 4.1 ms 244 fps
640x200 CGA 23.4 ms 4.2 ms 238 fps
320x200 EGA 23.4 ms 6.7..40.9 ms 24..149 fps Depending on logical screen width
640x200 EGA 23.4 ms 13.1 ms 76 fps
640x350 EGA 23.4 ms 22.9 ms 43 fps
640x480 VGA 23.4 ms 31.2 ms 32 fps
320x200 MCGA 23.4 ms 13.1 ms 76 fps
360x240 Mode-X 23.4 ms 17.8 ms 56 fps Used in "Settlers"
320x480 Mode-X 23.4 ms 35.0 ms 28 fps Used in "LineWars II"


Future work
For the coming week or two, I plan to still work on the new transfer system, fine tuning it and adding the missing features. First, I hope to come up with a faster way to transfer the screen graphics in the high resolution modes, and in special EGA modes that use a very wide logical screen (like Commander Keen 4 or Supaplex). After that, I need to improve and fix the SoundBlaster audio handling, and then look into the hardware mouse cursor and other mouse features. Also, I can now add all the keyboard-related features (visible upper/lower case changes, key flash when clicked, etc) that are in the original DSx86 but have so far not been possible to implement into DS2x86. I don't plan to work on any game-specific compatibility improvements until I have improved the new transfer system still quite a bit further.

Please report games to seriously misbehave using this new transfer system, or if some core functionality that I have not mentioned above is missing, though! It helps me in improving the new system if I have a list of games to test, so I don't need to guess and hope that my change fixes something. Thanks again for your interest in DS2x86!

http://dsx86.patrickaalto.com/DSblog.html