[atari7800] Re: DMA TIMING

>Based upon a demo I did a long while back the following is a rough guide: 2
>cycles / DL&DLL byte, 3 cycles / tile/graphics byte, approx 400 cycles
>available per line.

For "3 cycles /tile/graphics byte" does that mean 3 cycles for each character 
table entry byte and an additional 3 cycles per bitmap byte for a total of 6 
cycles per character? Then why does the software guide say 6 cycles per 
indirect and 3 cycles per Character Map access, implying 9 cycles per character?

In my case, I'm trying to write 2 layers of 320x2 characters, 96 bytes per 
layer. Only the bottom layer is being displayed but it is being displayed 
completely.

This implies that:

DLL entry (3 bytes) + DL List for 4 sets of characters (20 bytes) + 24*4 
Character Map bytes + 24*4 bitmap bytes + overhead ~= 456 cycles

To be conservative, I'll assume 30 cycles of overhead (startup, shutdown, DMA 
doesn't start until 7 cycles into a scanline, etc)
Four 5 byte DL entries = 48 cycles (according to software guide) [or 40 by your 
rough guide].
3 bytes DLL = Software guide doesn't say [6 cycles by your rough guide]

So,  after overhead, DL and DLL I should be left with 372 cycles (this may be 
ballparked)

372/96 characters  = 3.875 cycles per character.

So 3 cycles per character (total) is probably correct. If it were 6 or 9 then 
only half the bottom layer (or less would be displayed). Even if we assume 0 
overhead, 456/96=4.75 cycles per characters there's no way anything like 6 or 9 
is correct.

This does seem to indicate that characters DON'T take an appreciable 
performance hit over sprites. If they do, it's probably limited to some added 
overhead and NOT on the order of several extra cycles per byte


Soooo, to achieve my nefarious goals...

30 cycles of overhead
8 4 byte DL entries = 64 cycles
3 bytes DLL = ?/6

Worst cases 356 cycles left

192 bytes to be written 

192*3=576
192*2=384

So neither way is that going to work.

If instead I do 31-byte wide sprites, 3 per layer (186 bytes):

30 cycles overhead
6 4 byte DLL entries (3 per layer) = 48 cycles
3 bytes DLL = ?/6

Worst cases 372 cycles left

186*3=558
186*2=372

So, if placing bitmap data into RAM does drop it down to 2 cycles per byte 
(I've heard conflicting reports now from various sources) then we're in the 
right ballpark, depending on the actual overhead values. If I have to shave 
another byte off the edge, that's no biggee. Sure, I might wind up with a 
screen 310 pixels wide. I can live with that...

!!!

Hrm, wait a minute, I just realise that by writing 96 bytes of data I'm 
actually writing 384 pixels of data which extends off the right hand side of 
the screen. I only actually have to write 80 bytes of data per layer! Holy 
crap! Holy Dhuh!

So once again:

30 cycles overhead
6 4 byte DLL entries (3 per layer) = 48 cycles
3 bytes DLL = ?/6

Worst cases 372 cycles left

160*2=320
160*3=480

Even if I'm stuck at 3 cycles per byte, 372/3=124 so I could do about 62 bytes 
per layer which would leave an added 72 pixel border at both edged of the 
screen. Umm, maybe usefull for something... I dunno, unless I can get 
confirmation about 2 cycles per byte if it's coming from RAM, I'm probably just 
going to have to try the thing and see if it goes...

Maybe I'll just put the character bitmap into RAM, transition from 96 to 80 
bytes, and see if it makes any difference...

Chris...

Other related posts: