Adjust ADFFS !Boot so that it loads when first seen?

[wmd]

Let's say that I have ADFFS on the root of my hard drive. What I want is for !ADFFS to load as soon as the root of the drive is seen by RISC OS (e.g. I click on the drive icon). I know this needs to be done in the ADFFS !Boot file, but what would be the best way to go about this? The reason I want to do this is so that hard drive installed games that use ADFBootFloppy in their !Run files do not require the user to first manually load ADFFS.

[wmd]

Or, even better - is there perhaps a way to auto-load ADFFS when an ADFBootFloppy command is encountered, rather than loading ADFFS when the drive is first clicked?

[IanJeffray]

Just copy the !Run as !Boot

[Sophira]

Or, if you'd rather not do that, edit the !Boot file and add this line to the bottom:

Code: Select all

Obey <Obey$Dir>.!Run

Edit 1: Actually, on further expansion you'll *have* to do it this way rather than copying the !Run file as above, since ADFFS' !Boot file sets variables that the regular !Run file relies on - for example, it sets up ADFFS$Path which the !Run file then uses to refer to files within the app.

Edit 2: And if you don't want to alter !ADFFS at all (which is completely understandable), there's another method. Create your own app directory in the same location as !ADFFS, called !RunADFFS or something, then make an Obey file called "!Boot" in it with the following line:

Code: Select all

Filer_Run <Obey$Dir>.^.!ADFFS

This will cause !ADFFS to run when !RunADFFS is seen.

Edit 3: Oops, it turns out that first method of adding an *Obey wouldn't work either! It'd end up in an infinite loop, since the !Run file calls back to !Boot in its first line. So yeah, the !RunADFFS option (which wmd ended up choosing) is the easiest solution.

[IanJeffray]

you'll *have* to do it this way rather than copying the !Run file as above, since ADFFS' !Boot file sets variables that the regular !Run file relies on

That's broken behaviour, then. ADFFS needs fixing. No application should require being seen by the filer before being run.

[wmd]

Thanks for the suggestions. I will go with the !RunADFFS method. About ADFFS when it loads - I notice the screen momentarily goes black when loading. I don't recall this happening on older versions (I'm using the latest version). Any way to fix that?

[Sophira]

you'll *have* to do it this way rather than copying the !Run file as above, since ADFFS' !Boot file sets variables that the regular !Run file relies on

That's broken behaviour, then. ADFFS needs fixing. No application should require being seen by the filer before being run.

To be fair, the way it's done is such that it *doesn't* need to be seen by the Filer; the first line of the !Run file is an *Obey to execute the !Boot file. (Which is why, for example, the !RunADFFS method I outlined works.) But it does still mean that the !Boot file can't just be wholesale replaced.

[edit: Although that does make me realise that the suggestion I made of calling !Run in !Boot won't work either! It'd trigger an infinite loop. Oops.]

About ADFFS when it loads - I notice the screen momentarily goes black when loading. I don't recall this happening on older versions (I'm using the latest version). Any way to fix that?

ADFFS accesses the floppy drive on bootup, and if you're using an older machine, there's an issue if you're in a high-resolution, high-colour mode, RISC OS will blank the screen while accessing the floppy drive. Try accessing the floppy drive normally to see if that's the issue - if it is, then the workaround is to switch to a lower-bandwidth mode.

[sirbod]

Or, even better - is there perhaps a way to auto-load ADFFS when an ADFBootFloppy command is encountered, rather than loading ADFFS when the drive is first clicked?

I've not tried doing this but in theory you could use an alias:

Code: Select all

Set Alias$ADFBootFloppy Run ADFFS:!Run|MUnset Alias$ADFBootFloppy

The better option would be to "Filer_Run !ADFFS" in PreDesk as it has a dependency on CLib.

Just copy the !Run as !Boot

Don't do that - it will probably lock or crash the machine!

you'll *have* to do it this way rather than copying the !Run file as above, since ADFFS' !Boot file sets variables that the regular !Run file relies on

That's broken behaviour, then. ADFFS needs fixing.

Because ADFFS hooks into the filesystem, its intentionally split out into several files. !Run actually runs !Boot and to work around a "feature" of the OS, the core Modules have to be loaded via a separate !Loader. In the next release I've split it out into more files to solve another problem!

Essentially any settings that the end-user can alter are held in !Boot. !Run and the other files shouldn't be altered.

Suffice to say, its designed for the following scenarios:

1. Be "seen" by the Wimp if the Boot sequence loads a recent CLib or it's RO5. It will then auto-load when a floppy image is launched
2. Run manually or loaded via Boot.Tasks provided CLib is current
3. Run via Boot.PreDesk if CLib is ancient

Personally, I use the first option as all my machines have a recent CLib.

In the next release it checks where CLib is in memory. If it's out of date and in the RMA, ADFFS will refuse to load; if it's in ROM and out of date, ADFFS will auto-load the minimum supported CLib from its own folder.

I notice the screen momentarily goes black when loading.

That might AutoVIDC/LCDGameModes. Edit !ADFFS.!Boot and follow the instructions to disable LCDGameModes if they're not required.

ADFFS accesses the floppy drive on bootup

ADFFS doesn't actually accessing the floppy. The floppy access is a side-effect of ADFS being restarted to allow ADFFS to sit on the DiscOp/MiscOp entry points.

[wmd]

I notice the screen momentarily goes black when loading.

That might AutoVIDC/LCDGameModes. Edit !ADFFS.!Boot and follow the instructions to disable LCDGameModes if they're not required.

Thanks, that has fixed the screen blanking.

[wmd]

Or, even better - is there perhaps a way to auto-load ADFFS when an ADFBootFloppy command is encountered, rather than loading ADFFS when the drive is first clicked?

I've not tried doing this but in theory you could use an alias:

Code: Select all

Set Alias$ADFBootFloppy Run ADFFS:!Run|MUnset Alias$ADFBootFloppy

I tried this, but when double clicking a hard drive installed game that uses ADFBootFloppy, ADFFS loads as expected, but nothing else happens - game doesn't load (tested with Fireball).

[sirbod]

Code: Select all

Set Alias$ADFBootFloppy Run ADFFS:!Run|MUnset Alias$ADFBootFloppy

I tried this, but when double clicking a hard drive installed game that uses ADFBootFloppy, ADFFS loads as expected, but nothing else happens - game doesn't load (tested with Fireball).

And I wouldn't expect it work as its just an example of how you might go about using an alias to run something that goes on to provide itself as a * command. You'd have to extend it to execute the original command it was running for.