HForm

Steve’s link re “Filesystem Improvements bounty” Includes:
Deliverables:
C source code to handle partitions within RISC OS
Replacement HForm utility
Updated source code to FileCore, and if applicable its clients/filer front ends
Documentation of the new partition support, and any known limitations

So it seems our fears are misplaced:-)

n.b. I can’t recall seeing before that Bounties:
Filing system improvements (step 2) was underway
Or
EDID support (monitor auto-detection) was also underway
Great news:-)

I just bought a new hard drive for my BBxM today (I can hear that the existing one is about to fail).

First problem: the smallest drive I could get was 500 GB. We can’t use all of that, can we? But no-one sells new drives as small as 256 GiB these days.

Second problem: HForm 2.65 (12-May-2013), from a freshly downloaded HardDisc4 archive, doesn’t suggest an LBA flag, so I have to specify everything in CHS. How quaint. All its suggested values are the maximum values it reads from the drive, so it ends up formatting it as about 465 GiB. That isn’t going to work, is it?

How is anyone supposed to know what to do to get a drive formatted in a way that will work?

I presume I have to guess a value for cylinders that will end up with a tolerable drive size.

We have a problem, guys. It needs fixing.

no-one sells new drives as small as 256 GiB these days.

Really? Twenty seconds found this selection, and that’s out in the garden where the iPad likes to pretend WiFi doesn’t exist.
http://www.amazon.co.uk/s/ref=nb_sb_noss?url=search-alias%3Daps&field-keywords=USB+hard+disc+80gb

How is anyone supposed to know what to do to get a drive formatted in a way that will work?

I think if you try to format, set a custom drive shape, and choose “Other”, there ought to be an option to select the LBA flag. Got this from http://www.riscos.com/support/users/userguide3/book2ab/e_10.html#marker-9-10 – so I’m guessing CHS is the uninitialised default setting.

That isn’t going to work, is it?

As long as the drive is validly formatted (hasn’t got its panties in a twist), you can always format smaller and sacrifice some space. Back in the days of RISC OS 3.7, I used to partition (Simtec IDEFS) my drives at 499MB (instead of 512MB) so I could use a smaller LFAU. The excess? Since it was a 2GB drive and I had eight partitions already, I just formatted the excess as a valid partition (might as well), and just never mounted it…
I also used an 800MB drive ripped out of an old PC. Stuck it into my A5000, formatted it to 512MB, ignored the rest…

I’m fairly sure that LBA is “automagical” now.
On my RISC PC you need LBA for an 80GB drive and that version of HForm gives you an option. I’ve got 2 of those (IDE PATA) in my RISC PC and three “spare” which I ordered of amazon for about 9 quid each about a week ago.
For those I used the CHS values first, and got a 4GB disc :-(
So I’m fairly sure that it’s impossible to get anything much above that using CHS, or certainly with any consumer discs.
As the discs go larger you waste disk space, which might be why you are seeing such a large discrepancy. That I would agree is rubbish.
It worked without any problems, I didn’t realise for a month or so. When I noticed (After I ordered another 4 of ‘em) I did a quick google search to get the fudged, I mean LBA values.

<rant>CHS isn’t quaint, they are the correct values 

It’s just x86 hardware is generally so ****** that they’ve had 

to come up with yet another horrendous hack – and it is seriously awful,

like everything that is derived from a x86.

That awful frig that we have is LBA, based on 32 year old tech. that was pretty crud at the time.< /rant>

My 2TB Drive however is formatted ext3 and plugged into my router as a NAS, and mounted via Lanman98 on my RISC PC, my ArminiX, my Pi (and some other dirty hardware running an even dirtier OS) ;-)

Just ideas….

Really?

80 GB? When do you think that was new, Rick?

Malcolm – no, you’re thinking of the hack upon hack that was applied to CHS on x86 machines. Read this and weep: http://en.wikipedia.org/wiki/INT_13H

I believe LBA was originally used on SCSI as a way to address blocks on devices regardless of the underlying topology (sector, head, cylinder doesn’t make much sense on a tape streamer), and it was then applied to the second generation of IDE hard discs when the technology advanced to the point that a track (cylinder?) might have differing numbers of sectors on it depending upon how far it was from the centre of the disc. Something I’m surprised never happened with floppy discs (the outer track must surely be more than twice the covered distance of the inner track).

