RISC OS Compatibility
The primary goal of ROLF was always to produce an operating system that provided a programming and user experience as similar to RISC OS as possible. It was never about running particular RO programs, although I had given the concept some thought.
In response to some postings on Drobe, I thought I'd have another look at the compatibility library that is intended to be used by Brandy and QEMU.
I've implemented a very few SWIs in the library and sucessfully integrated (hacked) it into Brandy (although any programs using TIME= will get out of sync with OS_ReadMonotonicClock).
I've since started looking at QEMU, and it looks promising.
The emulator code is released under the LGPL and so I should be able to integrate it into the compatibility library. That should mean that I can provide SWI decoder code that can search both native i386 routines and also Relocatable Modules from RO, which can then call i386 SWIs.
Some outstanding questions:
Should the RMA be a shared memory area? (This would allow RMs to provide inter-process communication, but opens up a whole can of worms with locking the code/memory areas.)
Can restricting RM SWI calls to when the application has a lock on the Wimp (i.e. has received a non-redraw event from the Wimp) work? (Not really, Artworks, for example would need it's RMs' routines when redrawing.)
Update: [3 Nov] After a little more work, I've got various relocatable modules initialising and executing SWIs. For simplicity, I've gone for loading all the modules in each application, no shared memory; that means that only utility-style modules will work (task modules won't at all). ARM SWIs may call native (i386) code SWIs, but they can't call ARM module provided SWIs. (Also, I haven't looked at returning flags properly, including setting the V flag on a failed exit.) For each SWI a module needs, I either have to soft-load another module or implement the SWIs natively; of course the RISC OS modules aren't freely distributable.
Update 2: [4th Nov] I made the mistake of softloading Font Manager 3.40 (17 Aug 1998), which got some distance, but then failed for what I finally worked out was a non-32bit compatible instruction (of course, it's from 1998). So, now I'll have a look at the 41 Font_ SWIs.
Update 3: [10 Nov] I've been trying to get the ArtWorks renderer module to work, with permission and documentation from Martin Wuerthner. It's an interesting interface, in that it gives you a pointer to a routine within the relocatable module for the application to call and you have to pass the address of a callback routine to the renderer, so it can request more memory (among other things). That seems to be working, in that the ARM code runs and, with the addition of two special SWIs ROLF_RunARMCode and ROLF_CallOut, native code can call the ARM routines and ARM code can call native code (i.e. C, written and compiled under x86 Linux). Unfortunately, I seem to have done something wrong and the simple AWRender_DocBounds SWI fails. I'm working on that, and on making RO applications transparently executable on Linux.
Update 4: It seems to be a bug in QEMU, and Justin Fletcher's already been there! Unfortunately, it doesn't look like his quick fix is sufficient, so it looks like I'll have to have a look at the qemu internals.
Update 5: [12 Nov] OK, I've made a patch for QEMU which seems to work, but I should test it a bit more before sending it in. I'm trying to get the ArtWorks renderer module, http://www.mw-software.com/software/awmodules/awrender.html (and its dependencies) to work; it's a utility module that stresses the compatibility library (so similar modules should be easier to get to work), and Martin Wuerthner is supportive of my attempts. The framework appears to be working OK, so now its back to adding support for more low-level SWIs.
The comments are appreciated, I'll try to keep posting updates.
In response to some postings on Drobe, I thought I'd have another look at the compatibility library that is intended to be used by Brandy and QEMU.
I've implemented a very few SWIs in the library and sucessfully integrated (hacked) it into Brandy (although any programs using TIME= will get out of sync with OS_ReadMonotonicClock).
I've since started looking at QEMU, and it looks promising.
The emulator code is released under the LGPL and so I should be able to integrate it into the compatibility library. That should mean that I can provide SWI decoder code that can search both native i386 routines and also Relocatable Modules from RO, which can then call i386 SWIs.
Some outstanding questions:
Should the RMA be a shared memory area? (This would allow RMs to provide inter-process communication, but opens up a whole can of worms with locking the code/memory areas.)
Can restricting RM SWI calls to when the application has a lock on the Wimp (i.e. has received a non-redraw event from the Wimp) work? (Not really, Artworks, for example would need it's RMs' routines when redrawing.)
Update: [3 Nov] After a little more work, I've got various relocatable modules initialising and executing SWIs. For simplicity, I've gone for loading all the modules in each application, no shared memory; that means that only utility-style modules will work (task modules won't at all). ARM SWIs may call native (i386) code SWIs, but they can't call ARM module provided SWIs. (Also, I haven't looked at returning flags properly, including setting the V flag on a failed exit.) For each SWI a module needs, I either have to soft-load another module or implement the SWIs natively; of course the RISC OS modules aren't freely distributable.
Update 2: [4th Nov] I made the mistake of softloading Font Manager 3.40 (17 Aug 1998), which got some distance, but then failed for what I finally worked out was a non-32bit compatible instruction (of course, it's from 1998). So, now I'll have a look at the 41 Font_ SWIs.
Update 3: [10 Nov] I've been trying to get the ArtWorks renderer module to work, with permission and documentation from Martin Wuerthner. It's an interesting interface, in that it gives you a pointer to a routine within the relocatable module for the application to call and you have to pass the address of a callback routine to the renderer, so it can request more memory (among other things). That seems to be working, in that the ARM code runs and, with the addition of two special SWIs ROLF_RunARMCode and ROLF_CallOut, native code can call the ARM routines and ARM code can call native code (i.e. C, written and compiled under x86 Linux). Unfortunately, I seem to have done something wrong and the simple AWRender_DocBounds SWI fails. I'm working on that, and on making RO applications transparently executable on Linux.
Update 4: It seems to be a bug in QEMU, and Justin Fletcher's already been there! Unfortunately, it doesn't look like his quick fix is sufficient, so it looks like I'll have to have a look at the qemu internals.
Update 5: [12 Nov] OK, I've made a patch for QEMU which seems to work, but I should test it a bit more before sending it in. I'm trying to get the ArtWorks renderer module, http://www.mw-software.com/software/awmodules/awrender.html (and its dependencies) to work; it's a utility module that stresses the compatibility library (so similar modules should be easier to get to work), and Martin Wuerthner is supportive of my attempts. The framework appears to be working OK, so now its back to adding support for more low-level SWIs.
The comments are appreciated, I'll try to keep posting updates.
posted by Simon at
10:08 am
5 Comments:
A very interesting project and similar to another project I remember, ROBE maybe?
The idea of re-implementing RISC OS SWI's as a kind of veneer layer to Linux is wise...but still a lot of work!
I'd an 80's coder too so I appreciate what you're trying to achieve (efficient, bloat-free), I only wish I had the time to help!
I wish you did, too! :-)
Every module needs a bunch of SWIs implemented, or another module loaded, which needs its own set of SWIs implemented and so on....
This looks a truly excellent project. I always thought that combining RISC OS and Linux in someway would be a good idea, I just never thought it would be possible. I'd offer to help but I don't think my pitiful coding abilities would help much.
I'm in the same boat as ptolom - My programming experience is restricted to Speccy Basic from the 80s, enough BBC Basic to write a text adventure and a smattering of OPL.
This is the kind of project that makes me wish I had spent more time learning how to code.
Re: Your updates
Really glad to see work progressing!
Good luck! :)
Post a Comment
Subscribe to Post Comments [Atom]
<< Home