Compaticard (was: Any AMIGA users?

From: Richard Erlacher <edick_at_idcomm.com>
Date: Mon Dec 31 14:44:16 2001

I may be out of turn here, 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
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.

Dick

----- Original Message -----
From: "Fred Cisin (XenoSoft)" <cisin_at_xenosoft.com>
To: <classiccmp_at_classiccmp.org>
Sent: Tuesday, January 01, 2002 12:16 AM
Subject: Compaticard (was: Any AMIGA users?


> > > Yes. It's a very nice 765 implementation. It can handle single
density
> > > (I don't know off-hand whether they used a 37C65, or added extra
logic),
> > > can handle 4 drives, can operate at other addresses to permit use as a
> > > second controller, etc.
> > > But it's still a 765. As such, it can not do GCR, can't do hard
sectors,
> > > can't do MFM without WD style sector headers (AMIGA!), and can't even
do
> > > some WD MFM formats that start the first sector too early.
> > > Allison could tell you EXACTLY what its capabilities and limitations
are.
> >
> On Mon, 31 Dec 2001, Don Maslin wrote:
> > Fred, though I have never seen one, I have heard that they made some of
> > the CCIVs with the National Semi FDC chips that were a bit more flexible
> > than the 765.
>
> But those are still 765s, with the same basic capabilities and
> limitations. The added flexibility might help with the "first sector"
> issue, but it absolutely will NOT provide the RAW track read that would be
> needed for reading Amiga, GCR, etc.
>
>
Received on Mon Dec 31 2001 - 14:44:16 GMT