Internal ANTIC and GTIA schematics

[Bryan]

So, essentially, this is all we need to enact the 1 colour-clock shift in GTIA luma mode ?

 

Yep. What seems to happen is that mode 9 has the proper alignment if it's enabled at the beginning of a line, but may take on mode 10's alignment if enabled later. Heating up the GTIA slows down the internal propagation a little bit.

[Bryan]

Nice! So is someone going to design an upgrade that heats up the GTIA?

That would be a first!

[Rybags]

Actually, I was using the Gr. 0 screen, and the timings might be different.

 

Might try it again at some stage with a routine which I can alter to differ by single cycle steps.

 

This method in conjunction with interlace would produce some kick-arse screens... 160 (perceived) by 480 with 16 luma values.

[Bryan]

I wrote this in 1994, I think, so I don't remember everything I tried...

 

What if mode 10 is enabled, followed by mode 9. I wonder if there's a sequence that would have better success.

 

I can't find the rest of my picture files. I sent the whole thing to John Harris who was able to reproduce the effect on his machine after a 15 minute warm up. I wonder if he still has it.

Edited February 9, 2009 by Bryan

[Rybags]

Maybe some other combination.

 

With a SEC / ROR $D01B combination, we can get 2 stores in successive cycles.

 

First one will always put it back to "Normal" mode, second one will set GTIA Paletted mode.

 

Also, maybe twiddline DMACTL might change something. I've just done a DLI that does a continuous STA/STX to $D40A (A=00 X=$22).

You get pixel data appearing even though it's all blank characters. ed - I suspect that's the case because Antic can't buffer charmap data... if you hover over it, you still get the normal inverse video effect.

 

Graphics 0 screen, cursor just about line with DLI.

Edited February 9, 2009 by Rybags

[carmel_andrews]

All this GTIA 'heating' business, i guess that is only achieved by leaving the machine on for a prolonged period

 

Can you only achieve these 'extended' GTIA effects (as shown in bryan's pic's) via this 'GTIA heating' business

[atariksi]

Nice! So is someone going to design an upgrade that heats up the GTIA?

That would be a first!

 

Ha. If heat is the only cause in changing in timing, we need to figure out the combinations of registers that use the most transistors on the chip since more transistors that are used, the more heat is generated.

[Rybags]

Set all colours to $FF. Widescreen DMA, all PMGs present, looping code to replicate them horizontally.

 

I don't know if we could heat this thing up in software... it's not quite like a modern card doing billions of 3D calculations per second.

 

Don't feel inclined to point a heat gun at my machine either. Might try the XEGS later... as they say the Ataris got crappier build quality as time went on, so it's possibly the most likely to start malfunctioning when it gets busy.

[carmel_andrews]

Sounds like you've got to cook and not heat the chip to get it to do anything...going by your last post rybags

[potatohead]

What about those heat junction things. Peltier maybe?

 

When powered, they can either deliver heat, or cooling. One of those with a temp sensor, might make for an interesting Atari mod? The user can trigger it, wait half a minute, then run GTIA. A small bit of software could watch the temp sensor to keep things sane.

[Rybags]

Peltiers have the undesirable effect of generating condensation. Not to mention the inconvenience, cost, and fact that it'd likely need it's own power supply.

 

What would really be nice is if this effect exists on all machines without need to overheat components... maybe it does, and is reliant on just the right sequence of changes at cycle exact positions.

[Bryan]

If you do heat one of your GTIA's, I'd be interested to see if it happens on PAL machines at all. They clock pixels a little bit slower and therefore may not have the same propagation issues as NTSC chips.

[Rybags]

* BUMP *

 

I'm getting impatient...

 

Any progress? That is, with the schematics. We got a bit off topic in the middle.

 

Also, how's Curt? Can't say I've seen him post much in a while.

 

 

As part of my impatience, I'm also very tempted to hook the AN0-AN2 lines to my 'scope. Was thinking of running them through a resistor ladder so I can decypher their full value.

 

Would doing so put my machine in much danger? My XEGS has the least sentimental value, so it would be the guinea-pig here.

[+poobah]

* BUMP *

 

I'm getting impatient...

 

Any progress? That is, with the schematics. We got a bit off topic in the middle.

 

Also, how's Curt? Can't say I've seen him post much in a while.

 

 

As part of my impatience, I'm also very tempted to hook the AN0-AN2 lines to my 'scope. Was thinking of running them through a resistor ladder so I can decypher their full value.

 

Would doing so put my machine in much danger? My XEGS has the least sentimental value, so it would be the guinea-pig here.

 

probably easier to hook a logic analyzer to them and rope them together as a value.

[Rybags]

