TIA audio NTSC vs. PAL

[puke7]

I was looking at this pinout graphic online and it shows the difference between NTSC and PAL TIA chips.

 

They both have the 6 audio register pins in, but the PAL only has a single audio out. I was wondering if anyone knows if the two channels are mixed down for the PAL out or do you only get one channel?

[Rybags]

6 audio register pins?

 

Those ones with the dots:

CSync - composite sync output, which is HSync XORed with VSync, which is later mixed with the luma signal.

Lum0,1,2 - luma output, combined in a resistor ladder to provide luma signal.

Color - colour signal output.

 

Quite probable there is only one audio out in Pal. As it happens, on NTSC the audio is mixed into mono externally anyway. Plan A was supposedly to have built in speakers but production units never had them.

 

PAL also requires an external colour clocking input because the relationship between system clock, colour clock/pixel size isn't a direct integer one like NTSC, so PAL has an extra 4.43 MHz crystal which is used to generate the colour signal.

 

PAL-I / PAL-S pins - not sure what's going on there, one is probably the colour clocking input.

There is also a SECAM 2600, not sure if it uses the PAL TIA or the signal is generated externally. Secam systems only generate 8 flat colours which are chosen via the luma value, actual colour value in programs is ignored.

[puke7]

Yes, 6 audio register pins (or whatever you call them): A0 - A5. I've never really played with hardware before, but I was thinking it would be interesting to play with the audio abilities of the TIA directly. Thanks for all the info.

[SeaGtGruff]

Yes, 6 audio register pins (or whatever you call them): A0 - A5. I've never really played with hardware before, but I was thinking it would be interesting to play with the audio abilities of the TIA directly. Thanks for all the info.

 

There are six audio registers, but they don't have pins dedicated to them-- they get data from the data pins when you write to them. The only audio pins are the audio out, which is combined into a single pin on the PAL TIA.

 

The A0 through A5 pins are the bits for the addresses, which tell the TIA which registers you want to write to or read from.

[Rybags]

Another mystery... why so many CS pins? Or are some of those outputs?

[+nanochess]

Another mystery... why so many CS pins? Or are some of those outputs?

 

It's an easy to decode, just connect the A6, A7 and A8 to CS0, CS1 and CS3 and you decode the TIA in right place, of course surely CS2 to memory authorization . Not checked, but it looks this way

[SeaGtGruff]

Another mystery... why so many CS pins? Or are some of those outputs?

 

All four CS pins are inputs. Only two CS pins were truly needed for selecting the TIA chip. If you look at sheet 2 of the TIA schematics, it shows that all four CS pins were used. But on the left side of that page are some notes for "CHIP REV. E," and note number 2 says "2. CS1 + /CS3 DELETED." I don't know why Atari originally had four of them-- maybe some kind of redundancy, just to be on the safe side? And I assume that when the CS1 and /CS3 lines were removed inside the TIA, those two pins became NC or "not connected" pins. I wonder what other things they might have been used for if they'd been available from the beginning? For example, it would have been possible to use one of them for a second audio out pin on the PAL TIA-- or rather, keep the two audio outs from the NTSC TIA, plus the /BLK line, and use those two unneeded CS pins for PAL-S and PAL-I (although I don't think the /BLK line was needed for PAL, anyway, since I don't think PAL has the "blacker than black" blanking level that NTSC does-- although that doesn't mean that a /BLK signal would be worthless for PAL).

Edited April 11, 2014 by SeaGtGruff

[Rybags]

I think you can get away without "blacker than black" on NTSC anyway - GTIA doesn't have it and I doubt there's anything in the video gen circuit that does it.

 

Re CS - OK, I get it now... you'd need that many because there's no external decode/select logic going on.

Sacrifice a few pins rather than requiring another chip. I should think the higher order address bits would be needed to be connected and active low, so as to prevent ROM accesses going to TIA.

Edited April 11, 2014 by Rybags

[SeaGtGruff]

I think you can get away without "blacker than black" on NTSC anyway - GTIA doesn't have it and I doubt there's anything in the video gen circuit that does it.

 

I don't think the electrical level of the /BLK signal itself has anything to do with "blacker than black"-- I think it just indicates when the blanking is active. I don't know what the motherboard does with the signal, so it might be another pin that could have been omitted from the get-go. On the other hand, you can "draw" with the blanking in the middle of active scan lines by turning the blanking on and off manually. I don't know how that works with the PAL TIA-- maybe the color output is set to hue 0, luminosity 0 whenever blanking is active? The 8-bit computers take care of the video for you, so I suppose you can't "draw" with the blanking that way unless you turn off ANTIC?

[Rybags]

Isn't that the way proper interlace can be done on the 2600?

Get it to throw out an extra HSync halfway through the scanline before you set VSync.

 

The computer can sort of do it, that's how I did the 480i interlace mode. The hires bug in Antic allows you to generate extra HSync pulses but only outside the normal 240 scanline display and only within the area that can normally show graphics horizontally.

 

I would think if the /BLK signal is used, it's probably summed into the overall luma output value, could probably just go into the resistor ladder with the LUM bits.

[SeaGtGruff]

Isn't that the way proper interlace can be done on the 2600?

Get it to throw out an extra HSync halfway through the scanline before you set VSync.

 

The computer can sort of do it, that's how I did the 480i interlace mode. The hires bug in Antic allows you to generate extra HSync pulses but only outside the normal 240 scanline display and only within the area that can normally show graphics horizontally.

 

I would think if the /BLK signal is used, it's probably summed into the overall luma output value, could probably just go into the resistor ladder with the LUM bits.

 

The blanking isn't the same as the sync. To do interlacing on the 2600 I think all you need to do is turn on the sync at the right time-- and of course blanking must also be on, but that's the same for the normal progressive video. Turning blanking on and off during an active line doesn't affect the sync at all, it just lets you "draw" black areas on the screen-- not very useful (although extending the HBLANK period can be useful), since the minimum horizontal resolution of such a "blanking pixel" is 9 color clocks (3 CPU cycles).

 

Several years ago I wrote a couple of test programs, one that drew a maze on the screen by using blanking for the walls, and another that compared the blanking with regular black pixels by drawing alternating lines (odd lines alternated between blanking and active video, even lines alternated between black and red). The second program actually helped to improve the Stella emulator a bit, since I noticed that the blanking wasn't lined up with the black pixels in some emulators, although it was in Stella. It turns out that there's an extra 1-color-clock delay in the blanking signal, and at that time Stella wasn't emulating this properly. (This was several years ago; it's been corrected in Stella for a long time now.)

 

