GTIA Modes 9, 10 & 11 + ANTIC data and color clocks

[robus]

I'm trying to add support for these 3 special modes and I understand that they work slightly differently from the others in that they need 4-bits of data from ANTIC in order to determine the luminance or color. What's puzzling me is precisely that. As GTIA scans across generating color clocks, it has to "backfill" (for lack of a better word) the previous color clock when it has the second set of data from ANTIC. Meanwhile the PM graphics are placed as usual with the individual color clocks. Or do I have it wrong and in this special mode GTIA polls ANTIC twice within a single color clock to get the 2 packets of data to determine the color/luminance and then proceeds to fill in the second color clock?

 

The timing is not clear to me and I've checked the Altirra reference docs.

 

So what is actually happening under the hood?

 

Thanks!

[TGB1718]

Modes 9 and 11 use 4 bits for each pixel, mode 10 need 2 bits per pixel

[+MrFish]

9 minutes ago, TGB1718 said:

mode 10 need 2 bits per pixel

Mode 10 uses 4 bits per pixel.

 

[popmilo]

2 hours ago, robus said:

...it has to "backfill" (for lack of a better word) the previous color clock when it has the second set of data from ANTIC. Meanwhile the PM graphics are placed as usual with the individual color clocks. Or do I have it wrong and in this special mode GTIA polls ANTIC twice within a single color clock to get the 2 packets of data to determine the color/luminance and then proceeds to fill in the second color clock?

That's how I understood it, and it makes sense hardware wise.

 

Here's a screenshot comparisson from Altirra of my gtia ninja nyd demo. I've switched gtia mode on/off and copy pasted middle part with face details of ninja for comparisson.

Looks lik gtia pixels are 1 color pixel moved to the right. So antic fetches first bitpair, then as it fetches second it's already combining them, getting color value from registers and showing pixel.
ps. Antic works like in normal modes, just passes bits over couple lines to Gtia. Gtia probably has some kind of buffer to combine two+two bits and show single color next two color cycles.

Hope it helps

pps. I've attached ninja.xex just in case you want to look for yourself

ninja.xex

[robus]

Ah so it's always offset by a color clock? Altirra reference says it's like that for Mode 10 (9 color mode), but doesn't have the same note for 9 & 11 (which didn't make sense to me).

[+Stephen]

There is a difference in GTIA mode 10, whereby there is a single colour clock shift of the pixels, not present in modes 9 or 11.  Basically, the mode 10 pixels are displayed a colour clock "late" (shifted to the right).  I believe it's due to how it reads the registers to be able to display all 9 of them but I could be 100% wrong on the reason.

 

This pixel shift is what allows some of the "flicker" modes to have 160 horizontal resolution rather than 80.

[phaeron]

The difference in delay is due to the different data paths involved.

 

For all GTIA modes, GTIA has to wait one additional color clock for the 4-bit pixel regardless, since ANTIC only sends 2 bits per color clock and GTIA needs to assemble the 4-bit pixels using a 2-bit buffer. However, the difference is in the pipeline stages involved. Mode 10 interacts with the full priority logic and is thus forced to have a 1cc delay, as the playfield and player layer inputs aren't known at the head end until the full 4-bit pixel is available. Modes 9 and 11, however, simply shut off all playfield inputs and bypass the priority logic, injecting color or hue at the tail end in the color encoding logic based on whether the background is displayed. Thus, modes 9 and 11 don't have to have the same offset that mode 10 does.

 

I just realized that I never mentioned in the hw manual whether the right border is affected by the mode 10 delay, I should fix that.

[Rybags]

Regardless of mode there's a difference between character fetch, graphics fetch and the actual display.

The timing diagrams that show DMA fetches can help out there.

 

Not sure what level of buffering GTIA does with AN0-2 data - maybe it assembles 8 bits at a time into a shift register?  Or could it be just a cyclic thing.

[robus]

1 hour ago, Rybags said:

Regardless of mode there's a difference between character fetch, graphics fetch and the actual display.

The timing diagrams that show DMA fetches can help out there.

 

Not sure what level of buffering GTIA does with AN0-2 data - maybe it assembles 8 bits at a time into a shift register?  Or could it be just a cyclic thing.

