Reading TRS-80 discs (was RE: Archiving old discs...)

From: Allison J Parent <allisonp_at_world.std.com>
Date: Tue Sep 14 21:40:09 1999

<It's not that hard to replace a non-standard data separator with a 9216
<or a homebrew design, or....

Or jumper the pins of the 9216 for the correct mode. Since the 9216 is
only for the read side you still have to tweek the write and precomp
logic. The 9229 does both sides (read and write). It's pretty trivial
to do this even with SSI TTL.

<But you can only do this if you have access to the signals you mentioned.
<With the all-on-one-chip devices that are common on PC I/O cards you
<don't. And since PCs always use double-density disks, a lot of these
<chips were not properly tested in SD (FM) mode.

True, you already have the resources. This is a matter I have experince
with over 19 years, 19 of wich are with the 765 and heirs as I started as
a product engineer with NEC before the 765 was rolled out. What I have
for DOCs is, uhm, better than average.

The last byte mashed in the UMC is also common to most 765s and is related
to DMA read/write timing such that if you delay the DMA request by about
1-3uS (several FDD bit times) in FM mode it should work fine. In FM the
internal clocks are slower and the transfers internally take longer. Some
of the super parts compensate for this or there luck. It's part
of the reason why when you write a command sequence or read status there
can be a significant delay (12us for the 765A) as the clock runs the
internal processors (one for parallel ops and one for the serial ops). OH in
FM mode DTL byte in the command is significant (for MFM is filler).


Allison
Received on Tue Sep 14 1999 - 21:40:09 BST