Path: utzoo!utgpu!cunews!bnrgate!uunet!mcsun!ukc!edcastle!aipna!aipna.ed.ac.uk!as From: as@aipna.ed.ac.uk Newsgroups: comp.sys.acorn,eunet.micro.acorn Subject: Re: MODE 21 & MULTISYNC Message-ID: <3800@aipna.ed.ac.uk> Date: 7 Jan 91 15:31:54 GMT Sender: news@aipna.ed.ac.uk Reply-To: as@aipna.ed.ac.uk () Organization: Dept of AI, Edinburgh, UK Lines: 53 > 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