[Rpcemu] hdf file format

Matthew Phillips spam2011m at yahoo.co.uk
Mon Dec 17 00:18:52 PST 2018


In message <041a01d49337$7d74adb0$785e0910$@hollypops.co.uk>
 on 13 Dec 2018 Gerald Holdsworth wrote:

> ADF and HDF are, effectively, exactly the same. I have written
> documentation and published it here:
> 
> http://www.geraldholdsworth.co.uk/GuideToDiscImage/DiscImage.pdf
> 
> and I‘ve tried to write it so it makes more sense than the Programmer‘s
> Reference Manuals.
> 
> (This also includes other formats: Amiga ADF and HDF; Acorn/Watford DFS;
> and Commodore 1541/1571/1581)

This is an interesting document.  I think you could do with expanding on the
area of double-sided discs.  I think there is also a mistake on page 6 where
you say

"Double-sided disc images are stored where the tracks are interleaved. That
is, you get ten tracks of side 1, followed by ten tracks of side 2, and so
on."

I think you mean ten sectors of side 1, and then ten sectors of side 2.

The document is very much written from the point of view of understanding a
disc image file, rather than a physical disc.  What is lacking, perhaps, is
something about how the operating system sees the physical disc, and also a
distinction between double-sided formats where the user has to physically
turn the floppy disc over (where in reality the operating system sees the
floppy as two independent single-sided discs) and floppy formats where the
drive has a head for each side of the disc and the floppy disc has to be put
in the correct way up.  Obviously 3.5" discs are always the latter.  On the
Amstrad, the 3" disc drives originally supplied only had one head, so the
user flipped the disc manually to use the other side.  When people started
switching to 3.5" drives, some suppliers added a toggle switch to the drive
so that you could use both sides of a 3.5" disc in a similar way, because the
Amstrad's operating system could not actually access the other side of the
disc.  I don't know anything about BBC discs of that era: there were probably
lots of different solutions.

It is important, I think, to separate the explanation of how the operating
system accesses the disc from how the contents of the disc get stored in an
image file.  It is easier to talk about sides and tracks than to try to
reduce everything to sectors.  With ADF and HDF formats, it is just the
sector contents that are stored, but with some emulators, e.g. Amstrad and
Spectrum, the sector metadata also need to be stored, hence the more
complicated DSK and EDSK formats.

So I would split the problem into three:
1) how to translate from head/track/sector to a position in the image file
2) what order the operating system accesses the heads/tracks/sectors
3) how the disc contents is interpreted

Operating systems that can access double-headed drives might
order the tracks in different ways.  I have extracted the following from the
documentation from my !DiscImage application which you will find at
http://sinenomine.co.uk/software/

Something along these lines might be useful.

----------

For a double-sided disc, the order in which the sectors and tracks are
arranged is not obvious, because as well as moving from one track to
another, you must change sides (heads) at some point.

There are three common possibilities.  The examples that follow assume an
80 track disc:

a)  Interleaved
    Reading swaps to the other side of the disc before the track is
    incremented:
      head 0, track 0
      head 1, track 0
      head 0, track 1
      head 1, track 1
      head 0, track 2
      ...
      head 0, track 79
      head 1, track 79
    This is now the most common arrangement.

b)  Sequenced
    The whole of the first side is read in order, and then the whole of the
    second side is read starting again from track 0:
      head 0, track 0
      head 0, track 1
      ...
      head 0, track 79
      head 1, track 0
      head 1, track 1
      ...
      head 1, track 79
    Used for some older ADFS and DFS formats, as well as the 400K Acorn
    CP/M format.

c)  "Up and over"
    After reading the whole of the first side, the second side is read in
    reverse order:
      head 0, track 0
      head 0, track 1
      ...
      head 0, track 79
      head 1, track 79
      head 1, track 78
      ...
      head 1, track 0
    This arrangement is not used by RISC OS, but is used as a less common
    alternative to interleaved in some implementations of CP/M.

It is the responsibility of the identifier component of image filing
systems such as DOSFS, MacFS and CPMFS to represent foreign disc formats to
RISC OS in a suitable way.  Formats which are interleaved or sequenced will
normally be presented to RISC OS as such, and so in a plain image created
by DiscImage the tracks will be stored in the order shown above.

-------------

-- 
Matthew Phillips
Durham



More information about the RPCEmu mailing list