copy of SCSI 1 spec? (XT39.2)

From: Jules Richardson <>
Date: Wed May 26 16:48:04 2004

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

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.


Received on Wed May 26 2004 - 16:48:04 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:37:13 BST