Updated Filecore with RO4.02

Have tried loading the updated ‘Filecore’ module on RO 4.02.
Using a obey file from Memphis.

*rmkill filecore
*rmkill filecore
*load new msg file as a module.
*load filecore
*rmre. adfs

Floppy seems to work.
But the HD just produces the Hourglass.

Are any more modules required/ideas.

Someone else is trying to Run FAT32fs working on RO 4.39 with limited success.
Witha Castle USB podule & loading !SoftSCSI.
Opened a 8GB card – rename it,save a sprite file on it – adn dismount it.

I have vague recollection of being able to open a FAT32 SCSI drive, but I may be confusing that with being able to use it via the PC card and direct-SCSI.

The new filecore for 3.6 could be loaded from an ADFS floppy before reaching desktop, so if you can find out what was on the “FileCore v2.94 beta test” disc mentioned here http://iconbar.co.uk/forums/viewthread.php?threadid=11611&page=1#116429
in terms of modules and rmkill/rmload instructions, that may give some useful clues.

One of my RPC’s does something similar on RO3.7, if its any use the script is:

RMLoad NewMess
RMKill SCSIFS
RMLoad FileCore
RMReInit ADFS
RMLoad FileSwitch
RMKill ADFS
RMReInit FileCore
RMReInit ADFS
RMLoad ADFS
RMReInit SCSIFS
RMReInit SCSIDriver
RMReInit TaskWindow

“FileCore v2.94 beta test” disc

I have had a search for that disc both here and online, but is seems that it had to be oderered specially by Clan members (in 1995?) and although I have lots of Clan discs, I suspect I did not order that one.

If anyone has a copy, I would love to know how it managed to re-load the new FileCore.

The script Jon posted is interesting, but does not cater for RAMFS or IDEFS. It also seems to do strange things – like ReInit ADFS, then Load it again! Where did the script originate?

It was already on the machine when I purchased it from one of the RiscOS developers last year. The ADFS ReInit prior to loading an updated version is because its loading an updated ADFS module from an ADFS drive.

To cover IDEFS, you’d need to kill it and ReInit in a similar fashion to SCSIFS. What you will need to do, if not already, is run the script before the Desktop boot sequence runs. This machine does that by having this script in ADFS::4.$.!Boot, which is simply a boot drive, where I have softload and all OS versions from 3.7 up to 5.20 for testing ADFFS. After running the script (via Obey -c to avoid disc access issues), it runs ADFS::5.$.!Boot which is the usual boot file structure.

The module versions it’s loading are:

ADFS 3.33
FileCore 3.22
FileSwitch 2.52
NewMess 0.01

ADFS and FileCore are newer than the versions in RO4.39 so are probably development builds.

What file system is the HD on? Is it attached via onboard or a podule?

The versions looks like the same as in RISC OS 4.00 (Pace 20000808 aUUP00-00)
http://www.marutan.net/db/products.php?kProduct=32
What are the dates?

Same date, so I think you’re right.

I’ve just rewritten the script to cover IDEFS (although untested) and RO4.02 (tested). Doesn’t quite work on RO4.39 yet, but Colin doesn’t require that anyhow.

Colin, do you have more than one drive as these scripts will only work if you can boot the Supervisor to a drive separate to RO’s !Boot directory structure. If not, I’ll have to rewrite them to work from !Boot .!Run, which I think will be possible, I’ve just not tried it yet.

Had another go at this.

Added to the !Boot !Run file after a similar call to Softload – New CLib loaded.
*RMensure FileCore 3.63 *Run <Boot$Dir>.Run

This loads the new msg files to go with the modules.

And then calls a BASIC prog (are you using a Obey or Command file?)
How do you REM out in a command file?

This loads filecore module and the HardDisc still works!
The idea is to enable people with USB podules – to be able to use the Dosfs module with the new upper limit of 4GB.

The FileSwitch and ADFS modules give errors – at the moment.

