23 Sep
2020
23 Sep
'20
6:51 p.m.
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.
However, OpenBSD always seems to enable SCSI parity and complains about
disk parity errors. I tried to disable all lines in the aic7xxx and
ahc_pci driver source files that seem to enable parity, but nothing
seems to make a difference. The drive/ACB4000 is not detected by
OpenBSD, I get a "device not configured" error when accessing the disk
device files (/dev/sdxc and /dev/rsdxc).
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?
-- Michael
23 Sep
23 Sep
6:54 p.m.
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
8:28 p.m.
On 9/23/20 8:54 PM, Grant Taylor via cctech wrote:
On 9/23/20 12:51 PM, Michael Engel via cctech wrote:
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...
-- Michael
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 
8:44 p.m.
On Wed, Sep 23, 2020 at 1:28 PM Michael Engel via cctech <
cctech at classiccmp.org> wrote:
On 9/23/20 8:54 PM, Grant Taylor via cctech wrote:
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
On 9/23/20 12:51 PM, Michael Engel via cctech
wrote:
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.
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 
24 Sep
24 Sep
4:13 a.m.
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 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:
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...
-- Michael
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
7:12 a.m.
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:
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
On 9/23/20 12:51 PM, Michael Engel via cctech
wrote:
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? 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
3:23 p.m.
On 9/24/20 1:12 AM, Camiel Vanderhoeven via cctalk wrote:
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.
Very NICE hack Camiel. I like it!
I am a little surprised by getting different data for the same sectors.
I find that mildly concerning. Did you do something like read each byte
multiple times to find a majority sample? 2/3, 3/5, 4/6, etc? Do you
think the different data was an artifact of the old drive? Or was it a
tickle of a bug elsewhere in the chain?
--
Grant. . . .
unix || die
4:21 p.m.
On Sep 24, 2020, at 5:23 PM, Grant Taylor via cctalk
<cctalk at classiccmp.org> wrote:
On 9/24/20 1:12 AM, Camiel Vanderhoeven via cctalk wrote:
The drive was what seems to be a pre-production Fujitsu model (with a serial number of
37), 17MB in size; I?m pretty sure the disk itself had issues. On the first pass of
reading the disk, about 8% of all sectors wouldn?t read, returning an ?Unrecoverable Read
Error?; when I did a second pass reading just these failed sectors, I found that I could
read about 2/3rds of them. I repeated this 20 times or so, and then I had almost
everything. There were 43 sectors near the end of the disk that I never managed to read,
but these were beyond the filesystems on the disk. That gave me a disk that would boot,
but I has some corrupt files and a corrupt directory. Looking at these, I found that the
corrupt bits were sector-sized, and were identical copies of sectors elsewhere on the
disk.
In the end, what I ended up doing was read the entire disk 2 more times (so two more times
the 20 iterations of reading the missing sectors until I had a complete image), and
compared the resulting three disk images sector-by-sector. For some 99% of the sectors,
all three copies were in agreement; where they were not, there were always two images in
agreement, so I knew which one to pick.
I?ve documented some of this here:
https://www.vaxbarn.com/index.php/42-repair/577-convex-c1-xp-power-on
<https://www.vaxbarn.com/index.php/42-repair/577-convex-c1-xp-power-on>
https://www.vaxbarn.com/index.php/42-repair/579-getting-a-convex-c1-to-pass…
<https://www.vaxbarn.com/index.php/42-repair/579-getting-a-convex-c1-to-pass-all-diagnostics%5C>
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.
Very NICE hack Camiel. I like it!
I am a little surprised by getting different data for the same sectors. I find that
mildly concerning. Did you do something like read each byte multiple times to find a
majority sample? 2/3, 3/5, 4/6, etc? Do you think the different data was an artifact of
the old drive? Or was it a tickle of a bug elsewhere in the chain?
4:25 p.m.
On Sep 24, 2020, at 6:21 PM, Camiel Vanderhoeven via
cctalk <cctalk at classiccmp.org> wrote:
Oh, I was lucky when I spotted it; the first corrupt file I encountered was part of the
microcode to be loaded onto the vector processor. Those files have checksums, and the
microcode loader complained. I wrote a small utility to extract the files from the disk
image (it uses a variant of the UFS file system), and had a look at the corrupt file; one
of the blocks in the file looked like part of a directory, which was easy to spot, and
that led me to the conclusion that it was valid data, but read from the wrong place.
Camiel
On Sep 24, 2020, at 5:23 PM, Grant Taylor via
cctalk <cctalk at classiccmp.org> wrote:
On 9/24/20 1:12 AM, Camiel Vanderhoeven via cctalk wrote:
The drive was what seems to be a pre-production Fujitsu model (with a serial number of
37), 17MB in size; I?m pretty sure the disk itself had issues. On the first pass of
reading the disk, about 8% of all sectors wouldn?t read, returning an ?Unrecoverable Read
Error?; when I did a second pass reading just these failed sectors, I found that I could
read about 2/3rds of them. I repeated this 20 times or so, and then I had almost
everything. There were 43 sectors near the end of the disk that I never managed to read,
but these were beyond the filesystems on the disk. That gave me a disk that would boot,
but I has some corrupt files and a corrupt directory. Looking at these, I found that the
corrupt bits were sector-sized, and were identical copies of sectors elsewhere on the
disk.
In the end, what I ended up doing was read the entire disk 2 more times (so two more
times the 20 iterations of reading the missing sectors until I had a complete image), and
compared the resulting three disk images sector-by-sector. For some 99% of the sectors,
all three copies were in agreement; where they were not, there were always two images in
agreement, so I knew which one to pick.
I?ve documented some of this here:
https://www.vaxbarn.com/index.php/42-repair/577-convex-c1-xp-power-on
<https://www.vaxbarn.com/index.php/42-repair/577-convex-c1-xp-power-on>
<https://www.vaxbarn.com/index.php/42-repair/577-convex-c1-xp-power-on
<https://www.vaxbarn.com/index.php/42-repair/577-convex-c1-xp-power-on>>
https://www.vaxbarn.com/index.php/42-repair/579-getting-a-convex-c1-to-pass…
<https://www.vaxbarn.com/index.php/42-repair/579-getting-a-convex-c1-to-pass-all-diagnostics>
<https://www.vaxbarn.com/index.php/42-repair/579-getting-a-convex-c1-to-pass-all-diagnostics%5C
<https://www.vaxbarn.com/index.php/42-repair/579-getting-a-convex-c1-to-pass-all-diagnostics%5C>>
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.
Very NICE hack Camiel. I like it!
I am a little surprised by getting different data for the same sectors. I find that
mildly concerning. Did you do something like read each byte multiple times to find a
majority sample? 2/3, 3/5, 4/6, etc? Do you think the different data was an artifact of
the old drive? Or was it a tickle of a bug elsewhere in the chain? 
5:56 p.m.
New subject: Revived Terak 8510
Mine stopped working a decade or so ago. I have a dozen or so,
but none are powering up any more.
I seem to remember someone here who'd revived one. Did it mean
replacing sockets, replacing caps?
- John
6:03 p.m.
New subject: Revived Terak 8510
On Thu, Sep 24, 2020 at 10:57 AM John Foust via cctalk <
cctalk at classiccmp.org> wrote:
Mine stopped working a decade or so ago. I have a dozen or so,
but none are powering up any more.
I seem to remember someone here who'd revived one. Did it mean
replacing sockets, replacing caps?
I repaired mine a couple of years back. The caps on my supplies (both in
the CPU and the external disk unit) were mostly dead at the time (there was
electrolyte leaking out of them, in fact). Replacing them brought them
back to life. There was a fair amount of corrosion on the sockets for the
RAM on mine due to the environment it had been stored in, this may not be
the case on yours, but I was unable to make it run reliably until I
replaced them.
- Josh
- John
6:15 p.m.
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
25 Sep
25 Sep
3:10 a.m.
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
8:49 a.m.
Gentles,
As its really an MFM Disk why not read it with an MFM adaptor? Something like:-
https://www.pdp8.net/mfm/mfm.shtml
which will read and image MFM disks and replace them. Expensive perhaps, but perhaps some
one can lend you one to get an image...
... or if the SCSI <=> MFM adaptor supports two disks the use a DREM
https://www.drem.info/tech-info
and perhaps DD to copy the data.....
Dave
G4UGM
-----Original Message-----
From: cctalk <cctalk-bounces at classiccmp.org> On Behalf Of Grant Taylor via
cctalk
Sent: 25 September 2020 04:11
To: cctech at classiccmp.org
Subject: 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 
12:28 p.m.
On 9/25/20 5:24 AM, Al Kossow via cctalk wrote:
On 9/25/20 1:49 AM, Dave Wade G4UGM via cctalk wrote:
You really want one of Dave's boards if you need to do any sort of oddball
mfm hd recovery. I just recovered the data yesterday from a ETH Ceres 32016
workstation with one.
Gentles,
As its really an MFM Disk why not read it with an MFM adaptor?
That was what I was wondering as well.
5:08 p.m.
I was able to dump Torch Triple X System V, Release 1 Version 1.2
If anyone is interested I can share the image.
Best regards,
Plamen
On Friday, September 25, 2020, Al Kossow via cctalk <cctalk at classiccmp.org>
wrote:
On 9/25/20 5:24 AM, Al Kossow via cctalk wrote:
On 9/25/20 1:49 AM, Dave Wade G4UGM via cctalk
wrote:
You really want one of Dave's boards if you need to do any sort of oddball
mfm hd recovery. I just recovered the data yesterday from a ETH Ceres 32016
workstation with one.
Gentles,
As its really an MFM Disk why not read it with an MFM adaptor?
That was what I was wondering as well.
5:33 p.m.
On 9/25/20 10:31 AM, Al Kossow via cctalk wrote:
On 9/25/20 10:08 AM, Plamen Mihaylov wrote:
did the ever scan all the manuals?
http://www.computinghistory.org.uk/det/1031/Torch-Triple-X/
I was able to dump Torch Triple X System V,
Release 1 Version 1.2
If anyone is interested I can share the image.
I have a Torch Quad X CPU prototype CPU, missing the ASIC
26 Sep
26 Sep
11:42 a.m.
On Fri, Sep 25, 2020 at 6:33 PM Al Kossow via cctalk
<cctalk at classiccmp.org> wrote:
On 9/25/20 10:31 AM, Al Kossow via cctalk wrote:
I have a couple of Triple-Xs and a currently non-working Quad-X
Somewhere I have the schematic I reverse-engineered of the Triple-X. I
can dig it out and scan it if there's any interest.
I also seem to have 13 tiff files which claim to be the official
quad-X CPU board schematic which again I can share.
I don't know if I kept the Triple-X service manual. I had it at one
point and it was useless! No schematics. No pinouts. A block diagram
with major errors. And a glossary with entries like :
'IC : Integrated Circuit. one of those black things on legs on a circuit board
ICs : More than one IC'
I am not making that up.
[And it's not even accurate. The 68000, 68450 and 68451 are in ceramic
packages and are therefore not black. Two of the ICs on the Omti
SCSI-ST412 interface are in PLCC packages and are therefore not 'on
legs']
-tony
On 9/25/20 10:08 AM, Plamen Mihaylov wrote:
did the ever scan all the manuals?
http://www.computinghistory.org.uk/det/1031/Torch-Triple-X/ I was able to dump Torch Triple X System V,
Release 1 Version 1.2
If anyone is interested I can share the image.
I have a Torch Quad X CPU prototype CPU, missing the ASIC
25 Sep
25 Sep
6:35 p.m.
On 9/25/20 12:31 PM, Al Kossow via cctalk wrote:
On 9/25/20 10:08 AM, Plamen Mihaylov wrote:
Interesting. I had a couple of Quad-X systems; one went off to the Centre
for Computing History when I moved to the US, but the other I parked at
TNMoC and can hopefully get back at some stage (post-pandemic). I don't
know how many QX systems were made, but I don't think it was many - and
they're probably significantly rare in the US.
I do have some Quad-X source/design bits and pieces, I believe - I
inherited a pile of Torch corporate hardware ~15 years ago, and among that
were a couple of drives which had come from one of the company servers.
cheers
Jules
I was able to dump Torch Triple X System V,
Release 1 Version 1.2
If anyone is interested I can share the image.
I have a Torch Quad X CPU prototype CPU, missing the ASIC 
24 Sep
24 Sep
5:04 p.m.
Hi,
I remember I used Linux with an AdvanSys PCI adapter to successfully read a disk
connected through an ACB4000. It's been a while but I believe I had to run
an old kernel which I compiled myself with support for ACB4000. Might have
been that a patch was applied.
All I found in my archives is a copy of the dmesg from the host showing:
Linux version 2.0.38 (root at localhost.localdomain) (gcc version 2.7.2.3) #2 Wed Nov 11
20:33:21 CET 2009
[...]
scsi0 : AdvanSys SCSI 3.1E: PCI Ultra 16 CDB: IO D400/F, IRQ 12
scsi : 1 host.
scsi0 channel 0 : resetting for second half of retries.
SCSI bus is being reset for host 0 channel 0.
advansys: advansys_reset: reset request not active or waiting, completing anyway fbd018
Vendor: ADAPTEC Model: ACB-40XX Rev: 1.00
Type: Direct-Access ANSI SCSI revision: 01
Detected scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sda: hdwr sector= 512 bytes. Sectors= 148135 [72 MB] [0.1 GB]
sda: unknown partition table
Can try to dig around old disks some day to see if I find the patch.
Br,
Jonas
On Wed, Sep 23, 2020 at 08:51:39PM +0200, Michael Engel via cctalk 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.
However, OpenBSD always seems to enable SCSI parity and complains about disk
parity errors. I tried to disable all lines in the aic7xxx and ahc_pci
driver source files that seem to enable parity, but nothing seems to make a
difference. The drive/ACB4000 is not detected by OpenBSD, I get a "device
not configured" error when accessing the disk device files (/dev/sdxc and
/dev/rsdxc).
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?
-- Michael
25 Sep
25 Sep
4:38 p.m.
On Wed, Sep 23, 2020 at 11:51 AM Michael Engel via cctech
<cctech at classiccmp.org> 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.
26 Sep
26 Sep
3:22 a.m.
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.
--
Grant. . . .
unix || die
7:47 a.m.
On 9/25/20 8:22 PM, Grant Taylor via cctalk wrote:
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.
DO NOT ATTEMPT TO USE A PC MFM CONTROLLER WITH DISKS FROM EARLY BRIDGE BOARDS
There is a thread on VCF where someone tried to read a disk from a Viasyn S100
system with a PC controller and it silently REWROTE the contents of cyl 0
You have been warned
27 Sep
27 Sep
11:43 p.m.
On 09/26/2020 02:47 AM, Al Kossow via cctalk wrote:
On 9/25/20 8:22 PM, Grant Taylor via cctalk wrote:
Cutting the write wire should prevent that!
Jon
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.
DO NOT ATTEMPT TO USE A PC MFM CONTROLLER WITH DISKS FROM
EARLY BRIDGE BOARDS
There is a thread on VCF where someone tried to read a
disk from a Viasyn S100
system with a PC controller and it silently REWROTE the
contents of cyl 0
You have been warned
26 Sep
26 Sep
3:32 p.m.
On 9/26/20 5:22 AM, Grant Taylor via cctalk wrote:
On 9/25/20 10:38 AM, Glen Slick via cctalk wrote:
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
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
3:56 p.m.
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
3:59 p.m.
On 9/26/20 8:56 AM, Al Kossow via cctech wrote:
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?
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
10:47 p.m.
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.
10:51 p.m.
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. :-)
1869
days inactive
1873
days old
30 comments
13 participants
participants (13)
-
aekï¼ bitsavers.org -
ard.p850ug1ï¼ gmail.com -
camielï¼ vaxbarn.com -
cctalkï¼ gtaylor.tnetconsulting.net -
dave.g4ugmï¼ gmail.com -
derschjoï¼ gmail.com -
elsonï¼ pico-systems.com -
engelï¼ multicores.org -
glen.slickï¼ gmail.com -
jfoustï¼ threedee.com -
jmï¼ x25.ee -
jules.richardson99ï¼ gmail.com -
plamenspamï¼ afterpeople.com