seifert@freja.diku.dk (Michael Seifert) (12/21/90)
Hi All, I have a problem with Mode 21 and a multisync monitor. My machine is configured as follows: Arc 410/1 2Mb Ram, 20Mb HD, 3.5" floppy disk-drive. Eizo 9060SZ MultiSync Monitor The problem: When I access the (floppy) diskdrive in mode 21, my screen will turn "black with a small gray border" several times. It seems to me the it goes black whenever information is read from the diskdrive. Is this a problem with my Archimedes, the software I'm using (RISC OS II) or is it a production fault? It does seem rather stange that the gray border is kept on the screen when it goes black! Has anyone experienced these or similar problems? What do you guys at Acorn think? Wish you all a merry Xmas, happy new year, and a great summer vacation. May even more and better hard/software be developed for the Archi in the year to come (ARM 4 or affordable FPA would be really nice) Regards, Michael seifert@freja.diku.dk
gaspar@urz.unibas.ch (12/21/90)
In article <1990Dec21.031201.3334@odin.diku.dk>, seifert@freja.diku.dk (Michael Seifert) writes: > Hi All, > > I have a problem with Mode 21 and a multisync monitor. My machine is > configured > as follows: > Arc 410/1 > 2Mb Ram, 20Mb HD, 3.5" floppy disk-drive. > Eizo 9060SZ MultiSync Monitor > > The problem: > When I access the (floppy) diskdrive in mode 21, my screen will turn "black > with a small gray border" several times. It seems to me the it goes black > whenever information is read from the diskdrive. I think it is a completely normal behaviour, although very strange! I have the same hardware and see the same effects. Maybe it's the problem that there cannot be so much data (320K 50 times a second) be brought from memory to the screen and at the same time a lot of data from the disk to memory. > Wish you all a merry Xmas, happy new year, and a great summer vacation. thanks, for you, too! > May even more and better hard/software be developed for the Archi in the > year to come (ARM 4 or affordable FPA would be really nice) that would be great!!! laci
chughes@maths.tcd.ie (Conrad Hughes) (12/22/90)
In <1990Dec21.031201.3334@odin.diku.dk> seifert@freja.diku.dk (Michael Seifert) writes: >The problem: > When I access the (floppy) diskdrive in mode 21, my screen will turn "black > with a small gray border" several times. It seems to me the it goes black > whenever information is read from the diskdrive. It happens with any Arc, although I think the new VIDC solves the problem. Conrad -- experience teaches silence terrifies people the most - Bob Dylan Disclaimer: Opinions, when given, are my own.
thsa@rhi.hi.is (Thorvaldur S Arnarson) (12/22/90)
The problem with mode 21 is that it eats upp nearly all of the memory badwith and leaves little left for the precessor. When the diskdrive issues an NMI (non maskable interupt) for a slow flopy read the screen just doesn't get the bandwith it takes to display the screen and hence goes blank. This is roughly what happens, I don't know if the OS has a built in feature to turn all screen DMA's off during interrupts that might might cause it not to be fully redrawn, or if the harware behaves in such a civiliced manner. Greetings, Thorvaldur S. Arnarson. -- Regards, Thorvaldur S. Arnarson
banksie@whitu.isor.vuw.ac.nz (Philip Banks) (01/06/91)
In article <1990Dec21.101354.1261@urz.unibas.ch>, gaspar@urz.unibas.ch writes: |>In article <1990Dec21.031201.3334@odin.diku.dk>, seifert@freja.diku.dk (Michael Seifert) writes: |>> Hi All, |>> |>> I have a problem with Mode 21 and a multisync monitor. My machine is |>> configured |>> as follows: |>> Arc 410/1 |>> 2Mb Ram, 20Mb HD, 3.5" floppy disk-drive. |>> Eizo 9060SZ MultiSync Monitor |>> |>> The problem: |>> When I access the (floppy) diskdrive in mode 21, my screen will turn "black |>> with a small gray border" several times. It seems to me the it goes black |>> whenever information is read from the diskdrive. |> |>I think it is a completely normal behaviour, although very strange! |>I have the same hardware and see the same effects. |>Maybe it's the problem that there cannot be so much data (320K 50 times a |>second) be brought from memory to the screen and at the same time a lot of data |>from the disk to memory. |> And indeed that is percisely the case. From my experience any screen mode with more than about 220k of screen memory will blank out when the floppy drive is accessed. You will notice that the hard drive does not cause this problem and this is due to timing factors. With a floppy drive you have long start rotation times and a slower rotation speed so that for fast disk access the computer *must* be ready to accept the data whenever it arrives. However with a hard drive the high rotation speed (and the disk cacheing on some of the drive controllers...) skipping a rotation is not so serious in terms of speed and the Arc can accept the data at its own pace. Thus the screen does not blank out! Here endeth the explanation. *-----------------------------------------------------------------* @@@@@@/| | BANKSie! (aka Philip Banks) banksie@isor.vuw.ac.nz | @@@@@/#| | An Arc owner stuck in a non Arc spot. | @@@@/##| | Well you try drawing the Arc Symbol in Ascii 'Graphics'! | @@@/---| *-----------------------------------------------------------------* @@/ |
rcpieter@svin02.info.win.tue.nl (Tiggr) (01/06/91)
banksie@whitu.isor.vuw.ac.nz (Philip Banks) writes: > And indeed that is percisely the case. From my experience any screen >mode with more than about 220k of screen memory will blank out when the >floppy drive is accessed. You will notice that the hard drive does not >cause this problem and this is due to timing factors. With a floppy >drive you have long start rotation times and a slower rotation speed so >that for fast disk access the computer *must* be ready to accept the >data whenever it arrives. However with a hard drive the high rotation >speed (and the disk cacheing on some of the drive controllers...) >skipping a rotation is not so serious in terms of speed and the Arc can >accept the data at its own pace. Thus the screen does not blank out! What a nonsense. I'm not sure about what I'm going to put below this line, but I expect it to be slightly nearer the truth than what is quoted above. The major difference between reading from floppy and reading from harddisk is that reading from floppy involves the ARM needing to service an FIQ for every byte that is read. When reading from harddisk, the ARM is only involved every sector, servicing an IRQ. The next observation to make is that the FIQ routine resides at an optimal spot in memory for it to take advantage of the next-read-is-sequential feature of ARM/MEMC. When doing sequential reads, the ARM has priority on the bus over VIDC. I expect that in hires modes this might cause that VIDC sometimes can't get the next words for the screen in time. Now, all this sounds very fuzzy and doesn't explain why the screen becomes a nice shade of grey, but I guess it has something to do with it. Then pooh drops by and suggests this is done on purpose by the floppy reading routine. Hohum, reminds me of the good ol' Electron :-) Tiggr
rcbaem@rwa.urc.tue.nl (pooh 'Ernst' Mulder) (01/07/91)
In <1664@svin02.info.win.tue.nl> rcpieter@svin02.info.win.tue.nl (Tiggr) writes: >What a nonsense. [ looots of stuff deleted :] >Then pooh drops by and suggests this is done on purpose by the floppy >reading routine. Hohum, reminds me of the good ol' Electron :-) No, Tiggr, WRONG! I didn't say it _is_ done, I merely suggested it _might_ be done on purpose by the floppy reading routine. Sowing a 220K screen takes a lot of bus bandwidth, and so does reading from a floppy device the way the Archimedes does it. Thus it wouldn't seem unlogical to turn the screen off when it's big and you want to read from a floppy device. It might also be done by the video controller itself. Then again what do I know, I've only got a Mac with a 512x342 monochrome screen... :)) >Tiggr pooh
andras@alzabo.uucp (Andras Kovacs) (01/07/91)
In article <1664@svin02.info.win.tue.nl> rcpieter@svin02.info.win.tue.nl (Tiggr) writes: >banksie@whitu.isor.vuw.ac.nz (Philip Banks) writes: > >> And indeed that is percisely the case. From my experience any screen >>mode with more than about 220k of screen memory will blank out when the >>floppy drive is accessed. You will notice that the hard drive does not >>cause this problem and this is due to timing factors. With a floppy >>drive you have long start rotation times and a slower rotation speed so >>that for fast disk access the computer *must* be ready to accept the >>data whenever it arrives. However with a hard drive the high rotation >>speed (and the disk cacheing on some of the drive controllers...) >>skipping a rotation is not so serious in terms of speed and the Arc can >>accept the data at its own pace. Thus the screen does not blank out! > >What a nonsense. > >I'm not sure about what I'm going to put below this line, but I expect >it to be slightly nearer the truth than what is quoted above. > >The major difference between reading from floppy and reading from >harddisk is that reading from floppy involves the ARM needing to >service an FIQ for every byte that is read. When reading from >harddisk, the ARM is only involved every sector, servicing an IRQ. The >next observation to make is that the FIQ routine resides at an optimal >spot in memory for it to take advantage of the next-read-is-sequential >feature of ARM/MEMC. When doing sequential reads, the ARM has priority >on the bus over VIDC. I expect that in hires modes this might cause that >VIDC sometimes can't get the next words for the screen in time. > >Now, all this sounds very fuzzy and doesn't explain why the screen >becomes a nice shade of grey, but I guess it has something to do with it. > >Then pooh drops by and suggests this is done on purpose by the floppy >reading routine. Hohum, reminds me of the good ol' Electron :-) > >Tiggr Observation #1: On my A310 which has a ComputerWare ST506 Hard Disk podule connected to a MiniScribe 3053 40MB (24 msec), in Mode 21 (which chews up 320K video memory) the hard disk reads are noticeably slower. The screen doesn't blank out, but the read (with an already positioned head) takes approx. 1/4 of a second, which is much-much slower than other reads. Observation #2: when you do a read from the floppy while in high-res mode, the blankout is similar to the effect when you shut down the video refresh to drive the processor as fast as it goes. Quotation #1: "The processor will not be stopped if it is about to perform a sequential memory access; instead, the DMA operation is postponed until the processor requests an internal cycle or a non-sequential memory access. Excessive DMA hold times are avoided by limiting the maximum number of consecutive processor S-cycles to three." (VLSI VL86C010 book) Quotation #2: "Maximum video/cursor DMA latency: ... 1070 ns." (Same book) Speculation: IMO the DMA accesses take priority over anything; this is why the processor itself slows down on large video buffers. This effect works with the hard drive also. In the case of the floppy, I suspect that they(*) intentionally shut down the video refresh 'cause it would take away to much of the memory bandwidth and/or processing power; without it the floppy reads would be atrociously slow. Footnote on (*): When I say "they", I mean the Acorn dudes. When the vote was on for comp.sys.acorn, I counted approx. 30 ("yea") votes from acorn.uk sites. It would be really nice if someone would come on line from Acorn and explain to us mortals the nitty-gritty details of this problem. Please excuse me for the long posting... Andras -- Andras Kovacs "Could somebody tell me what kind of a world we live in andras@alzabo.UUCP where a man dressed as a BAT gets all of my press..." Nepean, Ont. The Joker
ecwu61@castle.ed.ac.uk (R Renwick) (01/07/91)
>In article <1990Dec21.031201.3334@odin.diku.dk>, seifert@freja.diku.dk (Michael Seifert) writes: >> Hi All, >> >> I have a problem with Mode 21 and a multisync monitor. My machine is >> configured >> When I access the (floppy) diskdrive in mode 21, my screen will turn "black >> with a small gray border" several times. It seems to me the it goes black >> whenever information is read from the diskdrive. > 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. 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? I can't remember off hand if this is low enough to avoid the screen blanking. I must admit, I find it rather annoying at times, but you get used to it after a while (so I am told). I don't know of any way round this other thans changing modes. Rik
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.
banksie@ono.isor.vuw.ac.nz (Philip Banks) (01/13/91)
In article <1664@svin02.info.win.tue.nl>, rcpieter@svin02.info.win.tue.nl (Tiggr) writes: |>What a nonsense. |> |>I'm not sure about what I'm going to put below this line, but I expect |>it to be slightly nearer the truth than what is quoted above. |> |>The major difference between reading from floppy and reading from |>harddisk is that reading from floppy involves the ARM needing to |>service an FIQ for every byte that is read. When reading from |>harddisk, the ARM is only involved every sector, servicing an IRQ. The |>next observation to make is that the FIQ routine resides at an optimal |>spot in memory for it to take advantage of the next-read-is-sequential |>feature of ARM/MEMC. When doing sequential reads, the ARM has priority |>on the bus over VIDC. I expect that in hires modes this might cause that |>VIDC sometimes can't get the next words for the screen in time. |> |>Now, all this sounds very fuzzy and doesn't explain why the screen |>becomes a nice shade of grey, but I guess it has something to do with it. |> |>Then pooh drops by and suggests this is done on purpose by the floppy |>reading routine. Hohum, reminds me of the good ol' Electron :-) |> |>Tiggr Hey! Hey! Hey! Before you completely rubbish my explanation (while it is wrong) could you please consider a few mitigating factors instead of being somewhat rude! My geographic location places me almost exactly on the oppposite side of the world from Britain and this leads to two big problems :- The nearest Branch of VLSI is in Australia some distance away from me and consequently unlike most of you Britishers I have not yet got a copy of the VLSI data manual on the ARM hardware. Also due distance I find it *very* hard to just drop into Acorn and ask their staff about the hardware of the Arc. Accordingly I am a little in the dark about the hardware of the Arc. Now when I noticed this screen blanking I noticed two things:- 1) it only occurs when the screen mode uses more than about 220K of memory. 2) It only occurs with floppy drives not hard drives! So I thinks to myself what is the difference between hard drives and floppies? The bigest is their rotation speed. So I feel I was quite reasonable in making the conclusions I did. I suggest next time you want to correct some one you do it a little more tactfully! *-----------------------------------------------------------------* @@@@@@/| | BANKSie! (aka Philip Banks) banksie@isor.vuw.ac.nz | @@@@@/#| | An Arc owner stuck in a non Arc spot. | @@@@/##| | Well you try drawing the Arc Symbol in Ascii 'Graphics'! | @@@/---| *-----------------------------------------------------------------* @@/ |