12 replies to this topic

[tschak909]

Does anyone have an example of bypassing ANTIC and controlling the GTIA directly? I am only aware of one such program that did this (Atari Basketball), and would like to know how this technique is done.

Are the DMA bits of ANTIC basically turned completely off (causing what would normally be a black screen), and basically just bit-bang the GTIA using the GTIA's VCOUNT register as a reference to the position on the screen (the 2600 way?)

-Thom

[analmux]

i don't understand exactly what you mean, but as far as i know only players & missiles can be directly accessed by a kernel, or (using the vsync register) you are only restricted to very coarse areas, writing data to the ColBK register by an on-screen-kernel, giving not much horizontal resolution.

when you restrict to horizontal ColBk areas and Players & Missiles you can get very far anyway.

I have a demo with Players & missiles (used as underlay graphics for color enhancement) that are accessed without antic DMA, and write directly to the GRAPHP0-3 registers of GTIA. So in this case only PM-dma is turned off.

you can find it in the 'scrolling MCS' thread (from a few years back), there's also a file with the (X-asm) source code available there.

see:

http://www.atariage....l=scrolling MCS (for the newest version)

or

http://www.atariage....l=scrolling MCS (where it all started)

Edited by analmux, Tue Jun 6, 2006 4:40 PM.

[tschak909]

Then what was Chris Crawford talking about, here?

Quote

KERNELS

The DLI was designed to replace a more primitive software/hardware technique called a kernel. A kernel is a 6502 program loop which is precisely timed to the display cycle of the television set. By monitoring the VCOUNT register and consulting a table of screen changes catalogued as a function of VCOUNT values, the 6502 can arbitrarily control all graphics values for the entire screen. A high price is paid for this power: the 6502 is not available for computations during the screen display time, which is about 75 percent of the time. Furthermore, no computation may consume more than the 4000 or so machine cycles available during vertical blank and overscan periods. This restriction means that kernels can only be used with programs requiring little computation, such as certain skill and action games. For example, the BASKETBALL program for the ATARI 400/800 Computers uses a kernel; the program requires little computation but much color. The multicolored players in this game could not be done with display list interrupts, because DLls are keyed to playfield vertical positions, not player positions.

It is possible to extend the kernel idea right into a single scan line and change graphics registers on the fly. In this way a single color register can present several colors on a single scan line. The horizontal position of the color change is determined by the amount of time that elapses before the change goes in. Thus, by carefully counting machine cycles, the programmer can get more graphics onto the screen. Unfortunately, this is extremely difficult to achieve in practice. With ANTIC DMAing the 6502, it is very difficult to know exactly how many cycles have really elapsed; a simple count of 6502 cycles is not adequate. If ANTIC's DMA Is turned off, the 6502 can assume full control of the display but must then perform all the work that ANTIC normally does. For these reasons horizontal kernels are seldom worth the effort. However, if the two images to be displayed in different colors are widely separated, say by 20 color clocks or more, the separation should cover up the timing uncertainties and render this technique feasible.

[Rybags]

It is only really needed for a game like Basketball where there is vertical movement and colour changes are needed in precise positions relative to the player sprite.

You could also use a kernal in conjunction with DMA to get more than 4 players visible without flicker. Fairly precise timing is needed and each instance of the player would be limited in it's horizontal position.

But, you could probably change graphics, colour and position for 1 player. You would probably only have sufficient time left over to reposition 1 or 2 other objects.

Essentially you would be using all CPU cycles for the duration of the kernal. In many/most cases it would be more efficient to just use software sprites.

One problem is the burst of refresh cycles that ANTIC steals at the left hand side of the visible display (see ANTIC DMA Timings thread).

Another problem is syncing each line - WSYNC freezes the 6502 until just after the end of a standard display line.

I can suggest 4 alternatives to WSYNC:

- use a display list which has 1 blank or 1 pixel vertical resolution modes with the DLI bit set for the duration of the kernal. Your DLI routine should disable DLIs as it's first task. Then, timing is acheived by a simple loop:
WAIT BIT NMIST
BPL WAIT
DLIs occur early in a scanline. The DLI bit is reset towards the end of the scanline.
You should re-enable DLIs either at the end of your kernal or with a VBI routine.

