Jules Richardson wrote:
Don Y wrote:
I'm just finishing up some ideas on a
quick-and-dirty
parallel port (SPP)-to-OMTI interface (so Jules can
salvage his "bits" :> ). Anyone like to add their
two cents?
Thought for the morning - it'd be nice if the hardware was switchable
between SCSI and SASI. In a moment I'll dig out the docs I have for the
Omti 5x00, Adaptec ACB4000, Xebec (umm, 1452 or something like that) and
the Emulex boards.
Some of those boards are SASI, some are SCSI (although I think all are
pre-CCS, but that's a software issue). What needs to be understood is
whether the extra handshake lines needed for SCSI can be included - and
if so can they be 'switched off' via either hardware or software to
drive a SASI device...
I hadn't thought of adding ATN (though I was debating supporting
the parity *signal* -- but not the logic) but it shouldn't be
a problem. The issue will be in the software (though even
that can probably be "solved once" and remembered)
(from memory, the OMTI is the closest board to
'real' SCSI, so designing
against that's likely a good thing)
One of the manuals (model 20?) that I have didn't support
parity so I hadn't yet planned on that (but will).
Note that I am
not aiming for performance. Just
a way to coax bits off a disk drive so they can
be imaged properly (is that correct, Jules?)
Yep, doesn't matter if it takes a while to run or chews CPU cycles to do
so - it's purely a way of imaging / restoring disks, not a way of
interacting with them (that can be done via the loopback device in Linux
once you have an image!)
One compensating factor is that the drives that typically are
involved will be small (tiny?!). It's not like trying to move
100GB! :>
I'm not sure if the "8MHz I/O bus" applies to newer PC's
(i.e. is it throttled down someplace) which would limit
accesses to the printer port hardware -- nor any limitations
on other hardware platforms. But, I am guessing you can
probably get 250-500KB/s through this interface. Not
stellar but sure beats DC!