This screen mode is not suitable for displaying the desktop

but Rick has scared me off!

:-(

Which part? Keeping copies is sensible. Acorn always used to recommend a CMOS reset when upgrading the OS (if just works differently these days), and something under the hood has changed so it is worth being aware of it.
The instructions otherwise are pretty much as Steffen wrote…

Rick has scared me off

I shouldn’t.

The thing about the Raspberry Pi installation is that it is on a card, if it gets messed up it’s just a card that is messed up, start again or revert to a backup. One can have lots of additional cards to experiment and learn with.

Rather than the FAT/SCSI partitioned SD card that RCxx makes I use a simpler system that has the RPi firmware and ROM on an unpartioned SD card with RISC OS on a SCSI formatted memory stick. The firmware SD card can be created on a Mac, or Windows or Linux, it contains just five files. It is possible to format the memory stick as SCSI and install ROOL’s Harddisc4 image using the SDFS filing system and downloaded zips saved to the card by the Mac on the SD card.

In practice I have, at least, two of both devices as backups.

It’s simple. Plug the SD card into the Mac, format if required, download and save to the card the firmware and a couple of ROOL zips. Then put the SD card into the Pi. You get the latest firmware, ROM and !Boot then all that is needed would be the lines required in CONFIG/TXT to enable the large monitor, and that is the bit I don’t know.

I can write this up more fully if it is of any interest.

I can write this up more fully if it is of any interest.

I’m sure it would be. I don’t suppose for a moment I’d be the only person interested – I could probably manage without, but it would help, and for people even less savvy than me (there must be plenty of them) it might well make the difference between confusion and success.

The method described below is an alternative to using the RCxx SD image supplied by ROOL.

The object is to install RISC OS on a Raspberry Pi from scratch, without using RISC OS on another machine, or RC14, or SystemDisc.

The latest OS5.23 ROM and HardDisc4 image will be installed. This comprises only ROOL components, a full RPi image as installed by RC14 would also have had a number of third party applications.

Pi ROMs from the 16th October 2016 onwards save CMOS settings in a file called “CMOS” alongside the ROM image file, previously these were stored within the ROM image file.

To keep it simple a small single FAT partition SD card is used the Pi firmware and the RISC OS ROM image, the RISC OS disc image goes on a SCSI formatted USB pen.

The SD card can be small, 2GB is positively huge for this usage. It will be used as a temporary filing system during the installation and that peaked at under 150MB. On completion the card only holds six files occupying less that 6MB.

The pen does not have to be big either, the minimal ROOL installation described here is only 47MB, but a user’s installation will grow to be a lot bigger.

The installation was started on a Mac here, but should be much the same on Linux or Windows, and has been tested on a RPi3.

If necessary format the SDcard using ‘Overwrite Format’. (This may take a while.)

Before handling files, as a mostly unnecessary reminder, it should be noted that the filetype extension separator in Windows, Linux and on the Mac is a dot which appears as a ‘/‘ in RISC OS.

Download firmware, boot code.bin, fixup.dat and start.elf from here and copy all three onto the SD card.

Get the Beta RPi ROM

Extract the ROM image which is the 2.7MB file ‘riscos’. Install this on the SD card as ‘RISCOS.IMG’ then also copy the zip to the SD card, it has the Zero Pain components that can be installed once RISC OS is up and running.

Get the self extracting Nightly Beta Harddisc4 and copy it to the card.

Add a ‘CONFIG.TXT’ file, as below, to the card. (The two lines at the end are new and are required for the new CMOS file.)

fake_vsync_isr=1
gpu_mem=64
init_emmc_clock=100000000
kernel=RISCOS.IMG
framebuffer_swap=0
ramfsfile=CMOS
ramfsaddr=0x508000

It would be good to download a NetSurf zip and copy that to the SD card for later. For the RPi3 use version 3.5 or later.

Insert the SD card in the Pi and go for it.

The start up will fail with “File &.!BOOT” not found, press ‘Cancel” to get to an unconfigured desktop.

Select click on the SD icon on the icon bar. Delete Apple Double stuff.

Initially there is no CMOS file the ROM does not create it. Manually create the CMOS file, either at the command line by pressing the function key F12 or in a TaskWindow by pressing CTRL-F12, with the following command :-

*SaveCMOS SDFS:$.CMOS

Reboot so that the ROM knows that the CMOS file is present. This will fail again with “File &.!BOOT” not found, press ‘Cancel” to get to an unconfigured desktop. Configuration is now enabled.

Set the file ‘HardDisc4.util’ to be of type “Utility" by middle clicking over it and sliding the pointer over the “File” menu entry arrow and using “Set type”. Double click on HardDisc4.util, wait a while, when finished the disc image will be in the HardDisc4 directory.

Plug in the pen that will be used for RISC OS. Format it as SCSI using !HForm in HardDisc4.Utilities.Caution accepting the default options offered which will ensure the drive is bootable and that the RISC OS startup application !Boot will be run at startup.

Copy the contents of the HardDisc4 directory on the SD card to the root of the SCSI pen.

Configure the boot file system and boot drive number with :-

*co. FileSystem SCSI
*co. SCSIFSDrive n

The SCSIFSDrive numbers ‘n’ are 0 – 3 for removable media, USB memory sticks, and 4 – 7 ‘fixed’ hard drives, except that a USB hard drive is not quite as ‘fixed’ as all that. (The numbers stem from the dawn of Acorn time and originally related to floppy drives and internal fixed hadrdrives.) The drive numbers are assigned at startup starting at 0 and 4, and may vary on a subsequent boot if the number of devices is different.

Reboot.

Worked here!!!

At this point NetSurf can be installed. Double clicking on the zip file will open the zip. The !NetSurf app can be installed in the ‘Apps’ directory on the SCSI device. A ReadMe file in the zips gives the further steps required to install necessary dependencies.

Networking should have set itself up using DHCP and once NetSurf is running other applications can be downloaded.

ZeroPain from the ROM zip should be installed, see the ReadMe text in the zip.

If there is a black border around the display add disable_overscan=1 to CONFIG/TXT.

For sound over HDMI add hdmi_drive=2 to CONFIG/TXT.

When finished with the temporary files can be removed from the SD card. All that is needed on the SD card is :-

bootcode.bin
CMOS
CONFIG/TXT
fixup/dat
RISCOS/IMG
start/elf

N.B. To use a monitor larger than 1920×1200 further commands may be needed in CONFIG/TXT see here and here

Brilliant! Many, many thanks!

Will report when I’ve done it…I may be a while (son moving out today – again)

What’s the “pen”?

What’s the “pen”?

Have I used the wrong term, USB memory pen, memory stick .. this sort of thing

P.S. The thought occurs there might be a snag if the monitor does not accept the default RPi 1920×1080 resolution. Hitch the Pi up temporarily to TV should sort that. Once booted a resolution that suits the monitor could be set.

P.P.S. The other thought that occurred was ‘boomerang’.

:-) Ah – I see. I’ve not had a memory stick on my Pi thus far, just a USB hard drive and the SD card, with !Boot on the SD card. The monitor I’ve got on the Pi at the moment certainly won’t accept 1920×1080 – it’s a 1600×1200 – but I can hook it up to the 2nd input on the Mac’s monitor, which will do 1920×1080 very happily (it’s 3840×2160 native) – the driving of which from the Pi is the whole point of this operation from my pov.

