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…
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-program…
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