Defining Disk Image Dump Standard

On Fri, 26 May 2000 Vintage Computer GAWD! wrote: > On Fri, 26 May 2000, John Foust wrote: > > > Below is the section from the manual that describes their > > file format. > > > > Each sector written to the file is optionally preceded by an > > 8-byte header record of the following form: > > > > > > +------+------+------+------+------+------+----------+ > > | ACYL | ASID | LCYL | LSID | LSEC | LLEN | COUNT | > > +------+------+------+------+------+------+----------+ > > > > ACYL Actual cylinder, 1 byte > > ASID Actual side, 1 byte > > LCYL Logical cylinder; cylinder as read, 1 byte > > LSID Logical side; or side as read, 1 byte > > LSEC Sector number as read, 1 byte > > LLEN Length code as read, 1 byte > > COUNT Byte count of data to follow, 2 bytes. If zero, > > no data is contained in this sector. > > > > All sectors occurring on a side will be grouped together; > > however, they will appear in the same order as they occurred on > > the diskette. Therefore, if an 8 sector-per-track diskette were > > scanned which had a physical interleave of 2:1, the sectors might > > appear in the order 1,5,2,6,3,7,4,8 in the DOS dump file. > > > > After the last specified cylinder has been written to the DOS > > file, AnaDisk returns to the Main Menu. > > This is a good start. The header should include a byte that contains a > flag indicating the status of the sector (good, bad, etc).

This seems rather "high level" if you are wanting to preserve the exact disk contents. Though it may be all you can do using a standard PC floppy controller.

> What about odd formats? I take my experience from the Apple ][. You had > stuff like half-tracks and quarter-tracks (the head was stepped half-way > or half of half-way between tracks to store data), odd disk formats > (custom sector sizes, custom sector layouts, etc.), synchronization > between tracks (one copy protection scheme was to write a two tracks so > that if a seek was done from one track to the other, a specific sector > would be expected under the head as soon as it got to the next track).

I would like to be proved wrong, but there is no way to account for every possible strange thing that could be done in terms of custom formats, copy-protection etc., at least in a high level file format that doesn't just sample the bits coming from the disk.

It would be possible to construct a device for archiving disks at a very low level. I guess this would be similar to commercial floppy disk duplicators, except writing data to a file instead of another floppy. The bit stream from the disk would be sampled at a very high rate to allow for various tricks that could be done. Or by modifying a floppy drive, the analogue signal from the read head could be sampled. Tricks like "pulsing" the drive motor during a write to vary rotation rate, changing the data rate mid-write (e.g. 2us vs 4us per bit cell), changing precompensation values mid write, using custom non-MFM-or-GCR coding methods, reducing drive motor speed for some tracks (thus writing long tracks which cannot be duplicated on an unmodified drive/computer),...

[Long tracks are a common form of copy-protection on Amiga games.]

Such a low-level dump of raw data would at least preserve all (or almost all) information on the disk. Successfully writing an exact duplicate back to another floppy would depend on the capabilities of your disk controller. Still, such as image file could be easily supported by emulators. Also bad sectors would be preserved, meaning that recovery of most of the data from them would be possible.

> The AnaDisk software doesn't seem to accomodate copy protected or > custom-format disks. The standard will have to address these disks as > well.

You may know that Amiga computers have very flexible floppy controller hardware. There are several programs on the Amiga that are intended to image/archive disks at a low level.

These read the raw bits from an entire track in one pass, and store that (from index to index, plus some). This is independent of the coding method used (MFM, GCR or whatever), and of course preserves sector order, distance between sectors etc. It should be possible to successfully archive almost any PC floppy disk that way, protected or not.

I don't have many copy-protected PC floppies. Was any famously "evil" type of disk-based copy-protection used for PC software? I would quite like to try making a working backup of a disk like this.

The Catweasel disk controller hardware (available as an ISA card for PCs) is capable of similar things. However due to its developer (stupidly IMO) refusing to release details on how to program it directly, this would be of no use; you're stuck with the provided drivers which are apparently pretty poor.

- -- Mark