22 May
2013
22 May
'13
9:31 a.m.
On 05/22/2013 04:28 AM, Vince Mulhollon wrote:
There are hardware issues also relating to your
selection of FDC. The
general consensus and experience of the N8VEM CP/M board builders is that
programmed IO with a 8 MHz and up Z80 and a modern 1.44 MHz floppy and a
9266 FDC works perfectly. I assembled a system this winter and that worked
perfectly. Obtaining 8+ MHz chips for modern Z80 designs is non trivial
and involves lots of ebay and searching.
But back to the question originally posted--can one use a 1770/1772 FDC
to do 500Kbps 3.5" floppy data transfer. Note that the 1770/1772 and,
for that matter, the slightly different WD1773 are specifically labeled
by the manufacturer as "$.25 disk controllers." In other words, the
manufacturer has specified them for 250 Kbps operation--and indeed, the
datasheet timings revolve around that assumption.
Further, note that these are 28-pin DIP packages, which is remarkable
when you start counting up the number of pins required for the function.
Indeed, none of these has a side-select pin; the 1770/1772 lacks a
DRIVE READY/ pin (performing the function internally, but does have a
motor control output); the 1773 drops the motor-control line and
replaces it with a multiplexed DRIVE READY/ENABLE PRECOMPENSATION pin.
Neither has any drive-select logic. These are single-supply FDCs and are
able to drive the inputs to a 5.25" floppy drive without any additional
buffering. It's easy to see why Atari and others used the
chips--they're a self-contained solution in a low-pin-count package.
I've got one on an ISA prototype board that I assembled some years back
and, for what it is, it's definitely a remarkable product for its time.
I believe that there's a -4 stepping of the 1772 that some have managed
to get working on the Atari ST to do 500Kbps data transfer. A 4MHz Z80
should be more than fast enough. I've never been able to get a 1770 to
operate at that speed.
Regarding slower processors (e.g. 2MHz 8080), I think Don Tarbell's
original design using the WD1771 (FM only) was a good approach--insert
wait states rather than have the CPU poll for data. The bottom of the
transfer loop is a conditional jump that tests for termination by the
FDC--no counting of data bytes transferred is necessary. For the time,
it was a great solution.
The original poster asked if a cache could be used to improve the data
transfer picture. Perhaps not a cache, but a FIFO might be the simplest
approach to accomplish this; I haven't examined the question in detail.
--Chuck