[comp.sys.acorn] MODE 21 & MULTISYNC

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'!       |   @@@/---|
*-----------------------------------------------------------------*   @@/    |