[ Home | About | Getting Started | Screenshots | Source Components | Project Page ]
SnareJ is a Java-based system that might run some old RISC OS programs. It was born out of a desire to run some RISC OS programs under Linux and/or Windows, without having to resort to a classic emulator. The problem with an emulator is that the applications live within a 'sandbox'—that is, the entire system is emulated, and applications can't easily 'see' outside of the emulated system. For example, you can't drag and drop a text file from a Windows Explorer window to Zap.
As I was starting the development back in 2006ish, I searched the web for similar projects. The inspiration really comes from WINE; we have the added complexities here of having to have an ARM emulator and then the fact that RISC OS is not a classic kernel/userspace design that lends itself to the 'thin-wrapper' approach of WINE. I did see riscose, but noted that developed had all but ceased. I must acknowledge that project, though, for not only the encouragement that it is possible, but also I found some of the ideas in the code very useful.
SnareJ is written in Java. I chose Java because:
It's not without disadvantages: it's perceived as slow, it uses more memory, and sometimes fitting the assembler/C-based ideas of RISC OS and libraries into Java can be a nightmare. Still, I think it was the correct decision for me.
The architecture is split into three main sections. Firstly, there is a (hopefully) replaceable ARM emulator. It operates at two levels: the code is interpreted first, and then repeatedly-executed code will be dynamically re-compiled to byte code. If you run some kind of graphical benchmark, this becomes really obvious.
Secondly, there is what I would very grandly call a 're-implementation' of RISC OS. It has an object-oriented API that uses many principles of the RISC OS APIs, but that is not based around SWIs.
The third layer is one that mimics the modules of RISC OS, including the SWI as the primary interface. The third layer bleeds a bit into the second, and some components do straddle the layers (e.g. the WIMP component).
RISC OS is extremely complex (I mean that generally in a good way; it provided a rich environment for development, constrasting starkly against the other OSes of the day). Implementing all of it will take a long time. No, I mean, a very long time. So, I've focused on a number of areas, detailed below.
I'm not sure where the kernel ends and user-space starts for RISC OS; perhaps someone can help me :-) In summary, I have quite a bit of the core implemented, though I am not claiming that it is stable or fully functional!
One thing I do not intend to support is vectors: it's tied very closely with the RISC OS implementation and good applications should not be using them (IMO).
There a lot of 'OS' SWIs, and I'm only implemented those which I've needed so far. Things like OS_Byte and OS_Word are daunting.
No support as yet. Most applications use Obey files for !Boot and !Run, so this is a must.
No support a yet. I'd love to write an implementation of BASIC in Java, with some of the dynamic re-compilation techniques I've used in the ARM emulator. Realistically, that's not going to happen, so I'll more sensibly plump for brandy.
The VDU sub-system works to some degree. A number of the plot operations are not written (for example, flood fill). There is de-coupling from the interpretation of the commands and the real rendering; the only implementation is one that uses AWT.
Sprites also work a little. A lot of the exotic operations (for example, put
greyscale sprite scaled) won't work, nor any of the modification operations
(for example, add, rename, delete a sprite). Again, it is de-coupled from the
OS_SpriteOp calls. The current implementation uses AWT: A
BufferedImage with a format matching that of the sprite is used as
the main content, with another optional BufferedImage for the mask.
A VolatileImage is used as a cache of the content with mask
applied; hence, repeatedly plotting the same sprite will give very fast
performance (i.e. on good graphics drivers it'll be done on the graphics card).
A tiny fraction of the WIMP is operational. Enough is present to create a window with icons and then do basic poll operations. Lacking support for templates is the big blocker right now.
A small bit of the C Library is operational. Things like printf are a little hacked to get Dhrystone working. It might be better to either re-code the GNU C Library as Java, or to call through JNI to safe variants of the C calls (e.g. snprintf and then copy the string).
Probably. I had to pick something. My preference was for 'snare', but that was already taken on SourceForge.
I wanted to reflect the fact that it's not emulating RISC OS (that is, by using the ROMs and emulating the hardware).
No. Not yet. Unless you like running Dhrystone tests, this is not for you yet! But if you have time, try applications (the Absolute file only so far) and see which SWIs are needed.
YES PLEASE! Any help is appreciated. Please email me:
qoholeth (at) users.sourceforge.net.