RISC OS Lite

A version of RISC OS that can be loaded from the SD card on a Beagleboard (constraint is that only around 7Mbytes of fat32 file space is available outside of the supplied Linux distribution) along with a ‘cut-down’ !Boot structure that could be loaded from the SD card [as the file ‘cmos’ is currently] into the RAM filing system (this assumes a non-RISC OS-aware target audience and thus no RISC-OS !Boot image in a Filecore pen drive).

The purpose is to use this method to present a multi-boot choice to the user from a keyboard selection (e.g. Linux command line, Linux GUI or RISC OS) thus making it useful even to those who have no initial interest in RISC OS itself. Aim is then to ‘draw them into’ use of RISC OS if only from curiousity.

Harddisc4 image that could be loaded from the SD card [as a single file being the contents of a RAM disc, as the file ‘cmos’ is currently] into memory so that it is put in the right place for RISC OS to use via the RAM filing system as the boot drive

The main coding requirement is to load a file ‘name to be agreed’ from the SD card into memory (the file may be 14Mbytes or 64Mbytes in size) at about the same time as the file ‘cmos’ is currently loaded, i.e. before RISC OS boots. To place it in memory so that it is at the right place to be seen as a RAM disc of the specified size (say 64Mbytes, may need this to be in cmos as the right number of pages as well) by RISC OS. Then if the cmos filing system number is set to 23 (RAMFS) to boot from it.

Is anyone interested in coding this facility? I would be happy to do the testing. Perhaps even to donate?

coding this facility

OS_ReadRAMFsLimits

Or OS_DynamicArea, OS_FSControl?

Like the CMOS data, how about:

1. Create (initially small) RAM disc and confirm its memory location/size
2. Save some (easily recognisable) dummy RAM disc contents to file from the appropriate memory location
3. Fatload this to somewhere safe before initialising RO
4. After launching to the RO Supervisor, initialise an (equiavalently sized) RAM disc and obtain its memory location
5. Fill that area of memory with the contents loaded from the file
6. *cat the RAM disc to check
7. Boot from it

Can’t this be tested in the first instance without having to change the ROM itself? I’ll try to have a look myself towards the end of next week, but if so, please bear in mind that I’d expect to be asking a lot of questions!

(I think that all except step 3 can be "easily" checked from the desktop, e.g. using a dummy ‘!Boot’ file/dir.)

[Edit: Perhaps if it’s then not too tricky to integrate with step 3 and also modify the ROM to automatically carry out steps 4, 5 and 7 then this could be a pocket-money bounty.]

How about doing something like this?

RISC OS 512MB

Cortex-A8 Processor

Acorn SCSIFS

No keyboard present - autobooting

To enter Supervisor hit any key.

Auto-booting using "Lite" demonstration boot sequence in...
3 seconds
Entering Supervisor.

Supervisor
*

[...]

3 seconds
2
1
0
Entering RISC OS "Lite".

I think we’d also need a new ‘su_lite’ or similar to replace the splash screen at ‘su_jellybean’. Is there scope for modifying the ROM to start with an alternative splash and would there be enough space to cater for more than one? If not, then I guess the sprites could be replaced with versions stored within the proposed RAM disc boot structure.

In terms of cutting down the boot sequence, I think that a lot of space is currently being used by the high-res sprites used by the Wimp and the ROM apps. Plus there’ll be a bit of space going to things which are redundant on OMAP, like the SCSI module softloads. It should also be possible to strip down the RO500Hook, RO510Hook, etc. folders (or get rid of them entirely – I can’t remember exactly how it works, but I’m fairly certain that the first time a boot sequence is booted it determines the OS version and copies the right hook folders into the main part of the boot sequence). Although I’m not entirely sure how many people would be convinced to give RISC OS a try via the ‘lite’ boot sequence, I can certainly see it being very useful for people trying to set up a beagleboard if they don’t have access to an existing RISC OS 5 machine (i.e. they’re unable to set up a boot sequence on a filecore-formatted pen drive).

Can’t this be tested in the first instance without having to change the ROM itself? I’ll try to have a look myself towards the end of next week, but if so, please bear in mind that I’d expect to be asking a lot of questions!

Before saving out the RAM disc, and before loading it back in over the top of the empty RAM disc, make sure you dismount it, otherwise FileCore will probably get very confused. Other than that, I can’t see anything wrong from a technical standpoint. In fact it wouldn’t surprise me if there’s already a utility out there somewhere to allow the contents of RAM discs to be saved/restored.

I think we’d also need a new ‘su_lite’ or similar to replace the splash screen at ‘su_jellybean’. Is there scope for modifying the ROM to start with an alternative splash and would there be enough space to cater for more than one? If not, then I guess the sprites could be replaced with versions stored within the proposed RAM disc boot structure.

