[ Home | About | Getting Started | Screenshots | Source Components | Project Page ]
You will need to install a Java 6 run-time on your system; try here or java.sun.com. Either the JDK or JRE is fine, though you're better off with the JDK if you want to do much development.
Please note that the code does rely on Java 6 API features; I may refactor these out to only use them if present, though I cannot promise this.
Be careful on a Linux system as many distros leave the 'java' command pointing
to GCJ. GCJ will not run SnareJ. You may need to replace the 'java'
command below with something like /usr/java/latest/bin/java.
To test your version of Java, at a command prompt type:
java -version
Verify that the version number is 1.6; my system reads:
java version "1.6.0_01" Java(TM) SE Runtime Environment (build 1.6.0_01-b06) Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_01-b06, mixed mode)
See the Files page to download the ZIP files.
Extract the SnareJ ZIP file to an empty folder. If you wish to test with the example binaries, extract the binaries ZIP folder to the same location.
Type:
java -jar snarejOsBootstrap.jar dhrystone
You will be prompted with the dhrystone test prompt. Try a large number of iterations, say one million or ten million. My system musters about 100,000 dhrystones/s, which is more than my aging ARM7 RiscPC. You will see some variation, particularly if you run a small number of iterations as both SnareJ's dynamic re-compilation and Java's warm-up will not have happened.
Type:
java -jar snarejOsBootstrap.jar -g circles
A graphics mode 13 (320 by 256, 256 colours) window will pop up and the program will draw a number of circles. It's not the most interesting program in the world, but it does demonstrate two things: Firstly, there is rudimentary support for graphics. Secondly, you'll notice a sudden speed up as the dynamic re-compilation kicks in.
Type:
java -jar snarejOsBootstrap.jar -g sprites
A graphics mode 13 (320 by 256, 256 colours) window will pop up and the program will draw sprites. You can use the given sprite file, or provide your own—it must be called 'spr' with a mode 13 sprite inside also called 'spr'.
Note: you will have to use Control-C from the console to properly kill the emulator. Sorry.
There is very rudimentary support for WIMP calls. The single biggest killer is a lack of support for templates (I don't know the format). The second biggest problem is a lack of a BASIC interpreter (thinking of using brandy) as most of my own old WIMP programs use BASIC :-(
In theory, you can use the same syntax as running a console application.
You'll need a fast PC for this to work well. The program doesn't use any multi-threading (though one could imagine that the dynamic re-compilation could) so you won't gain very much from having two cores.
If you have a 32-bit system, try using the 'server' VM. Use
java -server -jar snarejOsBootstrap.jar. In short, the
'server' VM has more aggressive optimisation that benefit long-running
applications. (On 64-bit systems, Sun only ships the 'server' VM.)
That all said, it compares favourably to emulators such as Red Squirrel and
RPCemu, particularly with OS graphics calls. Of course, that's because SnareJ
makes some effort to pass graphics calls through to the Java libraries to
handle. For example, sprites are cached as BufferedImages with a
type that matches the raw RISC OS data, and then painted through a
VolatileImage (which acts as a soft cache) meaning that repainting
the same sprites repeatedly will be very fast—if you have the
right settings in Java it will be done on the graphics card. Still, the lack of
OS call support rather limits this and makes it a little academic ;-)
Logging can be enabled by using a log4j.properties file. There is one in CVS
as src/binary/log4j.properties. Note that turning on logging at
a verbosity higher than ERROR will slow things down; reaching DEBUG will make it
crawl as it debugs each instruction it executes!
Have fun! Please let me know if it works:
qoholeth (at) users.sourceforge.net.