Antic DMA Timings

[Rybags]

A couple of additions. As in my previous post, if Missile DMA isn't active, ANTIC uses that cycle to fetch the DLIST instruction.

 

There is also the instance where the Address data (from an LMS) gets loaded where a normal Player 3 data access would occur.

 

I haven't tried Jump DLIST instructions yet (who ever uses that anyway?)

 

Also, does anyone know what triggers GTIA to read the data bus? Without PMG DMA enabled on ANTIC, it only seems to read it when ANTIC is doing DLIST instruction fetches. That is also the case if you disable screen DMA, but leave DLIST DMA active.

[Heaven/TQA]

the jump instruction is good if you have parts of the display changing... f.e. logo panel, you could simply use the jmp command to change that...

 

think of demos where top and bottom stay the same but the middle of the screen change several times...

[pps]

oh...it was not joyride...can not remember which polish demo it was...

 

joyride has just 2 gfx modes per scanline.

 

I can remember, that it was the Our 5oft Part of the Unity Demo (ABBUC & Pokey), which showed us the '3 graphics mode in a scanline' effect.

 

btw was this Demo ever released in finished version, I remember a version, where you have many tbr messages?

[Sheddy]

the jump instruction is good if you have parts of the display changing... f.e. logo panel, you could simply use the jmp command to change that...

 

think of demos where top and bottom stay the same but the middle of the screen change several times...

 

it's a shame it causes a blank line when used - it would be much more useful if it didn't.

Edited May 31, 2006 by Sheddy

[Bryan]

So here's a question... does jump also cause the loss of VSCROL info like blanks do? (I'm guessing yes)

 

-Bry

[Rybags]

Probably, since it is effectively a 1-blank line display instruction.

 

A much better system would have been a Load Register instruction (like the Amiga) where subsequent data (say, up to 4 bytes) could be loaded into ANTIC or GTIA registers.

 

Instruction code $41 could be used, then subsequent data would specify the address and operands.

 

Example:

 

INS: $41

Address: bit 7 specifies ANTIC (0) or GTIA (1) register,

bits 6-5 specifies number of bytes to load (1-4)

bits 4-0 specifies address ($00-$1F)

 

So, a JMP DLIST would be $41,$20,<DLIST low>,<DLIST high>

 

Extra logic could be added so that opertions involving Player graphics or position registers were executed at mid scan-line (for reusing PMGs within a scanline).

Since we "lose" the JVB instruction, functionallity would have to be provided by a register within ANTIC.

 

All we need now is for someone to email that idea back to 1978.

Edited May 31, 2006 by Rybags

[Rybags]

Ed: wrong info

Edited May 31, 2006 by Rybags

[Bryan]

A much better system would have been a Load Register instruction (like the Amiga) where subsequent data (say, up to 4 bytes) could be loaded into ANTIC or GTIA registers.

 

Yeah, just think if we could go back and help Atari out. Also, think of the code available for a killer in-store demo.

 

-Bry

[Rybags]

Actually, loading POKEY using DMA would have been really nice too... digitized effects at the cost of just some memory and a couple of hundred stolen cycles per frame, instead of near 100% CPU cycles doing it the conventional way.

[Bennet]

"A much better system would have been a Load Register instruction (like the Amiga) where subsequent data (say, up to 4 bytes) could be loaded into ANTIC or GTIA registers."

 

Given that Jay Miner was the lead engineer who worked on the 2600, then 400/800, then the Amiga, you could say that he just didn't think of that idea yet (or there was some reason why it wouldn't work).

 

If anything, Jay got it right with the Amiga 4 channel digitized audio with variable frequency playback, plus a decent amount of system memory.

 

 

So, did anyone have any comments, surprises, or anything on my Antic timing diagrams?

[Rybags]

One slight "surprise" is the way the refresh cycles are bunched together... it means that the CPU is more or less stangled for a time - but I suppose it's better to lose those cycles early in the display than during overscan/Hblank.

 

Just how over-engineered is the refresh system? Could they have gotten away with less? But I suppose there is a "worst case" scenario where you can get 2 "badlines" in a row where barely any refresh takes place (40 column textmodes with VSCROL=7)

 

Do the refresh cycles access a different memory row in succession or do they just do some sort of random read?

[Bennet]

Yea, especially on the high resolution character modes, the CPU is frozen. Which made me wonder how other computers of that era did their high resolution displays given you can only read so many bytes per scanline.

 

I think the refresh system could have gotten away with less but probably not much less. I think the refresh circuit increments sequentially whenver it gets a cycle to run. I like how it handles getting preempted. I also wondered if there was a way to alternate the VSCROL on some high res modes to make a bunch of 1 scanline 48 column text mode lines, but I didn't think further than that.

[Rybags]

The C-64 only runs at half the RAM speed, so VIC does refresh and much of the screen DMA on the "alternate" cycles.

 

The BBC micro apparently has RAM running at 4 MHz and the CPU at 2 MHz. Supposedly, all refresh and screen accesses are transparent. I remember running a long loop in assembler - from memory it was sufficiently faster than on an Atari to prove those facts.

 

