Rename SCSIForm

To format a FileCore device on a modern platform, we have:

• HForm, which formats discs on the Iyonix PATA ports only (the only current device to have an ATA controller)
• SCSIForm, which formats USB mass storage devices

The only recognisably ‘SCSI’ device that SCSIForm works with in the RISC OS 5 world is the Acorn SCSI card for people with an Iyonix with a podule backplane… an audience of approximately zero. And what’s with the ‘Form’ suffix… what’s wrong with ‘Format’?

The naming is very confusing. So how about renaming SCSIForm to be, say, USBFormat? I know we’re all waiting for the One True FileCore Formatter Utility, but this is a simple change that would reduce the confusion for new users.

HDformat. Hopefully one day it will support PATA (perhaps via a SCSI to ATAPI driver?)

Hopefully one day it will support PATA (perhaps via a SCSI to ATAPI driver?)

PATA/SATA/ATA/IDE support from SCSIForm is impossible; the ATA command set is completely different from the SCSI command set. SCSI commands can be sent over PATA/SATA cables via ATAPI, but that’s only going to work if the device at the other end can understand it. In practice only CD/DVD/etc. drives use ATAPI; hard discs and SSDs stick to using the native ATA commands.

According to Wikipedia, the reason ATAPI exists in the first place is because there wasn’t any sensible way to expand the ATA command set to cope with more than just hard discs. So instead they just invented a way to send SCSI commands over the cables.

At the end of the day, it boils down (again) to a simple block driver interface for all “drives” and “interfaces”, be they SCSI, USB, P-ATA, S-ATA or ATAPI. Basically, four “commands” would suffice: read block(s), write block(s), return the bytes per block, return the overall capacity.

And remember that ATAPI is also used for many harddisc-like removable discs like ZIP/JAZ/REV/SyQuest/MOD/DVD-RAM/BD-RE/PD. OK, most of those are a bit long in the tooth…

I agree that, for the moment, a rename to USBFormat would be best. A future application which does IDE hard drives as well, and handles partitions, could be called something else.

(Is this part of your thinking for getting the Raspberry Pi release a bit easier to use for newcomers, Theo?)

There is already a !USBFormat in use for formatting USB devices on the Simtec/UniPod/A9home USB interface, although this formats to FAT16 IIRC, and of course is limited to 2GB maximum size. It’s not got an official allocation though, so could probably be ‘usurped’!

I just looked at HForm again (the common source for both formatters) and my mind boggles why two apps were bred like that. The sheer amount of effort to make those changes vastly exceeds that of just deciding at runtime.

So, I reckon I can reunify them in a couple of hours (there are about 30 differences, about 15 of which are actual code differences, and the others are doing things like looking in SCSIForm$Dir instead of HForm$Dir and hence would vanish).

There would be some logic at startup along the lines of

  IF scsifs_present AND NOT adfs_present THEN mode = SCSI

  IF adfs_present AND NOT scsifs_present THEN mode = ADFS

  IF adfs_present AND scsifs_present THEN mode = FNprompt_user_for_mode

Note this isn’t the one true FileCore formatter of which people yearn, but it is at least one less bit of confusing madness as an interim step, the one true formatter should probably be in C unless BASIC gains some 64 bit variable types in the meantime.

I just looked at HForm again (the common source for both formatters)

I think there is an obvious name within that sentence.

Note this isn’t the one true FileCore formatter of which people yearn,

Shouldn’t it be named as though it is? Then when the One arrives, it can just adopt the name with the next digit up version number.

I dont think USBFormat is any more enlightening than SCSIFormat. If it was to be a unified formatter perhaps some name to do with the action being performed. For example FatFormat. For my use I often format my USBdrive with SCSIForm for backup purposes, and can do so knowing I cant format the IDE by mistake. Hopefully this safety factor would continue.
Thanks
Ron M.

Hopefully this safety factor would continue.

 IF adfs_present AND scsifs_present THEN mode = FNprompt_user_for_mode.

Hopefully the prompt would be big and scary. Also it would be good if it said which system it is using before it commits anything.

OK – after 3 hours of scraping my fingernails down a black board I’ve combined SCSIForm back into HForm so that the one tool deals with both.
I’ve temporarily located it here .

Could I ask at least one person takes it for a test drive? Ideally that person would