Putting it in the RAM disc boot sequence would probably be the easiest and best solution. No point having alternate sprites polluting the ROM image!

Can’t this be tested in the first instance without having to change the ROM itself?

At present RISC OS is loaded using

fatload mmc 0:1 0×81000000 riscos

go 0×81000000

If I have understood your suggestion correctly I should alter CMOS RAM so that the ‘noboot’ option is set and that the default filing system is 23 (RAMfs).

Alter the boot script so that it now has:

fatload mmc 0:1 0×81000000 riscos

fatload mmc 0:1 0×81010000 magic

fatload mmc 0:1 0×81010100 ramdisk

go 0×81010000

and write some code ‘magic’ that lives at 0×81010000 which first copies the RAMdisk into the memory space that RISC OS will expect the RAMdisk to be at (which I do not know how to do) and then jump to 0×801000000 (to start RISC OS) making sure that the configured size of the RAMdisc (in ‘cmos’) matches the size when it was created and saved – at present I’d make the size 64Mbytes throughout, with a full HardDisk4 image, not actually cut down in any way. Then just type !Boot at the supervisor prompt? Not sure whether RISC OS initialises the RAMdisc to blank on start up which would kind of defeat this approach.

alter CMOS RAM so that the ‘noboot’ option is set and that the default filing system is 23 (RAMfs).

I wasn’t thinking that far but it sounds right.

fatload mmc 0:1 0×81000000 riscos

fatload mmc 0:1 0×81010000 magic

fatload mmc 0:1 0×81010100 ramdisk

go 0×81010000

How about

fatload mmc 0:1 0×81000000 riscos
fatload mmc 0:1 IHAVENOIDEABOUTTHIS ramdisk
go 0×81010000

Then from the Supervisor, copy the contents to the RAM disc area (dismounting as Jeffrey recommends – I’d not thought about that).

How about

fatload mmc 0:1 0×81000000 riscos

fatload mmc 0:1 NEITHERHAVEI ramdisk

go 0×810100000

Then from the Supervisor, copy the contents to the RAM disc area (dismounting as Jeffrey recommends – I’d not thought about that).

I have a feeling that RISC OS, on entry at +0000, protects itself at 0×81000000 and remaps itself to appear at FC000000 in a 4mbyte block, then tests the remainder of memory, wiping it in the process and then fatloads ‘cmos’ (by methods I know not how) works out where the boot drive is and then boots itself. By then wherever the data for the ramdisc had been put it would have been trashed?

and then fatloads ‘cmos’ (by methods I know not how)

I guess that’s somewhere in Dave Higton’s CMOS-on-SD/MMC code. The latest changes don’t display much history (perhaps that should be a bug report/enhancement) but these changes must be part of it.

[Edit: NVMemory is another one listed in the ‘Detail’ section.]

Another approach, rather than fiddling about with RAMFS, is to borrow a trick from the embedded versions of RISC OS: make ResourceFS the default filing system and put !Boot there.

make ResourceFS the default filing system and put !Boot there.

that would make the ROM about 14Mbytes larger and then the !Boot image would be read only. That consumes RAM (for a larger ROM) but doesn’t give the flexibility of things like Wimp_Scrap.

That !Boot wouldn’t be 14MB and you put Wimp$ScrapDir in a ramdisc.

Wimp$ScrapDir in a ramdisc

OK

the !Boot image would be read only

What would we do with the bits (other than Scrap) which require write access (e.g. Configure)? Disable them? Locate Choices$Write (or whatever it is – maybe there are others) in the RAM disc too?

I am keen to try to implement a way of loading a file from SD card into memory and then into RAMdisk memory just prior to RISC OS booting up [at the time it loads ‘cmos’ for example] so that it can boot from this RAMdisk. Such functionality is something that has to be built in to RISC OS [as the ‘load cmos’ is currently] to be useful for the purpose I have in mind [attracting new users].

Creating a RAMdisk with the ‘vanilla’ HardDisc4 image in it and then running ‘!Boot’ manually from the RAM disc at the ‘Supervisor’ prompt is of course something that can be done but it is the ability to produce an SD card with ‘cmos’ ‘riscos’ and ‘ramdisk’ on it that will boot RISCOS with no external storgae for the benefit of a user who has never seen RISC OS before that is what I want to achieve in ‘RISC OS Lite’.

Creating a RAMdisk with the ‘vanilla’ HardDisc4 image in it and then running ‘!Boot’ manually from the RAM disc at the ‘Supervisor’ prompt is of course something that can be done

If I formulated this as instructions to a non-RISC-OS-aware Beagleboard owner I would say something like:
Running RISC OS on a Beagleboard

First steps:

Take a pen drive (fat 32 formatted) and create a directory ‘BEAGLE’ on it. Download the following file and put it in this directory:

HardDisc4.util (9.1 Mbytes HardDisc image, self extracting from here )

