HForm

Is this the right section of the forum to raise some moans and suggestions about the ‘user interface’ (sic) of HForm? I’ll assume it is unless directed elsewhere.

I just used HForm for the first time in heaven-knows how long. This was to reformat a 64GB SD card in the front slot of my ARMiniX as what I’ll call ‘filecore’ (Acorn) format to duck some of the questions/problems involved.

I’d asked about this previously elsewhere so had the good advice that it was the SCSI system I wanted NOT ADFS or SDFS. But even given that the user interface seemed pretty problemmatic to me for newbies or anyone who’d not used HForm for a long time. Hence the following long moan and some questions and suggestions to try and make this safer and clearer.

My first problem was tiny black system text top-left in a full white HD screen. This made reading the text hard given my lack of perfect eyesight. I realise an alternative presentation may be difficult to arrange for all setups, but not a good start from my POV.

The next was the choice between ADFS SCSI and SDFS followed by (A/S/M).

Erm… that gave me real pause, particularly as I wasn’t clear if the last letter was an ‘M’ at all. I can see the problem that SCSI and SDFS both start with ‘S’, but if (as I guess) the ‘M’ was chosen to mean ‘Main HD’ it might be good if this were explained clearly at this point. So the line had something like

ADFS SCSI MainHD(SDFS) before the (A/S/M)

In addition, might it be safer to have the user type in a fuller name? So type in ‘SCSI’ rather than ‘S’ for example to make sure the user knows what they are choosing? When I tried that it was rejected. I had to choose ‘S’.

Since I was reformatting the SD card because of a problem I was then puzzled by the ‘defect’ options. Apart from the ‘leave as is’ I had no idea what they meant or which to choose. So I abandoned my first try and read HForm’s !Help (sic). This seems to say no more than RTFM. In this case RTFM means ‘the user guide’.

Fortunately, I do have copies of various old Acorn User Guides. So I read them about HDForm. None shed any light on the ‘defects’ choices. So can I request that someone who really understands HForm and the modern systems actuall write a more details !Help for it, please?

I then had a second try and seem to have succeeded OK. I did choose to leave defects as is, and to format rather than initialise. I realised this would take longer and thrash the SD card. But I wondered/hoped that this might improve the chance that it would pick up and fix or identify any defects or problems with it. However again, I have no idea because of lack of clear info. So again, some details in !Help to advise users might be a good idea I think.

Similarly I left the whatever size at 8192 as suggested. No info on if any other choice would have been ‘better’. Ditto for the mysteries of ye olde cylinders, heads, etc. All a bit arcane for an SD card. Fortunately I wasn’t asked to sacrifice a goat or find a unicorn… ;→

The card is ‘good’ now according to discknight. But of course at this point I haven’t put anything on it. No doubt I’ll find out more later. :-)

In some ways I guess using HForm should be a ‘scary’ process as it isn’t something most people should use at the drop of a hat. But when you need it you may be very anxious and haven’t used it before (or for so long you’ve totally forgotten). And these days there are also puzzles like what the difference are between ADFS, SCSI, and SDFS given details like SCSI probably means USB, and so what is the difference between ADFS and SDFS anyhow! 8-]

Moan over. :-)

Jim

The “defects” thing is an anachronism from the old days when defects detected in formatting would need to be mapped out. This was important with ST506 drives, sometimes important with early IDE drives, and not very important since the advent of technologies like SMART.
So…. Ignore it.

SDFS – FileCore filing system that talks to SD cards.
ADFS – FileCore filing system that talks to IDE drives and floppies.
SCSI – apparently a catch-all for “other stuff”? ;-)

SDFS – FileCore filing system that talks to SD cards.
ADFS – FileCore filing system that talks to IDE drives and floppies.
SCSI – apparently a catch-all for “other stuff”? ;-)

That’s not right, is it? SDFS is for cards plugged direct into the motherboard (be it Raspberry Pi, Panda, BeagleBoard or whatever), and SCSI is for any storage device connected via USB (including built-in card readers which are connected by a ‘hidden’ internal USB hub).

