A3000 DMA and Video?
10 messages in this thread
A while ago, there were HD wars with long discussions (both here and in the
mag-rags) about the pros/cons of DMA HD's in an animation/video processing
environment. I got the impression that for those application environments,
the non-DMA (or partial DMA a la GVP) were preferable to the DMA
implementation due to possible contention for chip ram access.
The reviews and literature on the A3000 mention a "SCSI DMA hard drive
controller chip…" What does this mean to the video/animation user? Is it
better to upgrade to the A2630, GVP SCSI HD ctlr in a 2000 or go for the
A3000 or is it a "max nix" situation in that area?
wmc
Wayne,
According to Dave Haynie…the designer of the B2000 and A3000
CBM's DMA host adapter on the A3000 is a 'win' in any situation over a
non-DMA controller.
I don't recall all his reasons…but I know it made sense to me
when I read them.
Don
Don,
WOW, that ws a fast reply (smoking monitor where it screached in…;^} ).
Only problem is its one that makes the decision harder! Maybe I'll hit the
lottery tommorrow and the problem will be solved – accelerate the 2000 AND
buy a 3000!
wmc
Wayne: it might not be a 'macht nichts' situation. Then again, ?
True DMA is almost always preferable, as it (like the blitter) takes
another load off the cpu. Of course, someone would need to add an identical
drive to a 2000 and do some tests to see just how much difference there is.
It might not be a lot when going to chip ram.
The 32-bit access to the chip RAM in the 3000 should help, tho. Its DMA
chip will gather up 32-bits from the SCSI port at a time, and then write it
all at once to the chip ram. That should mean less contention with the
cpu/blitter (which it must have priority over) than otherwise. Unless…
Hmmm. If the DMA to video ram is _only_ during blanking (like floppy DMA),
then non-DMA could be far faster!
Double hmmm. Hires video mode is a stickler too. Unless they pulled some
kind of trick in order to transfer 16-bits first to one video bank, then
the other, DMA wouldn't help much at all no matter what.
Drat. This is one reason I don't like it when articles and press releases
don't go into details (and tech manuals are unavailable)… makes me
nervous debating speed relationships ;-). Everything depends on just how
fancy CBM implemented things.
Another thing you might want to think about, is that A3000 DMA can
DMA into FAST RAM. That has NO chip contention. So if you're
worried about DMA contention with graphics screens, don't.
As far as I know, the DMA contention only mattered using SEVERE overscan
HIRES screens. And at that, I don't think it was enough to be a problem.
I think it was originally a problem with the original A2090 hardware
or software, but probably not a real problem anymore.
-Richard
Yep, DMA into fast RAM is no problem. But he was specifically talking about
DMA into chip ram, for fancy audio/video apps.
The big Q is: does the SCSI DMA take place during cpu cycle slots? Or
sometime else? Or ?? I'm curious, also. – kev
It was my understanding that the problem with DMA into chip ram was
solved for A2091, etc by DMA'ing in smaller chunks. But, I think
I heard that quite awhile ago. Although I'd be surprised if there
is a problem going disk to chip ram for animations. That should
be something they would have wanted to fix if not did fix.
-Richard
Richard,
Trouble is, in hires-color modes there just isn't much time left for anyone
else to access the video RAM. Certainly not for the blitter nor cpu, and a
good guess is that the SCSI DMA uses the cpu cycles.
Now _perhaps_ CBM got fancy on the A3000 and allowed a transfer mode where
(in extreme cases) 16-bits are sent at a time (to the bank side which the
video isn't accessing at that moment), but I kinda doubt it.
So if the arguments ran that DMA into hires video wasn't much faster than
cpu transfers, I could easily go along.
But we just don't know yet. It appears to me, however, that CBM is being
pretty clever just to say "32-bit SCSI DMA"… because then people grab
this buzzword and assume all, on their own, that it's also an absolute
panacea for chip ram transfer speed. We need some testing, and tech specs!
best – kev
Kev,
I don't think many application programs reading data from a hard drive will
have the HD stick it straight into chip ram, unless that is all a person
has. Or let me put it another way – you have a program that shows IFF
pictures, you may think the data from the HD is going to go straight into
chip ram, but it shouldn't. IFF pictures are normally saved with some
compression, so the data would be loaded into a buffer the program
allocates, which should be in fast ram, the program decompresses the data,
an moves it to chip ram.
DPaint is supposed to be slow when reading SCSI disks using the 2090/2090A
boards. Maybe they tried to be cute, so they allocated the buffer in chip
ram so they could save a few cycles by using the blitter to move the memory
from one part of chip ram to another – or they just plain stupid! (anybody
have a program to see what part of memory data from a HD goes to? I know
Larry has one to see what size chunks are read.)
The problem with the 2090/2090A boards was not directly due to DMA
contention, just that DMA contention made the problem apparent. From what
I remember, during this condition, once the buffer was full on the 2090(A),
the data was still coming from the SCSI drive, so when the buffer was
emptied and ready to be filled again, the block on the HD had to be read
again.
I have a 2090A board here, though use the ST-506 side of it (no SCSI drives
here). Most of my stuff is done in 666×400 mode and never have any
problems with the CPU (A2620/4) or HD doing their work with out running
into problems. I was going to say fast enough, but until I have a machine
with a 68040 running at 25 MHz….
73, Kelly
Kevin,
Wonder if Dave M. could shed some light on this when he gets back form
vacation…
wmc