Date : Thu, 08 Jan 2004 11:37:34 +0000
From : Jules Richardson <julesrichardsonuk@...>
Subject: Re: IDE Interface for BBC
On Tue, 2004-01-06 at 01:50, Jonathan Graham Harston wrote:
> I'm building a prototype IDE interface for the BBC. I think if I'm careful
> I can get it down to a two-chip solution.
Nice :) (although I seem to have a bazillion SCSI drives on the shelf
and no IDE drives...)
> 1: The IDE interface uses a 16bit data bus. The usual solution to get at
> this through an 8bit data bus is to have two i/o locations, one for the
> bottom byte, one for the top byte. Does anybody have any opinion on
> whether I should put the two data registers next to each other in the i/o
> map, or 8 locations apart?
Having the two data registers next to each other looks cleaner to me,
but I don't think there's a lot in it either way to be honest.
It's been a long time since I've looked at the IDE interface - isn't the
a command (or maybe a physical attribute of the interface) to put the
drive into 8-bit mode in order to maintain compatibility with the
earliest IDE host interfaces? My memory is very hazy on that one though
- and who knows if modern drives actually support 8 bit mode...
> 2: How useful would it be to be able to remove the hard drive from the BBC
> and plug it into an Arc and access it natively with RISC OS ADFS? RISC OS
> supports ADFS/47 entries/old map, which is the ADFS used on 8bit Acorns.
> The point of this question is that ADFS L uses 256-byte sectors, and the
> vast majority of off-the-shelf IDE drives use 256-word sectors, with 16bit
> words, ie 512 bytes. It's quite hard to find an IDE drive that obeys the
> "sectorsize=256" command.
My suggestion there would be to use 512 byte sectors. Let someone else
worry about software to read the thing on an arc (or other system) if
they wanted to.
> * Deblock two 256-byte sectors "vertically" into the 512-byte IDE sector,
> by storing one set of 256 bytes in 00/lo, 01/lo, 02/lo ... up to FF/lo,
> and another 256 bytes in 00/hi, 01/hi, 02/hi ... up to FF/hi. The
> advantage with this method is that it is naturally expandable from
> accessing the drive as a purely 8bit device.
I would *much* prefer that option to the other. At least if the drive
ever crashes it's much easier to recover data that way rather than it
being all mixed up.
> Also, if there is no demand for drive interchangability, I can access the
> cylinder/head/sector in a different order. Most IDE drives are xx/16/63,
> and it would be easier to move that fiddly divide-by-63 away from the
> bottom of the address, eg as xx/63/16, or 63/1024/16 and partition the
> drive into 500MB sections. In fact, judging by the fact that RISC OS<3.60
> falls over with drives larger than 500MB, I suspect that's exactly what
> RISC OS ADFS actually does.
Hmm. Interesting. I'm used to SCSI drives and treating everything as a
linear sequence of blocks regardless of actual drive geometry. I'm also
used to backing up raw data from old machines using a different host;
spitting the data back onto a different drive with different geometry
still works as the data's still just a linear sequence. Messing around
with the way the addressing is done sounds a little iffy, but maybe
that's the way it has to be.
> 3: Does anybody have a desperate need to be able to access the IDE Drive
> Address register, or the Digital Output register. Documentation says that
> these two registers hold data normally of no use to the programmer. The
> IDE Drive Address register just holds a copy parts of the Head+Drive
> register, and the Digital Output register allows the IDE controller to be
> reset without using the Command resgiter. It makes the interface a whole
> lot easier if they are omitted (two-chip solution!).
They don't sound particularly vital to me.
cheers
Jules