USB Pen drives

RISC OS appears to be able to read FAT formatted pen drives [no bigger than 2 Gbytes] using SCSIFS, giving them the next ‘mount’ number available in the 0 to 3 series. But it cannot boot from them. FAT32FS has now been added (e.g. on the ARMini) but I’m not sure what that adds and I don’t think it can boot from a ‘PC formatted’ pen drive only a ‘RISC OS formatted’ one. Can someone please explain why we need fat32fs, what it does and why SCSIFS cannot boot from a drive it can read?

I think you’ve pretty much answered your own question.

As it stands, SCSIFS is limited by the filecore maximum of 2GB file size (FAT formatted discs are treated as a single image file).

FAT32FS allows direct access to FAT formatted drives of any capacity, bypassing filecore’s 2GB limit.

AIUI, you can’t boot from a PC formatted pen as you can’t set the correct Opt settings to make them RISC OS bootable (there’s probably many other reasons too).

Of course, you can’t boot from a >2GB PC formatted pen anyway, as you need to softload FAT32FS from somewhere first.

correct Opt settings

I suppose the ROM could possibly be amended to boot (exec an Obey file) from drives even if they don’t have the correct Opt 4 settings. This arrangement from the BBC could arguably be amended now: few people are realistically going to be booting RO5 from floppy (or elsewhere) in place of a standard boot sequence.

What would be the consequences of ignoring the Opt 4 setting and booting anyway, if Boot is Configured?

It needs to be Opt4,2 (Run) not Opt 4,3 (Exec) for a standard RISC OS !Boot structure, but I think Chris’s moves to get dual booting require an Obey file to be Execed, so there’s a conflict straight away.

The consequences of incorrectly booting from a disc configured not to be booted from are undefined, depending on what the actual !Boot on the disc does!

Chris’s moves to get dual booting require an Obey file to be Execed

Not at all – it is just that the only way to get a file on a non-RISC OS disc filing system (i.e. one that does not have a file type) to be executed sensibly in one step [i.e. without asking the user to set tits file type first] is to issue an ‘*Exec RunMe’ type command and have plain text in the file. If a !Boot structure is present (on a PC formatted pendrive) there seems no reason not to do a ‘*TaskObey Run’ or ‘*Run !Boot’ if that would work in absence of file-typing.

You still have the fundamental problem that only ROM based filing systems can be booted from (for obvious reasons). This is why I asked the author if Fat32FS could be included in ROM (he said yes). However, whether this is the most desirable solution, I don’t know.

It needs to be Opt4,2 (Run) not Opt 4,3 (Exec) for a standard RISC OS !Boot structure

Thanks. Silly me.

If a !Boot structure is present (on a PC formatted pendrive)

Won’t we still need the !Boot file(s) to extract a (filetyped) full sequence (as previously suggested)?

fundamental problem that only ROM based filing systems can be booted from

Or could FAT (and/or FAT32) based sequences work if the files were to be automatically Mimemapped from extensions? (This would presumably require all file references to include the appropriate “/xxx” extensions, breaking the sequence on ADFS drives unless ‘File not found’ errors are trapped and a check is made for the existence of an non-extension filename. If such a check is undesirable for mainstream OS usage, perhaps a module could be loaded to deal with it during the boot sequence – and then killed once the sequence is finished). Anyway, this mimemap idea sounds like a great deal of work for little gain – so is probably best ignored!