Compaticard (was: Any AMIGA users?

From: Fred Cisin <>
Date: Mon Dec 31 22:29:08 2001

On Mon, 31 Dec 2001, Richard Erlacher wrote:
> I may be out of turn here,
Only a little, since you WERE trying to help.

> but I think it's safe to say that the WD chips
> will have problems with a track read of GCR and other modulation schemes,
> since they're designed for FM and MFM only. A track read does not sample

That's nice. But,

The Amiga is NOT GCR!
The Amiga is NOT GCR!

The Amiga IS MFM! But it does not have WD style sector headers.
It reads and writes a track at a time, and parses it in software. There
are no gaps, synchronization issues between sectors, etc.

IFF the Amiga were to be GCR, like other Commodore machines, then your
advice would be entirely correct and valid.

Grumpy Ol' Fred
> bits from the medium surface, but, rather looks, with timing synchronized
> with the clock presumably extracted from the FM/MFM bitstream, at the data
> sream coming from the drive and attempts to make sense of it in the context
> of its own track write (format) command.  That means that when it thinks it
> sees an address mark, it returns the binary token that it accepts as the
> command to generate that address mark during a track-write command.
> I'd say you'll be disappointed with the WD FDC's ability to interpret GCR.
> Here's a description of the READ TRACK command from the data regarding the
> 179x in the 1983 WD Components Handbook.
> "
> Upon receipt of the READ TRACK command, the head is loaded and the Busy
> Status bit is set.  Reading starts with the rising edge of the first
> encountered index pulse and continues until the next index pulse.  All gap,
> header and data bytes are assembled and transferred to the data register and
> DRQ's are generated for each byte.  The accuulation of bytes is synchronized
> to each address mark encounterd.  An interrupt is generated at the
> completion of the command.
> This command has several characteristics which make it suitable for
> diagnostic purposes.  The are:  the Read Gate is not activated during the
> commandl;  no CRC checking is performed; and the address mark detector is on
> for the duration of the command.  Because the A.M. detector is always on,
> write splices or noise may cause the chip to look for an A.M.  If an address
> mark does not appear on schedule, the lost data status flag is set.
> The ID A.M, ID field, ID CRC bytes, DAM, Data, and Data CRC Bytes for each
> sector will be correct.  The gap bytes may be read incorrectly diring
> write-splice time because of synchronization.
> "
> Note that this neither confirms or denies my initial remark, but ISTR that I
> got that information somewhere else, but still from WD.
Received on Mon Dec 31 2001 - 22:29:08 GMT

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