> On Sep 23, 2020, at 10:28 PM, Michael Engel via cctech > <cct...@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