Defining Disk Image Dump Standard

From: Jacob Dahl Pind <rachael__at_gmx.net>
Date: Tue May 30 12:15:54 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


--------------------------------------------------
= IF this computer is with us now... =
=...It must have been meant to come live with us.=
= (Belldandy - Goddess First class) =
--------------------------------------------------
Received on Tue May 30 2000 - 12:15:54 BST