HForm on RPi4

Risc OS 5.27, Nightly build from 2020.09.27

!HForm does not find an SD-card on an USB-card-reader at one of the USB3-Ports of the Raspberry-Pi4.
All other SD-card functions are working: copy, !SystemDisk, …

!HForm needs a rewrite/replacement¹ for the RPi4
I’m not sure whether anything is in the works or awaiting the outcome of the Filecore developments.

¹ Some might point out that it has needed such attention for an awfully long time.

!HForm does not find an SD-card on an USB-card-reader at one of the USB3-Ports of the Raspberry-Pi4.

That is working here, an SD card in two different readers connected to a USB3 port is found.

*fx0
RISC OS 5.27 (27 Sep 2020)
*

FILECORE HARD DISC FORMATTER 2.75 (09-Dec-17)

Is your drive connected to SCSIFS or SDFS (S/M) ? S            
Searching for devices...
SCSI::0 : 0:1.0  Direct-access        7 Gbytes Generic- SD/MMC           1.00
SCSI::5 : 0:0.0  Direct-access      112 Gbytes Generic  External         1.14

How odd!

The readers are a Trust multi-port device and a single port Integral microSD only device.

Some might point out that it has needed such attention for an awfully long time.

They did. And it got an update to version 2.75 (09-Dec-2017) which removed its ability to wipe your SATA hard disc (drive :4) by pretending it was drive 0 (for example on an ARMX6) if it was the first USB/SCSI device enumerated. From then on it enumerated the discs with an explicit note of their drive number.

I assume it was placed in a directory called ‘Caution’ to avoid the embarrassment and opprobrium that the programmer would otherwise receive, allowing him to say ‘I told you so. Ho Ho!’

In case you ask, I speak from bitter experience. As the disc map is crucial to any recovery it was kind of the programmer not to keep a copy of this vital information when initialising a disc as although all the data still resides on the initialised disc recovery is completely intractable.

It should also display the drive names and explicitly exclude from the list the drive that matches the boot drive from Boot$Dir.

i have to correct: No USB to TF card is recognized with !HForm.
‘No hard discs connected or configured’
Only the internal TF-card reader is working with !HForm on the Pi4.

Also a problem with starting up after changing the TF-card:

monitor complains ’ no cable connected’ nothing happens.
I have first to boot with Raspbian buster, shut down, switch of. and afterwards the Risc OS TF-card is working.
I am using the ‘very latest beta release candidate SD card image’ together with the nightly build ROM from 2020.09.27

was kind of the programmer not to keep a copy of this vital information

As well as offering two filesystems beginning with S and a choice of S or M which isn’t entirely clear. You don’t want any guesswork at all when formatting drives.

It should also, if the target is a readable FileCore device, ask you to confirm according to the full path and drive name. Just as an extra precaution.

The last time I used HForm was on the Beagle. I copied it to RAMdisc, dismounted and removed everything else, and that way there was only one choice.

As well as offering two filesystems beginning with S and a choice of S or M which isn’t entirely clear. You don’t want any guesswork at all when formatting drives.

Better to list and select them by typing in the name or filesystem number, rather than non-obvious hot keys.

Not sure if it’s the same problem but using an older version of HForm fixes it here. The problem is not specific to RPi4.

FILECORE HARD DISC FORMATTER 2.61 (22-Apr-12)

Is your drive connected to SCSIFS or SDFS (S/M) ? S S
Searching for devices…
SCSI::4 : 0:0.0 Direct-access 112 Gbytes Crucial_ CT120M500SSD3 0


Not sure if it’s the same problem but using an older version of HForm fixes it here

Yes the new version 2.75 is fixed but the old version 2.61 is dreadful. DO NOT USE IT! The programmer should be shot.

Not sure if it’s the same problem but using an older version of HForm fixes it here.

A quick look with an earlier HForm shows that it does display the first four slots of a multi-format reader even when empty. The current HForm only shows the memory devices.

S C S I  D I S C   F O R M A T T E R   V2.58 (12-Feb-11)

SCSI Devices found:

0 : 0:0.0  Direct-access      112 Gbytes Generic  External         1.14
1 : 0:1.0  Direct-access      466 Gbytes Samsung  Portable SSD T3  0   
2 : 0:2.0  Direct-access     3796 Mbytes Generic- SD/MMC           1.00
3 : 0:2.1  Direct-access     Unknown     Generic- Compact Flash    1.01
4 : 0:2.2  Direct-access     Unknown     Generic- SM/xD-Picture    1.02
5 : 0:2.3  Direct-access     Unknown     Generic- MS/MS-Pro        1.03


 FILECORE HARD DISC FORMATTER 2.75 (09-Dec-17)

Is your drive connected to SCSIFS or SDFS (S/M) ? S            s
Searching for devices...
SCSI::0 : 0:2.0  Direct-access     3796 Mbytes Generic- SD/MMC           1.00
SCSI::4 : 0:1.0  Direct-access      466 Gbytes Samsung  Portable SSD T3  0   
SCSI::5 : 0:0.0  Direct-access      112 Gbytes Generic  External         1.14

It should also, if the target is a readable FileCore device, ask you to confirm according to the full path and drive name. Just as an extra precaution.

