wraggster
February 3rd, 2013, 23:39
via http://ax86.patrickaalto.com/ablog.html
I have managed to work quite a bit on ax86 during the past two weeks. Here is a list of the more inportant changes I have managed to implement:
Better file system support. Since the EXT3 file system used in linux is case-sensitive, my file routines from DSx86 (which only supported FAT file system) had problems handling files that were not in all capital letters. I improved my file routines so that if a requested file (which in the internal DOS routines is always in all upper case) is not found from the file system, ax86 scans the directory, converts each found file to upper case, and then checks if this is the correct file. This will of course take much more time than directly accessing the file, so it is still a good idea to actually have all file names in all upper case.
I still have a problem with the directory scanning routines. Currently I re-open the directory and skip a number of files for every DOS FindNext call, when I think that a better and faster approach would be to open the directory once on the FindFirst call, read all the files into a memory buffer (perhaps a linked list), and then use this linked list when DOS calls the FindNext routine. The current system is very slow with directories that contain hundreds of files, and also causes problems when deleting files. Every time you do a DEL *.*, the current system deletes only HALF of the files (because a file that the routine skips over has already been deleted, it skips over the NEXT file instead of the CURRENT file). So this still needs to be changed, but still the new file system support now allows me to test much more games.
AdLib audio support. This is what I spent the previous weekend on. I was able to mostly use the AdLib emulation routines from DSx86 (where the emulation runs on the ARM7 processor), but instead of using 9 separate hardware audio channels (with 9 separate sample buffers) I needed to change my code so that it mixes the output of the 9 AdLib channels to a single buffer which is then sent to the Android OpenSL system for output. This was relatively easy to do, and I managed to get audio out pretty soon, but the quality was very poor.
It turned out that in order to get rid of the clicks and stuttering of the audio, I needed to increase the buffer size to 2048 samples! In DSx86 I had a buffer size of 64 samples, so this was a major change to the code. In DSx86 the small buffer allowed me to handle the AdLib note commands between buffer fills and still not cause any audible problems with the note timing. The audio latency caused by the AdLib buffer filling was only around 2ms, while now with the 2048-sample buffer the latency is 64ms. Such a high latency causes very audible problems when handling note events only at 64ms intervals. Thus I needed to add a time stamp for every AdLib note event, and then interleave the buffer filling and note event handling so that the notes get handled at their correct relative times. This fixed most of the audio problems, but of course does not get rid of the actual latency, which is quite noticeable when a game plays sound effects with AdLib audio. I don't think there is much that can be done about this, though.
Last weekend I also ordered an IVSOŽ Wireless Bluetooth Keyboard Case For Google Nexus 7 Tablet (http://www.amazon.co.uk/gp/product/B009SL3WS4/ref=oh_details_o00_s00_i00) from Amazon, which then arrived already on Tuesday via DHL (quite a fast delivery considering I ordered it via Free SuperSaver Delivery option)! Some reviews on Amazon mention that it does not have a Tab key, but at least my version does, so it is quite a good match to ax86. I spent Tuesday and Wednesday evenings coding support for a Bluetooth keyboard into ax86, so now controlling games is much easier and simpler than using the on-screen virtual touch keyboard. This also meant that my improving the inbuilt touchpad keyboard went down in my TODO list priority order. :-)
On last Thursday I then decided to order a Raspberry Pi (http://www.raspberrypi.org/) computer, as I have been toying with the idea of porting DSx86 to it as well as to Android. It arrived on Friday, and I could not resist the temptation to start working on it immediately. Thus I began to experiment with porting my current ax86 version to it. The Friday evening was spent in an attempt to create my own Makefile system to compile ax86 (or rpix86 as I decided to call it), but after miserable failures and considerable frustration (it turns out I am really NOT a Makefile guru!) I decided to copy the Makefile system from Nintendo DS DevKitARM pretty much as-is, as it seems to work nicely and I am familiar with it. Using that I got practically all the code to compile on Friday, but the hardware-specific stuff was still missing, so it did not actually run yet.
I continued this work on Saturday, and finally by Saturday evening I was able to get 4DOS to start up inside rpix86 on Raspberry Pi! I still don't have any input (like keyboard) support on the Raspberry Pi side, so I just adedd a frame counter that exits the program after a few seconds, but still it was nice to see that I can use pretty much the same code for both Android and Raspberry Pi. From now on I think I will work on those two versions side by side, as I added some compile defines to places where I need to do things differently between those two, and most of those places are in a single source code module which contains the native interface.
It also looks like I will be able to do some development things (like using a cycle counter to help me optimize some routines) more easily on the Raspberry Pi than on Android. Eventually I will probably want to add some processor-specific optimizations to my code, so that will cause differences between the versions (since RPi has ARMv6 and modern Android devices have ARMv7 processors), but for now I can work on both at the same time.
Next I will probably spend some more time on the Raspberry Pi side to get it at the same level with the Android version (namely to get keyboard and AdLib support working), after that I need to add mouse support and floating point support to both, as those are the things that currently limit the number of games I can test on ax86/rpix86. Then I will need to add SoundBlaster digital audio support, implement the missing graphics features, and so on, so there is still quite a bit of work ahead before the eventual public release.
I have managed to work quite a bit on ax86 during the past two weeks. Here is a list of the more inportant changes I have managed to implement:
Better file system support. Since the EXT3 file system used in linux is case-sensitive, my file routines from DSx86 (which only supported FAT file system) had problems handling files that were not in all capital letters. I improved my file routines so that if a requested file (which in the internal DOS routines is always in all upper case) is not found from the file system, ax86 scans the directory, converts each found file to upper case, and then checks if this is the correct file. This will of course take much more time than directly accessing the file, so it is still a good idea to actually have all file names in all upper case.
I still have a problem with the directory scanning routines. Currently I re-open the directory and skip a number of files for every DOS FindNext call, when I think that a better and faster approach would be to open the directory once on the FindFirst call, read all the files into a memory buffer (perhaps a linked list), and then use this linked list when DOS calls the FindNext routine. The current system is very slow with directories that contain hundreds of files, and also causes problems when deleting files. Every time you do a DEL *.*, the current system deletes only HALF of the files (because a file that the routine skips over has already been deleted, it skips over the NEXT file instead of the CURRENT file). So this still needs to be changed, but still the new file system support now allows me to test much more games.
AdLib audio support. This is what I spent the previous weekend on. I was able to mostly use the AdLib emulation routines from DSx86 (where the emulation runs on the ARM7 processor), but instead of using 9 separate hardware audio channels (with 9 separate sample buffers) I needed to change my code so that it mixes the output of the 9 AdLib channels to a single buffer which is then sent to the Android OpenSL system for output. This was relatively easy to do, and I managed to get audio out pretty soon, but the quality was very poor.
It turned out that in order to get rid of the clicks and stuttering of the audio, I needed to increase the buffer size to 2048 samples! In DSx86 I had a buffer size of 64 samples, so this was a major change to the code. In DSx86 the small buffer allowed me to handle the AdLib note commands between buffer fills and still not cause any audible problems with the note timing. The audio latency caused by the AdLib buffer filling was only around 2ms, while now with the 2048-sample buffer the latency is 64ms. Such a high latency causes very audible problems when handling note events only at 64ms intervals. Thus I needed to add a time stamp for every AdLib note event, and then interleave the buffer filling and note event handling so that the notes get handled at their correct relative times. This fixed most of the audio problems, but of course does not get rid of the actual latency, which is quite noticeable when a game plays sound effects with AdLib audio. I don't think there is much that can be done about this, though.
Last weekend I also ordered an IVSOŽ Wireless Bluetooth Keyboard Case For Google Nexus 7 Tablet (http://www.amazon.co.uk/gp/product/B009SL3WS4/ref=oh_details_o00_s00_i00) from Amazon, which then arrived already on Tuesday via DHL (quite a fast delivery considering I ordered it via Free SuperSaver Delivery option)! Some reviews on Amazon mention that it does not have a Tab key, but at least my version does, so it is quite a good match to ax86. I spent Tuesday and Wednesday evenings coding support for a Bluetooth keyboard into ax86, so now controlling games is much easier and simpler than using the on-screen virtual touch keyboard. This also meant that my improving the inbuilt touchpad keyboard went down in my TODO list priority order. :-)
On last Thursday I then decided to order a Raspberry Pi (http://www.raspberrypi.org/) computer, as I have been toying with the idea of porting DSx86 to it as well as to Android. It arrived on Friday, and I could not resist the temptation to start working on it immediately. Thus I began to experiment with porting my current ax86 version to it. The Friday evening was spent in an attempt to create my own Makefile system to compile ax86 (or rpix86 as I decided to call it), but after miserable failures and considerable frustration (it turns out I am really NOT a Makefile guru!) I decided to copy the Makefile system from Nintendo DS DevKitARM pretty much as-is, as it seems to work nicely and I am familiar with it. Using that I got practically all the code to compile on Friday, but the hardware-specific stuff was still missing, so it did not actually run yet.
I continued this work on Saturday, and finally by Saturday evening I was able to get 4DOS to start up inside rpix86 on Raspberry Pi! I still don't have any input (like keyboard) support on the Raspberry Pi side, so I just adedd a frame counter that exits the program after a few seconds, but still it was nice to see that I can use pretty much the same code for both Android and Raspberry Pi. From now on I think I will work on those two versions side by side, as I added some compile defines to places where I need to do things differently between those two, and most of those places are in a single source code module which contains the native interface.
It also looks like I will be able to do some development things (like using a cycle counter to help me optimize some routines) more easily on the Raspberry Pi than on Android. Eventually I will probably want to add some processor-specific optimizations to my code, so that will cause differences between the versions (since RPi has ARMv6 and modern Android devices have ARMv7 processors), but for now I can work on both at the same time.
Next I will probably spend some more time on the Raspberry Pi side to get it at the same level with the Android version (namely to get keyboard and AdLib support working), after that I need to add mouse support and floating point support to both, as those are the things that currently limit the number of games I can test on ax86/rpix86. Then I will need to add SoundBlaster digital audio support, implement the missing graphics features, and so on, so there is still quite a bit of work ahead before the eventual public release.