DS2x86 progress

November 15th, 2011, 13:29 Posted By: wraggster

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

For the past week I have mostly been just studying the DSTwo SDK sources. I have not made much changes to DS2x86 yet, but I have been thinking of ways to improve the data transfer, and I have also been cleaning up the interface code that transfers the data between the MIPS side and the ARM side. I think I now have a rudimentary understanding of how the system works, so I can finally start changing it. The problem with these changes is that they will make DS2x86 not run properly for quite a long time, as I need to change a lot of the core functionality.

I plan to make several major changes to the data transfer interface, with the most notable changes being the following:

1. The lower screen keyboard handling moved completely to the ARM side. This will make the resulting file smaller, as I only need to use a 4bpp (16-color) version of the keyboard image instead of the 16bpp version that DS2x86 currently uses. Also, changing any config texts required me to send the whole 256x192x2 byte image from MIPS to ARM. This is already mostly working, except the HDD led functionality is still missing, and I still need to completely redo the debug screen handling (and the BSOD system). I also plan to add the keyboard key color change when you press a key (as in DSx86), as I can now handle that similarly to DSx86.
2. I also plan to transfer the top screen data directly from the x86 emulated data (which can be in various formats depending on the graphics mode, anything between 1bpp and 8bpp). Until now I have had to convert and copy this data into the 256x192 16bpp buffer that the DSTwo SDK can then send to the ARM side. All of this converting and copying has taken time from the CPU emulation. The actual transfer uses DMA, so it should not take much time away from the CPU emulation any more. I have just today began experimenting with this, by sending the 32KB text mode data (from x86 address B800:0000) to the ARM side, and having the ARM side then convert and write this data to the actual ARM VRAM using the 6x8 font. This seems to work in principle, I am just having some palette-related problems with that currently. Of course I would not absolutely need to copy more than 80x25 (or even only 42x25 if I really wanted to minimize the transfer size) characters in text mode, but even the 32KB is much less than the 256x192x2 = 96KB that the original method required. And, if I were to use code to select the amount of data to be sent on the MIPS side, I would lose some of the speed of simply letting the DMA system send the whole 32KB memory area.
3. The next big change is that I would like to do is to let the ARM side command the screen copying. The original DSTwo SDK method is such that the MIPS side commands everything, the ARM side just waits for commands and then executes them. I would prefer the ARM side to use the VBlank interrupt to make the MIPS side start sending the screen data, so that I could keep the data sending synced to the actual VBlank interval. Until now I have used a timer on the MIPS side that tries to emulate the VBlank interval, but using the actual VBlank interval would make more sense. This change would switch the MIPS/ARM master/slave relationship upside down, so I'm not sure how much work this would mean and if it would work in practice.
4. After the screen handling is done, I need to look into the audio handling. AdLib emulation should be simple as it is not so timing critical and sends very little data, but the SoundBlaster digitized DMA audio is more difficult. It needs two-way data transfer, as the emulated DMA registers on the MIPS side should be updated as the data buffer gets played on the ARM7, so this is something that I still need to spend some time thinking about. I have some ideas, but I need to first see about how I can get the video side working before I can then start working on the audio system.

There are 0 comments - Join In and Discuss Here