how many graphics modes can you have in a display list?

[xxx]

and im guessing you can have a different set of colours for each mode? say if i was using antic mode 4 (graphics mode 12) every time?

Edited September 11, 2022 by xxx

[rdefabri]

Not sure I am answering this correctly or misunderstanding the question, but I believe it's a single graphics mode per display list.

 

Each display list is essentially a horizontal line, or series of horizontal / scan lines on the screen.  So you can define a graphics mode for a single line, or for a specific number of lines.

 

Each display list / DLI would have it's own color restrictions, so that single display list could have (say) 4 colors, the next one might be monochromatic, etc.

 

I don't think there's a restriction on the number of display list interrupts you can have per screen.  So you can keep switching graphics modes per scan line...although managing that might be wonky.

 

I'm not an expert, so I'm not sure I answered this completely accurately...some of the more experienced folks here can weigh in.

Edited September 11, 2022 by rdefabri

[xxx]

im talking about using the same graphics mode over and over if that is possible

[robus]

You’d use a display list interrupt to change the color palette for each mode line instruction. But the question is a bit confusing. It seems like you’re asking about colors, rather than modes?

[xxx]

i wanted to know if you could use the same mode over and over, so you could have a different set of 5 colours on say every 8 lines, using antic mode 4. and how may times you could do this

[rdefabri]

15 minutes ago, xxx said:

i wanted to know if you could use the same mode over and over, so you could have a different set of 5 colours on say every 8 lines, using antic mode 4. and how may times you could do this

I think what you are asking is if you could do (say) antic mode 4 on one line, use 4 colors, then use antic mode 4 on the next line and use 4 different colors etc.

 

it’s a good question, I’m not sure of the answer but I would think you can do it.

[+Stephen]

You can - what you would do is setup a display list, and every 8th line you would enable the interrupt flag.  Then, you would have to write display list interrupt code to change the registers.  I do not think there is enough time to change 5 registers though.

[danwinslow]

A display list is a series of display line codes. It's like a very small program that Antic runs. You have a certain number of scan lines available, and you can for the most part use any combination of graphics modes you want as long as you don't go too far over or under the number of tv scan lines. As mentioned, you can set an interrupt bit and put a pointer to a small bit of 6502 program code that will get executed while the electron beam is tracking back to the left to draw the next scan line. This is known as a Display List Interrupt, or DLI. You can change a few things like colors, but you don't have much time. A lot of the screens that you see in small basic demos that draw all the colors possible in the atari on the screen at once are using the same graphics mode over and over.

There are many other things you can do in the display list - coarse and fine scroll, change video data address, etc.

Edited September 11, 2022 by danwinslow

[Rybags]

You can do all the modes.  GTIA modes would need DLIs to change them at the appropriate time.

The colour palette can only be changed programatically, there's no copper instructions to do it like Amiga can.

[zzip]

On 9/11/2022 at 10:34 AM, xxx said:

i wanted to know if you could use the same mode over and over, so you could have a different set of 5 colours on say every 8 lines, using antic mode 4. and how may times you could do this

What you want is display list interupts (DLI),   they execute a small piece of code at the start of every scan line,  you can use this to swap out the color palette.     Doing it every 8 lines should be no issue.   I noticed someone questioned whether there was enough cycles available to swap all 5.  I don't know the answer to that, but I thought you could. 

[TGB1718]

Although it may be possible depending on where the colour change takes place on the screen,

but I think the consensus is 3 colours are probably the most you could do in a DLI

 

De-Re-Atari has a good section on DLI timing

Edited September 12, 2022 by TGB1718

[Gibstov]

1 hour ago, TGB1718 said:

Although it may be possible depending on where the colour change takes place on the screen,

but I think the consensus is 3 colours are probably the most you could do in a DLI

 

De-Re-Atari has a good section on DLI timing

You also have to take into consideration whether you have any/both of the scroll bits set too.  This also robs some time.

 

I found this out the hard-way when creating Adventure Ponies.  I was changing two color registers, doing a lookup.  And it was working fine, until I turned on scrolling, then it broke it.  I had to browbeat it to get it work.  But, I got it working in the end.

 

