Date   : Sun, 03 May 2009 19:12:47 +0100
From   : mfirth@... (Michael Firth)
Subject: ADFS 1.53 patch

----- Original Message ----- 
From: "Sprow" <info@...>
To: <bbc-micro@...>
Sent: Sunday, May 03, 2009 6:55 PM
Subject: Re: [BBC-Micro] ADFS 1.53 patch


> In article <zL5PGVCxdd$JFwRP@...>,
>   Mike Tomlinson <mike@...> wrote:
>> In article <5055be80e6info@...>, Sprow <info@...> writes
>>
>> >The ATAPI commands need a 16 bit interface, so even if you throw away 
>> >half
>> >the drive capacity you can't even issue the command without a 16 bit
>> >interface.
>>
>> Many thanks.  I've just had a browse of JGH's site.  The separate
>> references to 8-bit and 16-bit IDE interfaces have gone, and there is
>> only mention of the one interface now, which appears to be the 8-bit.
>
> Shame, since the 8 bit interface is unbuffered so can't be used with other
> 1MHz bus kit.
>
>> I'm puzzled.  How does HDInit get the drive geometry from an 8-bit
>> interface?
>
> Because there's a certain amount of redundancy in the numbers, say a 512MB
> drive
>
>  0x20000000 as seen by 16 bit
>  0x20xx00xx as seen by 8 bit
>
> clearly the last byte must be zero because of the sector size, and with a
> few more heuristics you could guess the other byte I suspect (and so on 
> for
> other common drive sizes above this),
> Sprow.
>
It doesn't seem to be limited like this though. In regular '16 bit' mode, 
the HDInit command does have problems getting the geometry of the drive on 
an 8-bit interface, as you suggest (i.e. the 2nd and 4th bytes are wrong, 
usually 0xFF on the Retroclinic interface). However, press 'TAB' in the 
HDInit program, and the display changes to say that its running in 8-bit 
mode, and the 'get geometry' command now works correctly (i.e. the 2nd and 
4th bytes have valid values in).

Is there some trick in the code to let it read the data twice, but the 
second time have a 1 byte offset, so that the 'other' bytes of the 16 bit 
values become available, or is it just possible to switch an IDE interface 
into 8 bit mode?

Actually for the 1G CF cards I was using, the size wasn't that close to the 
'0x40000000' theoretical value that you suggest, and having the 2nd byte be 
its correct value, rather than zero (which is the only safe option if it 
isn't known), gave a reasonable amount of additional storage.

Regards

Michael