Hmm, I may have assumed a too tight connection between GTIA and ANTIC. I thought it pulled the andata as it rendered each color clock but I can see that having a bit of delay would help with the data processing, especially when priority and collision detection are involved.

[phaeron]

GTIA buffers only one pixel at a time. You can see it in ijor's reconstructed schematic, where the pass transistors capture even and odd AN0-AN2 values.

 

As for the process, ANTIC and GTIA don't process one pixel or color clock at a time; they have multiple pipeline stages over half a dozen cycles. I've been trying to construct a pipeline diagram, but it's hard to read the VLSI logic. By my estimation, there's ~8 pipeline stages in ANTIC and ~4 pipeline stages in GTIA between playfield bytes in RAM and the video output. GTIA's stages run on half color cycles, so there's often only a couple of gates between one stage and the next.

[robus]

I see, so I really need to decouple the two a bit more. Have ANTIC providing the andata and buffer that a bit so that when GTIA comes along it has the data it needs to make the right decisions.

 

3 bits of data is a bit awkward to manage. I guess I’ll stuff them into a 12 bit field and start shifting them out and feeding more in as I go?

[Rybags]

Is this software emulation or a hardware thing?

If it's software you can just about forget the AN0-2 bus and just process graphics data with regard to timing and GTIA mode.

There's stuff like the HSync and VSync commands that software doesn't need to worry about since they're usually fixed in time.

 

The timing also relates to palette entry changes, you should notice a single color-clock delay when one occurs.

[ijor]

21 hours ago, phaeron said:

As for the process, ANTIC and GTIA don't process one pixel or color clock at a time; they have multiple pipeline stages over half a dozen cycles. I've been trying to construct a pipeline diagram, but it's hard to read the VLSI logic.

I can perform a simulation and post a waveform showing the exact timing since playfield DMA to the output at the GTIA pins. Just let me know exactly what you are interested to see.

 

Quote

...  GTIA's stages run on half color cycles

Not sure what you mean by that. Most of GTIA and the last ANTIC section that interfaces with GTIA, both run at the same frequency. The only GTIA logic that runs at twice the frequency is the short high rez path.

[phaeron]

20 hours ago, ijor said:

I can perform a simulation and post a waveform showing the exact timing since playfield DMA to the output at the GTIA pins. Just let me know exactly what you are interested to see.

That would be really helpful. Could it include AN0-2 and modes 8/9/10? Should confirm the discussion here regarding mode 10 being special delay-wise.

 

20 hours ago, ijor said:

Not sure what you mean by that. Most of GTIA and the last ANTIC section that interfaces with GTIA, both run at the same frequency. The only GTIA logic that runs at twice the frequency is the short high rez path.

Sorry, to be more precise -- logic running either on alternating phases of the machine clock (1.79MHz) or color/fast clock (3.58MHz).

[ijor]

On 5/12/2024 at 8:51 PM, phaeron said:

That would be really helpful. Could it include AN0-2 and modes 8/9/10? Should confirm the discussion here regarding mode 10 being special delay-wise.

I am quite busy right now. But as soon as I have some time, I will definitely perform and post those simulation waveforms .

 

[robus]

On 5/11/2024 at 9:41 PM, Rybags said:

Is this software emulation or a hardware thing?

If it's software you can just about forget the AN0-2 bus and just process graphics data with regard to timing and GTIA mode.

There's stuff like the HSync and VSync commands that software doesn't need to worry about since they're usually fixed in time.

 

The timing also relates to palette entry changes, you should notice a single color-clock delay when one occurs.

This is software, just trying to figure out how to get the timing right so that it is able to priority correctly (though I understand these special modes also have special priority handling).

[ijor]

Simulation waveform showing ANTIC delay from playfield DMA to AN external signals:

 

Simulation captured video start at the left border. Display list IR was $4F (graphics mode 8). Valid also for GTIA modes 9-10 since ANTIC doesn't differentiate GTIA modes.

The signal phi2Counter at the top is a virtual signal counting PHI2 cycles.

The vertical yellow bar at cycle 61 marks the start of the first playfield DMA cycle.

The yellow bar at cycle 68 marks the time that the first playfield pixel was transmitted to GTIA over the AN pins.