Edited September 12, 2022 by Gibstov

[Synthpopalooza]

7 hours ago, zzip said:

What you want is display list interupts (DLI),   they execute a small piece of code at the start of every scan line,  you can use this to swap out the color palette.     Doing it every 8 lines should be no issue.   I noticed someone questioned whether there was enough cycles available to swap all 5.  I don't know the answer to that, but I thought you could. 

It's possible, but I think only in text mode ... and if you use Antic 5, half your resolution, it becomes easier to do ... Antic 4, maybe.  Especially if you go to 32 characters wide narrow playfield.

[rdefabri]

I don’t want to thread-jack, but my question is similar to OPs.  How can using DLIs help with PMG multiplexing?  I’ve read that so long as they aren’t on the same “line”, you can get more than 4 (or 5) Players on screen.

 

I get confused because I always viewed the PMG as overlay.  How does multiplexing work?

Edited September 13, 2022 by rdefabri

[+Stephen]

57 minutes ago, rdefabri said:

I don’t want to thread-jack, but my question is similar to OPs.  How can using DLIs help with PMG multiplexing?  I’ve read that so long as they aren’t on the same “line”, you can get more than 4 (or 5) Players on screen.

 

I get confused because I always viewed the PMG as overlay.  How does multiplexing work?

If using DLI, you can reposition a player horizontally after it has been displayed,  to make it show more than once per line.  Kernels (basically a DLI every scanline as you are locking the CPU to the raster) can not only change position, but the graphics that the player/missile is displaying.

 

A different type of multiplexing, is swapping the position / data of player/missile data every other frame but that causes flickering if done on the same scanline.

[TGB1718]

6 hours ago, rdefabri said:

you can get more than 4 (or 5) Players on screen.

See my post in this thread, from memory I think there's about 64 Players on screen, didn't use missiles.

 

[Irgendwer]

7 hours ago, rdefabri said:

I don’t want to thread-jack, but my question is similar to OPs.  How can using DLIs help with PMG multiplexing?  I’ve read that so long as they aren’t on the same “line”, you can get more than 4 (or 5) Players on screen.

 

I get confused because I always viewed the PMG as overlay.  How does multiplexing work?

Maybe it helps if you have a look on these two posts:

 

While the shown samples multiplex with busy waiting for a vertical screen position, a DLI would be much more efficient and frees a lot of cycles.

 

[drpeter]

It's a simple question, but here's a complex answer.

 

tldr: ANTIC/GTIA chips are limited to displaying a single 5-colour GTIA palette for character modes 4 & 5 over the full screen unless the 6502 intervenes to dynamically update the GTIA palette as the screen is drawn- typically through code invoked by interrupts triggered by ANTIC's display list- display list interrupts or DLIs.

 

To fully understand this, you have to think about how the CPU and graphics chips of the Atari interact to produce the signal for the screen display on an old-fashioned cathode-ray tube (CRT) TV or monitor.

 

The CRT display is created by moving an electron beam across a phosphor screen repeatedly left to right, each horizontal trace of the beam creating a 'scan-line' on the display.  After the beam moves beyond the right border of the display (as the viewer looks at it) the beam is switched off and flicked back to beyond the left border, and moved down slightly, in order to begin 'drawing' the next scanline down. The brief interval when the de-energised beam is flicked back from right to left is called the 'horizontal blank' period. When the beam has drawn a certain number of scanlines (a different number for the US NTSC system and European PAL system) the beam is switched off again and flicked back to beyond the top-left of the display in order to start again. The brief interval when the de-energised beam is flicked back to the top-left is called the 'vertical blank'.  The whole screen drawing process takes 1/50 second (PAL) or 1/60 second (NTSC).

 

You can't see this process happening for 2 reasons- (i) the phosphor of the screen continues to glow for a while after the electron beam has passed, so that it is still partially glowing by the time the beam returns to the same spot 1/50 or 1/60 second later; (ii) the retina of the human eye shows a similar 'persistence' in its response to incoming light, roughly of the order 1/50 of a second, so that 'flickering' light signals that flicker at least as rapidly as this (like an old-fashioned incandescent light bulb, or a CRT) have the flicker 'smoothed out' so that it is not apparent.

 