I loved your work on interlacing the 8-bit computer, by the way!

[supercat]

I don't know why Atari originally had four of them-- maybe some kind of redundancy, just to be on the safe side?

Having A11 feed an active-low chip select on the TIA and RIOT would have increased the cartridge address space to 6K, or made it easier to have 2K on the main board and 4K in a cart.

[+SpiceWare]

Turning blanking on and off during an active line doesn't affect the sync at all, it just lets you "draw" black areas on the screen-- not very useful (although extending the HBLANK period can be useful), since the minimum horizontal resolution of such a "blanking pixel" is 9 color clocks (3 CPU cycles).

 

Using blanking can be useful. Back in 2010 we used to for the two color 48 pixel routine that we came up with for Stay Frosty 2. It hides extraneous graphics that show up on either side of the image.

 

Only downfall is blacker-than-black can be noticeable on poorly adjusted displays.

 

A couple years later we figured out a different way to do it.

 

The Star Castle title screen graphic also uses the VBLANK trick.

[SeaGtGruff]

Having A11 feed an active-low chip select on the TIA and RIOT would have increased the cartridge address space to 6K, or made it easier to have 2K on the main board and 4K in a cart.

 

So if I understand you correctly, the extra CS lines were included during the TIA's design stage so the Atari 2600 could have more memory-- but Atari ended up not doing anything like that with the extra lines, so when they were putting together Revision E of the TIA they decided to delete the extra lines?

[SeaGtGruff]

 

Using blanking can be useful. Back in 2010 we used to for the two color 48 pixel routine that we came up with for Stay Frosty 2. It hides extraneous graphics that show up on either side of the image.

post-3056-129142478662.jpg

 

Only downfall is blacker-than-black can be noticeable on poorly adjusted displays.

post-3056-129142479655.jpg

 

A couple years later we figured out a different way to do it.

 

The Star Castle title screen graphic also uses the VBLANK trick.

 

I didn't mean that VBLANK isn't useful-- I was really referring to "drawing" with VBLANK, as I'd done in my old "Blue Maze" demo (which I unfortunately can't find right now). VBLANK is definitely useful for extending the HBLANK period, or-- as you pointed out-- covering up any unwanted graphics. But since the smallest "pixel" of blanking is 9 color clocks wide (3 CPU cycles, the shortest possible time needed to turn VBLANK on and then off again, or off and then on again), you can't really use it to draw objects on the screen-- well, you can, but the usefulness of doing so is limited by the size of the "pixels," as well as the limitation that a blanking "pixel" must start and end on a 3 color clock boundary. Additionally, trying to "draw" an object with the blanking requires you to devote a portion of the scan line time to turning VBLANK on and off, which takes away from the time you have for drawing the other graphics. My "blue maze" demo was essentially a "proof of concept" program to show that you can "draw" with VBLANK, but since the walls and corridors of the maze were 9 color clocks wide, there were only 17 or 18 "pixels" on each scan line, therefore the maze wasn't very detailed or difficult to "solve." As long as all of the other graphics (sprites) were set up during HBLANK and there were no need to strobe the RESxx registers during the scan lines, it would be possible to have sprites running around in the maze-- although any "collision detection" would have to be based purely on the sprites' positions, since sprites can't "collide" with the blanking.