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