SCSI on the small and cheap

Rod Smallwood rodsmallwood at
Mon Dec 6 05:42:39 CST 2010

This is kind of he same topic. I have a reasonable number of SCSI drives but
no ST506 (MFM drives). I know they used to fit ST506's with adapters to make
them SCSI. I need to go the other way i.e. have an adaptor to make a SCSI
look like a ST506. Any ideas folks? Or even make an IDE look like an ST506.

Rod Smallwood

-----Original Message-----
From: cctech-bounces at [mailto:cctech-bounces at]
On Behalf Of Ian King
Sent: 06 December 2010 08:26
To: General Discussion: On-Topic and Off-Topic Posts
Subject: RE: SCSI on the small and cheap

I did some digging in my personal collection and while I came up
empty-handed, perhaps someone else has this stuff.  

I recall from the days of the Motorola 6800 and 6809 an application note
that described how to build a SCSI (presumably -1) interface to the
processor employing common low-level components.  I thought it was perhaps
in the M6800 Microprocessor Applications Manual (which I have), but while
that talks about interfacing to a floppy disk it does not have details on
interfacing to SCSI.  I'll keep digging to see if I have that material, but
it wasn't where I expected to find it -- Ian 
From: cctalk-bounces at [cctalk-bounces at] On
Behalf Of jim s [jws at]
Sent: Saturday, December 04, 2010 1:17 PM
To: On-Topic and Off-Topic Posts
Subject: SCSI on the small and cheap

Does anyone have experience or notes on the absolute minimum hardware to
do parallel narrow (and slow) SCSI.

Back in the early days, we were doing non arbitrated buses, and they are
now essentially unsupported, and there are some more bits related to
Attention that possibly has to be responded to quickly to keep from
upsetting initiator stacks.  However I would think a small circuit
external to a small processor such as a PIC or AVR would allow one to
fool most initiators, and do a simple device with SCSI on one side, and
either ethernet or USB on the other, or even an SD ram part.

The reset signal has some real constraints about getting the drivers off
the bus really quickly, and that is one signal that can't be handled in
software unless you have really fast response.  Also there are some
state transitions related to Reset that I think might have some issues.
You would of course need to latch that a reset occurred and when your
slow device got around to polling it it could handle that.

Also when the states are decoded would not be too hard to record and latch.

I just wonder if this would be less than the simple target circuits out
there and would be very difficult to implement.

The messaging and selection added some logic I have not studied in a
long time such that there were some transitions that could not be easily
handled either.


More information about the cctalk mailing list