Thursday, October 30, 2008

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.

Friday, October 17, 2008

Remote Frame Buffer

I've taken a few days off trying to get NetSurf to work in order to add basic Remote Frame Buffer protocol support to the Wimp.

That's the protocol used by VNC, so now the Wimp can be used from a VNC client, either with or without displaying to an actual display. (Keyboard support is not yet included, but the mouse works.)

To use it, set the environment variable ROLF_VNC to anything (at the moment, later it will be used to define the port to listen at and, possibly, the frame buffer resolution). If ROLF_VNC is not defined, or FRAME_BUFFER is, the proper frame buffer device will be used (rather than a shared memory bitmap).

In use, it's much faster than running the system under qemu, and I can use the host system to debug code. I'll now go back to working out the coordinate system for netsurf.