I don't have one though... just bought a new 'scope, so gotta improvise due to lack of equipment.

[candle]

about heating up..

I remember Garth Wilson (6502.org) talking about his former boss and design flaw in circiuit that leaded to thermal instability

problem was timing was verry difrent from nominal and whole thing didn't work too long

boards were already produced, and it was eiter trash whole production run to the dumpster, or provide quick fix.

So his boss took 7805 regulator, shorted its output to ground and glue it to the failing device

7805 has thermal shutdown protection that was kicking in every time the regulator heated up itself, thus providing stable temperature to failing circuit - it was stable enought to save the company from financial problems at cost of increased current feeded into the circuiit

 

this was some time ago, and can't find the orginal text i'm talking about, not sure for the names, but quite sure for the principle

[+bob1200xl]

You could just tape foam insulation over the chip. Don't go crazy, here, just a piece of foam tape will heat it up a bit. Most of the internal heat flows out the leadframe.

 

I don't see how high value (>1K) resistors would hurt anything in AN0-AN2, but they may not have really good response times if you're looking for a timing race condition.

 

On the scope, you can add two signals and sync off of the third - might show you something.

 

Bob

 

I could try tracing your effect if you can explain how/what to do.

 

 

Peltiers have the undesirable effect of generating condensation. Not to mention the inconvenience, cost, and fact that it'd likely need it's own power supply.

 

What would really be nice is if this effect exists on all machines without need to overheat components... maybe it does, and is reliant on just the right sequence of changes at cycle exact positions.

[HiassofT]

As part of my impatience, I'm also very tempted to hook the AN0-AN2 lines to my 'scope. Was thinking of running them through a resistor ladder so I can decypher their full value.

You could use a simple buffer (bus transceiver, inverter, and/or/nand/... gates - whatever you can find) to de-couple your resistor-ladder from the Antic outputs. Then you should be safe to do whatever you want.

 

so long,

 

Hias

[Rybags]

I've got AN0-AN2 going through a buffer and resistor ladder so I can view the goings on with my 'scope.

 

Preliminary findings:

 

Towards the end of a scanline, Antic sends the HBlank code. It "pre-empts" what it thinks is going to be happening on the next scanline if it's the last scanline of a DList instruction. ie - it will be sending "011 - HBlank and set 40 column mode" if the current line was hires, otherwise it will be sending "010 - HBlank and clear 40 column mode".

 

In the case where a hires mode is either pending or ending, the HBlank code is corrected shortly afterwards. ie, it will transition to the other value. This occurs once the next Display List Instruction has been fetched - delay after fetch unknown, although the correction does seem to occur at about a quarter the duration of the total HBlank command.

 

At scanline 240, the "010 - HBlank and clear 40 column mode" command is sent continuously until VSync is due, except when we have the "Scanline 240 bug" in effect.

 

This would indicate that GTIA has some "autonomy" in that it will generate HSync pulses at their correct intervals without further prompting from Antic. One exploit of this behaviour - by toggling DMACTL betwen No Display and a display mode and back, you can force extra HSync pulses or delay upcoming ones.

It is even possible on PAL machines to upset the colourburst phase alternation such that the TV will show the wrong colours.

 

In such case as the 240-bug is in effect, the HBlank and set 40 column mode is sent.

Additional to this... unlike normal display lines, no "000 - Blank" code is sent in this area. In the course of a normal display, the 000-Blank code is sent in the interim period before and after the normal display part of a scanline... it's duration of course is dependant on what DMA Width is in effect.

During the "display" period of a >240 line when the bug is in effect, code "111" is constantly output during the horizontal portion of the display for the duration dictated by whatever DMA screen Width is in effect.

 

Folded "curtain effect": This is most likely due to the train of HSync pulses suddenly being put out of step. When the 240-bug comes into effect, the HBlank code is sent earlier to GTIA. As such, we have a short scanline near the bottom of the display (on PAL at least).

Unless overriding action is taken, this out of step behaviour persists until the next field (ie a Display List instruction is fetched and the new display starts).

Due to this effect, parts of the next field are also often warped. The warped effect is usually worst in narrow DMA mode, followed by normal and wide.

Of course, narrow suffers in that the HBlank command will be sent incorrectly while the scanline is only around 2/3rds finished.

 

VSync: In normal operation, the "010 HSync and Clear 40 column" command is continually output during the offscreen period, except for the 3 scanlines of VSync, when code "001 VSync" is sent.

 

If the 240-bug is in effect, Antic will behave as in other offscreen scanlines for the 3 VSync lines, except outputting "001 VSync" during the parts of the scanline which would be considered non-display as dictated by DMACTL, and outputting "111" otherwise.

