On Wed, 2004-05-26 at 21:18, jim wrote:
try a seagate st01 controller. they are supported by
linux drivers
you can rob for information on driving them.
Unfortunately a) I'd quite like the ease of moving this between a few
machines and b) I have one application in mind that would require the
target device (I'm not planning on having more than the one device +
host controller on the bus at once) to be able to be switched off with
the machine to which it is connected remaining on. I couldn't be certain
I could get away with that when using a dedicated SCSI controller, but
with a parallel port solution it's less of an issue.
I suspect you'd have problems with the select
sequence if using
a printer port. there are some things that are best done in hardware
even with the oldest scsi.
I'm not sure if I'm going to hit timeout problems if things aren't fast
enough. So far in the documentation I have here there's only mention of
needing certain signals asserted for a minimum period of time - no
mention if there's an upper limit. (The manual for the Omti bridge board
I have here is actually pretty good and gives a nice overview of SCSI
with timing diagrams etc. - I suppose it was pitched at people building
systems where there wasn't necessarily an existing SCSI host controller
available)
Of course most 8bit machines in the 80's with SCSI controllers did
everything in software and the hardware was just a few buffers and the
like. I don't know the theoretical transfer rate of a modern PC parallel
port, but it can't be that much worse than the data bus speed on an 8
bit micro using a software-driven SCSI controller which would have to be
servicing the display etc. at the same time. In other words, I'm hopeful
I can get something going :)
Raw transfer speed isn't an issue, so using the response-per-byte method
of data transfer (giving me around 1Mb/s transfer if I'm lucky I think)
should be fine.
I think that the ST01 is dumb enough you can do
anything you want
implementing the initiator state machine and have complete control to
handle what are now considered bugs by newer chips like adaptec
chips, etc that fully implement a lot of things for you, such as message
byte reading, and phase decodes.
That's useful to know if I do go for a 'smart' controller approach - one
of the problems I'm finding with some of these older device boards is
that they were made when the SCSI spec was a little vague, so they don't
support things now taken for granted like the inquiry command.
Unfortunately all the modern SCSI boards I have are Adaptec and use the
same chipset - Linux Adaptec drivers expect inquiry to work and mark the
device offline at boot if it doesn't, but because I'd have active modern
OS disks on the same system sharing the same driver I don't want to go
hacking the driver to death.
I really need two SCSI controllers in the system from different
manufacturers, then I could use one to host the modern OS disk and the
other to use for messing around with drivers and the like against.
cheers,
Jules