19 Apr
2000
19 Apr
'00
12:27 a.m.
Please see itemized comments below.
Dick
----- Original Message -----
From: allisonp <allisonp(a)world.std.com>
To: <classiccmp(a)classiccmp.org>
Sent: Tuesday, April 18, 2000 8:30 PM
Subject: Re: 8-bit IDE
write
savings
to.
through
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 >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 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
>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 1000+ files
is a real pita to look at on the tube and slower than sludge cpu time
wise.
<snip>
Allison