just a USB hard drive

In that case just get the new !Boot onto that and configure FileSystem and Drive to point to it. There is no need to bother with a pen.

The procedure as written was general purpose and assumes no pre-existing RISC OS.

Worked here!!!

It seems so simple now you explain it! What a pity even 2GB cards are hard to find! Even 512MB would do for this!

What I wonder about is; are there any speed implications? Would the traditional SDFS card be faster or slower than SCSI?

I actually use a pen drive myself for some of my software, but formatted for Fat32fs, and I’m not entirely sure why I chose to do this.

Would I be better or worse speed-wise if I chose to use a RISC OS format on the pen drive?

Also, is there a particular class of SD card which would be best for the FAT SD card?

I’m also wondering, in your set-up, if you get an icon at all for the SD card, or is SDFS still used even though there is no RISC OS part involved?

I’m away ATM, otherwise I’d be able to answer some of these questions by experiment!

Sorry to pose so many questions, and perhaps others could help to answer some of them!

What I wonder about is; are there any speed implications? Would the traditional SDFS card be faster or slower than SCSI?

I’ve heard it said that SCSI is faster than SDFS, but I think it depends heavily on the type of “pen” or SD.

Would I be better or worse speed-wise if I chose to use a RISC OS format on the pen drive?

I would say I’ve measured FAT to be faster, but the test was not performed with identical hardware so…

Also, is there a particular class of SD card which would be best for the FAT SD card?

Doubt it. You will get a noticeable speed increase with a class 10 card, but if you’re only loading the firmware and ROM, any card will do…

I’m away ATM, otherwise I’d be able to answer some of these questions by experiment!