The 6502 CPU of the Atari is not normally directly involved in the process of generating the signal for the CRT to display.  The specialised GTIA chip is the one which directly generates the signal. It holds a palette of 9 colours (5 for displaying bit-mapped or character graphics, 4 for player-missile graphics). As the electron beam moves across the CRT display 'drawing' a scanline, the GTIA chooses which colour from its palette is sent to the CRT for display at each point.  However, the GTIA is selecting the correct colour from its palette with the continuous assistance of the ANTIC chip.

 

At each point on the screen, ANTIC indicates to the GTIA which colour to choose from its bit-mapped/character graphics palette. ANTIC itself gets this information by retrieving data from graphics memory and interpreting that data through the display list.

 

The display list is a sequence of instructions ANTIC works through for each video frame.  The display list instructions tell ANTIC where graphics memory for each scanline is located and how data from that graphics memory should be retrieved and interpreted before being fed to GTIA as a sequence of selections to be made from GTIA's palette. The simplest display list instruction is 'retrieve no data and just tell GTIA to display the 'background' colour from its palette for the whole scanline'. For bit-mapped graphics, the instruction tells ANTIC to load a certain number of bytes of data sequentially from graphics memory and present that data to GTIA in terms akin to '...display the background colour from your palette...now display the second colour from your palette...now display the first colour from your palette...now display the background colour from your palette... etc. etc. etc.' For character modes, the instruction tells ANTIC to retrieve a sequence of bytes of data from graphics memory then use these to look up using the character set what sequence of colour palette instructions to feed to GTIA.

 

A single instruction in the display list may give information to ANTIC for displaying between 1 and 16 scanlines, depending on the ANTIC graphics mode (2 to 15) indicated by that instruction. At the end of vertical blank, with the electron beam at the top-left of the CRT display, ANTIC begins working through the display list, generating scanlines for display by GTIA, from top to bottom.  When ANTIC reaches an instruction indicating the end of the display list, it stops retrieving data from graphics memory and signals to GTIA to display the background colour from GTIA's palette until vertical blank completes and the process begins again for the next frame.  Thus the display is 'built up' via the display list, from top to bottom, as a sequence of horizontal bands, each corresponding to an ANTIC instruction in the display list, each displaying a graphics mode described by that instruction, and the whole frame being either a series of the same graphics mode repeated from top to bottom of the display or any mixture of graphics modes, as described in sequence by the display list.

 

When player-missile graphics (PMG) are enabled, during each horizontal blank ANTIC retrieves from PMG graphics memory the 5 bytes of PMG display data for the forthcoming scanline and feeds them to 5 PMG graphics data registers in GTIA. GTIA also holds the registers for the horizontal positions of players and missiles, which are not ordinarily updated with each scanline.  On each scanline, GTIA waits until the electron beam reaches the horizontal position of a player/missile then begins using the data from that PMG graphics data register in conjunction with the bitmap/character data it is simultaneously being fed by ANTIC, to decide which colour from its palette to display.  If the player/missile 'has priority' over the bitmap/character data, GTIA displays the colour in its palette corresponding to that player/missile.  If the bitmap/character data has priority, GTIA displays as usual the relevant colour (as signalled by ANTIC) from its bitmap/character palette.  (Small-print: in certain priority states, the bitmap/character palette colour and the PMG palette colour, and/or the colours from overlapping PMGs, may even be combined by GTIA to form a new colour not directly corresponding to any of the GTIA palette colours.)

 

Leaving aside these unusual colour-combining priority states for PMGs, the above description shows that within one frame the Atari can ordinarily only display the 9 colours represented by GTIA's palette registers- and without PMGs a maximum of 5-because all displayed colours derive from those palette registers and ANTIC has no way of updating those registers as the video frame is constructed.  There is no display list instruction enabling ANTIC to upload a palette register with new values, and GTIA itself is merely an interpreter of the graphics data fed to it by ANTIC.  This is where display list interrupts (DLIs) come in, by enabling the 6502 CPU to muscle in on the display process, manipulating GTIA registers 'on-the-fly' as the video frame is built up.

 

