GTIA on a Breadboard

[UNIXcoffee928]

This thread is for describing methods of accurately reverse-engineering the GTIA, so that it may first be described & documented on a breadboard, and then, may be used to facilitate a model that can be used in a FPGA description language.

 

This idea came to life in the "Atari on a Breadboard" thread, but will be treated as a separate concept, to keep the threads from becoming distracting & cluttered.

 

Here are the links to all related threads in this "Brute Force Initiative":

 

- Atari on a Breadboard

- POKEY on a Breadboard

- ANTIC on a Breadboard

- SALLY on a Breadboard

- GTIA on a Breadboard

- PIA on a Breadboard

 

- Full Atari Documentation for the GTIA in .pdf format

 

 

=========================================================
CTIA/GTIA
=========================================================
           _________
          |   | |   |
          |    -    |
01. A1    -| 01   40 |- 40. A2:
02. A0    -| 02   39 |- 39. A3
03. Vcc   -| 03   38 |- 38. A4
04. D3    -| 04   37 |- 37. D4
05. D2    -| 05   36 |- 36. D5
06. D1    -| 06   35 |- 35. D6
07. D0    -| 07   34 |- 34. D7
08. T0    -| 08   33 |- 33. R/W
09. T1    -| 09   32 |- 32. CS
10. T2    -| 10   31 |- 31. LUM0
11. T3    -| 11   30 |- 30. Ø2
12. S0    -| 12   29 |- 29. FØ0
13. S1    -| 13   28 |- 28. OSC
14. S2    -| 14   27 |- 27. Vss
15. S3    -| 15   26 |- 26. HALT
16. PAL   -| 16   25 |- 25. CSYNC
17. DEL   -| 17   24 |- 24. LUM3
18. AN0   -| 18   23 |- 23. LUM2
19. AN1   -| 19   22 |- 22. LUM1
20. AN2   -| 20   21 |- 21. COLOR
          |_________|
          |CTIA/GTIA|
          |_________|

 

=========================================================
CTIA/GTIA (Pins run 0-20 on left & 40-21 on the right)
=========================================================
01. A1:     Addr bus         1
02. A0:     Addr bus         0
03. Vcc:    +5V power
04. D3:     Data bus         3
05. D2:     Data bus         2
06. D1:     Data bus         1
07. D0:     Data bus         0
08. T0:     Joystick trigger input 0
09. T1:     Joystick trigger input 1
10. T2:     Joystick trigger input 2
11. T3:     Joystick trigger input 3
12. S0:     Console buttons - Start, Select, Option, ?
13. S1:     Console buttons - Start, Select, Option, ?
14. S2:     Console buttons - Start, Select, Option, ?
15. S3:     Console buttons - Start, Select, Option, ?
16. PAL:    PAL/NTSC indicator (R/W direction unknown)
17. DEL     (CAD3 in the diagram): Color delay line adjustment
18. AN0:    ANTIC data input 0 (see below)
19. AN1:    ANTIC data input 1 (see below)
20. AN2:    ANTIC data input 2 (see below)
21. COLOR:  Color frequency output (to TV modulator?)
22. LUM1:   Luminance output (to TV modulator?)
23. LUM2:   Luminance output (to TV modulator?)
24. LUM3:   Luminance output (to TV modulator?)
25. CSYNC:  Composite sync output
26. HALT:   Signals the GTIA chip to pull player/missile graphic data from the data bus during horizontal blank, if p/m DMA is enabled (GRACTL). (As a reminder, ANTIC also uses HALT to suspend the CPU while it is reading memory.)
27. Vss:    Ground
28. OSC:    Input clock?
29. FØ0:    Fast phase clock output to ANTIC
30. Ø2:     Phase 2 clock input
31. LUM0    Luminance output (to TV modulator?)
32. CS:     Chip select
33. R/W:    Read/write direction
34. D7:     Data bus         7
35. D6:     Data bus         6
36. D5:     Data bus         5
37. D4:     Data bus         4
38. A4:     Addr bus         4
39. A3:     Addr bus         3
40. A2:     Addr bus         2

 

 

Welcome Aboard!

 

Edited November 11, 2008 by UNIXcoffee928

[UNIXcoffee928]

Can someone familiar with both the 2600's TIA & the Atari 8-Bit's CTIA/GTIA talk about the differences between the two?

 

There are FPGA implementations of the TIA available, could they easily be used as a code skeleton to describe a GTIA, or are the ICs so completely different that it wouldn't be worthwhile?

 

I ran across a very interesting analysis of the TIA here.

[Rybags]

Optimising the collision detection logic would probably be one of the most important tasks.

 

So, if that's already been covered it could save a lot of headache.

 