That said, I’m up for bashing x86 … just because. Do we need a reason? Look at that horrid excuse of an instruction set!¹ And don’t think I will forget the amount of stuff polluted with __near and __far pointers, not to mention the hoops we had to jump through in order to allocate a “big” wodge of memory.¹

¹ It ought to be clear this is DOS era 16 bit 386/486ish stuff. After that, I gave up caring and just used VisualBasic…

@ Dave: depends upon your definition of “new”. In this context, I define “new” as unused, still in its commercial wrapping.
If you are looking for one made yesterday, then no, no such thing exists. There’s no market for devices that small any more.

I really, really wish you were wrong Rick, now the bad memories are coming flooding back.
I really am weeping now ;-)
But I thought the same applies to LBA (or the way it’s implemented in IDE anyway), could be wrong..again… ;-)

Reading the wikipedia entry for LBA makes me weep even more!

I’ve used HForm 2.65 (13 May 2013) a few times recently on a SanDisk 64GB SSD via three different interfaces (IDE-SATA in the Iyonix, USB-SATA salvaged from a Seagate USB spinner, and most recently a USB-SATA from eBay).

One very surprising thing is that HForm never mentions LBA and always asks me for the CHS values. The drive definitely supports LBA, because part of its label information says: “LBA: 125,045,424”. Why should HForm behave as it does?

The other surprising thing is that, when I used HForm most recently, the CHS values it offered were way different from how it had been formatted last time. Sorry, I didn’t write down the old numbers, which are of course blown away.

The good news is that I was able to copy the BBxM’s hard drive’s contents over to the SSD, substitute the SSD, boot from it and use it, for the first time. Victory for eBay cheap and cheerful in this case.

Do you know if the SSD’s improve compilation time? At the moment the 2.5 and 3.5 spinning discs in my Iyonix compile a rom image after a change to a rom program in about 120 secs. It would be nice to reduce that significantly.

To answer my own question. I bought a 120GB sandisk ultra II and it doesn’t work on the pata – sata adapter I have on my Iyonix. It appears on the iconbar but that is as far as it gets. It does work via USB but its wasted there. I have discovered that another 2.5in drive I have doesn’t work either. So it may be the adapter but as the 2.5 drive that does work is the oldest I have I wonder if some protocol has been dropped on later drives.

To answer my own question. I bought a 120GB sandisk ultra II and it doesn’t work on the pata – sata adapter I have on my Iyonix. It appears on the iconbar but that is as far as it gets. It does work via USB but its wasted there.

Just wondering whether this change is relevant?

Could still be a fail.

Could the change be relevant? Dunno, but it does remind me of something I asked/talked about a long time ago…

Service_IdentifyDisc seems to me to be outdated in its aims. It was sensible when discs only had a single partition. Nowadays it’s common for discs to be partitioned (and sensible in view of the hugely increased sizes of discs). What we need, ISTM, is Service_IdentifyPartition instead.

So we could for example have a disc of a substantial size, with a RISC OS partition and a DOS partition. Each filing system only claims the partition that it has any business to claim.

Just wondering whether this change is relevant?

Don’t think so. I managed to run HForm on it while it was on the IDE interface – though it gave wild numbers and eventually crashed when HForm tried to dismount it.

Thinking about it, as it works on usb I assume the usb-sata interface is interpreting the SCSI commands riscos is sending via usb and the drive is happy with that but it’s not happy with the ATA commands sent directly through the IDE interface.

If this is correct that would mean that a sata interface would require more work than just using the sata controller as a drop in replacement for a pata controller.

Hopefully work on the iMX6 will will result in a working sata interface.

Do you know if the SSD’s improve compilation time?

Sorry, I haven’t been ignoring you. I had a little project I wanted to do, and then I found that booting with just the SSD was unreliable. It may have been caused by the USB switch/hub which is also connected to a permanently powered RPi. I need to do a few more experiments to verify problem and cure, then I’ll set two builds going, one with spinning rust and one with the SSD.

No need Dave I bought an SSD but it’s not fast enough over USB, and anyway, I don’t want my data on USB while I’m playing with the usb stack. I’ve sent for a different pata/sata adapter to see if my SSD works with that.