Edited March 20, 2009 by Rybags

[ClausB]

I've got AN0-AN2 going through a buffer and resistor ladder so I can view the goings on with my 'scope.

Nice work!

This would indicate that GTIA has some "autonomy" in that it will generate HSync pulses at their correct intervals without further prompting from Antic.

That makes sense, since GTIA's ancestor, the 2600 TIA, generates HSYNCs on its own. The 2600 has nothing like ANTIC; the CPU handles the vertical structure of the display.

[Rybags]

The generation of extra pulses - I have it 90% understood, maybe more.

 

With the "240 bug", Antic doesn't unlatch AN2 properly, so it gets stuck set at 1. That's why instead of black, you get Playfield 1 represented in the normal display area (although you can set GTIA modes and instead get Luma F, Colour 15 etc).

 

But, outside of whatever horizontal area you've allowed via the width setting of DMACTL, it acts "normally", ie it will send the HBlank + 40 col command.

 

The problem there of course, is that it sends it immediately at the end of the display portion of the scanline, rather than around Colour-Clock position 222.

 

But, we can use this to advantage. An extra HSync pulse is a mere case of enabling Wide DMA, then disabling it again. I once tried a quick program that did probably a dozen on a single line.

 

We can also have the bug in force and get a normal display. So long as DMACTL is held at 00 for the duration, the HBlank command isn't interrupted, therefore the pulses GTIA generates don't get knocked out of step.

 

As for VSync - by setting DMACTL to wide mode, VSync can be almost eliminated... not that it seems desirable to do so.

 

Another application, albeit next to useless: The Atari could emulate Macrovision protection as used on VHS tapes. Since we can control colour/luma output in the normally Black/Blank level areas that VCRs expect, we could probably do some colour cycling stuff that would throw out the gain control.

[atariksi]

The generation of extra pulses - I have it 90% understood, maybe more.

 

With the "240 bug", Antic doesn't unlatch AN2 properly, so it gets stuck set at 1. That's why instead of black, you get Playfield 1 represented in the normal display area (although you can set GTIA modes and instead get Luma F, Colour 15 etc).

...

 

I thought "111" on AN2..AN0 corresponds to playfield 3.

 

>Another application, albeit next to useless: The Atari could emulate Macrovision protection as used on VHS tapes. Since we can control colour/luma output in the normally Black/Blank level areas that VCRs expect, we could probably do some colour cycling stuff that would throw out the gain control.

 

You mean like the Disney videos that are copy protected.

[Bryan]

It is even possible on PAL machines to upset the colourburst phase alternation such that the TV will show the wrong colours.

This is interesting. On NTSC machines, if the colorburst could somehow be generated with a different alignment then you could control what the artifact colors are and shift the entire hue palette around.

The Atari could emulate Macrovision protection as used on VHS tapes. Since we can control colour/luma output in the normally Black/Blank level areas that VCRs expect, we could probably do some colour cycling stuff that would throw out the gain control.

Finally! We can prevent the rampant videotaping of Atari software!!

 

-Bry

[Rybags]

Re Playfield (AN0-2 = 111) - since you need a hires mode to invoke the 240-bug in the first place, then it's PF1 that's normally what becomes visible at the vertical extremes of the screen.

 

Re colourburst - NTSC doesn't do Phase-Alternating, so I don't think it would be possible.

As for PAL, forcing the phase alternation out of step might have some use, but that's a whole different effect to explore.

 

Re macrovision - another oddity that might be pointless. Some newer video equipment reacts to later Macrovision versions... no idea if they can be simulated.

No idea either if TVs ever bother with automatic level control based on Black Level expected during VBlank. If it was the case, it might be possible to alter the luma level of the entire display to something not normally achievable, but then it would probably be something very model specific and not of great general use.

Edited March 22, 2009 by Rybags

[ijor]

At scanline 240, the "010 - HBlank and clear 40 column mode" command is sent continuously until VSync is due, except when we have the "Scanline 240 bug" in effect.

 

This would indicate that GTIA has some "autonomy" in that it will generate HSync pulses at their correct intervals without further prompting from Antic.

 

Yes, that is seen in the schematics and I think I already mentioned it.

 

GTIA has its own horizontal counter and logic that is reset every 228 color clocks. HSYNC is derived from this counter, and not directly from any ANx code. The AN HBlank code resets this counter as well, and this is how ANTIC & GTIA synchronize their horizontal positions.

 

OTOH, VSYNC is completely upto ANTIC, GTIA doesn't have a vertical counter. But note again that sync here is composite (CSYNC), so outside GTIA, there is no physical distinction between HSYNC & VSYNC.