Still over here then? ;-)

What I wonder about is; are there any speed implications? Would the traditional SDFS card be faster or slower than SCSI?

I never thought there was much difference between the SDFS and SCSI, whatever one does the Pi always has a leisurely attitude to disc filing. ADFS on the Titanium, now that is truly transformative!

I actually use a pen drive myself for some of my software, but formatted for Fat32fs, and I’m not entirely sure why I chose to do this.

Fat32FS is quite a bit quicker than SCSI or SDFS in some circumstances but it cannot be booted from, the Fat32fs module is in !Boot.

Also, is there a particular class of SD card which would be best for the FAT SD card?

It really does not matter for an SD card only containing the firmware. The files are read at startup, CMOS is written at closedown, and that’s all. (I think.)

I’m also wondering, in your set-up, if you get an icon at all for the SD card, or is SDFS still used even though there is no RISC OS part involved?

The icon on the iconbar is the same blue ‘SD’ icon. The FAT contents are shown using SDFS.

[ me ] Also, is there a particular class of SD card which would be best for the FAT SD card?

[ David ] It really does not matter for an SD card only containing the firmware. The files are read at startup, CMOS is written at closedown, and that’s all. (I think.)

So what would happen if the Boot card were made Read only.

A default CMOS settings file would be loaded at start-up as part of the ROM image (pre-pended?).

Would an error be raised on Shutdown? Would this matter?

On RISC OS start-up, could a further CMOS file be loaded from the RISC OS side, and be arranged to be re-saved at close-down, again on the RISC OS side.

If so, this could mimic the original pre-new wave behaviour, where the ROM was a physical ROM, except the CMOS is restored from file rather than battery-backed memory, an option which already existed.

What basic mistake have I made in thinking this through?

Would using a standard CMOS-settings file result in any advantages – like transparency, the ability to use an editing app, stuff like that?

It seems to me that using the SD card read-only might confer advantages – extended life, for example?

Or am I just talking nonsense?

And does this merit a thread of its own?

A default CMOS settings file would be loaded at start-up as part of the ROM image

Except file system, boot options, monitor type, etc are what CMOS is for…

Except file system, boot options, monitor type, etc are what CMOS is for…

But here I’m talking about what happens now. All I’m suggesting is that aspects of this might be altered later on the RISC OS side by a standard RISC OS CMOS file.

Obviously there is room for cock-ups with that, but the default file prepended to the ROM image will act like a reset to be modified where appropriate on the RISC OS side within Boot.

Sorry

My question has nothing to do with Screen modes on the Raspberry Pi, but i have a question for Chris Hall about !Cat and i don’t know how to reach him. In an Announcement he says that he uploaded !Cat version 0.24 in !Packman and !Store. But in !Packman the highest version 0.22.

Does anybody now how i can reach Chris Hall, or where i can get !Cat version 0.24? I can’t contact the plingstore server.

Thank you if you would answer this

Unplugs, CMOS and a change of module order in a new ROM

Therefore, the last thing you should do before booting the new ROM is to quit all active applications, go to the command line and *Close and then count to five before pressing the reset button (or power cycling if you haven’t wired up the reset button). Do not shut down normally.

I failed to get that wrinkle to work here, I always finished with my CMOS settings and not the defaults.

What did work is having made sure RISC OS has no unfinished business install the new ROM then take the card out. That will with quite a high probability ensure the current CMOS settings are not written back. There will be an error, cancel that (twice) to get to the restart window. Put the card back in, restart, new ROM default CMOS.

P.S. Had to do that again, having got a new ROM now with default CMOS I wanted to return to the new ROM with my CMOS which was preserved in the form of _RISCOS/IMG. That was reinstated as RISCOS/IMG and the card pulled out over the restart otherwise the default CMOS would have overwritten mine.

but i have a question for Chris Hall about !Cat and i don’t know how to reach him

fromevert (at) svrsig (dot) org

where i can get !Cat version 0.24?

Thanks again to all, especially David Pitt – I’ve managed to get last night’s overnight build running on my Pi, and hooked up to the big monitor – but so far only 1920×1200 resolution (still a useful improvement on the 1600×1200 I had before). It’s sort of working at 2560×1440 and 3840×2160, but not really. I’m starting a new thread to discuss how to go beyond 1920×1200, if it’s possible with a Pi Model B (Revision 2).

I’ve got !Boot on the SD card, rather than reformatting my hard drive, and that works okay.