- have a specific collision event setup to occur on every scanline (like a missile to player or playfield object). Wait loop could be something like:
WAIT LDA M0PF ; wait for missile 0 to PF collision
BNE WAIT
You would then have to store to HITCLR each line. Obvious disadvantages of this method is that you lose collision info for the kernal, plus it uses more cycles, and you have to position objects to force a collision.

- Wait on VCOUNT:
LDA VCOUNT
WAIT CMP VCOUNT
BEQ WAIT
Then create your timing by padding with NOPs and run your loop for the duration of 2 scanlines. At the end of loop, go back to the WAIT loop.

- Finally, you could use POKEY timers. The best method is to have IRQs disabled - but you have to enable the Timer IRQ on POKEY. Start the timer at a known horizontal screen position. Then, wait for the timer event:
WAIT LDA IRQST
LSR A
BCS WAIT ; wait for Pokey Timer 1 to trigger
To reset a timer, you have to disable it's IRQ then re-enable it. Then you have to store to STIMER.
Possibly the hardest method. You would probably end up with a condition of the IRQ creeping rightwards each scanline.
In 15 KHz mode, POKEY can exactly match the horizontal scanning speed. But, joining 2 voices and setting 1.79 MHz for the voice would allow cycle-exact triggering of the event.
Obvious disadvantages: can be tricky to implent, plus you lose 1 or 2 voices.

[classics]

I believe Turmoil, Worm War and other titles by that company are programmed this way.

Steve

[Heaven/TQA]

Rybgas two of your methods i never touched in 20 years... esp. the "DLI without DLI" method looks interesting...

Pokey interrupts i never used either...

[Heaven/TQA]

its interesting that a guys coming from 2600 always ask for the "kernel"-method for coding...

but there are other details missing from 2600 than just DMA... what about REPx?

[Rybags]

Demo kernal:

 kernal1.zip   861bytes   65 downloads

Zip contains a BASIC program and the Atari ASMED source code of the DLI routine.
Use the joystick to move each player left/right (hold button to move right hand player).

This demo uses the "Wait for DLI" method - the disadvantage of that (and other "waiting" methods) is that there is some jitter, since the DLI can be triggered at any stage of your wait loop:

WAIT BIT NMIST ; 4 cycles
BPL WAIT ; 3 cycles if true else 2

So, you get "jitters" so far as timing goes... no great problem - it just means that there will be a screen region of about 16 pixels where you shouldn't try and position a "split" Player.

Using WSYNC would probably be a better method. You then get precise timing, and all that remains is to have a delay loop and/or padded NOPs to acheive the fine delays.

There are timing differences.

WSYNC releases the CPU at the end of a standard display (colour clock 200).

DLIs occur early on in the display, so the wait loop ends just before a standard display starts.

[tschak909]

well, it's not that i am asking for it coming from the 2600, it's that I am interested in what i can pull off with it :-)

I will be doing a 2600 project _AFTER_ I do one successful 800 project..hehe :-)

-Thom

[Cybernoid]

This is kind of what I did for the 6bit PCM player...

http://www.atariage....wtopic=62266=

ANTIC is turned off and I place the PCM data into the hoizontal position registers of the GTIA. It is not really a kernal since it does not montior VCOUNT or anything, but this is the basic idea: players/missiles can be written directly into the GTIA registers at any time if the DMA is turned off.

[tschak909]

was decoding the display list used in BallBlazer, and I see the following:

BC20: 3x 8 BLANK
BC23: LMS BC40 MODE 2
BC26: 23x MODE 2
BC3D: JVB BC20


WTF?!

-Thom

[Rybags]

That's just a standard text screen.

Ballblazer uses 2 windows with Mode E (GR. 15) with an LMS on each scanline. In the middle it alternates between Mode 2 and 4 depending on what is needed there (score, intro).

[Heaven/TQA]

yup. you have given the dlist of the standard atari gr.0 screen...

just load ballblazer in atari800win enter the monitor and enter DLIST. it should bring up the displaylist....

and ballblazer sets the hscrol bit as well each scanline of the playfield.