SDFS is for cards plugged direct into the motherboard (be it Raspberry Pi, Panda, BeagleBoard or whatever),

That’s one source of confusion which crops up. My ARMiniX has an SD card for its main on-board HD. It is NOT connected via USB. But I can plug SD cards into a slot on the front of the ARMiniX. These ARE connected via USB. Just to make it even more confusing for people, it comes up as ‘SCSI’ not ‘USB’.

But beyond that is SDFS any different to ADFS apart from being a term for the main on-board card? Or is the difference that SDFS works with dual partition cards so you can have a Fat partition for the ROMs, etc? Or both, or what? I’ve never seen a clear definition to distinguish SDFS from ADFS.

Also,I’ve lost count of how many times someone I’ve been working with has assumed that the on-board SD card I use must be ‘USB’. And with no real SCSi hardware, using that term for removable USB storage devices can be somewhat of a puzzle to someone not familiar with the evolutionary history of RO hardware.

These confusions may well lead people into trouble. Chances are some people will go into a shop, buy an SD card and then want to format it filecore for use with a RO machine. They then try HForm… Ok, best of three? ]8-/

And I don’t even know if SD/SDHC/SDXC cards have anything that HForm/verify/etc would handle as a ‘defect’. Note both the removable I’ve reformatted and my main ‘hard disc’ are SD cards, not SSDs of the kind I use in my Linux boxes.¹

All I know is that I had an SD card that discknight couldn’t fix and refused to accept more files. Given the lack of knowing if verify, etc could do anything I just decided to reformat the card as there was nothing on it that I was concerned about losing. That then led me to (re)discover the joys of using HForm.

Bottom line though, isn’t my individual puzzles. But how someone not very familiar with RO systems would navigate the use of HForm and know what is appropriate (or disasterous!) for their specific situation. I muddled though, but others may not.

Jim

¹ That raises another issue about how on earth you can tell if a reader or slot can cope with SDXC or SDHC other than trying and seeing if the result is a mess… But that isn’t HForm’s responsibility.

That’s one source of confusion which crops up. My ARMiniX has an SD card for its main on-board HD. It is NOT connected via USB. But I can plug SD cards into a slot on the front of the ARMiniX. These ARE connected via USB. Just to make it even more confusing for people, it comes up as ‘SCSI’ not ‘USB’.

That’s what I said isn;t it, that if it’s plugged into the main board, it’s SDFS.

But beyond that is SDFS any different to ADFS apart from being a term for the main on-board card? Or is the difference that SDFS works with dual partition cards so you can have a Fat partition for the ROMs, etc? Or both, or what? I’ve never seen a clear definition to distinguish SDFS from ADFS.

It’s just the same as on previous RISC OS systems, each different way you attach a storage medium has a different filing system. On a RiscPC You could have ADFS, IDEFS, ATAFS, SCSI etc. All of which were Filecore formatted drives, but connected to different filing systems (motherboard, Simtec IDE podule, RapIDE podule & SCSI podule in this case). In modern systems we have SDFS for storage plugged straight into the main board, SCSI for storage plugged in to USB and ADFS on legacy systems like RiscPC & Iyonix. We’ll not go into things like FAT32FS, SparkFS, & ShareFS here!

Also,I’ve lost count of how many times someone I’ve been working with has assumed that the on-board SD card I use must be ‘USB’. And with no real SCSi hardware, using that term for removable USB storage devices can be somewhat of a puzzle to someone not familiar with the evolutionary history of RO hardware.

I’d agree that SCSI: might have been better named USB: but changing hat now might break a variety of things.

These confusions may well lead people into trouble. Chances are some people will go into a shop, buy an SD card and then want to format it filecore for use with a RO machine. They then try HForm… Ok, best of three? ]8-/

I agree it probably needs some better documentation, but once you select a filing system, it does present you with a list of attached devices, so if your card doesn’t show up there, then you know you’ve picked the wrong one!