And so should FAT32Form. I’ve just about, after a week, got my ARMX6 back to a usable state, although with no historic email or address book entries.

During the recovery HForm is used to reformat the SSD, then the !Boot from a recovery SD copied across. I have been wondering whether DiscKnight would have recovered anything if I’d been able to run it between those two steps.

I’m afraid DiscKnight can’t do anything if the drive is reformatted to the same shape, as both copies of the map are completely erased.

To avoid the vast majority of slip ups, the very first thing HFORM should do is check where it was run from and refuse to reformat that drive, so it doesn’t matter if your main drive is :0 :4 or whatever. Should you actually want to reformat your main disc, then asking you to copy it to the ram disc and run from there is not unreasonable.

It is surprising how firmly the stable door can be bolted after the horse has.

Of course, with Open Source (or even Shared Source), it’s completely possible for anyone to decide that these problems are undesirable and submit fixes – and that process is simplified thanks to the ability to submit them through Gitlab.

I believe that HForm is even written in BASIC, so the usual “Oh, but I don’t understand C” and “I don’t have the DDE” won’t apply.

:)

I believe that HForm is even written in BASIC

Why does it need to be distribued in unreadable crunched form? If not to discourage us from finding how it works.

“Oh, but I don’t understand C”

I don’t understand crunched BASIC.

Why does it need to be distribued in unreadable crunched form?

That’s generally how BASIC is distributed, because the interpreter is supposedly optimised for it.

If not to discourage us from finding how it works.

Fortunately, the uncrunched source is trivially easy to find thanks to RISC OS being Open Source.

That’s generally how BASIC is distributed, because the interpreter is supposedly optimised for it.

I thought there was something about (allegedly) having a specific variable set during the boot sequence so that the system crunched code on loading?
That would presumably turn up in either !Boot.!Boot or !Boot.!Run

Something like this:

Set <Basic$Crunch> ="TRUE"

is trivially easy to find

I thought there was something about (allegedly) having a specific variable set during the boot sequence so that the system crunched code on loading?

I thought that, too, but when I mentioned it recently I was told not. It’s optional, but not set as standard.

That said, the BASIC programs the drop into RISC OS distributions aren’t quite as simple as they seem. For a start, the source is stored as plain text so that the version control system doesn’t treat them as binary files and prevent useful version control actions like diffs and merging. In addition, many (including HForm) use the C Preprocessor to pull in additional header files and apply conditional inclusion of things like debug code. For example, this from the HForm source isn’t pure BASIC:

#ifdef DEBUG
Verbose%=TRUE
#else
Verbose%=FALSE
#endif

It will end up as Verbose%=TRUE or Verbose%=FALSE in the end result.

All in all, you don’t want people changing the tokenised versions and then submitting them back as patches, because it’s a faff to sort out. What is needed is changes to the text-based source files.

Something like this: Set <Basic$Crunch> =“TRUE”

I suspect that it would be

Set Basic$Crunch TRUE

You need to sign in or sign up before continuing.

Not with the link I posted, you don’t. The source is there, in full, and nicely syntax-coloured into the bargain. You can even download the source in its ASCII form using the download button, but you’ll need to include the FSNumbers header, remove the conditional stuff by hand and tokenise it (TEXTLOAD in BASIC) before use.

If you want to make changes and submit them back to ROOL for consideration and possible inclusion in the OS, then yes, you need a ROOL GitLab account – that’s pretty standard for any collaborative project like this. You’re presumably happy to have a login for this forum, so if you were planning to submit changes, why would signing up for the Git repo be any more of an issue?

Not with the link I posted, you don’t. The source is there, in full, and nicely syntax-coloured into the bargain.

The BASIC program is listed, complete with the non-basic bits, but no download button. I can’t see what the first #include does, but I’ll comment that out and see what happens.

Git sounds like a step too far for me at the moment.

Git sounds like a step too far for me at the moment.

OK, do it the nice obvious way and download a bz2 compressed tarball of a specific subset of the source or all of it, from this page

There’s enough there to (re)build the whole OS and disc image plus some other bits.

The BASIC program is listed, complete with the non-basic bits, but no download button.

At the right-hand end of the grey bar at the top of the program listing (the one that says “!RunImage” at the left-hand end). It’s a down-pointing arrow towards an in-tray, which is standard download pictogram. If you hover the mouse over it with a real browser, it even says “Download” for you in a tooltip.

I can’t see what the first #include does

It includes the Global/FSNumbers.h file, which will be substituting values for all of the fsnumber_ references in the code. Exactly what mechanism it uses for this I don’t know – I assume there must be more to it than just in-lining an ObjASM header file.

At the right-hand end of the grey bar at the top of the program listing (the one that says “!RunImage” at the left-hand end).

I am afraid that probably depends on the browser you are using … certainly using Netsurf 3.10 here the only buttons visible are Edit and Web IDE, immediately under !RunImage 79.1 KB – and they just lead to the sign-in. Nothing at the right at all. There is another !RunImage above, with buttons of Find File, Blame, History and Permalink.
Even the source is not displayed. No problem here – I will look later with Iris and Win10 FFox.