Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter?

[Camiel Vanderhoeven]

> On Sep 23, 2020, at 10:28 PM, Michael Engel via cctech <cctech at classiccmp.org> wrote:
> 
> 
> 
> On 9/23/20 8:54 PM, Grant Taylor via cctech wrote:
>> On 9/23/20 12:51 PM, Michael Engel via cctech wrote:
>>> Do you know if is there another OS which would make it easier to change crucial SCSI parameters in the driver (config) or maybe a specialized tool that could help me to image the disk?
>> 
>> Try booting off of a Linux live CD / DVD and seeing if it will behave any different
> Not really, unfortunately. The error messages are a bit cryptic:
> 
> [ 1069.277571] (scsi8:A:0:0): Sending SDTR period 45, offset 0
> [ 1069.278961] scsi 8:0:0:0: Attempting to queue a TARGET RESET message
> [ 1069.278964] CDB: 0x12 0x0 0x0 0x0 0x24 0x0
> [ 1069.278975] scsi 8:0:0:0: Command not found
> [ 1069.278979] aic7xxx_dev_reset returns 0x2002
> [ 1069.279286] (scsi8:A:0:0): Sending SDTR period 45, offset 0
> [ 1069.280736] scsi8: Slave Alloc 1
> [ 1069.543400] scsi target8:0:1: asynchronous
> [ 1069.543416] scsi8: target 1 using asynchronous transfers
> [ 1069.543420] scsi8: Selection Timeout on A:1. 0 SCBs aborted
> 
> It seems that the problem lies in the firmware of the ACB4000, which doesn´t seem to support some standard commands, e.g. the INQUIRY command. Most recent Linux SCSI drivers seem to use this command.
> 
> Some information on this problem can be found here:
> https://www.zot.org/~hamish/hacks/acb-4000.html
> 
> There´s a thread (in German, sorry) in which someone tried to get a disk on an ACB4000 to work:
> https://de.comp.os.unix.linux.misc.narkive.com/ti21cHO0/scsi-1-platte-unter-linux-ansprechen
> and somebody else (also in German...) claims that he could run a disk on an ACB4000 (from an Atari SH204) on an Adaptec 1542:
> https://forum.classic-computing.de/forum/index.php?thread/18576-wie-programme-vom-pc-auf-atari-mega-st-bringen/&pageNo=2
> 
> So maybe an Atari ST with an ACSI->SCSI adapter might help. That seems to be one of the machines we don´t have here…

Yes, the ACB-4000 doesn’t play well with anything modern. The SPU (service processor) disk on my Convex C-1 uses a Fujitsu MFM disk with an ACB-4000. I absolutely had to save the contents of that disk, so here is my approach:

I used an Ancot Ultra2080/Lite SCSI-bus Analyzer. This is a device that connects to a SCSI bus and has a serial port. Over the serial port, you can monitor the signals on the SCSI bus, and use it as a SCSI protocol analyzer. There’s also the possibility to construct and send a SCSI command. Rather than connect a serial terminal to the serial port, I connected a PC, then wrote a C program to control the Ancot. I had the Ancot send commands to the disk to read a sector at a time, and recorded the data sent in response to a file to create a disk image. Slow as hell (each byte on the disk requires sending two hex characters and a space over a slow serial line), but it works. I had to make several passes over the disk, because occasionally the data received from the disk turned out to be data from a different sector than the one I was trying to read. By reading the disk multiple times, I could get rid of these mis-read sectors. 

I put the image created this way on a new disk (well, an old DEC 1GB disk with a SCSI-1 mode jumper) and was able to boot the SPU from this disk (It could not boot off the original disk), and later replaced it with a SCSI2SD.

If you’re interested, and have access to an Ancot, I can probably dig out the C code I wrote.

Camiel