Take the micro SD card. Rename the file ‘user.scr’ to ‘userold.scr’ and put the file ‘riscos’ which is inside the zip archive below onto the primary fat32 partition of that card, along with the file ‘user.scr’ described below:

rom-omap.5.17.zip (Beagle ROM from here )

user.scr from here

This version of ‘user.scr’ will allow the Beagleboard to boot up into RISC OS, as it contains the following commands (which can be entered manually from the serial port if you don’t want to change ‘user.scr’ but you do need the file ‘riscos’ to be present)
fatload mmc 0 0x80100000 riscos
go 0x80100000

Reboot the Beagleboard.

You should see the following:

RISC OS 512MB

Cortex-A8 Processor

Acorn SCSIFS

Supervisor

*

Type the text shown in bold and you should see the text in plain:

*BASIC

ARM BBC BASIC V version 1.44 © Acorn 1989
Starting with 525738236 bytes free
>SYS “OS_ChangeDynamicArea,5,64000000
>QUIT

*mount 0

*dir BEAGLE

Dir. SCSI::2GFLASH.$.beagle Option 00 (off)
CSD SCSI::2GFLASH.$.beagle
Lib. SCSI“Unset”
URD SCSI”Unset”
HardDisc4/util WR/

*settype HardDisc4/util Utility

*copy HardDisc4/util RAM::0.$.*

Copy file SCSI::2GFLASH.$.beagle.HardDisc4/util as RAM::RAMDisc0.$.HardDisc4/util (Y/N/Quit/Abandon) ?y

*ram

*run HardDisc4/util

*copy HardDisc4.* * ~c d r ~v

*.

Dir.  RAM::RamDisc0.$ Option 00 (off)

CSD   RAM::RamDisc0.$

Lib.  RAM“Unset”

URD   RAM”Unset”

!Boot       D/R   Apps            D/   Diversions D/

HardDisc4   D/    HardDisc4/util WR/   Printing   D/

Public      D/WR  Sound           D/R  ThirdParty D/

Utilities   D/

*run !Boot

This will open the RISC OS desktop.

Note all of the instructions and user input above could be done automatically if RISC OS could load the RAMdisc image from the SDcard and boot from it.

The interesting points are that:
(i) a FAT32 formatted pen drive plugged in to one of the four USB sockets on the Beagleboard can be read using SCSIFS before RISC OS has booted;
(ii) a RAM DISC can be created despite none being configured (and in any case the CONFIGURE RAMFSSIZE command cannot allocate much RAM anyway);
(iii) once RISC OS has been started this way, a pen drive can be formatted under SCSIForm so that it can thus appear as a bootable drive.

This allows a Beagleboard to be set up as a RISC OS computer without prior access to SCSIForm, i.e. so long as a couple of files can be copied onto the SD card (riscos) and onto a FAT32 pendrive (HardDisc4.util).

If it works then I’m sure it’s OK (have only had a glance).

This allows a Beagleboard to be set up as a RISC OS computer without prior access to SCSIForm

This is already possible, as it can be extracted at the desktop. What’s not possible is to get a working boot sequence without going through all of that first. The RAM disc (or ResourceFS) suggestion would mean a boot from the SD card alone, in order to try things out.

If I formulated this as instructions to a non-RISC-OS-aware Beagleboard owner I would say something like:

But of course I would like to present them with something that was immediately helpful and didn’t require all this twiddling before it could be booted up.

The RAM disc (or ResourceFS) suggestion would mean a boot from the SD card alone, in order to try things out.

Absolutely. And of course the resulting desktop can be peppered with helpful information, links, textfiles etc. for a new user.

If it works

It did because I just did it on my ARMini – putting a FAT32 formatted drive in a rear socket means it is seen as SCSI:0, but it is not a bootable drive (being FAT32 formatted not under SCSIForm) and so it drops to the Supervisor prompt. The rest is what I typed in and what happened.

I think the most elegant solution would be for !boot to be in resourcesfs (hopefully compressed), and to have a memphis style RAMdisk/scrap.

In the absence of a !choices being seen on a available writable FS, and changes would be silently discarded on shutdown (or perhaps even the option of saving a choices file, could be presented.)

This would also be a sensible option for RISC PCs (with a lot of RAM) and save interfering with the existing !boot)

The ROM could be supplied in Fat and Thin versions, the Fat version would contain boot in resources and default to using it, the thin version would be as the current versions.

The Fat version would negate need for a live CD.

The Fat version would negate need for a live CD.

Don’t we still want a CD version for use with emulators?

Don’t we still want a CD version for use with emulators?

I meant a live CD for RISC OS machines. To make a live CD for RISC OS you’d just put the relevant softloader on a CD.

Why not create a ISO file on the FAT filing system with a HardDisc Image for RISCOS?