6 Jul
2006
6 Jul
'06
6:32 p.m.
Hi,
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?
Note the operative word here is "quick-and-dirty".
If you want to build a monument to your own cleverness,
you can design/build it yourself :> Goal here is
something that can be built and debugged easily
(so I'm NOT using an FPGA, microcontroller, etc.)
If someone has access to a double sided PCB
facility (to save the hassle of wire-wrapping
the thing), I'll layout a 2 layer PCB (on the off
chance that someone else might want to tinker
with this stuff).
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?)
Thanks!
--don
7 Jul
7 Jul
7:06 a.m.
Don Y wrote:
Hi,
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?
Don,
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...
(from memory, the OMTI is the closest board to 'real' SCSI, so designing
against that's likely a good thing)
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!)
cheers
Jules
1:59 p.m.
Jules Richardson wrote:
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.
Right, low-down on the various boards:
OMTI 5000 series: Manual calls the interface "SCSI/SASI" - from the wording it
was current before SCSI was actually a recognised standard, but they've done
their best to cope with the forthcoming spec. The board does support parity
detection/generation (can be disabled via a jumper) and the device ID is
selectable. The board *does not* support disconnect/reconnect, message out, or
re-select. Single-host environment only.
Bus signals used: D0-7, parity, BSY-, ACK-, RST-, MSG-, SEL-, C-/D, REQ-, I-/O.
Drive geometry is controlled by an "Assign disk parameters" command (0xC2) and
is *not* persistent across power cycles.
Bytes/sector is jumper-selectable to 128, 256, 512 or 1024 bps.
Xebec S1410: Manual calls the interface SASI. No support for parity generation
or checking on this one. Device ID is selectable by cutting PCB traces (yuck).
Bus signals used: D0-7, BSY-, ACK-, RST-, MSG-, SEL-, C-/D, REQ-, I-/O.
Drive geometry is controlled by an "Initialize drive characteristics" command
(0x0C) and is *not* persistent across power cycles.
Bytes/sector is jumper-selectable to either 256 or 512 bps.
Adaptec ACB4000: Manual uses the term 'SCSI' exclusively. Parity
generation/detection is not supported, however. The board doesn't support
disconnect/reconnect, or arbitration. Single-host environment only.
Bus signals used: D0-7, BSY-, ACK-, ATN- RST-, MSG-, SEL-, C-/D, REQ-, I-/O.
Drive geometry is controlled by a mode select command (0x15) and *is*
persistent across power cycles; at format time the board stores the drive
geometry at block 0 (and offsets normal drive accesses by 1 block) - when the
board is power cycled it automatically reads this geometry back from the drive.
Bytes/sector is selectable to 256, 512 or 1024 bps.
Emulex: I don't have any info on their boards, just the boards themselves.
Will check bitsavers at some point.
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 :-(
cheers
Jules
8 Jul
8 Jul
2 p.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!
7 Jul
7 Jul
2:11 p.m.
Jules Richardson wrote:
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!
Don Y wrote:
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)
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... (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!)
6585
days inactive
6587
days old
4 comments
2 participants
participants (2)
-
dgy＠DakotaCom.Net -
julesrichardsonuk＠yahoo.co.uk