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 .