Graphics 12.10 and 1.10 - Altirra vs real Atari

[Synthpopalooza]

I was experimenting with the ICE CIN editor on my Atari 1200XL and using Graphics 10 settings on modes 1 and 12, and I noticed some discrepancies in the display vs the way it looks on Altirra.

 

Specifically, Graphics 12.10 on the 1200XL is set up in the following manner, using bit quads:

 

0000 - 704 (background)

0001 - 704

0010 - 705 (p1)

0011 - 706 (p2) 707 (p3-inverse)

0100 - 704

0101 - 704

0110 - 705

0111 - 706 707 (inverse)

1000 - 712 (pf4 - graphics 10 color 8 )

1001 - 708 (pf0)

1010 - 709 (pf1)

1011 - 710 (pf2) 711 (pf3 inverse)

1100 - 712 708 (inverse)

1101 - 712 708 (inverse)

1110 - 712 709 (inverse)

1111 - 712 711 (inverse)

 

The problem is, Altirra shows 1000 to be 708, while it is 712 on the 1200XL. Do other Ataris show 712, or just the 1200XL

 

To test this, this program works:

 

10 GRAPHICS 15:POKE 623,128:POKE 712,14

20 COLOR 8

30 POSITION 0,0:XIO 18,#6,0,0,"S:"

 

On Altirra this will show orange (708) but on the 1200 XL it shows white (712).

 

I've noticed Graphics 1.10 (1 with GTIA set to 10) also has differing colors from Altirra and other emulators.

 

Could someone test this on other real Ataris (130XE and 800XL specifically) to see if they get the same results?

Edited November 17, 2011 by Synthpopalooza

[José Pereira]

Atari800WinPlus also show White.

[Synthpopalooza]

Forgot something:

 

Add a POKE 87,10 to that listing after the Graphics call. That will fool the Atari into thinking its in Graphics 10

Also, poke 765,8

Edited November 18, 2011 by Synthpopalooza

[phaeron]

Well, this is an interesting mystery. I can definitely reproduce this on my 800XL, and this behavior only seems to occur for mode 10. What I can't figure out is why this is happening. A 00 pixel in ANTIC mode E is sent out on the ANx bus as 000, which should be getting interpreted the same as a 01 pixel in mode E, which is sent as 100. For some reason, this is getting interpreted as 11 instead for the second bit pair and activating playfield 3. I can't see in the schematics how this would happen. Anyone got a clue?

[ijor]

For some reason, this is getting interpreted as 11 instead for the second bit pair and activating playfield 3.

 

Phaeron, this doesn't seem to match the OP description. Playfield 3 is activated, or background?

 

I didn't check on real hardware, but I will assume the behaviour is the one described by the OP, because that's the one I can see on the schematics.

 

The screen bitmap 10_00, will make Antic (thinking it is in mode E) send AN codes 101 (playfield 1 for pattern 10) and 000 (background for pattern 00). Altirra GTIA emulation probably interprets this as Gtia mode 10 playfield 0. This is taken from the table at the GTIA datasheet, that describes the AN2/AN1 pattern over two clocks x100 as playfield 0:

 

But that table assumes that you would be a good boy and use gr.8 for GTIA modes Or more precisely, it assumes that all the pixels in GTIA modes would have AN2 signal set, and not clear. If you happen to clear AN2 (as in this case), then you would mess with the GTIA logic to select the PF colors in GTIA mode 10.

 

When GTIA wants to select a given PF color on mode 10, it uses the same logic as in the normal (non GTIA) mode. That logic works only when A2 is set (because when A2 is clear in the other modes, it is either background or blank/vsync code).

 

This can be seen on the last page of the GTIA schematics. The PF selection logic is at the mid right. It starts with a small 4 columns x 5 rows PLA, near the bottom. The bottom row of that PLA comes from AN2, negated. If AN2 is clear, that row would deselect all the column outputs of that PLA. And then, no PF would be selected.

 

If no Plafield nor Player color is selected, the priority logic (whic is still active in this GTIA mode) selects the background color.

[phaeron]

Whoops! You're right, that's BAK, not PF3. Okay, that does make sense and explains why it's specific to mode 10. I should be able to fix that up.

[Synthpopalooza]

Yes, color 8 shows BAK (712) on real Atari but on Altirra shows PF0 (708).

 

The paletting for Graphics 1 under GTIA is also wrong in Altirra.

