ISTR something about the fact that the parallel zip drive was basically a SCSI device internally, but used level shifters or whatever was necessary to make it I/O compatible with the parallel port. If I'm not mistaken, I think the driver even "talked to the drive" with SCSI commands over the parallel port... but I could be full of condensed milk. However, if one were to attempt to reverse-engineer that device, it might be old and/or slow enough to glean some clues on how to interface parallel -> SCSI...

ISTR something about the fact that the parallel zip drive was basically a SCSI device internally, but used level shifters or whatever was necessary to make it I/O compatible with the parallel port.

However, if one were to attempt to reverse-engineer that device, it might be old and/or slow enough to glean some clues on how to interface parallel -> SCSI...

I disassembled a couple of those, they were fried logic wise, they had 53c80 scsi chips in them and some 74 series logic. I don't think there was enything else in them (don't remember for sure)

On 5 Dec 2010 at 19:57, Geoffrey Reed wrote: I've got an T358, but I grabbed a no-name unit with a SCSI 50pin HD connector on it rather than the Trantor's "Centronics" one. Okay, I'm about to pop it open... Surprise, surprise--it's got an NCR 53C80 on one side of the PCB and what appears to be an ASIC on the other side labeled KINGBYTE KBIC- 951A. So no help there. --Chuck

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

the problem is MFM is a disk level interface and you have to do revere MFM to get the data and then interpret the byte stricns for sector numbers and also look at the step and direction for cylinder, the return side would require data in MFM format

and other responses like TRK000. EDSI is really the same thing faster with a bit more control intelligence.

In the end to do that is a lot of complication where a MFM drive directly would be easier or to drop on the bus and grab all the control signals before they go to the MFM controller.

The fact that I was grabbing ST5xx drive and ST2xx drives when they were almost junk for free has paid over time as I have a store of drives to avoid this level of pain.

On 7 Dec 2010 at 19:50, Tony Duell wrote: Speaking as one who has studied the problem a bit and who has no intention of implementing anything, I think that a sampled stream is overkill. While it's true that the result is something that's controller- and format-independent, it's more straightforward and requires less horsepower to simply generate the formatting information, inserting the data as required. There's a floppy emulator that does this with comparatively little RAM and runs on an 8-bit 8MHz AVR. One also doesn't need to worry about aliasing effects. I suspect that a 60-70MHz ARM MCU might prove to be useful in this respect.

On 7 Dec 2010 at 19:50, Tony Duell wrote: Speaking as one who has studied the problem a bit and who has no intention of implementing anything, I think that a sampled stream is overkill. While it's true that the result is something that's controller- and format-independent, it's more straightforward and requires less horsepower to simply generate the formatting information, inserting the data as required. There's a floppy emulator that does this with comparatively little RAM and runs on an 8-bit 8MHz AVR. One also doesn't need to worry about aliasing effects.

I am not all convinced that an unused hard drive will 'keep' for ever... -tony