as@aipna.ed.ac.uk (01/07/91)
> This is quite normal. The machine can't refresh the high res > screen modes while maintaining the data tranfer rate needed for the disc > access. So the screen is not refreshed while data is being transferred > from the disc. If I remember correctly, even the old Electron did this > in some modes. I cannot belive that it is the ABSOLUTE data transfer rate that makes it impossible. Floppies, after all, only transfer 25K per second. That is 40 uSec per byte, or assuming mode 21 eats up 4Mhz of memory bandwidth, 160 instruction cycles. This is plenty to shift one byte into a buffer. The real reason - I CONJECTURE - is that the Arch does floppy disk I/O in much the same way that the old BBC did - i.e. transferring each *byte* using a tiny non-maskable interrupt routine. In mode 21 I suspect the interrupt latency turned out to be too high for reliable floppy operation and a quick patch had to be made. It would be nice to hear from someone who KNOWS though... After all, if things are as I suspect blanking could be disabled by using interrupt per sector floppy disk i/o routines. Also, wouldn't it be nice to have a true 8 bit colour video card with its own memory. Surely possible - doesn't one of the slots have a 32 bit data-path and 512K of addressing space? > The only time you shoulf worry is if the same thing happens in a > lower res mode such as 12 or 15. Have you tried mode 20? Mode 20 works just fine - it only uses 1/2 the memory bandwidth of mode 21. On a lighter note the NMI approach to disk I/O seems to have led to something of a cult of low interrupt latency at Acorn. When asked at the launch of the model B why Acorn had gone for the 6502 rather than the (much nicer, much more expandable, also available on Acorn's board-level products) 6809 an Acorn engineer explained that they were worried about the 6809's interrupt latency. This turns out to be 60-80 cycles, i.e. much too slow to do floppies byte by byte, a la 6502. A pity - with the 6809 (and its MMU's and OS's) the Beeb could have been an all round much nicer engine to program and more stretchable. Albeit, it might had trouble doing disk i/o and all those other interrupts simultaneously! Andrew Andrew Stevens, JANET: as@uk.ac.ed.aipna Dept. of Artificial Intelligence, ARPA: as@aipna.ed.ac.uk 80 South Bridge, UUCP: ...!mcvax!ukc!aipna!as Edinburgh University, EDINBURGH -- Andrew Stevens, JANET: as@uk.ac.ed.aipna Dept. of Artificial Intelligence, ARPA: as@aipna.ed.ac.uk 80 South Bridge, UUCP: ...!mcvax!ukc!aipna!as Edinburgh University, EDINBURGH
has@ukc.ac.uk (H.A.Shaw) (01/08/91)
In article <3800@aipna.ed.ac.uk> as@aipna.ed.ac.uk () writes: > >On a lighter note the NMI approach to disk I/O seems to have led to >something of a cult of low interrupt latency at Acorn. When asked at >the launch of the model B why Acorn had gone for the 6502 rather than >the (much nicer, much more expandable, also available on Acorn's >board-level products) 6809 an Acorn engineer explained that they were >worried about the 6809's interrupt latency. This turns out to be 60-80 >cycles, i.e. much too slow to do floppies byte by byte, a la 6502. Is this true? I'm not sure how you define Interrupt Latency but I have used 6809s (GWP - Gods Wonderful Processor) for many years and the literature (borne out by measurement with a 'scope) tells me that... Fast IRQ takes 12 cycles and RTI from it takes 6 cycles. NMI or IRQ takes 21 cycles and RTI from it takes 15 cycles. SWI takes 19 cycles and RTI from it takes 15 cycles. SWI2 and SWI3 take 20 cycles and RTI from them takes 15 cycles. If we catch the CPU at the beginning of the longest duration instruction ... JSR [label,PCR] - take 16 bit label and add Program Counter to get 16 bit address. (Add wraps around at $FFFF to allow -ve offsets) - take 16 bit data at this address as the address to jump subroutine to. ... we have to wait 15 cycles before the interrupt is started. So a maximum possible total of 36 cycles in and 15 cycles out of an interrupt under worst conditions, and a mimimum of 12 in and 6 out. In fact 6809 instructions take an average of 5 cycles if the Direct Page is used a lot and so the average delay from NMI/IRQ to the first opcode fetch of the interrupt routine will be about 24 cycles. In fact you can use the SYNC instruction with all interrupts disabled to get an interrupt responce of 1 cycle because SYNC halts the CPU, and an interrupt restarts it in 1 cycle. In the BBC the OS stuck in a tight loop while the NMI was used to get the bytes from the floppy so the SYNC method would work well. The tight loop becomes the interrupt routine and a SYNC instruction is placed at the begining of the loop. In fact you use IRQ and not NMI under these conditions and have to remember that ANY interrupt will trigger the exit from SYNC. >-- >Andrew Stevens, JANET: as@uk.ac.ed.aipna >Dept. of Artificial Intelligence, ARPA: as@aipna.ed.ac.uk >80 South Bridge, UUCP: ...!mcvax!ukc!aipna!as >Edinburgh University, EDINBURGH The poor 6809 gets so little press I feel SOMEONE ought to stand up for it. Email: has@ukc.ac.uk | Howard Allan Shaw. | The Unit for Space Science. Phone: +44 227 764000 Extn: 3785 | Room 165, Physics Laboratory, | The University, | Canterbury, England. CT2 7NZ
nick@abccam.abcl.co.uk (Nick Reeves) (01/08/91)
The situation as some of you seem to have guessed is that the floppy driver turns off video DMA temporarily if lack of bandwidth causes an overun error. Remember that the FIQ for each byte of the sector must be serviced in 32 us or the whole sector must be retried. This means that there is a minimum bandwidth needed for floppy operations to be possible.