• Have about an hour to spare
• Have access to machines with ADFS and SCSIFS (ideally both or one and none) such as an Iyonix and Beagleboard
• Have a USB stick they can format, and a parallel ATA harddisc they can format
• Take care to check that all the messages are correct given the context for each code path (ie. try both the ‘Yes’ and ‘No’ options to each question)
• Report back the results, good or bad

Hopefully the prompt would be big and scary

There’s a minimum of 4 questions you have to answer before anything gets formatted, more if you have to pick devices, and even then there’s a last “are you sure?” so I think that’s a fairly large safety net.

Could I ask at least one person takes it for a test drive?

I might get a chance this weekend, otherwise it’ll be late next week.

Presumably it should work on an RPC as well as an Iyo?

Hopefully it’ll run from a blank machine (i.e. saved to floppy)

Presumably it should work on an RPC as well as an Iyo?

Yes, it should work on anything after RISC OS 3.60. I checked it on ADFS on RISC OS 4.02 booted from ROM, so I think that particular combination is good.

Obviously I’ve not seen the new version yet, presumably you have replaced the outdated defaults with something more modern (e.g. 128GB for RO 4, and to keep the Iyonix using UDMA, 2GB for RO 3.7, etc)?

I’ve just tried it.

It appears to work fine on a couple of memory cards.

However, if an empty slot is chosen it gives an error message
Type mismatch: string needed at line 650

Also, it might be nice to default to scsi.

I won’t be able to try on IDE for a while.

I’ve just tried it. It appears to work fine on a couple of memory cards. However, if an empty slot is chosen it gives an error message ‘Type mismatch: string needed at line 650’

Thanks for testing the SCSI stuff, there were a few places where SCSIForm was just using PRINT"Messsage in english" rather than translating via the Messages file, and it looks like I got the one at line 650 wrong! I’ve fixed that an uploaded a corrected one.

replaced the outdated defaults with something more modern (e.g. 128GB for RO 4, and to keep the Iyonix using UDMA, 2GB for RO 3.7, etc)?

The table of known drives isn’t really intended to be used by humans, it’s mainly there for HForm’s slightly undocumented manufacturing test case (you can reply to all the questions by setting HForm$AutoReply) and so only contains those models that got used in production – so it gained a few 40G/80G models but it’d be an endless task to add every drive made by every manufacturer. Choosing ‘OTHER’ uses the values queried from the drive, which is what you generally want to do.

it might be nice to default to scsi.

Where only one of its known filing systems is present it will do so (eg. Beagleboard), but from the sounds of it you tested on Iyonix and therefore had to choose per my post of November 26th.

If you, or someone, can get back to me on using it on ADFS on the Iyonix I’ll get it released.

Choosing ‘OTHER’ uses the values queried from the drive, which is what you generally want to do.

I was thinking of the cases where you want to format to smaller than the capacity. e.g 499(?) MB for RO 3.5, 2GB for 3.7 (without patch/buffers setting) 128GB for Iyonix, so whole filesystem uses UDMA.

Where only one of its known filing systems is present it will do so

Sorry, I meant the default answer, not that I wanted to lose the ability. On an Iyonix, it would be more common to format an external drive, setting the default answer to S would remove one possibility for disaster.

If you, or someone, can get back to me on using it on ADFS on the Iyonix I’ll get it released.

Unfortunately (or fortunately from POV of bank account) I’m unlikely to have time to do the required work on the Iyonix for about a week.

As it turned out, I found time.
I formatted an old 8 GB drive and a 16MB flash (via IDE adaptor). Both worked exactly as expected.

Choose ‘OTHER’

I was thinking of the cases where you want to format to smaller than the capacity. e.g 499(?) MB for RO 3.5, 2GB for 3.7 (without patch/buffers setting) 128GB for Iyonix, so whole filesystem uses UDMA.

Oh, I see what you mean. But no, I’ve tried only to do the minimal amount of work on it because I think HForm is a dead end in its current guise – and I’m mindful that the filing system bounty for partitioning includes HForm work for someone. It does however stop you trying to format beyond the capabilities of the filing system – for example stopping at 512MB when the sector disc op isn’t supported.

the default answer to S would remove one possibility for disaster

Good idea. I’ve done that and checked it in.