<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
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.
<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>