And I don’t even know if SD/SDHC/SDXC cards have anything that HForm/verify/etc would handle as a ‘defect’. Note both the removable I’ve reformatted and my main ‘hard disc’ are SD cards, not SSDs of the kind I use in my Linux boxes.

As Rick said, ‘defects’ are really a throwback to ST506 drives, so the default choice of ‘Leave as is’ is sufficient. On the whole, once you’ve chosen the filing system, HForm does present sensible default choices for each stage.

Bottom line though, isn’t my individual puzzles. But how someone not very familiar with RO systems would navigate the use of HForm and know what is appropriate (or disasterous!) for their specific situation. I muddled though, but others may not.

I’m sure ROOL would appreciate you writing a better !Help file.

That raises another issue about how on earth you can tell if a reader or slot can cope with SDXC or SDHC other than trying and seeing if the result is a mess… But that isn’t HForm’s responsibility.

The same way you tell for any other card reader on any other system. Look to see if it has the SDHC/SDXC logo on it, or failing that, suck it and see. This isn’t a specific RISC OS issue.

That’s not right, is it? SDFS is for cards plugged direct into the motherboard (be it Raspberry Pi, Panda, BeagleBoard or whatever), and SCSI is for any storage device connected via USB

That’s sort of what I was getting at. SDFS for built-in SD readers. ADFS is irrelevant (no IDE/floppy interface). The rest (via USB) comes under “SCSI”. It can get “complicated” (SD card reader plugged into USB). ;-)

I’ve never seen a clear definition to distinguish SDFS from ADFS.

Different filing system. My A5000 had two internal harddiscs (ADFS), four external IDE harddiscs (IDEFS) and two SCSI harddiscs (SCSIFS). That’s just “how it is”. ;-)

That raises another issue about how on earth you can tell if a reader or slot can cope with SDXC or SDHC other than trying and seeing if the result is a mess… But that isn’t HForm’s responsibility.

That’s how it goes for anything. I can’t speak for SDXC compatibility (though IIRC CJE is selling a 128GB SD card for the Pi so I guess it works); however having been into computer stuff during the transition between SD and SDHC, I’ll just say that __most_ things do not fail gracefully. Little digital cameras, older mobile phones, card slot readers, their usual response to being given an SDHC is to freeze solid. Thankfully plain-SD is old enough now that most things you’ll find these days won’t freak when given >2GB.

That’s sort of what I was getting at. SDFS for built-in SD readers. ADFS is irrelevant (no IDE/floppy interface).

ADFS is not only “irrelevant”¹ on the new hardware isn’t present in the ROM, however a bit more clarity would be handy. As a long term user the specific icon/file system is not a problem, but I can see newbies having problems.

¹ Mind you it becomes rather relevant if you have an application/utility that insists on using ADFS SWI’s

Why is there a need to choose the filing system, what does it matter to the person formatting the disc. Couldn’t all the attached discs just be listed? The filing system is only the route to put the same filecore format on the disc. If you format the disc on scfs you can use it on scsifs

I had to delve into !Hform myself for the first time in years recently and I agree with Jim its very daunting.

Why is there a need to choose the filing system, what does it matter to the person formatting the disc. Couldn’t all the attached discs just be listed? The filing system is only the route to put the same filecore format on the disc. If you format the disc on scfs you can use it on scsifs

Imagine you had a 32GB SanDisc SD card in your Pi, and wanted to format another 32GB SanDisc SD card in a card reader. If HForm just listed the available devices but not which filing system they were connected to, how would you tell which was which?

It might be nicer if HForm presented the filing systems as a list with some explanation, eg.

1) SDFS (plugged in to the main board)
2) SCSI (Connected via USB)
3) ADFS (Motherboard devices on legacy systems)

and you pick 1, 2 or 3 rather than A, S or M. It’s also more easily expandable than the current way.

But filing system name doesn’t locate the device. You dismiss ADFS as legacy but will a sata port end up appearing as ADFS – it can’t be much different to pata. If I have a SCSI interface on PCI on an Iyonix can SCSIFS be made to work with that – does that count as motherboard? You can’t ‘generally’ say that sdfs is a motherboard FS

