7

I've been looking at MicroBee floppy disk image files. They use the DSK/EDSK image file format originally created for Amstrad CPC emulators, probably because both systems use derivatives of the CP/M 2.2 disk layout.

This is a high-level image format which records information about each track and sector (but not down to the FM/MFM bits). The per-sector info includes track number, side number, sector ID, and sector size - the same info that FDCs have in the IDAM field before each actual sector data field.

My expectation was that the sector ID in the IDAM would contain the logical sector number that results from any sector skew/interleave. So for a disk with 10 sectors per track and a skew of 3 if I read the sector ID from each sector in order from one track I would expect one of these sequences of sector IDs:

0 3 6 9 2 5 8 1 4 7 or 1 4 7 10 3 6 9 2 5 8

Instead what I find is:

0 1 2 3 4 5 6 7 8 9 or 1 2 3 4 5 6 7 8 9 10

(For some MicroBee disk formats the sector IDs start at a much higher number, but the sequencing remains the same.)

And then I'm finding that the sectors containing the disk's directory information is not contiguous, either by the order they come on the track, or by the sector IDs of the directory sectors.

For instance, some MicroBee disk images have the directory on sectors 1, 4, and 7 of track 1 going by the physical order on the track, which is sectors 2, 5, and 8 when going by their sector IDs.

So I was expecting the order of the sectors would be the physical sector numbering and the sector IDs in the IDAMs would be the logical sector numbering, and that the logical sector numbering would be the number after applying the skew/interleave factor.

But what I'm finding is that the sector ID in the IDAM only tells me whether sector number starts at 0 or 1, and does not tell me anything about the skew or interleave.

Does this mean that I had it wrong and that skew/interleave is never stored in the IDAMs? Or does it mean that some OSes might store it in the IDAMs and other OSes don't?

Other possibilities are that it's a quirk of the DSK image format, or a quirk of CP/M 2.2 or a quirk of the MicroBee. It's hard to compare between systems or image formats because some are always in physical order and some are always in logical order. This info on the MicroBee disk format doesn't answer my question and I can't find any other info.

Improve this question
7
  • 1
    I suspect that what you are discovering is due to bugs or quirks in the software that was used to make disk images, and not a real behavior of real hardware. Real hardware does what you expect: the IDAM stores the actual sector number, but there is no requirement that sector numbers be ordered in any particular way. Note that in order to determine the actual physical order of sectors on a track, you need hardware which is able to read an entire track in a single revolution. If images were made on systems that couldn't do this, the original physical sector ordering may have been lost.
    – Ken Gober
    Jul 23, 2020 at 13:29
  • 1
    the gap is certainly identifiable by the controller chip, but for the OS to be able to see the physical sequence of sectors, the system needs to be fast enough that you can read the whole track in a single pass. otherwise if you ask the controller to fetch sector 1, then ask it to fetch sector 2, there is no guarantee that sector 2 immediately followed sector 1, only that a sector numbered "2" was found somewhere on the track (assuming you don't get a 'sector not found' error). disk controller chips do not typically have a "tell me what sector comes after sector n" command.
    – Ken Gober
    Jul 23, 2020 at 17:15
  • 1
    My main point here is that just because a disk image records IDAM fields, there is no guarantee that the order of sectors in the image matched the order of sectors on the original physical floppy diskette, unless you know that the person who recorded the image was using hardware capable of detecting and preserving that ordering. As a result, a disk image with non-interleaved sectors doesn't really tell you anything about whether the original hardware did or did not do interleaving. An image with interleaving is generally a good sign the original hardware did, though.
    – Ken Gober
    Jul 23, 2020 at 17:21
  • 1
    I don't know whether any programs took advantage of this, but a benefit of having the decision of what order to write sectors made at the application level is that different applications may benefit from different interleave factors. If a 16-sector 300rpm disk could support 3:1 interleave when doing a bulk read, but the application that's going to use data would take another 50ms to process each sector, writing the disk with 9:1 interleave may allow that application to process more than it twice as fast as would be possible if it were written with a 3:1 interleave.
    – supercat
    Jul 23, 2020 at 19:59
  • 1
    Note that operations that could have supported a 3:1 interleave would be slowed down by a factor of three when using a 9:1 interleave, but if one will be using the slower application more often than one performs operations that would benefit from the 3:1 interleave, the improved performance of that program may be worth it.
    – supercat
    Jul 23, 2020 at 20:01

1 Answer 1

Reset to default
7

I don't know the MicroBee, but grew up with CP/M 2.2 and 3.0 and its variety of floppy disk formats.

There were two different ways of implementing skew in use:

  • assigning the low-level sector IDs in a non-contiguous order, and simply access sectors by a 1:1 mapping from their logical number, resulting in sector ID sequences like 0 3 6 9 2 5 8 1 4 7,
  • assigning contiguous sector IDs like 0 1 2 3 4 5 6 7 8 9, and having the software (BIOS) translate from the logical sector number to the low-level sector ID.

The first approach meant you only had to consider skew in the formatting routine, while the second needed to do some sector ID translations in each and every disk access.

By the way, there were a lot more parameters to consider when trying to read a CP/M disk from a foreign system, e.g.

  • recording format FM or MFM,
  • physical sector size (popular from 128 to 512 bytes),
  • number of tracks/heads (40 or 80, single oder double sided),
  • track order with double-sided disks (sides interlaced or second side after first one),
  • allocation block size (typically 1 or 2 kBytes)
Improve this answer
7
  • Yes the DSK image file format is higher level than FM vs MFM but has most of the other info with sides always interleaved. It also does not include any info on allocation blocks. Working with disk images is often more complicated than I'd expect but I'm sure it's easier than if I were trying to use foreign floppies in an actual disk drive (-:
    – hippietrail
    Jul 22, 2020 at 14:15
  • Does somewhat standard terminology exist to clearly differentiate between the two approaches? It seems that physical vs logical won't be enough since that could also suggest numbering from 0 vs numbering from 1 etc.
    – hippietrail
    Jul 22, 2020 at 14:31
  • Most probably, you have to write translation code that maps a "logical sector number" (although that term never existed in CP/M, IIRC) to a Track/Head/Sector address. When reverse-engineering a CP/M format, you hopefully have some longer text file on a sample DSK image where you can check if you got it right.
    – Ralf Kleberhoff
    Jul 22, 2020 at 14:44
  • If an implementation allows a file's sectors to be stored in any arbitrary sequence, I would think the only part of the system that would need to care about ordering would be the allocate-next-sector routine, and having that be configurable based upon the intended usage of a file may make it possible to achieve better performance for most tasks than would otherwise be possible, at least when using software that could exploit that.
    – supercat
    Jan 12 at 18:06
  • 1
    @RalfKleberhoff: The Commodore's 1541 floppy drive had a byte in RAM that would control the interleave used when writing, and different fast loaders differed as to what interleave they could support when reading. Saving files with the optimal interleave for the fast loader one was using could yield much better performance than would be achieved if the interleave was too tight.
    – supercat
    Jan 13 at 15:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .