Compaticard (was: Any AMIGA users?

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

Then why the statement, " But it's still a 765. As such, it can not do GCR,
...?" That's the only reason I mentioned GCR at all.

Clearly, I misinterpreted the key issue.

Happy New Year!

Dick

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


> 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,
> WE ARE NOT TALKING ABOUT GCR!!!
> WE ARE NOT TALKING ABOUT GCR!!!
>
> 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.
>
That's almost enough to make one wonder why they used MFM. Had they used
RLL, which requires no complicated, or even simple modulator, they'd have
had half-again the capacity.
>
> IFF the Amiga were to be GCR, like other Commodore machines, then your
> advice would be entirely correct and valid.
>
I'm sure your point is well taken. It's just that I was addressing another
aspect of the source post.
> --
> Grumpy Ol' Fred cisin_at_xenosoft.com
>
>
> > 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 - 16:11:16 GMT