If the high bit of an ANTIC display list instruction is set, during display of the final scanline generated by that instruction ANTIC interrupts the 6502 from its current tasks and directs it to running some interrupt code instead, before returning to those tasks  Typically that code would update some GTIA registers, most commonly colour palette registers, with new values.  So, for example, if a DLI is set on a display list instruction half-way down the screen, and the interrupt code changes the colour value in GTIA's background colour register from black to yellow, from half-way down the frame all parts of the screen interpreted by GTIA as displaying background colour from its palette will be yellow instead of black. (Small-print: the vertical blank usually also generates an interrupt (the VBI), running separate code, and the standard VBI code resets all GTIA colour registers to their original values from so-called 'shadow registers' in RAM memory. So by the start of the next frame, the GTIA background colour register is back to black, before being reset to yellow again by the DLI half-way down the screen.) 

 

There is no technical limit on how many changes a DLI routine makes before returning the 6502 to its previous tasks- it could for example update all 9 GTIA colour registers so that they display different colours in the bottom half of the screen to the top.  It can also have the 6502 hang around making multiple sequential changes to the same colour register on sequential scanlines- or rarely even within a scanline, so that for example the displayed background colour changes from black to yellow to green as the electron beam traces the scanline from left to right.  In practice, the electron beam moves so quickly that the 6502 is somewhat constrained in how many changes it can make within a given horizontal, or even vertical, section of the screen.  Having the 6502 hang around while multiple scanlines are drawn, making updates to graphics registers, is often referred to as a screen kernel.  Various technical aspects of the Atari 8-bit hardware are designed to facilitate screen kernels- in large part because (lacking an equivalent of ANTIC) this was the required mode of graphics programming for the 2600 video games console that preceded the 8-bit line.

 

As noted above, the GTIA player/missile horizontal position registers are not ordinarily updated as the video frame is built, meaning each player or missile's graphic data is displayed within a narrow vertical band over the full distance from top to bottom of the screen.  ANTIC updates the PMG graphic data in GTIA registers during each horizontal blank, so that a varying bitmap pattern is displayed within that band as the frame is built, but the horizontal position of the band remains unchanged. Like the colour registers, ANTIC has no direct way of changing GTIA's player-missile horizontal position registers.  Again, this is where DLIs can assist.  As well as or instead of updating colour registers, a DLI routine can update horizontal position registers.  From that point onward (i.e. downwards on the screen) that player/missile will be displayed at the new horizontal position.  A single repositioning by a DLI half-way down the screen will shift the vertical band within which PMG graphics data is displayed to the new position, giving the impression of a 'new' player/missile.  The obvious constraint of this technique is that this is something of an illusion- although the horizontal positions of the 'upper' and 'lower' bands of the player/missile can be independently controlled, they can't overlap vertically. (Small print: player/missile horizontal position registers by default have no 'shadow registers' in RAM and are not reset during VBI, so a programmer using this technique must set up this or something similar for themself.)

 

However, akin to the technique described for colour registers, it is also possible, within timing constraints, to display a player/missile in one position to the left of a scanline and update the horizontal position register so that it is displayed again further to the right on the same scanline.  Ordinarily it will redisplay the same graphics data in the new position, i.e. that which was provided by ANTIC during the previous horizontal blank, producing an 'identical twin' PMG on the right side of the screen.  However, subject to even tighter timing constraints, it is even possible for the 6502 to update the GTIA PMG graphics register within each scanline before the twin is displayed, so that a different bitmap is displayed in the new position.  With an update of the player colour register too, it's therefore possible to 're-use' a PMG to create the illusion of an entirely separate player/missile occupying the same scanlines.

 

It will be obvious with a little thought that multiple DLIs positioned at strategic points in the display list, or in extremis a screen kernel that fully slaves the 6502 to updating graphics registers throughout the entire screen-drawing process, can produce a large number of independent (mostly horizontally-banded) 'colour palette zones' on-screen, which can also be dynamically shifted in position, and/or the illusion of multiple players/missiles on screen far in excess of the standard 4/4 of each.  The chief constraints are the speed with which the 6502 can make updates and the amount of CPU time these techniques 'steal' from general processing- which in the extreme case of a full screen kernel will be restricted to the vertical blank interval between frames being drawn.

