Date : Tue, 06 Jan 2004 01:50:19 +0000
From : jgh@... (Jonathan Graham Harston)
Subject: IDE Interface for BBC
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. However, before I commit the
design, I'd appeciate a few comments on some options.
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? The two options are:
A3=low/high A0=low/high
FCx0 Data low byte FCx0 Data low byte
FCx1 Error FCx1 Data high byte
FCx2 Count FCx2 Error
FCx3 Sector FCx3 (always zero)
FCx4 Cylinder low FCx4 Count
FCx5 Cylinder high FCx5 (always zero)
FCx6 Head+Drive FCx6 Sector
FCx7 Status/Command FCx7 (always zero)
FCx8 Data High Byte FCx8 Cylinder low
FCx9 (always zero) FCx9 (always zero)
FCxA (always zero) FCxA Cylinder high
FCxB (always zero) FCxB (always zero)
FCxC (always zero) FCxC Head+Drive
FCxD (always zero) FCxD (always zero)
FCxE (always zero) FCxE Status/Command
FCxF (always zero) FCxF (always zero)
I like the A3=low/high option as the disk data address runs in
consectutive locations: 3,4,5,6 and so can be thought of as a single 32bit
word. A0=low/high is useful as it has both data locations in adjacent
memory locations. There's no intrinsic performance or programatical gain
for either, a read loop would be:
LDX #1:LDY #0 LDX #1:LDY #0
.loop .loop
LDA &FCx0:STA (ptr),Y:INY LDA &FCx0:STA (ptr),Y:INY
LDA &FCx8:STA (ptr),Y:INY LDA &FCx1:STA (ptr),Y:INY
BNE loop BNE loop
INC ptr+1:DEX:BNE loop INC ptr+1:DEX:BNE loop
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.
It is easier to program accessing those 512-byte sectors by either:
* Ignore the high byte. Each 256-word sector holds 256 bytes of data in
the low byte, and the high byte is ignored. The halves the stated
capacity of the drive. An 80MB drive would actually hold 40MB of
accessable data.
* Deblock two 256-byte sectors "horizontally" into the 512-byte IDE
sector, by storing the first 256 bytes in 00/lo, 00/hi, 01/lo, 01/hi ...
up to 7F/lo, 7F/hi, then the second 256 bytes in 80/lo, 80/hi, 81/lo,
81/hi ... up to FF/lo, FF/hi. This is a bit fiddly programatically, but
doable.
* 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.
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.
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!). If I do include them
they would end up at address FCxE and FCxF if addressing option 1 is used.
Thanks!
--
J.G.Harston (JGH BBC PD Library) 70 Camm Street, Walkley, SHEFFIELD S6 3TR
jgh@... - Running on BBCs & Masters with SJ MDFS FileServer
Z80+6502/CoPro+Tubes/Econet+SJ - - - - - - - http://www.mdfs.net/User/JGH/
NOBODY expects the MACRO ARGUMENT INQUISITION! Our chief weapon is
unexpected addressing modes... unexpected addressing modes and local
branches out of range. Our two weapons are unexpected addressing modes
and local branches out of range and quoted argument lists. Our *three*
weapons are unexpected addressing modes, local branches out of range,
quoted argument lists, and an almost fanatical devotion to the pope.
*Amongst* our weapons are such elements as unexpected addressing modes,
local branches out of range... I'll come in again.