| Behind the scenes of a pocket RiscPC |
|
Published: 6th Jun 2006, 01:39:21GMT Source: drobe.co.uk
By the Drobe news desk
|
| Page 1 of 1 |
|
| How a mobile port of RPCEmu came about |
|
 Developing a port of open source RiscPC emulator RPCEmu to a PDA was a feat that excited those of us longing for a truly mobile RISC OS.
Here, Jan Rinze Peterzon (right) talks us through how the port came about, what it's like to use RISC OS with a touchscreen and stylus, and how well the emulated platform performs on a Loox 720 device.
How long did it take you to produce the port?
 The port itself was done in a matter of days and ran at about one million instructions per second. [An A7000+ in comparison manages 43 MIPS] The problems started when I wanted the proper screen resolutions and mouse support.
The touchscreen is not supported by RISC OS so I had to emulate the mouse for it. The biggest obstacle here is that mouse devices give relative movement in the x- and y-coordinates. The touchscreen gives absolute coordinates. To convert absolute to relative coordinates, the emulator now computes the distance from the touchpoint to the real mouse pointer. Single and double click action now works when tapping the screen. Menu and Adjust are mapped to hardware buttons.
For performance reasons I switched from MS Embedded Visual C to GCC 4.1.1 for Windows CE (cegcc).
What sort of performance does it give?
The current speed of the PocketPC port is about 2-3 MIPS and the main focus now lies at making the emulator faster. RPCemu's author Tom Walker has written the emulator with a Desktop PC as his target and most optimisations work pretty well on an AMD desktop processor.
The XScale however only has a 32KB data and a 32KB instruction cache. This is much smaller than the caches of an AMD processor. Using lookup-tables and other optimisation sometimes makes the emulator run slower on a PocketPC. There are a couple of optimisations that I am discussing with Tom which might improve the speed of the PocketPC port.
One is to do a sort-of simple dynamic recompilation where all ARM instructions will become calls to emulation functions. The good part of this is that some instructions can be run directly instead of a call. The bad part is that self-modifying code can become hard to emulate. The second route could be to exctract the ARM emulation from A310emu by Jan de Boer but I would first have to discuss this with Jan. His emulator is quite fast on the Iyonix's IOP321 XScale processor.
Why did you decide to port RPCEmu to that PDA?
The Loox 720 is a pretty well designed Pocket PC, with a 520Mhz XScale PXA 270, 128 MB RAM, USB 1.1 slave, USB 1.1 host, audio in/out, built-in camera and so on. Actually, if you look at it, the specifications are somewhat in between an A9 and an Iyonix. This led me to think that RISC OS would be a perfect replacement for Windows CE. The RPCEmu source code by Tom enabled me to experiment with the combination of RISC OS and Pocket PC.
A long time ago I had been busy with riscose and that ran pretty fast in native mode under Linux - 56000 dhrystones or something like that when running an a 275 MHz StrongARM Netwinder. The Windows CE operating system on the other hand is very restrictive and has a simple memory model. Riscose would not run under Windows CE. A port of Linux for the Loox 720 is slowly being developed but is not sufficiently far to use it as a WindowsCE replacement.
What will we see in the future for mobile RPCEmu?
The best way to run RISC OS on Pocket PC hardware would be to run it natively. That would mean that all the code runs directly on the XScale processor. Currently I would be happy if only parts could be run natively. I am looking into the inner workings of Windows CE to see if that would be possible.
It is a lot of fun using RISC OS with a stylus on a small touchscreen and it is really nice to figure out how both machines work - the RiscPC and the Pocket PC. The port is only tested on a Fujitsu Siemens Loox 720 and is intended to run on VGA Pocket PC devices. QVGA is not supported, yet..
Aside from Pocket PC hacking, Jan Rinze also took part in a hardware challenge, where he and two friends built up a robot using a Netwinder and a ethernut device.
Links
RPCEmu websiteRelated articles
The story behind RiScript 5
Behind the scenes at Drobe
KinoAmp 0.26: Behind the scenes
This article has been linked to, or is available in the following formats:
|
| |
|
druck (+2.1)
6/6/06 9:44AM |
The ultimate aim shouldn't just be getting RISC OS running at an acceptable speed, making it take full advantage of the hardware, that means support for things such as the built-in camera and GPS on some Loox models, so there is a real purpose to having such a device. Software to control camera should be fairly trivial, and its easy enought to build a simple GPS location and tracking program using scanned map images for walkers, but a full vector map based satnav system is probably outside our grasp. |
JanRinze (+2.0)
6/6/06 4:01PM |
Actually, the camera hardware is pretty hard to get to since HTC doesn't open up the API. GPS o.t.o.h. is fairly trivial since its protocol is specified by NMEA standards.. As for scanned map images, they can be converted to vector by a couple of PD programs. Just add coordinates to the vectorized image and your set to go.
Currently I am busy to see wether an Assembler written instruction emulator could speedup the RPCemu. Together with Jan de Boer we are making a little progress towards a more optimized solution. We hope to achieve about 20 MIPS with this approach. A more aggressive approach with dynamic recompilation is also being investigated. The latter however is not likely to be in the near future.. So don't hold your breath.
Jan Rinze. |
druck (+1.0)
6/6/06 4:37PM |
For GPS sat nav which can perform routing, as opposed to a simple location tracker, you need vector information that contains a lot more than the just road shapes, (such as road class for speeds, carridgeway directions, junction types and limited access details), and it needs to be updated regularly. This really means obtaining it from a commercial source at considerable expense, which is likely to be beyond the means of anyone in the RISC OS market.
The information to drive the camera might be difficult to obtain, and it will probably require quite a bit of hacking to find out, but when the data is extracted, not a lot needs to be done with it apart from store it to disc, where other RISC OS software can manipulate it further.
An assembler emulator is the sensible next move, and a 2x-5x improvement over the C routines should be achiveble. Dynamic recompilation would be in the order of 5x-20x for frequently used code, but its quite an expensive technique in terms of memory useage, so wont be easy to do on the current generation of PDAs. When they start getting 256MB-512MB of program memory it will be more feasible. |
PeterT (+1.0)
7/6/06 10:41PM |
Did you consider using Qemu for cpu emulation? Running on the Iyonix under Debian, it achieves between 1/7 and 1/16 of the original speed when running the distributed.net client, depending on the used core. This is quite the same ratio which is achieved on a Centrino cpu with 1MB L2 cache, if the emulated ARM client is compared to the native x86 client. It seems that Qemu is not too sensitive to a missing L2 cache. Maybe Qemu could be a good base for running RISC OS on an ARM based machine? |
JanRinze (+1.0)
8/6/06 10:31AM |
To PeterT:
Qemu is not viable under WINCE. It has similair methods as riscose where the SEGV and mmap together allow for fast control and detection on memory areas. In WINCE there are no good equivalents.. (I may be wrong here but I have not found any pointers to such codehandling for WINCE.) Qemu does sort of dynamic recompilation of the code and assumes knowledge of the code flow to predict the behaviour for data and code. This is possible by having a 16MB translation cache. This amount of memory is very hard to come by on WINCE. Each process can only allocate 32MB in total!
Under ARM Linux all these restrictions don't apply. Qemu runs fine there and i.i.r.c. there are already people busy getting RISC OS to run under Linux/Qemu.
Jan Rinze. |
druck (+1.0)
8/6/06 3:23PM |
The VirtualAlloc function on CE can be used to allocate memory outside the 32MB application space restriction as long as 2MB or more is requested. It doesn't have the functionality of mmap, but page access permissions can be set up, and it might be possible to something with it. |
JanRinze (+1.0)
8/6/06 4:13PM |
to druck:
Is it possible to set execute bits with the VirtualAlloc on WINCE? How would you install a SIGSEGV an SIGILL handler so the code running in the virtually allocated memory area can be controlled?
On the side: It is very possible to do a file mapping and claim more memory on WINCE if more than 32 MB is necessary. It is just that this memory can only be used for Data i.i.r.c.
Jan Rinze. |
PeterT (+1.0)
8/6/06 10:48PM |
In reply to JanRinze:
Considering the small size of typical RISC OS applications, we could probably reduce the size of the translation cache from 16MB to maybe 4MB or even less. But as long as there is no equivalent of SEGV and mmap, it does not help too much.
Running RISC OS under Linux/Qemu is probably especially useful on a fast x86 machine, but not on an Iyonix 
Is it possible to support also 240x320 displays with RPCEmu? Because this is the only one I (and probably also others) have now, 480x640 is still quite rare. |
druck (+1.0)
9/6/06 9:32AM |
In reply to jan:
Yes there are execute permissions, although I've not tried them myself, and MS has a horrible habit of putting stuff from NT in the CE documentation which doesn't work in practice across all versions and architectures. See [Link: msdn.microsoft.com] and [Link: msdn.microsoft.com]
In reply to PeterT:
yes RISC OS applications are quite small, but remember that the OS needs to be emulated too, and for dynamic translation to be efficent you need to keep a working set cached to offset the initially very expensive analysis and compilation step, and allowing multiple reuse of the resulting fast code. Also the code in the cache is going to be quite a bit larger than the original, even for ARM on ARM, as there will be additional register spillage and memory access translations. |
PeterT (+1.0)
9/6/06 7:17PM |
In reply to druck:
Of course we should be able to reuse the code from the translation cache many times, that is obvious and does not need to be explained. However, there are some reasons that make me believe that 16MB are really oversized in our case. The most important is, that 16MB seem to be sufficient to run Windows inside Qemu on a Mac. |
JanRinze (+1.0)
11/6/06 2:17PM |
In reply to PeterT:
The preliminary assembler based work that Jan de Boer and I are doing is quite encouraging. Using jump-address caches speeds-up the emulator quite a bit. The total size of the caches still needs to be detemined.
Anyway, don't hold your breath yet.. We're still a long way off from inserting this assembler stuff in the emulator..
Jan Rinze. |
| 1 comment(s) are below your moderation threshold. Login to view them. | | |
|
|
|