RMLOAD <FileCore$Dir>.Filecore
*RMReInit ADFS
REM *RMLoad <FileCore$Dir>.FileSwitch
REM *RMKill ADFS
REM *RMLoad <FileCore$Dir>.ADFS
*RMReInit TaskWindow
*RUN ADFS::HardDisc4.$.Run
**

REM for an obey/command file is | (vertical split line) normally the key left of Z shifted!
As you will find in many programs !Run file.

Using Obey files, the first does some of the work and sets up F0 to load FileCore and run the second script, that finishes up and runs the normal RO !Boot directory.

That method won’t work if its in !Boot .!Run, I’ll need to change it to use BASIC as you’ve already discovered. I’ll recode it tomorrow. If you drop me an eMail, I’ll send it over: jon at jaspp dot org dot uk

I’ve recoded to work in !Boot .!Run, as follows:

In !Boot .!Run, ensure you have the following at the top of the Obey file:

!Boot .!FileCore contains all updated FileCore related modules (in my case NewMess, ADFS, FileCore, FileSwitch), and the following files that do the work:

!Run (Obey)

!Run2 (BASIC)

If you’ve not updating FileSwitch or ADFS, just remove the lines that RMload them. For modules you are loading, change all the RMEnsure’s where there’s a version no. to the version you’re updating too.

I can’t for the life of me figure out how to show the above as code, so I hope formatting hasn’t knackered it.

Thanks Jon for posting that. Presumably !Run2 is only Basic so it is loaded into memory before execution?

Why is FileCore always Re-Initialised, even when it has just been loaded? Without it, I would have thought the ADFS Kill and ReInit round it could go?

Why is TaskWindow re-initialised? Does that have a connection with FileCore etc?

I also note that RAMFS would not work after this process, unless it is initialised after Boot.!Run.

I admit that my requirements are unlike any of the other posters, as I just need to load a version of FileCore v3.21 with some debugging on a RO4.39 machine (which normally runs FC3.21). It is is a remote machine, running ADFS plus IDEFS*, RAMFS*, RMFS, and FontFS (and the starred ones must work with the new FileCore), but my RPC is running ATAFS & RAMFS (where I can test!). Detecting the active FS is easy – you used one way, I used OS_Module,12 to read the FileCore Instantiations. Just about to run some tests here…

Correct, !Run2 needs to be memory resident. “Obey -c” should also work, however I found that killing FileSwitch caused it to immediately stop executing.

FileCore is reinitialized because FileSwitch is being loaded or reinitialized.
TaskWindow – reinitializing it may not be necessary, but it was in the original script so I left it. I didn’t test with it removed.
RAMFS doesn’t seem to need reinitializing, I’m guessing it does it on a service call, such as StartUpFS. It can be easily added if necessary, in the same way SCSIFS and IDEFS are handled.

RO4.39 … I know the script above doesn’t work on RO4.39, I didn’t look into why. My guess is one of the modules are incompatible.

If you’d like a hand to get you’re requirements working, by all means send me an email with the files etc. By the sound of it, you just want to load a debug version of FileCore 3.21, if so, you should only need to RMKill FileCore, RMLoad the debug version and then RMReInit all the FileCore filesystem modules. You will need to preload FileCore into memory and use OS_Module 11 to get it into the RMA, if you’re loading it from a FileCore based filesystem.

RAMFS doesn’t seem to need reinitializing

Suprising! I managed to get it to work by issuing *ChangeDynamicArea -RamFsSize 0K and another to set the correct size.

You will need to preload FileCore

It worked here without … which is also suprising, now I think about it. But I am not messing with FileSwitch.

If you want to try my version, drop me an email on my reporter address? I have failed to find yours!

I managed to load RO5 ‘Filecore’ module on RO4.02 – seems to work ok – but the ‘Dosfs’ didn’t like being softloaded – must be hard coded to ROM.

FileSwitch and ADFS version – gave errors – so no go there.