Re: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter?
On 9/26/20 10:32 AM, Michael Engel via cctech wrote: Using DOS might be another option, I seem to hit a roadblock with every Unix version I try... hmm, have a look here: http://ftp.vim.org/ftp/pub/ibiblio/kernel/patches/scsi ... adaptec-40XX-1.02.tar.gz looks like it might do the trick. Use at your own risk etc. :-)
Re: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter?
On 9/26/20 10:56 AM, Al Kossow via cctech wrote: ACB4000s aren't common command set. it expects the driver to tell it the drive parameters I'm possibly/probably wrong, but I thought the ACB-4000 only needs the parameters setting prior to format - I don't know it it has some form of non volatile RAM (unlikely) or if it stores the params in the first sector on the drive and then offsets r/w requests by a set amount (I know at least one vendor's board did that) so that they don't get overwritten.
Re: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter?
On 9/26/20 8:56 AM, Al Kossow via cctech wrote: sd3: non-CCS device found at target 0 lun 0 on esp0 sd3: at esp0 target 0 lun 0 sd3: corrupt label - wrong magic number sd3: Vendor ´ADAPTEC*´, product ´ACB4000*´, 181520 512 byte blocks ACB4000s aren't common command set. it expects the driver to tell it the drive parameters just get a gesswein mfm emulator already.. this is a trivial data recovery job for it i'm sorry if this offends you, but i watched the whole thread on vcf unfold where the guy screwed around with his rare copy of viasyn ccpm until he wiped out a part of it you ARE doing this with write-gate cut on the cable, right?
Re: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter?
On 9/26/20 5:22 AM, Grant Taylor via cctalk wrote: On 9/25/20 10:38 AM, Glen Slick via cctalk wrote: If the Adaptec 2940 BIOS seems to detect the disk I wonder what would happen if DOS was set up on the system and ASPI8DOS.SYS was loaded. Would the Adaptec 2940 and ASPI driver respect the BIOS parity setting and interact with the ACB4000 bridge well enough for a fairly simple DOS program to be able to use the ASPI interface to send READ CDBs to read the sectors from the device? If I had such a device myself to experiment with I'd probably give that a try to see if it works. If it would work, I wonder if you could then use something like Ghost to copy the drive to an image or another more standard drive that could then more easily be worked with Using DOS might be another option, I seem to hit a roadblock with every Unix version I try... After quite a bit experimenting it seems that older Linux kernels (down to 2.2, I´m not sure if earlier kernels would support the Pentium 4 I have here) don´t seem to make a difference, Linux doesn´t talk to the disk via the Adaptec 2940 and complains about parity errors. So I tried another idea from this thread - using a SunOS 4 machine. I set up a Sparcstation LX for netbooting SunOS 4.1.4 and it discovers the disk (typed in from the screen, I didn´t think of setting up a serial console): sd3: non-CCS device found at target 0 lun 0 on esp0 sd3: at esp0 target 0 lun 0 sd3: corrupt label - wrong magic number sd3: Vendor ´ADAPTEC*´, product ´ACB4000*´, 181520 512 byte blocks The corrupt label is expected and the vendor and product name as well as the disk size seem to be discovered correctly. However, when I try to dump the disk, I get the following error message: # dd if=/dev/sd3c of=/root/foo bs=512 (same for /dev/rsd3c) SunOS complains: dd: open: /dev/sd3c: No such device or address The disk is jumpered to address 0, it shows as address 3 due to the strange SCSI address renumbering of SunOS 4. Partition c should be the "whole disk" device. When I rejumper the ACB4000 to address 3, it shows as sd0 as expected - but I still get the same error message (with the other disk device name shown, of course). /dev/sd3c has major device ID 7, minor 26 (sd0c is 7/2), both were generated with the SunOS 4 MAKEDEV script in the NFS root directory, so they should be correct. I can also read the internal disk just fine with dd when I connect it. So it seems that this is a problem of a missing disk label that confuses the SunOS SCSI driver (I seem to remember having similar problems in the ´90s with our Suns)? Maybe I have to start reading SunOS kernel code... Btw., NetBSD (I tried 1.3.3 and 1.6.2) on the Sparc LX complains about SCSI phase errors if the ACB4000 is attached, so that´s also probably not an option. -- Michael
Re: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter?
On Wed, Sep 23, 2020 at 11:51 AM Michael Engel via cctech wrote: > > Hi, > > still working on backing up the Tektronix 440x disks. My current problem > is that the ACB4000 SCSI-to-MFM adapter doesn´t support SCSI parity. > > I finally managed to find a PCI SCSI controller (Adaptec 2940) and a > Pentium 4 PC with PCI slots and installed OpenBSD 6.7. I disabled parity > checking in the Adaptec BIOS config and it detects a disk at ID 0 with > no name. So far, so good. > If the Adaptec 2940 BIOS seems to detect the disk I wonder what would happen if DOS was set up on the system and ASPI8DOS.SYS was loaded. Would the Adaptec 2940 and ASPI driver respect the BIOS parity setting and interact with the ACB4000 bridge well enough for a fairly simple DOS program to be able to use the ASPI interface to send READ CDBs to read the sectors from the device? If I had such a device myself to experiment with I'd probably give that a try to see if it works.
Re: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter?
On 9/24/20 12:15 PM, Jules Richardson via cctech wrote: the Linux kernel at least has depended on it for a very long time Do you have any idea how far back one might need to go to get a kernel that didn't depend on SCSI Inquiry? I wonder if a retro computer with a really old kernel and a SCSI card that it supported might be a viable option. -- Grant. . . . unix || die
Re: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter?
On 9/23/20 3:28 PM, Michael Engel via cctech wrote: 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. Lack of Inquiry support seems to be quite typical for early SCSI devices, sadly - and the Linux kernel at least has depended on it for a very long time. I remember trying to work out how to bypass it in the kernel source, but there were so many layers of code (without any design-type docs that I could find) that I ended up homebrewing a SCSI controller out of a few TTL chips and hacking some user-land code to drive it. From what I recall (this was around 15 years ago now) there aren't any timeouts to worry about on the HBA side of things, only on the targets, so it didn't matter that it was slow as molasses. cheers Jules
Re: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter?
> On Sep 23, 2020, at 10:28 PM, Michael Engel via cctech > 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/=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
Re: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter?
I have the same problem with Torch Triple X disk which uses OMT SCSI/MFM adapter. I believe the best solution is to use David’s MFM emulator board. Best regards, Plamen On Wednesday, September 23, 2020, Michael Engel via cctech < cctech@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/=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... > > -- Michael > >
Re: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter?
On Wed, Sep 23, 2020 at 1:28 PM Michael Engel via cctech < cctech@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. > Earlier versions of SunOS and Solaris know how to deal with Adaptec SCSI bridges properly; I've done so on SunOS 4.1.4, for example. I'd still suggest using something like this: https://www.pdp8.net/mfm/mfm.shtml to image the MFM disks themselves. A friend of mine is in the middle of assembling a run of them... - Josh
Re: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter?
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/=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... -- Michael
Re: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter?
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. -- Grant. . . . unix || die
