Date   : Mon, 01 Oct 2007 16:16:10 +0100
From   : julesrichardsonuk@... (Jules Richardson)
Subject: Acorn SCSI access / serial transfer

Andrew Benham wrote:
> The most recent modification was, rather than writing to floppies, writing to
> the serial port with XMODEM protocol.  This enabled me to get a copy of the
> hard disk on one of my Linux boxes, where I can use my ADFS Fuse filesystem
> to read it.
> 
> It reads raw sectors.  The only "ADFSish" part is the code that decides when
> to stop, and that's easy to remove.
> [ In fact, when backing up my hard disk to XMODEM, I manually set the start
> and stop sectors and did the transfer in about 3 chunks ].

That sounds ideal, then - if I can manually set start/stop params then it 
should do the job :-)

Any idea how well it copes with drive defects? I think ordinarily it's the 
filesystem's responsibility to handle duff sectors and avoid them as necessary 
  - which means anything doing a raw read will potentially encounter bad 
sectors and have to cope with them...

I suppose ideally I'd like the program to pad out duff sectors with zeros, 
flag a message on screen, and then continue - that way the resulting image on 
the PC side would be the right size, just with a few zeroed sectors 
corresponding to bad blocks. That's about as good as it'll get (unless there's 
a 'read sector' command which can do a partial read on a bad sector and give 
256 bytes of corrupted data which might be semi-readable)

>> I want to look into how complex it'll be to concoct something to grab raw 
>> sectors from the drive and spit them down a serial line at 9600 baud (19200
at 
>> a push!)  - probably quite trivial for someone who knows 6502 assembler
or BBC 
>> BASIC, but that ain't me! ;)
> 
> You need my program then!

Sounds that way :-)

> The other option is to connect the Adaptec bridge board to a SCSI controller
> under Linux and 'dd' the data off the drive, but I've (still!) not tried this
> and I wouldn't put money on being able to get this sorted inside 6 weeks.

I've looked into that in the past without much luck. The Linux SCSI code's 
pretty hairy, and also doesn't like talking to things which appear as 
mass-storage devices but won't respond to the 'identify' command [1]. It seems 
to offline them within the whole SCSI kernel system at boot time as being 
broken, even though they'd probably happily respond to raw read commands via 
'sg' (which would be good enough for what we want to do). [2]

No doubt there's a relatively simple kernel hack to stop this behaviour for 
someone who can actually make sense of the SCSI code though :-) Once the 
system's booted and can be accessed using the sg interface, it'd be reasonably 
easy to throw any necessary vendor-specific commands at the attached bridge 
board (Adaptec, Emulex, OMTI, Xebec etc.) so that the bridge knew what drive 
it was talking to (although for Adaptecs this happens automatically), and from 
there just issue SCSI 'read' commands via sg in order to grab the data.

[1] At least with Adaptec and Future Domain boards. Maybe that behaviour is 
controller-specific, but I don't have anything else which is supported under 
Linux and isn't from those two. I did once have an ancient PAS16 sound card 
with a SCSI interface, but couldn't find it when I looked last; I think I gave 
it away.

[2] The VP-415 Domesday player falls foul of this, too - or at least the one 
with whatever firmware revision I have does.

cheers

Jules