Date   : Sun, 30 Oct 2005 20:06:58 +0000 (GMT)
From   : Greg Cook <debounce@...>
Subject: Re: BBC using 3.5 high density format

On 30 Oct 2005 09:39:36 +0000, Jonathan Graham Harston
<jgh@...> wrote:

> > Message-ID:
> <20051029215011.36440.qmail@...>
>  
> Greg Cook <debounce@...> wrote:
> > > disc spins and the density the bits are packed at you end up with
> > > about 40us per byte.
> > 
> > High density may be achievable, if we take a leaf from Opus' book.
> > 
> > Supposing the HD controller board only raises NMI on a data request
> (by
> > not connecting INTRQ), all the service routine need do is fetch the
> > value, store it and increment the address.  To do a disc operation
> we
> > issue a single sector command then poll the status register and the
>  
> That *is* how the disk I/O works. The code does something like:

The DDOS controller, and the Acorn one as emulated by BeebEm, do raise
NMIs on an 'event.'  This caused trouble with EDOS as too many bytes
were being loaded and saved.

>From earlier correspondence on this list (24 Nov 2004) I was under the
impression that loading/saving whole sectors to memory (as opposed to
cancelling the command after the exact number of bytes had been
transferred) was rare.

> .iord
> LDA FDC_Status:Bxx iord_finished  ; No more data
> LDA FDC_Data                      ; Get byte from FDC
> .iostore
> STA &FFFF                         ; This is initialised to dest addr
> INC iostore+1:BNE iord_ok         ; Inc low byte of address
> INC iostore+2                     ; Inc high byte of address
> .iord_ok
> RTI                               ; Done this byte
> .iord_finished
> STA foreground_flag               ; Set flag for foreground loop
> RTI
[...]
> So, reading to I/O memory takes seven instructions per byte. The
> NAUG totals this up to 7+4+2+4+4+6+2+6+6=41 or 7+4+2+4+4+6+3+6=36
> cycles. That's 41us or 36us per byte at 1MHz, 21us or 18us per
> byte at 2MHz.

If we're on a strict DRQ'ing system, the NMI routine shouldn't need to
look at the status register at all, especially if it just writes a
semaphore to halt the outer loop.  Accessing the data register will
clear the NMI.  If we have a shared DRQ/INTRQ interrupt, b7 (motor on)
isn't the right flag to test (BXX)...

> Somebody earlier said that an HD FDC would spew bytes out every
> 40us. At 1MHz there's not enough time to process 255 out of every
> 256 bytes when the branch skips the high byte increment.

The interval for SD is 1s/3125/5 = 16 /250 kHz = 64us. HD is a quarter
that.  Allowing for varying drive speeds and jitter an interval of 15us
should be accepted, ideally 14.5us.  See Tom Seddon's post for a 1 MHz
solution.

> If
> accessing the FDC keeps the CPU running at 2MHz, though, there is
> plenty of time, the NMI occupies on average 52.5% of processor
> time.

CPU power saving?  Where? :-)  (I know what you meant, but only that
cycle would be stretched, the code itself will run according to the
speed of page &D, which had better be 2 MHz.)

Greg



               
___________________________________________________________ 
To help you stay safe and secure online, we've developed the all new Yahoo!
Security Centre. http://uk.security.yahoo.com