Defining Disk Image Dump Standard

From: Mark <mark_k_at_iname.com>
Date: Sun May 28 17:38:55 2000

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
Received on Sun May 28 2000 - 17:38:55 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:33:10 BST