please see embedded comments below.
Dick
----- Original Message -----
From: allisonp <allisonp_at_world.std.com>
To: <classiccmp_at_classiccmp.org>
Sent: Tuesday, April 18, 2000 4:11 PM
Subject: Re: 8-bit IDE
> >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,
but
> > 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.
>
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.
>
> >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 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.
>
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
> with apps that ran under V2.2. After all I want is better and not
obsolete
> perfectly good software.
>
What matters to me more than making the extended versions of CP/M work, is
making the REAL CP/M work.
>
> Allison
>
Received on Tue Apr 18 2000 - 19:08:29 BST