wraggster
February 11th, 2013, 22:12
via http://rpix86.patrickaalto.com/rblog.html
On last Thursday I 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 (http://ax86.patrickaalto.com/) 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 a Raspberry Pi! I still don't have any input (like keyboard) support on the Raspberry Pi side, so I just added 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.
During the past week I have continued working on rpix86, to get it up to the same level as where my ax86 (http://ax86.patrickaalto.com/) currently is at. Here is a sort of a timeline for last week, the improvements and other things I have managed to get implemented.
First, I found a very interesting technique by a Raspberry Pi forum member Andrey for using the OpenGL ES hardware vertex and fragment shaders to perform the palette lookup table handling in hardware from the Raspberry Pi forum Atari 800 emulator (http://www.raspberrypi.org/phpBB3/viewtopic.php?f=78&t=30889) thread. I spent a couple of days converting this code to plain C (as I am not very familiar with C++ and prefer to work with C) and changing it to work in my rpix86 environment. The converted code is available here as gles_video.c (http://www.dcemu.co.uk/gles_video.c) in case you are interested in it. This speeds up the graphics rendering considerably especially in the 256-color modes. I still need to do some changes to my code to have it handle all the Mode-X variations and such, but in any case this was a very useful technique!
I also joined the Raspberry Pi forums myself, and created a thread for rpix86 (http://www.raspberrypi.org/phpBB3/viewtopic.php?f=78&t=32934) there. So, if you have questions about rpix86 that might interest other future users, feel free to post on that thread!
Next, I spent some time to get cycle counting working on my Raspberry Pi. I found a blog post (http://blog.regehr.org/archives/794) explaining the required steps, but sadly the kernel module that was included was not compatible with the kernel that my Raspberry Pi uses. However, it turned out that simply using a hex editor to change the vermagic string in the module to match the kernel one allowed the module to load. I'm sure hacking the module like this is something that should not be done, but hey, it works! :-) I also noticed that the blog post does not mention that by default the counters are disabled, so you need to enable them with:
.global ccnt_enableccnt_enable: mov r0, #1 @ Enable all counters mcr p15, 0, r0, c15, c12, 0 bx lrAfter I got the cycle counters working, I implemented the same profiler features into rpix86 as what I used in DSx86. I ran Doom several times to determine the slowest opcodes, and it turned out that most time is spent in a simple opcode 0x8A (mov reg8,r/m8). It looks like Doom uses a lot of SIB (Scaled Index Byte) versions of that opcode, and my SIB byte handling is not very optimal. I have been trying to figure out ways to improve that, but so far have not been able to come up with anything noticeably faster.
After getting tired of playing with the profiler, I decided to look into audio support, namely porting the AdLib audio support to Raspberry Pi. I just an hour ago managed to get this working, and it looks like the audio latency is much better in RPi than what it is on the OpenSL system I use on Android. However, adding even AdLib audio to Doom made it again run considerably slower than before.
The next step is to change the EGA (16-color) modes to work with the new OpenGL ES rendering technique, and after that rpix86 is pretty much at the same level as ax86.
On last Thursday I 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 (http://ax86.patrickaalto.com/) 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 a Raspberry Pi! I still don't have any input (like keyboard) support on the Raspberry Pi side, so I just added 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.
During the past week I have continued working on rpix86, to get it up to the same level as where my ax86 (http://ax86.patrickaalto.com/) currently is at. Here is a sort of a timeline for last week, the improvements and other things I have managed to get implemented.
First, I found a very interesting technique by a Raspberry Pi forum member Andrey for using the OpenGL ES hardware vertex and fragment shaders to perform the palette lookup table handling in hardware from the Raspberry Pi forum Atari 800 emulator (http://www.raspberrypi.org/phpBB3/viewtopic.php?f=78&t=30889) thread. I spent a couple of days converting this code to plain C (as I am not very familiar with C++ and prefer to work with C) and changing it to work in my rpix86 environment. The converted code is available here as gles_video.c (http://www.dcemu.co.uk/gles_video.c) in case you are interested in it. This speeds up the graphics rendering considerably especially in the 256-color modes. I still need to do some changes to my code to have it handle all the Mode-X variations and such, but in any case this was a very useful technique!
I also joined the Raspberry Pi forums myself, and created a thread for rpix86 (http://www.raspberrypi.org/phpBB3/viewtopic.php?f=78&t=32934) there. So, if you have questions about rpix86 that might interest other future users, feel free to post on that thread!
Next, I spent some time to get cycle counting working on my Raspberry Pi. I found a blog post (http://blog.regehr.org/archives/794) explaining the required steps, but sadly the kernel module that was included was not compatible with the kernel that my Raspberry Pi uses. However, it turned out that simply using a hex editor to change the vermagic string in the module to match the kernel one allowed the module to load. I'm sure hacking the module like this is something that should not be done, but hey, it works! :-) I also noticed that the blog post does not mention that by default the counters are disabled, so you need to enable them with:
.global ccnt_enableccnt_enable: mov r0, #1 @ Enable all counters mcr p15, 0, r0, c15, c12, 0 bx lrAfter I got the cycle counters working, I implemented the same profiler features into rpix86 as what I used in DSx86. I ran Doom several times to determine the slowest opcodes, and it turned out that most time is spent in a simple opcode 0x8A (mov reg8,r/m8). It looks like Doom uses a lot of SIB (Scaled Index Byte) versions of that opcode, and my SIB byte handling is not very optimal. I have been trying to figure out ways to improve that, but so far have not been able to come up with anything noticeably faster.
After getting tired of playing with the profiler, I decided to look into audio support, namely porting the AdLib audio support to Raspberry Pi. I just an hour ago managed to get this working, and it looks like the audio latency is much better in RPi than what it is on the OpenSL system I use on Android. However, adding even AdLib audio to Doom made it again run considerably slower than before.
The next step is to change the EGA (16-color) modes to work with the new OpenGL ES rendering technique, and after that rpix86 is pretty much at the same level as ax86.