Please see itemized comments below.
Dick
----- Original Message -----
From: allisonp <allisonp_at_world.std.com>
To: <classiccmp_at_classiccmp.org>
Sent: Tuesday, April 18, 2000 8:30 PM
Subject: Re: 8-bit IDE
> >Boggles the mind, doesn't it? I remember that I paid $1250 for the first
> >ST506 I bought. It even said Shugart Technology rather than Seagate
> >Technology . That was 5 MB.
>
>
> Managed to get my St506 in mid 81 for much less than half that.
> connections.
>
> >Well, if you're willing to believe that what's in the timing diagrams,
> after
> >you see they clearly violate other spec's, you can do that. I prefer to
> >latch the data to ensure that I have it. Likewise, whether I have to
write
> >two locations or the same one twice, the data has to be latched. You
also
>
>
> Didnt' say you didn't need the latch only you didnt need an extra FF to
> track
> the silo status.
>
it's just one D-flip-flop, which, for the writes, is implemented as a shift
register that shifts out the write strobe a clock tick after the high byte
is written to the IDE. It also generates the OE* to both registers. For
reads, the negative-going read strobe enables the buffers' outputs and the
inverted read strobe clocks the registers.
>
> >'646..'654 type device, which won't work the way that's needed because
> >they're edge-triggered, you'll run up the parts count. After all, you
have
> >to latch the low byte on writes and the high byte on reads. I think
saving
>
>
> What about 573s? Thats what I used. though the proto used ls373s.
>
Those parts run up the parts count too much. The '646 family devices have
registers in each direction as well as a '245-style buffer bypassing them in
each direction.
>
> >parts by leaving out functionality is risky here. If you write the high
> >byte to the latch first, then write the low byte AND high byte, in a
single
> >unlatched write for the low byte, it may work, but now you can't use
those
> >handy instructions that make the Z-80 handier than the 8080/8085.
>
> Well true, but then I don't always use z80. one version happens to use a
> 8749 with a 8155 and 8251 to serialize the data for a low speed net.
> I only said I didnt' require the FF to track the data, not that it would
> allow INIR.
>
> >IMHO, once you have more than two components you have to look at
> >programmable logic. I'm convinced that a CPLD, a small one, in fact, is
> the
> >correct solution here, except in the case of an 8-bit capable drive, in
> >which case no logic at all is needed, beyond what's already there.
>
>
> I have 2064s and 3030s but those packages are a real pain to wirewrap.
> Then I ahve to balast a erpm with the pattern and wire that too. No
savings
> in wiring. For a PC card, yep, the only way.
>
> >Yes, it's been done, and if I'm going to do the 16-bit interface, I'm
going
> >to do it with what's essentially their code. That means a pretty similar
> >interface, which, by the way, is pretty minimal. It does latch both
bytes
> >of the data at the port.
>
>
> Still no need to do that. you only latch the data you cant transfer
> immediately.
> Saves one latch though you could use it for a gated buffer if you wanted
to.
>
> >What matters to me more than making the extended versions of CP/M work,
is
> >making the REAL CP/M work.
>
>
> Been there done that. It's easy enough, I have working examples. the
> problem is with 8mb logical disks I tend to fill them and ploughing
through
> 1000+ files
> is a real pita to look at on the tube and slower than sludge cpu time
wise.
<snip>
>
> Allison
>
Received on Wed Apr 19 2000 - 00:27:31 BST