wraggster
February 17th, 2013, 23:08
via http://rpix86.patrickaalto.com/rblog.html
The last week was spent working on getting rpix86 to the same level as where ax86 currently is. I began the week by changing the CGA and EGA graphics blitting routines to also use the new OpenGL ES2 palette handling system. Since both the CGA and EGA (and also some Mode-X versions) use non-contiguous graphics memory organisation, I decided to still use a separate 256-color off-screen buffer which is then given to the glTexSubImage2D OpenGL routine as input. In the MCGA and SVGA 256-color modes I can use the emulated 0xA000 segment VRAM directly as input for the texture subimage routine, and I also added a system where I can build the texture from two subimages for cases where the Mode-X version uses a LineCounter to split the screen into two areas (like for example in my LineWars II game).
After the graphics modes were implemented I decided to add a screen capture system (so that I can add some pretty pictures to these blog posts, and also to have some screen copies on the Raspberry Pi Store (http://store.raspberrypi.com/) when I eventually release rpix86 there). Here is the first screen capture I took, from the Norton Sysinfo CPU performance test page. The "80486, 53MHz" estimation is based on the division opcode speed, so it does not give a proper overall performance estimate. The performance bar is a better indicator as it actually runs various opcodes using a timer. The speed is around a 80386 40MHz machine, which translates to a 80486 20MHz machine. So not especially fast as my DS2x86 running on a MIPS processor at 396MHz is about as fast. I suspect the Linux operating system itself causes quite a performance hit (in addition to my having to emulate almost everything on a single CPU, while in DS2x86 I was able to divide the emulation chores between 3 separate CPUs).
http://www.dcemu.co.uk/sysinfo.png After I got the screen capture working, I decided to redo my AdLib emulation to be a bit faster. In DSx86 my AdLib routine always calculates all the samples for all the 9 AdLib channels even when the channels are not active. This was not a problem in DSx86, as I used the otherwise idle ARM7 secondary processor to run this emulation. However in rpix86 and ax86 I need to use the main CPU also for the audio emulation, so it would be better to have it use as few CPU cycles as possible. I implemented a simple cycle counter to count the cycles spent in my AdLib emulation, and ran it first without any changes. I used the Silpheed game to test my changes, mainly just because it has pretty nice AdLib music. :-)
The original algorithm used 734.000 CPU cycles to mix and calculate 2048 samples for all 9 channels when no channel was playing audio, and up to 1.000.000 CPU cycles in Silpheed. Each channel consists of two "slots" which both produce a sample, but the first slot is usually used as a phase modulation for the second slot, instead of directly generating audio. So each sample for each slot takes about 27 CPU cycles to create. This number includes also the initial buffer clearing and all envelope and modulation handling, as I put my cycle counting routines around the whole AdLib emulation subroutine.
After some experimentation I found out a way to skip the channels that are not currently active. This is not quite as trivial as it sounds, as there is no "active" flag for the channels. If the virtual "key" (as in a piano key) is turned off, the sound will slowly fade based on the release envelope, so I can not just check whether a key is on and skip a channel if not. Also, if the slot is used as a phase modulation input for the second slot, turning this modulation off too early generates incorrect sound. I used a combination of key off, envelope phase and current volume to determine when it is safe to skip a slot. I managed to get the CPU usage down to 60.500 cycles when no channels are playing, and to around 470.000 cycles in Silpheed. It is not very common that all 18 slots are actually generating sound at any one time during a song, so this slot skipping will help the performance also during music playing.
The next step was to add mouse support, which turned out to be quite easy for rpix86. I haven't yet implemented this in ax86, where I need to use the touch screen system for mouse emulation. In rpix86 I can simply use the real mouse input. Next I will continue working on the still missing features, like floating point support, various graphics operations that are still missing, etc. Here below is a screen capture from Little Big Adventure which I just got working. There are still some small palette problems in it, which I will need to study more closely.
The last week was spent working on getting rpix86 to the same level as where ax86 currently is. I began the week by changing the CGA and EGA graphics blitting routines to also use the new OpenGL ES2 palette handling system. Since both the CGA and EGA (and also some Mode-X versions) use non-contiguous graphics memory organisation, I decided to still use a separate 256-color off-screen buffer which is then given to the glTexSubImage2D OpenGL routine as input. In the MCGA and SVGA 256-color modes I can use the emulated 0xA000 segment VRAM directly as input for the texture subimage routine, and I also added a system where I can build the texture from two subimages for cases where the Mode-X version uses a LineCounter to split the screen into two areas (like for example in my LineWars II game).
After the graphics modes were implemented I decided to add a screen capture system (so that I can add some pretty pictures to these blog posts, and also to have some screen copies on the Raspberry Pi Store (http://store.raspberrypi.com/) when I eventually release rpix86 there). Here is the first screen capture I took, from the Norton Sysinfo CPU performance test page. The "80486, 53MHz" estimation is based on the division opcode speed, so it does not give a proper overall performance estimate. The performance bar is a better indicator as it actually runs various opcodes using a timer. The speed is around a 80386 40MHz machine, which translates to a 80486 20MHz machine. So not especially fast as my DS2x86 running on a MIPS processor at 396MHz is about as fast. I suspect the Linux operating system itself causes quite a performance hit (in addition to my having to emulate almost everything on a single CPU, while in DS2x86 I was able to divide the emulation chores between 3 separate CPUs).
http://www.dcemu.co.uk/sysinfo.png After I got the screen capture working, I decided to redo my AdLib emulation to be a bit faster. In DSx86 my AdLib routine always calculates all the samples for all the 9 AdLib channels even when the channels are not active. This was not a problem in DSx86, as I used the otherwise idle ARM7 secondary processor to run this emulation. However in rpix86 and ax86 I need to use the main CPU also for the audio emulation, so it would be better to have it use as few CPU cycles as possible. I implemented a simple cycle counter to count the cycles spent in my AdLib emulation, and ran it first without any changes. I used the Silpheed game to test my changes, mainly just because it has pretty nice AdLib music. :-)
The original algorithm used 734.000 CPU cycles to mix and calculate 2048 samples for all 9 channels when no channel was playing audio, and up to 1.000.000 CPU cycles in Silpheed. Each channel consists of two "slots" which both produce a sample, but the first slot is usually used as a phase modulation for the second slot, instead of directly generating audio. So each sample for each slot takes about 27 CPU cycles to create. This number includes also the initial buffer clearing and all envelope and modulation handling, as I put my cycle counting routines around the whole AdLib emulation subroutine.
After some experimentation I found out a way to skip the channels that are not currently active. This is not quite as trivial as it sounds, as there is no "active" flag for the channels. If the virtual "key" (as in a piano key) is turned off, the sound will slowly fade based on the release envelope, so I can not just check whether a key is on and skip a channel if not. Also, if the slot is used as a phase modulation input for the second slot, turning this modulation off too early generates incorrect sound. I used a combination of key off, envelope phase and current volume to determine when it is safe to skip a slot. I managed to get the CPU usage down to 60.500 cycles when no channels are playing, and to around 470.000 cycles in Silpheed. It is not very common that all 18 slots are actually generating sound at any one time during a song, so this slot skipping will help the performance also during music playing.
The next step was to add mouse support, which turned out to be quite easy for rpix86. I haven't yet implemented this in ax86, where I need to use the touch screen system for mouse emulation. In rpix86 I can simply use the real mouse input. Next I will continue working on the still missing features, like floating point support, various graphics operations that are still missing, etc. Here below is a screen capture from Little Big Adventure which I just got working. There are still some small palette problems in it, which I will need to study more closely.