Of course, TIA doesn't have the same complexity regarding playfield, although I'd bet the underlying logic would be nearly the same.

 

GTIA modes is another area of contention - PMGs also behave differently there, and not sure what happens to collisions either.

 

Then there's priority, although I'd assume a lot of that is probably due to having two pipelines that process the graphics data (?) - PL0/1 are tied in with PF0/1 etc.

 

VDelay (for PMGs) is easy - as is the PMG DMA. If the Halt from Antic is asserted on a certain cycle, then GTIA assumes that it is fetching the PMG data. VDelay set for an object means to ignore the fetch if it's on an odd scanline.

 

There is a "bug" though - Antic will use the cycle to fetch DList data if it doesn't have Missile DMA enabled, and GTIA will load that data into the missile data registers.

[mimo]

Are there any differences between the PAL and NTSC GTIA chips, especially with regards to pin outs?

I am thinking of maybe using an 8bitdomain 5200 video mod on a UK Atari 400.

[atariksi]

Optimising the collision detection logic would probably be one of the most important tasks.

...

VDelay (for PMGs) is easy - as is the PMG DMA. If the Halt from Antic is asserted on a certain cycle, then GTIA assumes that it is fetching the PMG data. VDelay set for an object means to ignore the fetch if it's on an odd scanline.

 

There is a "bug" though - Antic will use the cycle to fetch DList data if it doesn't have Missile DMA enabled, and GTIA will load that data into the missile data registers.

 

I thought it was the opposite that VDelay bit set means data IS fetched from ANTIC for the player/missile on odd scanlines and skipped on even scanlines. If first scanline is 0 (even) then that would allow motion of double resolution sprites down by one scan line.

 

I guess the "bug" you are talking about is when you enable the Players DMA, an extra CPU cycle is taken up anyway as if missiles were enabled.

[atariksi]

Are there any differences between the PAL and NTSC GTIA chips, especially with regards to pin outs?

I am thinking of maybe using an 8bitdomain 5200 video mod on a UK Atari 400.

 

I haven't seen pinout differences, but even NTSC GTIA is NOT really NTSC. For one thing, NTSC defines 262.5 scanlines/field whereas Atari is using 262.0 scanlines/field as proven by the fact that 29868 cycles are used in one frame time and writing a simple one scan line kernel routine repeating altering colors gives a solid color bar output (all DMAs disabled). Also, Atari seems to be repeat the fields on the same scanlines rather than interlace (at least on my TV). It seems NTSC display devices have the tolerance to deal with that leeway since the B&W TVs had a slightly different frame rate to begin with, however I know that my Thinkpad 770ED cannot display the Atari video output whereas it shows the VCR/TV output fine.

[Rybags]

VDelay - one or the other...

 

The "bug" - GTIA has the Halt input from Antic and it also naturally knows what point of a scanline everything is at.

 

It uses Halt to determine if it should stuff the graphics registers if GRACTL is set to allow it. Problem is, Antic, if it's PMG DMA isn't enabled, will use the Missile's cycle to read the Display List instruction.

[+bob1200xl]

A TV or monitor builds the display on a CRT using two free-running oscillators. LCDs and computers (digital displays) use clocks. The difference is that the computers and LCDs need to know the odd frame from the even frame in an interlaced display - the TV/monitors do not. Some digital displays just arbitrarily assign odd/even and show whatever is input, others get angry and refuse to show anything.

 

Claus is going to help us fix this with his FRAM video hack. With a version designed for it, we might be able to do our own assignment and feed digital displays a tricked interlaced picture.

 

 

Bob

 

 

Are there any differences between the PAL and NTSC GTIA chips, especially with regards to pin outs?

I am thinking of maybe using an 8bitdomain 5200 video mod on a UK Atari 400.

 

I haven't seen pinout differences, but even NTSC GTIA is NOT really NTSC. For one thing, NTSC defines 262.5 scanlines/field whereas Atari is using 262.0 scanlines/field as proven by the fact that 29868 cycles are used in one frame time and writing a simple one scan line kernel routine repeating altering colors gives a solid color bar output (all DMAs disabled). Also, Atari seems to be repeat the fields on the same scanlines rather than interlace (at least on my TV). It seems NTSC display devices have the tolerance to deal with that leeway since the B&W TVs had a slightly different frame rate to begin with, however I know that my Thinkpad 770ED cannot display the Atari video output whereas it shows the VCR/TV output fine.

[ClausB]

Claus is going to help us fix this with his FRAM video hack. With a version designed for it, we might be able to do our own assignment and feed digital displays a tricked interlaced picture.

I'm not sure we can make interlacing work, but I have an idea for generating 480p30 (480 progressive scan lines at 30 Hz). Though I don't know which display devices really support that mode.