wraggster
February 25th, 2013, 20:45
via http://ax86.patrickaalto.com/ablog.html
The week after my previous ax86 blog post was spent mostly getting rpix86 up to the ax86 level. During the last week I have then been working on both rpix86 and ax86, mostly fixing bugs in either one of them. During the previous weekend I noticed that my AdLib audio emulation did not work correctly on ax86, for example in Leisure Suit Larry 3 the intro music did play fine, but then there was only intermittent audio during the actual game. When I was debugging this I suddenly noticed that I had forgotten to adjust the modulation levels to take into account the sample volume levels that are lower than in DSx86 (this lower volume level is needed for the software channel mixing)!
After I adjusted the modulation volumes, the audio began to sound much better on rpix86, but still there was the problem of missing notes on ax86. I made all sorts of tests but still did not manage to find the cause, until I then finally decided to test the exact same AdLib emulation code (slightly optimized for ARMv6) in ax86 that I used in rpix86. It did play the audio correctly! So, the problem was obviously in some of my non-ARMv6 code, and now that I had only a very limited amount of code to check, I finally found the problem. One of the sample loops mixed the audio properly in the ARMv6 code, but simply overwrote the samples in the ax86 code! This was relatively easy to fix, so now the AdLib audio works correctly in both versions.
The next problem was that rpix86 (which uses the OpenGL ES 2.0 vertex and fragment shaders for palette handling) did not seem to show all palette values correctly. I compared the same DOS games between ax86 and rpix86, and was able to determine that the problem is indeed in the shader code, since ax86 did show the palette correctly. After some adjustments (hacking, to be honest, as I am still very unfamiliar with the shader language) I managed to get the palette values to get converted correctly, so that both ax86 and rpix86 both display the same colors, even though one uses hardware and the other software to handle the palette lookup.
Next, I worked on switching the text mode to use 8x16 pixel character font also in ax86. I had used the original 6x8 chanacters from DSx86 in ax86, and the better looking 8x16 fonts only in rpix86. My eventual goal is to have ax86 adjust the character size based on the physical Android device screen properties, but for now I am using the 8x16 fonts (meaning the text mode screen is 640x400 pixels) always in both versions of my emulator.
This Saturday I then began working on one of the remaining major issues, Sound Blaster digital audio emulation. I am porting the routines from an old version of DS2x86 (which still used the original DSTwo data transfer system) as I need to have somewhat similar buffering scheme. I am also using parts of the DSx86 code, as it is written in ARM assembly instead of MIPS assembly in DS2x86. So, in effect I am combining the algorithms from DS2x86 with the actual code from DSx86. :-)
I already managed to get the easiest digital audio mode, simple one-shot DMA output, working on Saturday. I used Supaplex and my own LineWars II to test this, and both of those games now play audio fine. It was nice to again hear the original music by u4ia in my LW2. :-)
Today I have been working on getting the auto-init DMA system working. This is considerably harder, as it is very timing-critical to not get buffer underflows or overflows, and still make the emulated game think that the audio runs at some quite different speed to what the actual hardware is playing the audio buffers at. I am using Doom for these tests, as I am familiar with how it works (it plays a 4096-sample buffer at 11.1kHz, with an IRQ request after every 128 samples have been played). Converting this to my double-buffered 2048-sample buffers running at 32kHz is somewhat difficult, and I have not yet managed to get it working perfectly. It does already play recognizable audio, but it still has some stuttering and occasional skipping.
During the next week I will continue with the audio features, for example all the ADPCM digital audio formats are still missing. Then the most essential features have been implemented, so I will just need to spend some more time testing and creating some configuration options and settings, before I could release the first beta version. I don't think floating point support is essential for the first beta, as not very many DOS games use floating point operations.
The week after my previous ax86 blog post was spent mostly getting rpix86 up to the ax86 level. During the last week I have then been working on both rpix86 and ax86, mostly fixing bugs in either one of them. During the previous weekend I noticed that my AdLib audio emulation did not work correctly on ax86, for example in Leisure Suit Larry 3 the intro music did play fine, but then there was only intermittent audio during the actual game. When I was debugging this I suddenly noticed that I had forgotten to adjust the modulation levels to take into account the sample volume levels that are lower than in DSx86 (this lower volume level is needed for the software channel mixing)!
After I adjusted the modulation volumes, the audio began to sound much better on rpix86, but still there was the problem of missing notes on ax86. I made all sorts of tests but still did not manage to find the cause, until I then finally decided to test the exact same AdLib emulation code (slightly optimized for ARMv6) in ax86 that I used in rpix86. It did play the audio correctly! So, the problem was obviously in some of my non-ARMv6 code, and now that I had only a very limited amount of code to check, I finally found the problem. One of the sample loops mixed the audio properly in the ARMv6 code, but simply overwrote the samples in the ax86 code! This was relatively easy to fix, so now the AdLib audio works correctly in both versions.
The next problem was that rpix86 (which uses the OpenGL ES 2.0 vertex and fragment shaders for palette handling) did not seem to show all palette values correctly. I compared the same DOS games between ax86 and rpix86, and was able to determine that the problem is indeed in the shader code, since ax86 did show the palette correctly. After some adjustments (hacking, to be honest, as I am still very unfamiliar with the shader language) I managed to get the palette values to get converted correctly, so that both ax86 and rpix86 both display the same colors, even though one uses hardware and the other software to handle the palette lookup.
Next, I worked on switching the text mode to use 8x16 pixel character font also in ax86. I had used the original 6x8 chanacters from DSx86 in ax86, and the better looking 8x16 fonts only in rpix86. My eventual goal is to have ax86 adjust the character size based on the physical Android device screen properties, but for now I am using the 8x16 fonts (meaning the text mode screen is 640x400 pixels) always in both versions of my emulator.
This Saturday I then began working on one of the remaining major issues, Sound Blaster digital audio emulation. I am porting the routines from an old version of DS2x86 (which still used the original DSTwo data transfer system) as I need to have somewhat similar buffering scheme. I am also using parts of the DSx86 code, as it is written in ARM assembly instead of MIPS assembly in DS2x86. So, in effect I am combining the algorithms from DS2x86 with the actual code from DSx86. :-)
I already managed to get the easiest digital audio mode, simple one-shot DMA output, working on Saturday. I used Supaplex and my own LineWars II to test this, and both of those games now play audio fine. It was nice to again hear the original music by u4ia in my LW2. :-)
Today I have been working on getting the auto-init DMA system working. This is considerably harder, as it is very timing-critical to not get buffer underflows or overflows, and still make the emulated game think that the audio runs at some quite different speed to what the actual hardware is playing the audio buffers at. I am using Doom for these tests, as I am familiar with how it works (it plays a 4096-sample buffer at 11.1kHz, with an IRQ request after every 128 samples have been played). Converting this to my double-buffered 2048-sample buffers running at 32kHz is somewhat difficult, and I have not yet managed to get it working perfectly. It does already play recognizable audio, but it still has some stuttering and occasional skipping.
During the next week I will continue with the audio features, for example all the ADPCM digital audio formats are still missing. Then the most essential features have been implemented, so I will just need to spend some more time testing and creating some configuration options and settings, before I could release the first beta version. I don't think floating point support is essential for the first beta, as not very many DOS games use floating point operations.