So far only the external signals were captured. Please let me know if you are interested in adding any internal nodes.

 

I will perform GTIA simulation separately after that. GTIA will require multiple simulation for the different graphic modes.

[+Cafeman]

On 5/10/2024 at 5:28 PM, Stephen said:

There is a difference in GTIA mode 10, whereby there is a single colour clock shift of the pixels, not present in modes 9 or 11.  Basically, the mode 10 pixels are displayed a colour clock "late" (shifted to the right).  I believe it's due to how it reads the registers to be able to display all 9 of them but I could be 100% wrong on the reason.

 

This pixel shift is what allows some of the "flicker" modes to have 160 horizontal resolution rather than 80.

 

This was a mystery to me, as I've been experimenting for the first time with Antic F / GTIA Mode 10.    I thought I'd try it in my game's info panel, due getting 9 colors in background pixel graphics.  But now that I tried it, I'm not sure I like the look of GTIA10.  I believe I can deal with the color-clock shift to the right, since these are mostly static images.  But Quad-width pixels sure take up a lot of screen real-estate and give a very blocky look.  

[+MrFish]

1 hour ago, Cafeman said:

But now that I tried it, I'm not sure I like the look of GTIA10.  I believe I can deal with the color-clock shift to the right, since these are mostly static images.  But Quad-width pixels sure take up a lot of screen real-estate and give a very blocky look.

None of the GTIA modes are very-well suited for lettering. In your case, you might be able to put your lettering/labels in Antic 2 or 3 above or below some GTIA 10 lines with the status indicators.

 

I'd never used mode 10 much myself either; but an idea did present itself when someone was trying to get a bunch of colors on a single line, for doing the APX logo. I was able to come up with this idea, which also employs some dithering for transitional colors.

 

 

[+Cafeman]

I’ve read you can activate GTIA mode on Graphics 0, which I believe is Antic 2.  How does that work? Antic 2 is a character set mode, not a pixels mode. ?  What benefits are there to this? 

[+MrFish]

16 hours ago, Cafeman said:

I’ve read you can activate GTIA mode on Graphics 0, which I believe is Antic 2.  How does that work? Antic 2 is a character set mode, not a pixels mode. ?  What benefits are there to this? 

From Antic 2, you just set the appropriate bits in GPRIOR. You end up with characters formed in GTIA pixels and color attributes. The benefits are anything you can think of that characters benefit from over bitmapped modes.

 

Also, you obviously need some way of defining characters for GTIA modes. There are some character editors that can. One is Graph2Font, if you want to work from your PC. One that I recommend that runs on your Atari is Macro Edit. I still use Macro Edit for various development tasks.

 

[Rybags]

GTIA modes can be activated with any graphics modes but usefullness is limited in most.

They work because the action takes place on the incoming bitstream to GTIA so the underlying graphics mode isn't totally important.

Gr. 8 and Gr. 0 are indistinguishable to GTIA as is mode 3, the descending character mode.

 

Generally it's the 40 byte/line modes that allow useful results when activating GTIA modes.

[+Cafeman]

30 minutes ago, Rybags said:

Gr. 8 and Gr. 0 are indistinguishable to GTIA as is mode 3, the descending character mode.

Interesting.  does using Gr 0 use less amount of memory than if you used Gr 8 with GTIA modes? 

[+yetanothertroll]

16 minutes ago, Cafeman said:

Interesting.  does using Gr 0 use less amount of memory than if you used Gr 8 with GTIA modes? 

Much, much less. GR.0 is the default 40x24 text mode, and the screen memory is only 40x24 bytes, but ANTIC looks those up in the character table and feeds the data from the table to C/GTIA. In GR.8, the screen memory soaks up half your RAM and ANTIC feeds it directly to GTIA

 

EDIT: ...but GTIA can't tell whether the pixel data it's getting from ANTIC is coming from screen memory or from a character table in ROM or what

Edited September 6 by yetanothertroll
Hit Save too soon

[+Cafeman]

GTIA mode 10 has quad width pixels. Are the GTIA modes9 and 11 also pixels always quad width? Are they quad width even if using Gr 0 with a GtIA mode?