RISC OS on the Raspberry Pi

I certainly wasn’t using “someone” as an alias for “Jeffrey”

Don’t worry; I didn’t read it that way. Although I could do with doing some more work around here anyway, since for the past couple of months I’ve been doing stuff I enjoy (playing with ArcEm) instead of wrestling with buggy hardware and confusing documentation.

By the way, you can probably add “USB CD driver” to the list of things that will be done for the Raspberry Pi release. Today I got my CDFSSoftSCSI driver to the point where it all the main features are in place, now I just have to iron out all the bugs that are stopping it from working properly (e.g. I copied most of the logic from the ATAPI driver, so it’s trying to use a few obsolete commands that won’t work on modern SCSI/USB drives).

So, yes, bodges like using RAMFS might address a short term need …

Don’t under-estimate the importance of having something ready to go when it is needed rather than ready a year later when no-one is looking. Whilst it is clearly a bodge to load the whole of the !Boot structure from SD card into an initialised RAMdisc, there are a few components in the boot structure that require RW access. Presently we have a read only SD filing system and even when we have a R/W system, there are issues over multiple R/W affecting lifetime of the SD card. So a revised !Boot structure in something like Resources: with Scrap etc. in RAM demands the same functionality to initialise the RAM disc from the SD card in any case…

It might even result in a faster boot time – three files to *LOAD from SD card and then booting from RAMdisk.

Bodge is therefore a little strong – the Linux distro uses the ramdisk method to start up so we would be in good company.

One thing I was thinking of in terms of ‘doing things properly’ is to use sparse and/or shrinkable DAs to implement some kind of caching strategy. In the most extreme case this could be a full mmap() implementation, but more simply could be a way to use spare RAM to increase read performance by doing extra background transfers, while at the same time keeping the files writeable on SD. Borrowing RAM from the OS while it isn’t using it seems to be feasible, but slipping in another layer into the filing system (to do it properly) isn’t so nice. SDCardFS could do it itself, I suppose.

There’s a massively souped-up clone of Asteroids (whose name temporarily escapes me) which was one of the first programs of any sort to be ported to 32-bit RISC OS… anyone know how to contact the author?

I don’t remember Spheres of Chaos ever being 32-bitted. The StrongARM version on the web site doesn’t run on my Iyonix. I’ve been playing the old low resolution Archimedes version under ArcEm on my Iyonix lately.

If there is a 32-bit version, that would be great. It’s a brilliant game. :)

Hope it was OK to tweet the news about the “USB CD driver”.
It was retweeted by six others including Raspberry Pi who sent it on to just under 5000 followers.
Just mentioning this so that people are aware that there are a lot of folk following this thread at the moment….

While I’m here, let me pass on the news that it looks like Fedora Linux will be the ‘default’ OS that ships with the Pi – but this
has yet to be confirmed. Also, there is some fun and games afoot with a fake Russian website trying to take pre-orders for the Pi.
Link on the RISCOScode home page if you are curious.

“Spheres of Chaos” – Yes, a great game – I remember the sound being very appropriate.

“Zool” is a game that was made 32 bit neutral by Castle Technology.

Regards,
Martin.

Hope it was OK to tweet the news about the “USB CD driver”.

Yes, that’s fine. Although I’m not quite sure why the Raspberry Pi team found it so exciting :)

Spheres of Chaos is still around and the Risc PC version has been made freeware by it is other. A couple of years ago (around 2006) I emailed him about a version that would work on an Arm7(the one on the website only plays on a StrongArm) and he emailed me a version. So it could be possible to mail him and find out if somebody would be allowed acces to the source code for 32bit. link

Martin: Where can I find this version of zool?

Two other great games that work on my IGEP are Revolver and Big Bang by Psycore. Albeit I am unable to trick the IGEP in to the correct displaying mode (Last time i tried was almost two years ago!)
You can download them from the Acorn Arcade

A (children’s) manual is in preparation. Has anyone contacted them […]

I sent Andrew Hague a note two days ago but haven’t heard anything from him so far. Guess he doesn’t check his inbox on the R-Pi forum. By all means feel free to send him or Chris Beale an email.

Who’s Chris Beale? And there’s also this post. Anyway, I don’t want to hassle anyone too much, so will wait until Monday – unless you post saying you’ve had a response by then.

A further thought occurs to me. Assuming we can bundle the RISC OS ROM with the RPI as one of the start up options (a licensing issue) then with a configuration ‘*CONFIGURE FILESYSTEM 46’ in the CMOS RAM and the essential parts of the !Boot structure in ResourceFS (so that you have a !Boot directory as well as the existing ‘Apps’, ‘Fonts’ and ‘Resources’ in Resources:$) this would achieve a pre-configured Raspberry Pi with working DHCP networking, a Netsurf browser, BBC BASIC all in a nice GUI with no external storage. The ROM would be larger (to accommodate the bigger ResourceFS) reducing the available RAM from 256Mbytes to nearer 200Mbytes. The only programming work needed for this is to get the USB stack working (for keyboard and mouse and networking).

