8 Jul
2006
8 Jul
'06
11 a.m.
Jules Richardson wrote:
[Right, low-down on the various boards:]
OMTI 5000 series: <snip>
Bus signals used: D0-7, parity, BSY-, ACK-, RST-, MSG-, SEL-, C-/D,
REQ-, I-/O.
I have some documents for a "model 20" that doesn't support parity.
Drive geometry is controlled by an "Assign disk
parameters" command
(0xC2) and is *not* persistent across power cycles.
This (and other related CCS missing features) would have to be
something you would accommodate in your software...
Actually, for prototyping (software), I wonder if hacking
together some shell scripts wouldn't be a bad way to go.
So, you could interactively invoke particular SCSI commands
and see their results (e.g., #set_drive_geometry XX YY ZZZ).
<shrug>
The problem here lies with the Adaptec board - it uses
the ATN line
found in full-blown SCSI, whereas all the other bridge boards don't. At
least on this side of the pond, it's a common board too that gets used
in a lot of classic hardware; it'd be a shame if it was unsupportable :-(
Adding the extra signals (ATN, parity, etc.) is no big deal.
But, I'll have to rethink just how "automated" I make the
handshaking of interlocked signals. As you said (offlist?),
it makes assumptions about the board that it is talking to
(which may not apply to other boards). The downside is that
it makes the transactions more expensive (but, we're not
concerned with that :> )
You might try a dummy inb/outb loop on your host-of-preference
to verify tht you *can* access t from user land AND get some
idea for how fast these opcodes are (run the loop 10^6 times,
etc.). If it turns out that they aren't restricted to legacy
bus speeds (assuming a PC target), then the aforementioned
handshaking is *best* done in software!