> On Sep 24, 2020, at 5:23 PM, Grant Taylor via cctalk <cctalk@classiccmp.org> > wrote: > > 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? 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-all-diagnostics <https://www.vaxbarn.com/index.php/42-repair/579-getting-a-convex-c1-to-pass-all-diagnostics%5C>
Re: Disabling SCSI parity checking to dump disk on ACB4000 MFM-SCSI adapter?
Camiel Vanderhoeven via cctalk Thu, 24 Sep 2020 09:21:51 -0700
- Disabling SCSI parity checking to dump disk... Michael Engel via cctalk
- Re: Disabling SCSI parity checking to ... Grant Taylor via cctalk
- Re: Disabling SCSI parity checking... Michael Engel via cctalk
- Re: Disabling SCSI parity chec... Josh Dersch via cctalk
- Re: Disabling SCSI parity chec... Plamen Mihaylov via cctalk
- Re: Disabling SCSI parity chec... Camiel Vanderhoeven via cctalk
- Re: Disabling SCSI parity ... Grant Taylor via cctalk
- Re: Disabling SCSI pa... Camiel Vanderhoeven via cctalk
- Re: Disabling SCS... Camiel Vanderhoeven via cctalk
- Revived Terak... John Foust via cctalk
- Re: Revived T... Josh Dersch via cctalk
- Re: Disabling SCSI parity chec... Jules Richardson via cctalk
- Re: Disabling SCSI parity ... Grant Taylor via cctalk
- RE: Disabling SCSI pa... Dave Wade G4UGM via cctalk
- Re: Disabling SCS... Al Kossow via cctalk
- Re: Disabling... Al Kossow via cctalk
- Re: Disabling... Plamen Mihaylov via cctalk
- Re: Disabling... Al Kossow via cctalk