18 Apr
2000
18 Apr
'00
5:11 p.m.
drive work. I'm interested in the ones too small
to bring even $10 at the
flea market, i.e. the ones that are 10x what I need but only cost $6 or so.
Ok that ranges up to maybe 500mb now.
It takes more than a latch, by the way, since you have
to latch and hold
the
low byte on writes, and the high byte on reads, in
order not to screw up
the
order of the bytes. Consequently, you need not only
the two latches, but a
bit of logic to effect the byte steering on reads and to perform the write
after the CPU does the write, since the only time you can guarantee data
valid is at the very end of the write strobe.
Limited logic, one latch. No rule said only one address for the data read
or write.
The reason I'm whoring after the few drives with
this feature included is
that when this feature was available, if at all, the popular drives were of
about the "right" capacity for the typical application of CP/M.
Of course when the IMSAI and Altair were around that would be casette tape,
8" floppy (SSSD 256k) or maybe minifloppy (80k).
Better find two as likely they will be so old that any reliability has been
run
out of them.
The nice part of a real 16bit interface is if it fails any drive make a good
replacement even if I dont choose to use all of it. that and despite the
claim that 8080 and cpm was slow they do run better with fast drives and
ramdisks proved that. So a fast drive (13-15ms or so, 4500rpm) with a
cache of say 32-256k does indeed improve perfomance.
Since IDE has been done for CPM (several articles in TCJ) and SCSI
even longer the idea of the right size is really a red herring to me. In the
CPM world the right size was literally whatever you had or could get
you hands on, the bigger the better. Even the deblocking example
in the CP/M-2.0 alteration guide they talk about how taking advantage
of it enabled a 35mb drive to be formatted using larger sectors to 57mb
with better perfomance. that was written in 1981. The concept was the
abiltiy to interface to almost any storage hardware via an extensable BIOS.
My current project is to take CP/M V2.2 and capitalize on P2DOS (suprbdos,
novados, Zrdos etal) clones and add a heirarchal directory to get past the
former flat structure (user areas helped only a little) and stay compatable
with apps that ran under V2.2. After all I want is better and not obsolete
perfectly good software.
Allison
18 Apr
18 Apr
7:08 p.m.
please see embedded comments below.
Dick
----- Original Message -----
From: allisonp <allisonp(a)world.std.com
To: <classiccmp(a)classiccmp.org
Sent: Tuesday, April 18, 2000 4:11 PM
Subject: Re: 8-bit IDE
but
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
have to have bidirectional buffers. If you use anything other than a
'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
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.
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.
tape,
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.
> My current project is to take CP/M V2.2 and
capitalize on P2DOS (suprbdos,
> novados, Zrdos etal) clones and add a heirarchal directory to get past the
> former flat structure (user areas helped only a little) and stay
compatable
What matters to me more than making the extended
versions of CP/M work, is
making the REAL CP/M work.
> Allison
>drive work. I'm interested in the ones too
small to bring even $10 at
the
>flea market, i.e. the ones that are 10x what I
need but only cost $6 or
so.
Ok that ranges up to maybe 500mb now.
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.
It takes more than a latch, by the way, since you
have to latch and hold
the
>low byte on writes, and the high byte on reads, in order not to screw up
>the order of the bytes. Consequently, you need not only the two latches, > abit of logic to effect the byte steering on
reads and to perform the
write
after the CPU
does the write, since the only time you can guarantee data
valid is at the very end of the write strobe.
Limited logic, one latch. No rule said only one address for the data read
or write.
>The reason I'm whoring after the few drives with this feature included is
>that when this feature was available, if at all, the popular drives were
of
about the
"right" capacity for the typical application of CP/M.
Of course when the IMSAI and Altair were around that would be casette 8" floppy (SSSD 256k) or maybe minifloppy
(80k).
Better find two as likely they will be so old that any reliability has
been
run out of them.
The nice part of a real 16-bit interface is if it fails any drive make a
good
replacement even if I dont choose to use all of it.
that and despite the
claim that 8080 and cpm was slow they do run better with fast drives and
ramdisks proved that. So a fast drive (13-15ms or so, 4500rpm) with a
cache of say 32-256k does indeed improve perfomance.
Since IDE has been done for CPM (several articles in TCJ) and SCSI
even longer the idea of the right size is really a red herring to me. In
the
CPM world the right size was literally whatever you
had or could get
you hands on, the bigger the better. Even the deblocking example
in the CP/M-2.0 alteration guide they talk about how taking advantage
of it enabled a 35mb drive to be formatted using larger sectors to 57mb
with better perfomance. that was written in 1981. The concept was the
abiltiy to interface to almost any storage hardware via an extensible
BIOS.
with apps that ran under V2.2. After all I want is
better and not
obsolete
> perfectly good software.
7:29 p.m.
On Tue, Apr 18, 2000 at 06:11:15PM -0400, allisonp wrote:
Limited logic, one latch. No rule said only one
address for the data read
or write.
I'm curious, how can it be done with just one latch? In my ISA-8 thing,
I used one latch for writing data, to hold the low byte until the PC writes
the high byte. And another in the other direction, to catch the high byte
when the PC reads the low byte. Then a 244 to allow writing the high byte,
and a 245 for all other cases (including 8-bit register accesses). Is there
some way I'm not thinking of, to flip one 373 around and use it in both
directions???
John Wilson
D Bit
19 Apr
19 Apr
12:09 a.m.
Please see my comments below.
Dick
----- Original Message -----
From: John Wilson <wilson(a)dbit.dbit.com>
To: <classiccmp(a)classiccmp.org>
Sent: Tuesday, April 18, 2000 6:29 PM
Subject: Re: 8-bit IDE
writes
On Tue, Apr 18, 2000 at 06:11:15PM -0400, allisonp
wrote:
> Limited logic, one latch. No rule said only one address for the data
read
or write.
I'm curious, how can it be done with just one latch? In my ISA-8 thing,
I used one latch for writing data, to hold the low byte until the PC the high byte. And another in the other direction, to
catch the high byte
when the PC reads the low byte. Then a 244 to allow writing the high
byte,
and a 245 for all other cases (including 8-bit
register accesses). Is
there
some way I'm not thinking of, to flip one 373
around and use it in both
directions???
keep the 'LS646 in mind. It contains the equivalent of a pair of
'574's
with a '245 wired across the two registers. You can transfer data in
pipelined mode or in immediate mode, which potentially would allow you to
reverse byte order, for example, by passing the first received byte to the
register and the second to the outputs. This works in either direction.
Allison mentioned a strategy that would enable you to do this with a single,
albeit bidirectional register (e.g. LS646). If you decode the data bus high
byte and low byte separately, you could write to the lower byte at one
location and write to the higher at another, which, coincidentally, turns on
the outputs of the lower register, while presenting the output from the bus
receiver on the high byte. Likewise, if you read from the high byte
directly, using the enable to the high byte as the latch strobe to the
registered low-byte, you can later read the low byte. This, unfortunately
reverses the byte order.
OTOH, if you write the low byte and register it in a '646, and then write
the high byte into another '646, you need to wait until the write cycle is
ended, since that is guaranteed only on the trailing edge of the write
strobe pWR* since the '646 is rising-edge sensitive. If one were to use a
'573, one could write the low byte with no transaction on the IDE channel,
followed by a write of the high byte, during which the low byte output is
enabled, thereby effecting a word write. The register in the high-byte's
'646 would only be used in the case of a read from the IDE. The physical
IDE 16-bit channel would be latched on the high byte with its output enable
turned off, while the low byte is read through the transparent latch.
Unfortunately, these devices are edge-triggered rather than level gated
registers. That requires a separate read cycle that occurs only AFTER the
IDE is registered.
John Wilson
D Bit
7:39 a.m.
keep the 'LS646 in mind. It contains the
equivalent of a pair of '574's
with a '245 wired across the two registers. You can transfer data in
pipelined mode or in immediate mode, which potentially would allow you to
reverse byte order, for example, by passing the first received byte to the
register and the second to the outputs. This works in either direction.
the 646 is pointless for s100. You need a split data bus any ways and two
ls373s would do the job easier with far less steering logic..
If s100 had a unified data bus then maybe...
Allison
9026
days inactive
9027
days old
4 comments
3 participants
participants (3)
-
allisonp＠world.std.com -
edick＠idcomm.com -
wilson＠dbit.dbit.com