The aim of Opt 4

Many years ago I had homesoldered clone of “ZX-Spectrum” with “Beta Disk Interface”. There it was very easy: if the boot program is present on the disk during reset – it will start, otherwise we will get an OS prompt. But in the RISC OS it is not enough.
I’m trying to understand the aim of the *Opt 4 in the RISC OS.
The boot file can be *Load’ed… What for? What’s next? Booting is incomplete?
*Run – it’s good, boot file will do its job. If to strain the brain, the difference between *Run’ning and *Exec’ing of boot file can be also understood (while it would be better if someone explained), but *Load…?

Quick reply – writing in car.

Use the Run action.

I think the others are hangovers from the days of the BBC Micro.

Hope this helps. ;-)

No I’m at home and can look in the PRM, I can add some more detail:

*Opt 4,0 is for no boot action.
*Opt 4,1 is to *Load the !Boot file. This doesn’t seem to be terribly useful because Load is not Execute, is it?
*Opt 4,2 is to *Run the !Boot file. This will perform the “Run action” applicable for the type of file that it is.
*Opt 4,3 is to *Exec the !Boot file. This will pass it to the command line and treat each line as if entered at the keyboard.

Old school Archie boot setups often used *Exec – my custom boot script did.

However there is one major difference between then and now, and why we must *Run it. Why? Simple. There is no !Boot file, it is a directory. You can’t *Exec a directory. *Load is nonsense in this context. So the only viable option is to *Run it. Using *Run will invoke the usual application directory behaviour – namely that the !Run file within is Obeyed; and that’s what kicks off the whole process.

Okay. I can’t find a copy of the Arthur 1.2 PRM online, and no idea where my paper copy is (not seen/needed it in ~15 years). I’ve read the Beeb Advanced User Guide, the Master Advanced User Guide, a lot of crap about 8271/1770 (A)DFS types, Master MOS manuals, and a bunch of Google searches.
I’ve turned up nothing regarding the rationale behind having *Load as a boot option. As far as I can figure out, it would load a file into memory (machine code directly, but I suppose on RISC OS you could *Load a BASIC program?) and… yup… then it would just stop. Stuff’s been loaded, that’s what was asked.

I guess somebody somewhere might have an explanation. I sure don’t. ;-)

You could *Load a screen image ¹ but I’m not sure why you’d want to do that and stop there.
I can’t recall any sensible use, though it is half a life time ago for all of us:-/

¹ You have to be in the correct mode already! (Settable by dip switches/soldered links on the keyboard).

You could …

May I suggest that, with the possibility of multiple hard discs (or equivalent) one might require a Boot disc, a disc to load a data file, and a further disc to execute or otherwise run a command file.

Seems sensible to me – cover all bases!

I suspect the intellectual barrier is that there should be only one (Boot) disc.

Perhaps Acorn was more prevoyant! Sorry, lapsing into French there – more fore-seeing!

John

Well, let’s not touch ‘*Load’ more…
*Opt 4 sets the boot option for the current filing system. Therefore (IMHO) CMOS must have individual cells to store boot options for any of the ‘bootable’ filing systems ;-)
I could not find them.
See this
And for the RPi, what filing systems for (except SDFS) is *Opt 4 applicable?

For SDFS I seem to recall that the is a ‘soft-wired’ OPT4,3 assumed as there is nowhere to store the option on the card?

*Opt 4 works on the RPi’s SDFS and is remembered between resets. I check it through *Cat.
If *Opt 4,0 then grey desktop starts in mode 28 (640×480×256) without icons. If *Opt 4,3 then boot ends with error.

Yes, if you do ‘Opt 4,0’, then you will effectively start RISC OS and the Desktop without the boot sequence running. And as Rick said, ‘4,3’ will try to *EXEC the application, which will fail.

As I recall things from back-in-the-day, the opt setting was stored on the disk (hard or floppy). I agree it’s a bit of a relic these days – what’s the harm in just assuming every disk/device is effectively set to ‘4,2’? I find it one of those things you forget all about until you set up a new hard disk and wonder why it’s not booting. :)

I think the others are hangovers from the days of the BBC Micro.

Rick, I think you are right; the OPT set goes back to the BBC Micro days.
Only OPT 0 and OPT 4 are relevant now ant these are the only ones that appear in the RISC OS3 User Guide. I use these two to swap boot drives between Main and Mirror using this Obey file on Main or maulally at the *:

*OPT 4,0 (switches off booting from Main)
*Dir IDEFS::Mirror (changes selected directory to root of Mirror)
*OPT 4,2 {switches on booting from Mirror)
Error The next boot will be from Mirror

I’ve turned up nothing regarding the rationale behind having *Load as a boot option. As far as I can figure out, it would load a file into memory (machine code directly, but I suppose on RISC OS you could *Load a BASIC program?) and… yup… then it would just stop. Stuff’s been loaded, that’s what was asked.

I guess somebody somewhere might have an explanation. I sure don’t. ;-)

Isn’t it because the three useful actions of *Opt 4 were determined by the various settings of two binary flags, and *Opt 4,1 was just an unneeded fourth combination?

‘No combination should be wasted!’ as slogan? IMHO, the most unlikely assumption.

‘No combination should be wasted!’ as slogan? IMHO, the most unlikely assumption.

I rarely agree with Sherlocks ‘Once you have removed all other possibilities what you are left with must be true’¹ but in this case it does seem the most probable.
If the auto loaded program was a BASIC program would it effectively be ‘LOAD “MyProg”’ and therefore be ready for editing? In which case that would have been useful in a time when users expected to be editing programs.
Maybe Sophie Wilson could shed some light on this question

¹ The problem I see is that in most situations it is impossible to think of ALL possibilities.