HForm for RISC OS 3.1

Does anyone have a copy of (or know a source of) HFORM for RISC OS 3.1 that doesn’t have anonymous variable and procedure names e.g. Cc%, L%, PROCM etc. I think the ROOL sources only go back as far as HForm for 3.7 which I believe will not run on 3.1

Most drives spinning rust, SD cards, Compact Flash and MSATA drive that are obtainable NOW and not decades old are too large to be formatted with the 1992 version of HForm. We have though found that if we format them with a Later version of HForm on RISC OS 4 they will work. We (and our customers) would like to be able to do the formatting on the RISC OS 3.1 machine the drive will be used on.

@ Chris

So the official HForm version distributed with RISC OS 3.1 was HForm 2.19 which is also the one chrunched. This version requires a wimpslot of 512KB so it’s suitable for most Archimedes.

The release you want, instead, is (IIRC) release 2.56, which is not crunched so easier to modify, BUT that release seems to require a wimpslot of 2000K.

I have here an “hybrid” version I made for myself, if you want to try it I’ll send it over, but please no warrantee it works fine.

Also (I know you know this already, so just a reminder), formatting large discs with the old Archimedes can require to make quite few coffee (errm tea!) :D

Please do send us a copy. TIA.

no problem, packing it now for you guys :)

HForm 2.70 worked on RISC OS 3.10, the check in message specifically mentions so (on an A5000).
It’s possible a change after that broke something but as at 29-Nov-2014 the ROOL HForm would be OK. Why not try the latest? You might be pleasantly surprised.

@ Sprow

The version distributed with RO5 HardDisc Images seems to be the crunched one.

Where can I find the 2.70 not crunched?

I can see the !HForm 2.76 on RO5 checks for min RO 3.10 and still uses only 512K, so good recommendation sir! Thanks :)

HFORM might run on older machines, but out of the box it will produce discs which wont work with anything before 5.2x due to using an ID Len larger than the maximum on older OS’s (21 vs 19).

You should be able to lower the ID Len by using a LFAU 4x larger than the default offered by HFORM, but I don’t have any older systems now to verify such as disc will be understood.

Does anyone have a copy of (or know a source of) HFORM for RISC OS 3.1 that doesn’t have anonymous variable and procedure names

You’ll want the uncrunched HForm 2.56, which is attached to my RISCOS 3.20 ROM thread on StarDot

HFORM might run on older machines, but out of the box it will produce discs which wont work with anything before 5.2x due to using an ID Len larger than the maximum on older OS’s (21 vs 19).

Sure about that? The bounds HForm uses are:

IF FileCore <= 2.98 THEN
  max_idlen%=15
ELSE
  REM Allow big directories too
  IF FileCore <= 3.74 THEN
    max_idlen%=19
  ELSE
    max_idlen%=21
  ENDIF
ENDIF

Guys,
Sprow did not answer my original question, so I did some digging, given that Chris’s original question was about the un-crunched version of HForm.

We all can find the latest ROOL version of HForm in an un-crunched for here:
https://gitlab.riscosopen.org/RiscOS/Sources/Utilities/HForm/-/blob/master/bas/!RunImage

Please note, historically the release version of HForm has always been in the messages, however in the gitlab it’s available here:
https://gitlab.riscosopen.org/RiscOS/Sources/Utilities/HForm/-/blob/master/VersionNum

The browsable version is always the latest, so to get to Sprow recommended release 2.70 you’ll need to switch to branch HForm-2_70, here:

https://gitlab.riscosopen.org/RiscOS/Sources/Utilities/HForm/-/tree/HForm-2_70

And then look at the `bas` subdirectory where the un-crunched release resides.

Hope this helps :)

Thanks lads. A lot of information. We will have to do some testing!
I was going to say that the 16GB drive we formatted to 512MB on a RISC OS 4 Risc PC ‘seemed’ to work fine in an A4000 but that was done on ZIDEFS with the ZIDFS hacked HForm for 3.1!

@Sprow thanks for the clarification, you are correct that I was trying to format a drive for an older OS on a newer one.

o.k. test results:
Using the mSATA drive that had previously been formatted on the ZIDEFS hacked HForm:
HForm 2.76 reported “Drive does not have a valid filecore partition”
We then formatted it and everything seems to work as expected!

HForm 2.76 reported “Drive does not have a valid filecore partition”

You missed out the important bit that although HForm reported no valid filecore partition, we were still able to read and write to the mSATA drive as formatted by ZIDEFS (using an A3020’s ADFS interface)