SCSI on the small and cheap

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. Regards ? Rod Smallwood -----Original Message----- From: cctech-bounces at classiccmp.org [mailto:cctech-bounces at classiccmp.org] 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 classiccmp.org [cctalk-bounces at classiccmp.org] On Behalf Of jim s [jws at jwsss.com] 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. Jim