Date   : Sat, 27 May 2006 16:14:12 +0100
From   : Jules Richardson <julesrichardsonuk@...>
Subject: Re: Back in circulation

D.G.van der Pol wrote:
> The 256 bytes/sector is absolutely an issue. SCSI uses block-transfers 
> for data. If a harddisk is formatted with 512bytes/sector, all 
> block-transfers expect 512 bytes. ADFS does only cope with 256 bytes, so 
> there are two possibilities: Rewrite ADFS to support 512 bytes 
> transfers. This would probably double the amount of memory space needed 
> by ADFS.
> Or try to find an harddisk that allows a low level reformat with 256 
> bytes/sector. I found documentation about a few drives that support 
> sector sizes from 256 til 1280 bytes per sector. But I never could lay 
> my hands on such drive.

I think there's also an issue in that surely the formatting code is going to 
expect to be able to send a "define drive geometry" command to an Adaptec 
bridge board - that command's not going to make any sense when sent straight 
to a SCSI disk and will presumably fail. I've no idea what the formatter code 
will do at that point - whether it'll just ignore the failed command and issue 
a "format unit" anyway, whether it'll handle the error gracefully, or whether 
it'll just lock up solid.

There may be a similar issue with ADFS on subsequent starts of the machine - 
some bridge boards allow persistent storing of drive geometry on the board 
itself, but I don't recall if the Adaptec does that. If it doesn't, ADFS is 
going to read the drive geometry that the formatter has stored at block 0 and 
try to issue its own Adaptec-formatted "define drive geometry" command at each 
boot. Who knows how it'll cope when that fails if issued to a SCSI disk.

(bridge boards just look like a SCSI mass storage device with two LUNs when 
running - ignoring any additional floppy/tape interfaces for the moment - but 
they all have their own vendor-specific ways of initially describing drive 
geometry)

> My experience is a bit different: I can sent commands to the drive, have 
> the led come on, send it to sleep etc. But an effective low-level format 
> never resulted in something else than 512bytes/sector

That's interesting that it gets past the geometry definition phase, though.

I suspect what you're seeing is the formatter essentially issuing a "format 
unit with default b/s" command - I can't remember if b/s would be set within 
the format unit command itself, or in a previous geometry definition. Either 
way, I bet it's set to "default" (0) rather than 256 and the code's  expecting 
the drive / bridge board to either default to 256b/s or be jumpered to do so.

Everything would probably spring into life if that value is changed in the 
formatter - and isn't it just a BASIC program? Anyone got a (ASCII txt file) 
listing handy?

cheers

Jules