This would then present a commercial opportunity for ROOL (or others) to sell licensed ‘native’ ROOL pen drives to any interested Raspberry Pi user that wants external RISC OS storage (and some more software).

Are there any issues over putting !Boot in a read-only directory that would stop RISC OS working? Limitations (such as installing software) are not a show stopper as it would be intended as a ‘taster’ for RISC OS. But do some applications regularly write to !Boot and rely on it being R/W (other than for things like ‘preferences’)? For example any application that writes to or creates a scrap file and falls over if it can’t?

I use memphis on my iyonix and that creates a scrap folder within itself. The one thing I have to do is to copy the RUfl_cache into it on start up, otherwise netsuft takes forever to start.

You should be able to get a hint as to what might go wrong by using the lock feature on an existing system. I tried it a few days ago, and themes and stronged had issues.

As well as creating a scrap in ram, would the system check any mounted filesystems for choices and if there is none, create one in ramfs (which could be copied to a mounted drive later on.)

It would be nice if a disk formatter and packman could be squeezed in too, because then installing a system would be really easy.

(A similar configuration would also be good for trying RO5 on Risc PCs without conflicting with the existing system.)

A couple of ideas for software:

1) Utilities: !DirSync – recently converted to be ARMv7 compatible. I’ve used this in the past and found it to be excellent.

2) Programming: Is TBA Software’s new version of BASIC part of the ROM yet? If not, it would be nice to have that on the disc image so people could play around with VFP/SIMD. To that end…

3) Programming: Some of Kuemmel’s example code

I had lots of other nice ideas, but now they’re all gone…!

Added

RE : ZOOL

“Martin: Where can I find this version of zool?”

The 32 bit version was part of the software package that came with the Iyonix.
There must be quite a few copies around but for who owns it, probably best to ask ROOL.

I found a reference for it in the ‘bundled applications’ section on the Iyonix website on the following page,

http://www.iyonix.com/iyonix/info/RISCOS.html

Hope that helps,
Martin.

re: Zool

The copy that comes with the Iyonix has a ReadMe file by James Byrne, dated 19th Feb 2002. It gives his email as jbyrne (a) gol (dot) com

Added

Thanks, Trevor!

James Byrne

Do you fancy dropping him a line? Notes: Joystick interface posting, Drobe profile.

Due to a potential conflict of interest, it might be best if someone other than me contacted him.

OK, I’ll do so.

“I use memphis on my iyonix and that creates a scrap folder within itself. The one thing I have to do is to copy the RUfl_cache into it on start up, otherwise netsuft takes forever to start.”

I installed Memphis on my Iyonix and it did not require manually copying of RUfl_cache or any other setting up.
It just all works ‘out of the box’.
Memphis version 3.03 (28 Apr 2005)

I just tried deleting RUfl_cache (which is copied by a script that runs on start on my Iyonix) and Netsurf took 45 seconds to process cyberbit.

Of course this might not be an issue with the proposed use, because cyberbit might not be able to be included.

And memphis might not be possible, so scrap would need to be copied as part of the boot process, so it could have any such files preloaded anyway.

For reference, we gained Zool and Prem Manager as part of the Krisalis stuff / CD, and the Iyo version was included as part of our bundle deal for the Iyo which included DialUp Lite/Mpro Lite. Unfortunately it all go a bit confused when the bundle became separate to the hardware after the first few batches of Iyos :(

Zool and Prem Manager

I don’t s’pose the sources were included, were they?

“I just tried deleting RUfl_cache (which is copied by a script that runs on start on my Iyonix) and Netsurf took 45 seconds to process cyberbit.”

Of course, but why did you delete it? In Memphis Configuration just tick ‘Set as Scrap’ and ‘Save/Load disc on Quit/Start’
It is only a copy operation when Memphis starts, nothing for !Netsurf to do.

Of course, but why did you delete it?

The whole point was as a test to see the implications of not making provision for it on a read only boot, with a separate scrap.

In Memphis Configuration just tick ‘Set as Scrap’ and ‘Save/Load disc on Quit/Start’

I want it it to go away when I power off, hence copying what is needed.

A further thought occurs to me. Assuming we can bundle the RISC OS ROM with the RPI as one of the start up options (a licensing issue) then with a configuration ‘*CONFIGURE FILESYSTEM 46’ in the CMOS RAM and the essential parts of the !Boot structure in ResourceFS

This is one of the reasons I’d advise against a bodge – because there may be a different bodge which works better! ResourceFS is something we talked about with someone (I forget who, sorry) at the end of the London Show. Basically, this is what we used to do on STBs back at Acorn. Have a little !Boot in ResourceFS which ran some magic that kicked-off the following sequence: fetch a single RISC OS module (usually over an IP network) and load and run it. That module would actually be a wrapped-up disc image that would be installed into ResourceFS and the boot sequence could then start proper. For transient storage, we used CacheFS rather than RAMFS but that’s an implementation detail.

We’ve been speaking to the people at RPi and doing thinking here about the whole thing. We’d very much like to get RISC OS working properly in time to hit all of the first sales and press coverage but there are quite a few different bits that need to come together from different directions in a very short space of time. I like the idea of having separate USB storage as a paid-for add-on though :)