Edited September 14, 2022 by drpeter

[zzip]

11 hours ago, rdefabri said:

I don’t want to thread-jack, but my question is similar to OPs.  How can using DLIs help with PMG multiplexing?  I’ve read that so long as they aren’t on the same “line”, you can get more than 4 (or 5) Players on screen.

 

I get confused because I always viewed the PMG as overlay.  How does multiplexing work?

You just change the horizontal position of the PMG during a DLI,  if I remember correctly you just need to change the value of one memory location,  and the PMG can be split into any number of sprites.

 

But if you need to reposition them vertically so that they do end up on the same line, you will need to use a different technique.

 

[zzip]

12 minutes ago, drpeter said:

The CRT display is created by moving an electron beam across a phosphor screen repeatedly left to right, each horizontal trace of the beam creating a 'scan-line' on the display.  After the beam moves beyond the right border of the display (as the viewer looks at it) the beam is switched off and flicked back to beyond the left border, and moved down slightly, in order to begin 'drawing' the next scanline down. The brief interval when the de-energised beam is flicked back from right to left is called the 'horizontal blank' period. When the beam has drawn a certain number of scanlines (a different number for the US NTSC system and European PAL system) the beam is switched off again and flicked back to beyond the top-left of the display in order to start again. The brief interval when the de-energised beam is flicked back to the top-left is called the 'vertical blank'.  The whole screen drawing process takes 1/50 second (PAL) or 1/60 second (NTSC).

It's funny,  I take all this for granted.   But this made me realize someone coming to this in 2022 without a background in how CRT TVs worked may find all this perplexing.   Thanks for the background info!

[rdefabri]

29 minutes ago, zzip said:

You just change the horizontal position of the PMG during a DLI,  if I remember correctly you just need to change the value of one memory location,  and the PMG can be split into any number of sprites.

 

But if you need to reposition them vertically so that they do end up on the same line, you will need to use a different technique.

 

For what I am thinking, I only need to re-position horizontally (left to right), so this technique could work.  I just have to try to understand it more...I'm getting the basic concept, just need to learn more.

[glurk]

2 hours ago, rdefabri said:

For what I am thinking, I only need to re-position horizontally (left to right), so this technique could work.  I just have to try to understand it more...I'm getting the basic concept, just need to learn more.

Just as an example of this, look at "Fishing Derby."  Either the 2600 original, or my 8-bit port.  All of the fish that are swimming side-to-side are one "player" sprite.  Basically, it's one large vertical "stripe" of fish, but the horizontal positions are changed for each fish-row as the beam moves down the screen.

[rdefabri]

1 hour ago, glurk said:

Just as an example of this, look at "Fishing Derby."  Either the 2600 original, or my 8-bit port.  All of the fish that are swimming side-to-side are one "player" sprite.  Basically, it's one large vertical "stripe" of fish, but the horizontal positions are changed for each fish-row as the beam moves down the screen.

This is a good example, I'll take a look at the game with this in mind.  So based on it being a vertical "stripe" of fish, I'm assuming one stripe is (say) P0, another can be P1, and so on?

[rdefabri]

2 hours ago, glurk said:

Just as an example of this, look at "Fishing Derby."  Either the 2600 original, or my 8-bit port.  All of the fish that are swimming side-to-side are one "player" sprite.  Basically, it's one large vertical "stripe" of fish, but the horizontal positions are changed for each fish-row as the beam moves down the screen.

I'm guessing you used this technique in Freeway too?

[glurk]

39 minutes ago, rdefabri said:

I'm guessing you used this technique in Freeway too?

The 2600 original does.  All the cars are P0 and (both) chickens are P1 (using a precisely timed re-position).  My 8-bit port is done differently, it actually uses ANTIC Mode 4 characters for the cars, because I wanted colored windows and stuff...  And I used 2 "players" for each chicken, because they are also subtly multi-colored using overlap.

 

But this type of re-use is incredibly common on the 2600, as it only HAS 2 player objects.  So it's super common to re-use one sprite object for multiple things.