Un-unplugging A ROM Mdoule

Seems a little silly to ask this…How to I re-plug a ROM Module?

In the Largest FAT32 Partition thread it was suggested that I unplug DOSFS, this worked and my issue diagnosed.

I went to !Boot.Loader (I am on a Pi) and realised that the DOSDisc file was not recognised by anything, so I attempted to re-insert the module using the following commands at different reboots:

RMReInit DOSFS
RMInsert DOSFS

each time RISC OS Starts up with it unplugged?

If I middle button on the raspberry> shutdown I get Internal Error AODT @ &20635A10, then the Restart splash.

Am I going mad and remembering incorrect commands

I wouldn’t care except I need to switch between a zero pain free ROM (to use spr2png) and the latest build – meaning I have to use another computer.

RISC OS 5.23 21-Mar-16

TIA

Michael

Your post can be read two ways; have you tried RMReInit by itself (without RMInsert)? The docs for RMInsert say that it doesn’t reinitialise the module, which could potentially negate the effect of RMReInit.

NB: I’m not actually familiar with RMInsert so I’m just going by my own interpretation of the Help command :)

Yes….I had thought that and tried both together too…alas to no avail.

IIRC the cmos functionality on the Pi is still implemented by appending it to the end of riscos.img in the loader partition. But you’ve unplugged DOSFS so RISC OS has no way to access the partition to write the RMReinit value….

Catch 22!

I think you are correct sir!

It would also explain the AODT on shutdown (Where I expect it does the save?)

So my question is why oh why is it modifying the ROM, isn’t that the very thing we pride ourselves on, the OS doesn’t modify itself? I’d have thought a CMOS file would have been better (self generated if it doesn’t exist using defaults). Isn’t that how RPCEmu does it?

looks like I’m back to loading it in via another Pi and replacing the ROM.

So my question is why oh why is it modifying the ROM, isn’t that the very thing we pride ourselves on, the OS doesn’t modify itself?

Good question.
Having established a fair while ago that it was a bad idea the follow up question is why is it still like that?

Good question.

The current system is a compromise.

I’d have thought a CMOS file would have been better (self generated if it doesn’t exist using defaults). Isn’t that how RPCEmu does it?

The difference being that RPCEmu is not RISC OS, but an emulation of a machine that runs RISC OS.

Having established a fair while ago that it was a bad idea the follow up question is why is it still like that?

The thing is, RISC OS needs to know certain configuration values from early initialisation. This is before any filesystems have been started, which means it can’t be held as a file on disc.

Therefore, a space around the HAL (at the start of the file) has been set aside for where the settings are stored. By writing directly into the RISC OS image, these settings are loaded into memory as RISC OS itself is loaded, so they are available from the very beginning.

The reason RPCEmu (etc) can use a file is because they fake the older IIC hardware, so RISC OS can directly load important settings during the initialise phase.

Of course, this means that it is possible to hit edge cases such as the one encountered here (unplugging DOSFS, oops), though such edge cases are not normal…

I’d have thought a CMOS file would have been better (self generated if it doesn’t exist using defaults). Isn’t that how RPCEmu does it?

The difference being that RPCEmu is not RISC OS, but an emulation of a machine that runs RISC OS.

Discuss that with Dave Higton – he’d done a CMOS emulation in a disc file. As I recall he wasn’t impressed with either the CMOS chip add on or the (later) save back in the rom image.

You may have missed those bits, I think you were still in the wilderness.

Discuss that with Dave Higton – he’d done a CMOS emulation in a disc file.

I believe that is a possibility with the Beagle (etc) boards that use U-Boot and thus are able to be told to load a file into memory prior to loading the OS ROM.

Ah yes, it is on my blog:

uenvcmd=mmcinit;fatload mmc 0:1 0x8100f800 rocmos;fatload mmc 0:1 0x81000000 riscos;go 0x81000000

…though I think the fatload statements are the wrong way around, wouldn’t riscos overwrite rocmos? Hmmm… I wonder when I copy-pasted that back to front?

The Pi, however, just loads the one specific file as the “kernel”, so it is a lot simpler for RISC OS on the Pi to write the settings into itself.

This, of course, can be a bit of a PITA when building your own ROMs, though a neat trick to do is to copy the new RISCOS/IMG file into the DOS partition, and then run !Boot and go through the configuration and Set everything. RISC OS will provide you with its remembered settings, and then write them into the new image file. It’s simpler than having to reconfigure everything. Once that’s done, then you reboot… ;-)

though a neat trick to do is to copy the new RISCOS/IMG file into the DOS partition, and then run !Boot and go through the configuration and Set everything. RISC OS will provide you with its remembered settings, and then write them into the new image file.

You just need to shutdown after copying the new rom. If you control break you lose the settings

I do shutdown, it’s the logical way… but it never seems to remember the sound choices if I do it like that. Maybe other stuff too, like the iconise button.

But you’ve unplugged DOSFS so RISC OS has no way to access the partition to write the RMReinit value…. Catch 22!

This is true, but it can’t be read at start up either.

As Verma can show, on restart with DOSFS previously unplugged then SDCMOS comes up as dormant. Rmrenit DOSFS then SDCMOS and then reboot resolves the “catch 22”.

RMReInit DOSFS
then
RMReInit SDCMOS

did the trick!

Thank you :)

For reference, as I still need DOSFS unplugged, to access the “Loader” / Boot partition on the SD Card:

*Filer_OpenDir Fat32FS::16.$

Don’t forget that you can rmkill a module if you only want to get rid of it temporarily.