Path: utzoo!attcan!uunet!super!udel!rochester!cornell!mailrus!ames!amdahl!oliveb!amiga!bart
From: bart@amiga.UUCP (Barry A. Whitebook)
Newsgroups: comp.sys.amiga
Subject: Re: 2090A problems
Keywords: 2090A, DMA, overscan
Message-ID: <3109@amiga.UUCP>
Date: 15 Nov 88 20:46:55 GMT
References: <6055@killer.DALLAS.TX.US>
Reply-To: bart@popeye.UUCP (Barry A. Whitebook)
Organization: Commodore-Amiga Inc, Los Gatos CA
Lines: 27

In article <6055@killer.DALLAS.TX.US> aimania@killer.DALLAS.TX.US 
(Walter Rothe) writes:
)AMAZING computing just came out with an article that shows that the 2090A 
)slows way down when doing a 704 by 644 by 4 bitplane overscan display. 
)I would expect some slowdown since this leaves only 50 slots out of a
)total 226 to do all other DMA and CPU cycles during one scan line.
)However, there should be plenty of time during vertical retrace to get
)the needed disk activity in. Other controllers seem to be able to do this
)but the 2090A does not seem to be able to use this time. What's going on?

fyi: what is going on is that there is a fifo buffer between the dma 
controller and the scsi disk for input/output which must be serviced before
over/underrun. when there is dma contention (for example 704x644x4 display)
on the bus there isn't time during vblank to guarantee a full transfer of
large transfers of data. so the 2090 driver is forced to transfer a block
at a time and to GUARANTEE that no over/underrun occurred (you wouldnt like
a single byte of your file to get corrupted, would you?)

to avoid the problem when displaying a dma saturated display and transferring
data with the 2090 just "drag the screen down". you'll find that the maximum
transfer rate proportional to the amount of dma cycles that you free up.

note that the 2090/A code is fully multitasking compatible. within this 
framework, the only solution to this problem is full dma/scsi handshaking
via hardware control lines.

bart