If Hform listed attached discs it knows which filing system they are attached. It can add the FS to the disk list display if you think it’s useful

Why not get HForm to innumerate all drives on all filing systems it supports & finds, giving Filing System name and drive info:e.g.
1. SDFS: 64GB Sandisk SD card
2. SCSIFS:00:32GB Kingston SD Card
3. SCSIFS:01:2GB Kingston USB PEN
4. SCSIFS:03:240GB SSD Drive

ADFS support either removed or not listed when not present/no devices found

FormatDisc is a planned future addition to the DiscTools suite.
The standard formatter included with RISC OS, HForm, isn’t particularly friendly to use, and doesn’t always make the best use of the space available. It’s also unlikely to survive the upheavals that will be needed to FileCore to support discs bigger than 256 GB (though it might just stretch to 2 TB with 4K sectors). For this and other reasons, I’ve been in the process of writing an all-new formatter for some time. In fact, RISC OS Pi and NOOBS both use a prototype version, but it needs more polish before it’s ready for general release.
Please come back later for full details

Sounds like Ben Avison is your man

I’m sure ROOL would appreciate you writing a better !Help file.

I did think of that. But my problem is that I don’t know enough to ensure that what I wrote wouldn’t mislead someone else in other cases/circumstances with disasterous results! Better to see baffling ‘instructions’ than ones that seem clear… but wrong!

Pleased to hear about FormatDisc.

I succeeded because Andrew Rawnsley told me in clear and simple terms that for my situation ‘SCSI’ meant ‘USB devices’ so was the one to use. And that SDFS was only if I wanted to reformat my main on-board device so NOT to use that. And that ADFS was a deceased waterfowl.

However I assume some people will be using a USB connected main ‘HD’. So I wonder about how we cover the range of circumstances and explain this clearly. Indeally, any description or instructions/help will ensure that the main HD someone is booting from is clearly distinguised, etc.

Jim

I can’t speak for SDXC compatibility (though IIRC CJE is selling a 128GB SD card for the Pi so I guess it works);

Does the fact that I formatted a 64GB SD card using the front slot of an ARMiniX establish the slot is SDXC OK? Or might the formatter simply not know that something was wrong? The difficulty here is that various items just say ‘SD’ on them but plainly work for cards > 2GB. Does having ‘SD/MMC’ or even ‘SD/MMC/RS-MMC’ give any idea if a reader/slot can cope with > 32GB cards? Is there a way of having the USB system probe a card slot or reader to determine if it is SD, SDHC, or SHXC?

Or does such a slot/reader simply not work at all for a card that is ‘too big’? So if it works, it works?

Jim

Is there a way of having the USB system probe a card slot or reader to determine if it is SD, SDHC, or SHXC?

Most USB mass storage devices (cards readers, memorysticks, sata-usb adaptors) present themselves as SCSI thats why we use SCSIFS. It is possible for a mass storage device not to use SCSI over USB but we don’t have drivers supporting other protocols – and it wouldn’t work with SCSIFS.

The transition from SD to SDHC involved changes to the low-level protocols that meant an old reader would be relatively unlikely to be able to access a new card. The situation’s different with SDHC to SDXC – the main thing is just that they come pre-formatted with exFAT rather than FAT – that’s just a software change. If you’re reformatting it to FileCore format, it’s therefore basically irrelevant whether a card is SDHC or SDXC.

Most USB mass storage devices (cards readers, memorysticks, sata-usb adaptors) present themselves as SCSI thats why we use SCSIFS. It is possible for a mass storage device not to use SCSI over USB but we don’t have drivers supporting other protocols – and it wouldn’t work with SCSIFS.

IIRC, SCSISoftUSB also supports the subclasses for SFF-8020 and SFF-8070. Never had a device that used those subclasses however.

The situation’s different with SDHC to SDXC – the main thing is just that they come pre-formatted with exFAT rather than FAT – that’s just a software change. If you’re reformatting it to FileCore format, it’s therefore basically irrelevant whether a card is SDHC or SDXC.