The layout in the emulator shows:'=

 

00 01 10 11

0-31 704 704 704 704

32-65 704 705 708 709

66-95 704 706 712 712

96-127 704 707 708 711

 

But this does not match on real Atari ... I can't remember the layout except that 712 is in all three palettes, and there is no 708 anywhere,

 

The embarassing thing is, I wrote an article for the PCIN IRG mode (One of my ICE modes, Graphics 12 + Graphics 12.10) for AtariUser, but the settings I documented were under Altirra ... looks like I am going to have to correct it now.

Edited November 18, 2011 by Synthpopalooza

[Synthpopalooza]

This is a demo for the ICE mode Super 1.10 that I did recently. You can use this to test, you should get differing results on a real Atari vs Altirra.

 

super110.atr

[phaeron]

Alright, try this:

http://www.virtualdub.org/beta/Altirra-2.00-test51.zip

http://www.virtualdub.org/beta/Altirra-2.00-test51-src.zip

[serj]

Avery, test 51 crashes if you select

help ----> change log

 

http://imageshack.us...50/errordc.jpg/

[Synthpopalooza]

Graphics 12.10 appears correct, as does 1.10 ... the caps lock appears to act funny though. SHIFT to get lowercase letters

[fox]

I wonder if we can get 160 pixels resolution in mode 10 using this trick?

[Heaven/TQA]

Fox. how???

[fox]

This is a new discovery that AN2 affects mode 10 output. If AN2 doesn't get latched by the GTIA mode logic, we can alternate it every color cycle.

[ijor]

This is a new discovery that AN2 affects mode 10 output. If AN2 doesn't get latched by the GTIA mode logic, we can alternate it every color cycle.

 

But it is latched every other color clock cycle.

[fox]

What a pity.

[Rybags]

I got real doubts.

 

Even if we could force half-sized pixels, the CPU is nowhere quick enough to drive it. I think the best hope is if a way could be found to do the half-pixel shift on demand (without needing heated up GTIA) - then we'd have some handy new modes.

 

Someone promised to post up some code a few weeks back, but nothing has materialised.

 

I've been meaning to revisit digging for the pixel shift. I think as far as Antic/GTIA tricks go re stuff not documented about the hardware, we've probably got them all discovered.

[Synthpopalooza]

The only way I can think of to do 160 pixels in mode 10 would be to set up what I call PCIN ... it's like CIN except you alternate mode 10 and mode 15, with no color changes. You also need to set HSCROL on the mode 15 lines so they line up properly. This gives you about 30 colors at 160 pixels.

 

Out of curiosity, what would be the effect of switching GTIA into mode 10 on an Antic E line, after one color clock? Would this accomplish the pixel shift?

Edited December 8, 2011 by Synthpopalooza

[phaeron]

This can only be done every two color clocks since the color clock is twice as fast as the bus clock. That means you can only hit one phase out of two and I think it's the wrong one.

[Rybags]

Antic only feeds the 2 bits of pixel data per colour-clock, so even if GTIA could be convinced to do the higher resolution in these modes, it'd be of no use.

[fox]

This is a new discovery that AN2 affects mode 10 output. If AN2 doesn't get latched by the GTIA mode logic, we can alternate it every color cycle.

 

But it is latched every other color clock cycle.

 

Where's this latch in GtiaReschem.pdf ?

[ijor]

Where's this latch in GtiaReschem.pdf ?

Last page of GtiaReschem.pdf. Bottom center, low rez:

Higher rez:

 

There, at the "coupler" highlited with red. It is a dynamic latch, not a static latch.

 

The circle at the schematics denotes a coupler, or pass transistor. When the control of the coupler is high, the transistor is conducting and, logically, it behaves as it wouldn't be present. When the control is low, the transistor doesn't conduct and the wire is disconnected. But the ouput (at the right side of the coupler) still retains the previous value due to capacitance. This, in effect, works like a transparent latch, except that if disconnected for too long, the capacitance would discharge (that's why it is dynamic).

 

The control of the latch is seen in the low rez sample. It comes from the GTIA modes even/odd logic. When not in any gtia mode, the "ngm" (not gtia mode) signal is active, and this would result in the control being high all the time (no latching, transparent). Otherwise (when some gtia mode is on), the control is activated every other cycle. At the other cycle, the value is kept latched.

Edited December 29, 2011 by ijor

[fox]

Thank you for excellent explanation!