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 Ive tried to write it so it makes more sense than the Programmers > 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 _______________________________________________ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