Ah! To make sure I’ve understood that:

That means that once a reader or slot shows it can read/write cards above 2 GB I can expect it to work with Filecore format cards both above and below the 32GB SDHC/SDXC ‘split’? For filecore I can ignore any distinction between SDHC and SDXC when using cards in readers or the slot on my ARMiniX?

FWIW All the cards I have are > 2GB. 4GB is the smallest, then a few 8 and 16GB, and then two (filecore formatted) 64GB ones.

Given the above, if I format an SD card as ‘Fat’ using either Fat32Fs or something like the tools in Linux GParted can I make the same assumption? i.e. if it formats to the size according to the formatting software, it should be fine on any reader and in the slot given they work with 4GB and 8GB cards?

So I can stop worrying about this as an issue? If so, excellent news.

Jim

I succeeded because Andrew Rawnsley told me in clear and simple terms that for my situation ‘SCSI’ meant ‘USB devices’…

However I assume some people will be using a USB connected main ‘HD’. So I wonder about how we cover the range of circumstances and explain this clearly.

I think you just answered your own question there, if it’s a USB connected device, then it’s SCSI, as Andrew correctly told you. It’s that simple.

I think you just answered your own question there, if it’s a USB connected device, then it’s SCSI, as Andrew correctly told you. It’s that simple.

Not for (new) users who don’t have Andrew or some equivalent kind person to explain this mystery to them. I could have guessed that SCSI really meant USB. But should the user need to play such guessing games when wanting to reformat a device? The results of a mistake can be rather a severe penalty.

If it means “USB Memory” for modern systems then maybe it should say so. Or even dare to explain this in !Help rather than “Read the User Guide (which you may not have)”.

And if “choices” like cylinders, defects, etc, are irrelevant, why add the confusion for a standard reformat. Might that be better for an ‘advanced’ mode so to avoid making puzzles for newcomers? The problem here is what HForm does as such, it is the very confusing way it presents and asks questions.

I have the feeling that the current behaviour of HForm is the result of two factors;

1) Most users rarely need it once they are using a working machine.

2) It’s presentation suffers from the tendency of experts (who would be writing something like a formatter) simply assuming “everyone knows that” because they and the people they know have done for years. Not even a conscious decision.

Its all too easy to do that. After I’d been teaching a practical electronics lab for about 5 years I found I was getting irritated by student questions that seemed “obvious”. I then realised that I was unconsciously feeling “I explained that before!” But of course to a different set of people… All too easy to do this sort of thing unawares.

I’ll look forward to FormatDisc. :-)

Jim

Not for (new) users who don’t have Andrew or some equivalent kind person to explain this mystery to them.

What Andrew said is only true for an arminix board and how you use it. He is trying to stop you formatting your sd hard disc accidentally. There’s nothing stopping you using the internal sdfs card reader to format any of your sd cards – In fact it would probably be safer as then you have removed the card that you don’t want to accidentally overwrite.

Im not saying Andrew is wrong I’m saying it is not advice you could put in a help file unless you want to be machine specific and dictate how to use it.

Im not saying Andrew is wrong I’m saying it is not advice you could put in a help file unless you want to be machine specific and dictate how to use it.

Indeed. This is an example of why I wasn’t myself willing to try improving the !Help file and/or the dialogue. Needs to be done by someone with a fuller understanding of the range of situations, etc. What I might be able to comment on is how clear any re-write might be. But even then, if I get familiar with it I cease to be as easily able to spot problems for newcomers, for reasons I’ve already exampled. Human nature for people to take for granted what they’re familiar with. I realise this area is a very difficult one. But for something like a formatter I think it becomes very important.

Jim

I would advise parking this as there’s a good chance any work here would be obsoleted by a release of FormatDisc. Given we’ve got the Filesystem Improvements bounty currently underway, there’s a good chance FormatDisc will be appearing sooner rather than later.

My one potential concern with FormatDisc is that having to buy a commercial tool simply to format a disc/card seems rather odd, and new users won’t be impressed that RISC OS can’t even format media itself. Other than that, I look forward to it.