8-bit IDE

From: allisonp <allisonp_at_world.std.com>
Date: Tue Apr 18 17:11:15 2000

>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
Received on Tue Apr 18 2000 - 17:11:15 BST