31 Dec
2001
31 Dec
'01
8:11 a.m.
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(a)xenosoft.com>
To: <classiccmp(a)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:
schemes,
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 > 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(a)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.