How to test FileSwitch Module?

Two weekends ago we had a private RISC OS meeting. One of us wanted to count some files inside various directories. He had to detect that OS_FSControl 28 is limited to 4GB which is meanwhile a bit small. He tried to implement the file counting in another way. Parallel to this I tried to extend OS_FSControl to 64 Bit.

I think that I made the modification right. However before publishing it we wanted to test it. And yes thats the problem.

The fileswitch module is so central that it refuses to be RMLoaded etc.. Therefore my question: Has anyone an idea how to test central modules like this?

Many thanks in advance

Thomas Milius

Build an IYONIX ROM image and softload it – sadly that requires someone to tweak the SoftLoad tool to softload on the IYONIX (it was written for the RiscPC). I think Adrian Lees was having a look at doing this so it would be worth asking him how he’s getting on.

Doing a ROM build is a simple case of checking all of the sources out as defined in the Products/Tungsten/modules file and then installing the Acorn C/C++ tools into that build environment, running RiscOS/Apps/!Builder and doing a “Tungsten” build. I think ROM builds are described on our Wiki somewhere.

The SoftLoad tool sources, for those who are interested, are here…

http://www.riscosopen.org/viewer/view/castle/RiscOS/Utilities/Debugging/SoftLoad/

• allocates an RMA block
• loads the test FileSwitch module into it
• does the “insert module from memory” OS_Module call
• reinitialises all the filing systems (or as many as desired) so they re-register with the new FileSwitch

Many thanks for the hints.

I shall try to start with Ben’s way first for it seems a Bit simpler to handle.

If it won’t work I shall try to build and softload the ROM image. It is because I didn’t build all the RISC OS 5 components already and this will also take a while. I am also exspecting some corrections during the tests and so Bens way may be the faster one instead rebuilding a ROM every time.

I’ll just keep plugging the softloader in the hope someone will fix it! :)

I think the softloader is working, though it’s still a little early to be sure. Suffice to say that I created a dummy ROM image which just contains a section of code to write a message into the NV’s screen memory, and the modified softloader can now load this, do its mungeing and run the ROM.

Now to make the HAL softload-aware…. which is prob quite a bit more work.

[softloader] Hooray! [HAL] Ahh. Bummer.

Brief update to say that I’ve managed to get 5.14 to boot to the desktop softloaded, though there are a number of issues. It seems to have trouble accessing the machine ID (and graphics card types?) from the flash, the network doesn’t work (for me at least) and I was unable to start NetSurf (though that may just have been because the boot sequence didn’t complete properly). Progress of a sort, anyway.

It /will/ definitely need a few small changes to the HAL source before we can softload cleanly. At the moment I’ve just bodged the softloader to apply the necessary patches to the in-memory ROM image before execution.

Network’s up and running. I’ve experienced a couple of unexplained machine freezes so it’s not quite happy, and I have yet to get a picture using the GeForce5 card for some reason. Have switched back to GF2 temporarily.

Great work! Thanks for the updates. For your information, Ben and I programmed the RO5.14 image into an IYONIX for the Midlands show. I’ve used that machine for various things since with no obvious problems so we can be a little confident that the freezes aren’t the result of fundamental faults with the ROM.

Note, however, that the ROM programmer does some wacky patches to the ROM image before it programs it (look inside one of your ROM updates from Castle). It might be that some of these patches are part of what fixes your GF5 issues?

Thanks. I knew that jwb stored info on the graphics card types somewhere, but had forgotten the details. I’ll modify the softloader accordingly, and I suspect you’re right about the GF5 problems. Not yet sure what caused the 2 freezes I’ve seen, but I did run the softloaded OS for many hours last night and actually started developing on it.

Didn’t help, unfortunately (and indeed my machine normal runs an unpatched ROM and starts most times out of 10). Whilst I try to work out why not, is there anyone out there with a GF5 card who’s willing to try the softloader (I can deactivate ADFS in the loaded ROM image as a safety measure, if you like) to see whether it’s a quirk of my (pre-production) IYONIX pc or a general problem that will affect all GF5 users?

If you get no other takers, I have an FX5500 card I can put in and try. I did buy it to use, but its fan is far to noisy for me !!

Thanks to the hints mentioend above and an old piece of software I managed it to test my fileswitch modification.

Before fileswitch can be removed it is necassary to RMKILL Free. Afterwards the new instance can be easily loaded by a simple BASIC program.

I have modified OS_FSControl 28 in such a way that in case in Bit 15 in Mask Bits R3 is set R4 will contain Bits 32-63 of the size else the behaviour is backward compatible including the wrong counting above 32 Bit. Bit 15 in mask Bits has been declared as 64 Bit mode.

An alternative would be to leave the Bits unchanged and to introduce a new OS_FSControl SWI. Which is this preferred way?

By ‘new OS_FSControl SWI’ I presume you mean a new reason code (value in R0), and I’d suggest that this is the way to go. If you use the mask bit in R3 then software can’t detect whether FileSwitch supports that bit, and thus won’t know whether the count is reliable. Using a new reason code will return an error on older versions of FileSwitch and application code can thus choose whether to just use & trust OS_FSControl 28 or attempt some other recovery.

It’d be worth updating ‘Count_Code’ (s.FSCommands) and ‘Util_FilesDone’ so that *Count benefits too, although the latter is called from a couple of other places.

Have you worked out the kinks in the softloader yet, Adrian? I’d be willing to give it a go with my GF5 if you send a copy my way.