Z80 based computers don't have the pipelining advantage of the 6502 and memory accesses are less frequent. They probably suffer a slightly smaller penalty from DMA - but it's common knowledge that a Z80 needs to run at about a 60% or higher clock speed to match a 6502.

[Heaven/TQA]

is this somehow "standard" or does this depend on your researches?

 

Theory

 

------

 

ANTIC contains internal 4-bit register

 

DCTR, which counts scanlines. Normally

 

for every line of mode it counts from

 

zero to a value specific to the mode

 

(in our case of ANTIC 15 mode it's

 

zero). It's different after enabling

 

vertical scrolling. In first scrolled

 

line DCTR counts from VSCROL to 0,

 

in the subsequent normally, and in

 

the last from 0 to VSCROL. "Counts

 

from a to b" means: first DCTR is

 

loaded with a, and near the end of

 

every line DCTR is compared with b,

 

if there's equality, next DL

 

instruction will be fetched; otherwise

 

DCTR is incremented by 1.

 

Consider following DL:

 

$2f

 

$0f

 

and VSCROL=13 (decimal). We will see:

 

- first line 4 times (DCTR values

 

13,14,15,0 - DCTR wraps from 15

 

to 0, because it's 4-bit)

 

- second line 14 times (DCTR values

 

from 0 to 13)

 

Similarly for VSCROL=3:

 

- first line 14 times

 

- second line 4 times

 

What is important, the screen data

 

repeated in several scanlines is

 

fetched from main memory only once.

 

 

 

Obtaining the mode

 

------------------

 

As should be now easy to figure out,

 

to have each line shown 4 times,

 

we create following Display List:

 

b($6f),a(screen)

 

b($0f)

 

b($2f)

 

b($0f)

 

...

 

and only have to update VSCROL

 

register in proper moments.

 

 

 

Following picture should help in

 

understanding what happens

 

(in this English translation

 

I'll just use ASCII art, I hope

 

it's readable :-) ).

 

 

 

DCTR

 

13 @-------------------------

 

14 --------------------------

 

15 --------------------------

 

0 --------------------------

 

0 ==========================

 

1 ==========================

 

2 ==========================

 

3 ====!==================*##

 

\--visible screen--/

 

 

 

'-' - first line of mode

 

(bit 5 in DL is set)

 

'=' - second line of mode

 

(bit 5 in DL is clear)

 

'@' - here VSCROL must contain 13

 

'!' - here starts DLI

 

'*' - here VSCROL must contain 3

 

'#' - here we put 13 into VSCROL

 

 

 

This picture shows two lines

 

of mode, i.e. 8 scanlines.

 

It also shows the timing (scale

 

is not preserved) - as time goes

 

by, each scanline is displayed

 

from the left to the right.

 

 

 

First VSCROL must contain 13 decimal

 

(it's a 4-bit register, so high

 

nibble of value written to $d405

 

may be anything). As soon as ANTIC

 

loads DCTR with this value, first

 

line of mode is guaranteed

 

to be displayed correctly. Then

 

the second line will be shown

 

and only near the end of last

 

scanline VSCROL is required to

contain 3. So we have much time

to write 3 to VSCROL. We may do it

e.g. on DLI in the first line.

It's much worse with preparing

to display third line of mode.

As you see on the picture ('#')

there's little time to put 13 into

VSCROL (just a few cycles).

[Bennet]

is this somehow "standard" or does this depend on your researches?

 

It makes sense to me. but the formatting makes it very hard to read here. Any way to edit out those extra line breaks? It looks like the file came from an Atari!

 

Sounds like it's saying how you can make Antic display multiple lines of Mode F? (or any other mode) by setting VCTR to an invalid value through scrolling. Based on the internal workings I've seen this is to be expected.

Edited June 2, 2006 by Bennet

[Rybags]

Another attribute, although possibly not useful:

 

 

If you disable screen DMA by setting just bits 0,1 of DMACTL to 0 (ie- still allow DLIST DMA) on a badline, ANTIC doesn't fetch character codes.

 

As shown, it reuses what it has buffered.

This screen is just a single DLI which does WSYNC, clear bits 0,1, WSYNC again and enable widescreen.

 

Since the first line of the widescreen didn't do character fetches, it reuses the line above's characters (although only 40 were fetched).

 

The extra characters to the right are buffered from the last line displayed (ie - previous frame, with VBLANK and several normal lines displayed subsequently).

[Bennet]

Another attribute, although possibly not useful:

 

Very useful! I never tested this myself, but what you did shows that the Antic's does not start counting through video memory always at the start of wide, it starts when the playfield starts. As in, if the numerical character values lined up vertically it would mean it always start at wide, and they don't.

 

Is there a way to see what happens if you switch off the DMA mid-scanlile? Or on scanline 4 of the character mode to see if it stops fetching character graphics for the remaining lines? (or if it simply grabs bus noise)