Try running ScrHelp to check whether the GPU is sending data to the monitor at the right resolution when you have RISC OS set to 2560×1440 and 3840X2160. If not, then you need to specify the right resolution for the GPU in config.txt so that they match – if the GPU is sending 1920×1200 to the monitor and RISC OS is using 2560×1440 then it will look a bit blurred.

It’s not blurred at all – it’s lovely and sharp, but – oh, see my new thread, almost finished writing what’s going on.

https://www.riscosopen.org/forum/forums/11/topics/6440

Except file system, boot options, monitor type, etc are what CMOS is for…

But here I’m talking about what happens now. All I’m suggesting is that aspects of this might be altered later on the RISC OS side by a standard RISC OS CMOS file.

I’ll try it this time with more words. ;-) The CMOS holds a number of settings. Some are “important” and should be held in CMOS; others are less important and probably can be dropped.

First up – what filesystem? RISC OS will need to know this to know how to boot. Or, to put it another way, there’s no point in holding any settings on a filesystem if you don’t know what filesystem this will be…

Monitortype? This is usually replaced partway through boot, however it is useful to start off with RISC OS able to output some sort of visible picture right from the beginning. If something has gone horribly wrong and your machine boots with “Broken free space map”, it would be useful to actually be able to see that, rather than wondering why it hangs on start.

It might be tempting to get rid of settings such as the language, which seems like an anachronism from the past, however one of the strengths of RISC OS is that it is able to get itself into a useful state by itself with no outside help. If your !Boot startup file gets messed up or has an error, you can go to the desktop and load !Edit and look at the file to see what is happening. Part of this is the direction of the CMOS giving hints of how to get there. Yes, the language setting isn’t really necessary, RISC OS could easily boot to Supervisor and one could easily type *Desktop; but it is what it is.

With this in mind, there is a need to have CMOS and to allow it to be user configurable. There have been various ways of doing this. A file pushed into memory prior to boot (OMAP), a “widget” (various), and a bit buried in the ROM image (HAL). The widget is probably the most useful as it will behave the most like traditional CMOS RAM. The next best choice is writing into the ROM image (because the SDCMOS module hides most of the nuts and bolts from the user – “it just works”).

to the ROM image will act like a reset to be modified where appropriate on the RISC OS side within Boot.

I believe RISC OS contains default CMOS options in the kernel, but I’m not sure how you’d nuke CMOS RAM, because power-up-with-R isn’t going to work with a USB keyboard.

What comes to mind for me are two things that might be usefully added to CMOS:

1. This seems like a brilliant place to hold a High Vectors / Low Vectors switch. The information is loaded into memory with the rest of the ROM image so it’ll be available at boot. What simpler way to switch from one to the other?
2. IIC speed. Pretty much every IIC device made since ~1990 supports the 400kHz fast mode. Yet for some inexplicable reason the Pi starts up with the bog standard eighties-era 100kHz mode.
   I’ve hacked my Pi’s firmware to run the IIC at ~400kHz and everything works (including the CJE RTC/power controller/temp). Personally, I see no reason to be stuck at Mesolithic speeds, however there’s probably somebody somewhere who runs some ancient bit of hardware via a level shifter, so a config option would be the best choice.

I believe that it’s high time that CMOS reflects hardware options; with soft-options (such as Keyboard auto-repeat rate) moved elsewhere, such as a *Command.

So what would happen if the Boot card were made Read only.

How would you make it read only? AIUI on the Pi the ‘read only’ switch on the SD card is not connected or only read by software, so would only work if the OS read and obeyed the switch. I don’t think any other storage media used by current RISC OS systems has a write protect switch that is enforced by the storage media itself.

How would you make it read only? AIUI on the Pi the ‘read only’ switch on the SD card is not connected or only read by software

OK – so it won’t work for that reason. I had assumed the little switch worked autonomously.

What a pity! On the RPC we had CMOSSave which would allow saving and loading of such files. Also Mike Ironmonger and Richard Hallas’ CMOSEdit. But there’s no point if the card gets written to every shutdown – the aim of a longer-lasting read-only SD Card and managing “CMOS” in the old-fashioned way both go out of the window.

Never mind.

IIRC Jeffrey mentioned a while back that he now thought that later firmware allowed loading the riscos/img with a parameter of a file name e.g. riscos/img CMOS. That would at least stop the ROM image file from being written to and allow backing up/editing of the CMOS settings. Anyone up for the challenge to implement this? Jeffrey seems to be very busy on other desired RISC OS features.

n.b. microSD cards have no write protect switch so implementing read only for full size SD cards in software would be a dead end.

the aim of a longer-lasting read-only SD Card

Anybody tried making the image file read only?