Atari 800 - CTIA or GTIA?

[phaeron]

Yup, the hires collision logic (PF2C) is parallel to the 40COL path. It's also possible that the change in delay is on the lores output path instead, but a fix on the 40COL path makes more sense. If the hires path were one-half color clock (one hires pixel) late on the CTIA, it would explain both the visible shift and the flipped artifacting colors.

[jacobus]

 

(I tried Best Electronics as well, but after another crappy customer service experience, I discovered they are out of stock as well)

 

 

That suprises me, Best is usually pretty good at taking care of people

 

The first time I tried dealing with them they doubled the price of the item when they saw my order. This time the rather rudely insisted that I check stock levels before ordering. (how I was to do that, I still don't know)

[jacobus]

Could you try that Basic example again except with "SETCOLOR 2,0,0" and "POKE 704,6".

 

Then try typing some text and inverse Spaces around the stripe, then tell us in your judgement if you think the stripe isn't exactly aligned with the character boundary (the inverse spaces should adjoin the edge of the stripe).

 

The reasoning for this is that one document suggests that the PM Graphics were offset by single hires pixel (which I have real doubts about).

 

Probably not worth worrying about a photo - you need just the right lighting conditions for a TV photo to look any good, you usually need to eliminate all external lighting influences.

 

OK - I took your advice and have some better pictures (borrowing my wife's camera probably didn't hurt either)

 

First as a control, I ran both programs on a GTIA 800 (same lighting conditions, camera and monitor)

 

 

 

Then the two programs on the CTIA 800

 

 

For both of the "red" versions, I cranked the brightness down to it's minimum.

[Kr0tki]

We talked about this some time ago. IIRC, you were involved in the debate as well. My conclusion was then, that the shift is not exactly between PM and PF, but between high rez and non-high rez (including PM). If I'm correct, it is a shift between chroma and luma, and it is the same shift that provokes the difference in artificats as well. And I think that this probably does not affect collision.

Yes, I remember that topic, although I've forgotten the conclusion.

 

 

OK - I took your advice and have some better pictures (borrowing my wife's camera probably didn't hurt either)

(...)

 

Thanks for the photos. Unfortunately, they are inconclusive - and I believe that the test program itself is at fault. For best results, the colours and brightnesses for playfield and PM should be identical.

 

Below is my attempt at a testing program. I believe it will help resolve all doubts.

 

The program should produce a screen similar to this:

 

The 3 right-hand rectangles are for reference - they should have 100% straight edges on all systems.

 

The left-hand rectangles are composed from alternating lines of (from top to bottom):

1. GRAPHICS 0 (8 scanlines) and Player 0 (8 scanlines);

2. GRAPHICS 0 (8 scanlines) and GRAPHICS 3 (8 scanlines);

3. GRAPHICS 3 (8 scanlines) and Player 0 (8 scanlines).

 

With a GTIA, those rectangles also should have straight edges. With a CTIA however, on one or more rectangle there should be noticeable shift on the rectangle's vertical edges.

 

Jacobus, please run my test on your CTIA and make a photo again. The program is longer than the previous one, but I hope it will be the last one.

 

0 BRI=10
10 PMBASE=PEEK(740)-4:POKE 106,PMBASE:GRAPHICS 0:DL=PEEK(560)+256*PEEK(561):SC=PEEK(88)+256*PEEK(89)
20 POKE 53277,2:POKE 53248,84:POKE 53249,164:POKE 53250,124:POKE SC+2,0:S=PMBASE*256
100 FOR I=0 TO 47 STEP 8:READ A:FOR J=0 TO 7:POKE S+I+J,A:NEXT J:NEXT I
110 DATA 0,96,48,24,85,170
200 FOR I=6 TO 28:READ A:POKE DL+I,A:NEXT I
210 DATA 2,2,2,112,2,8,2,8,112,8,8,8,8,112,2,15,15,15,15,15,15,15,15
300 FOR I=1 TO 16:READ A:POKE SC+A,128:NEXT I
310 DATA 9,10,29,30,69,70,89,90,109,110,149,150,169,170,219,220
320 FOR I=1 TO 8:READ A:POKE SC+A,40:NEXT I
330 DATA 202,252,262,267,277,282,287,297
340 FOR I=300 TO 319:POKE SC+I,4:POKE SC+I+20,5:NEXT I
350 FOR I=340 TO 659 STEP 40
360 FOR J=0 TO 19:POKE SC+I+J,85:POKE SC+I+J+20,170:NEXT J
370 NEXT I
380 POKE SC+139,1:POKE SC+179,2:POKE SC+229,3
400 POKE 559,42:POKE 54279,PMBASE:POKE 756,PMBASE
410 FOR I=512 TO 895:POKE S+I,0:NEXT I
420 FOR I=1 TO 5:READ A,B:FOR J=A TO B:POKE S+J,255:NEXT J:NEXT I
430 DATA 532,535,540,543,572,575,580,583,676,691
440 FOR I=1 TO 2:READ A,B:FOR J=A TO B:POKE S+J,64:NEXT J:NEXT I
450 DATA 800,803,808,811
500 POKE 704,BRI:POKE 705,BRI:POKE 706,BRI:POKE 709,BRI:POKE 710,0
510 GOTO 510

You can manipulate the BRI variable at line 0 to adjust screen brightness.

 

 

On a side note, I've run the program on my PAL 65XE with a good GTIA (connected through composite) and noticed a slight shift between hi-res and low-res graphics - although only on the rectangles' left edges. So it seems that ijor is right on this one.

HIRES.LST.zip

[jacobus]

 

Thanks for the photos. Unfortunately, they are inconclusive - and I believe that the test program itself is at fault. For best results, the colours and brightnesses for playfield and PM should be identical.

 

 

OK, here are two photos - the first a normal picture, the second with the brightness turned down.

 

 

 

and for reference, the same test on a GTIA 800

 

Edited November 16, 2010 by jacobus

[ijor]

Unfortunately, they are inconclusive - and I believe that the test program itself is at fault...

OK, here are two photos - the first a normal picture, the second with the brightness turned down.

 

Great work both Kr0tki and jacobus!

 

This is more conclusive, and seems it proofs that there is a shift between hi-rez and low-rez, and not between low-rez and players.

 

On a side note, I've run the program on my PAL 65XE with a good GTIA (connected through composite) and noticed a slight shift between hi-rez and low-rez graphics - although only on the rectangles' left edges.

 

I'm not sure this is the same issue, althought it might be. The reason you see this tiny mis-alignment on GTIA, is likely because the LUMA on hi-rez is really not synchronized. Let's remember that GTIA (and CTIA as well) is cheating here, and playing some dirty tricks for hi-rez. The frequency operation of GTIA is one color clock, too coarse for hi-rez which is half color clock. So it really can't synchronize the path for this signal correctly. This means that a tiny distortion on the timing is possible, and it might depend on each specific chip/board and even working conditions (such as temperature). And this means that there could be differences between the raising edge and falling edge as well.

 

It might be the same issue as GTIA vs. CTIA or it might be not. Initially, I though that it was a specific half clock difference (sync). Now, I think that it might possibly be just a significant difference in the combinatorial (async) path.

Edited November 16, 2010 by ijor

[phaeron]

I thought GTIA did operate at 7MHz internally, with phase 1 and 2 sync points throughout?

 

Also, I've noticed that the 130XE I have shows a slight visible offset between luma and chroma, whereas my 800XL doesn't. Perhaps the analog output path plays a part in determining relative delays, too?

[ijor]

I thought GTIA did operate at 7MHz internally, with phase 1 and 2 sync points throughout?

 

No. GTIA gets its ~3.58 MHz clock, and it works internally at that frequency. It does generate the two phases, as just about any other synchronous chip at the time. But two 3.58 MHz clocks don't make a 7.16 MHz one. You would need something like a PLL to double the frequency, something pretty common in modern chips, but certainly not then.

 

There are some tricks to manipulate a signal on both edges/phases, as GTIA does with the hi-rez luma. But it has some limitations. One of them is that such a signal can't be synchronized any further. In this case, you would like to synchronize the hi-rez/lo-rez luma mux, but you can't. Then some timing issues are possible.

 

Also, I've noticed that the 130XE I have shows a slight visible offset between luma and chroma, whereas my 800XL doesn't. Perhaps the analog output path plays a part in determining relative delays, too?

 

This is a different issue. In the GTIA vs. CTIA issue, or what Kr0tki found in his own computer, it is about a timing difference, in the luma signal, between hi-rez and lo-rez. This has to be something purely digital, and it must originate inside GTIA. The CTIA shift between chroma and luma (which seems to happen in hi-rez only), is only a byproduct of this. In your case, if I understand you correctly, the offset is (more or less) constant.

[Kr0tki]

OK, here are two photos - the first a normal picture, the second with the brightness turned down.

Thanks! The photos finally give the definite answer.

 

On a side note: the photos don't seem to represent the colours correctly (it's expected when making a photo from a CRT) so I'd like to verify the one last thing. Jacobus, what were the colours on the bottom on the screen? (I'm expecting the answer to be blue on the left and reddish-brown on the right for CTIA, and the opposite to GTIA.)

 

This is more conclusive, and seems it proofs that there is a shift between hi-rez and low-rez, and not between low-rez and players.

Yes, it seems that the hi-res luminance is shifted wrt. to all other graphics by exactly half a colour clock to the left.

 

One thing that's still bugging me: what happens when you do GRAPHICS 8:COLOR 1:PLOT 0,0 on a CTIA? I presume that the pixel would appear to the left of the playfield, on the border, and it would assume the border's chrominance (0). Right?

 

On a side note, I've run the program on my PAL 65XE with a good GTIA (connected through composite) and noticed a slight shift between hi-rez and low-rez graphics - although only on the rectangles' left edges.

 

I'm not sure this is the same issue, althought it might be. The reason you see this tiny mis-alignment on GTIA, is likely because the LUMA on hi-rez is really not synchronized. (...)

On second thought, I believe it's a separate issue. It was already reported previously that in hi-res the "0" pixels "are output somewhat sharper and brighter" than "1" pixels. It seems that switching from 0 to 1 happens a little bit later than switching from 1 to 0 - the result is that single "1" pixels are a bit narrower than "0" pixels.

 

Or, maybe the position of hi-res pixels (odd/even), and not their 0/1 value, has something to do here. Anyway, it would be five minutes to check.

 

Also, I've noticed that the 130XE I have shows a slight visible offset between luma and chroma, whereas my 800XL doesn't. Perhaps the analog output path plays a part in determining relative delays, too?

Whatever the cause is, I believe it would also cause a difference in artifact colours (which have been reported to be pink/green on some if not all XEs). Phaeron, can you check the artifact colours on your machines?

Edited November 16, 2010 by Kr0tki

[jacobus]

OK, here are two photos - the first a normal picture, the second with the brightness turned down.

Thanks! The photos finally give the definite answer.

 

On a side note: the photos don't seem to represent the colours correctly (it's expected when making a photo from a CRT) so I'd like to verify the one last thing. Jacobus, what were the colours on the bottom on the screen? (I'm expecting the answer to be blue on the left and reddish-brown on the right for CTIA, and the opposite to GTIA.)

 

 

OK, on the CTIA 800, the left hand side is a purple-ish blue and the right hand side is green.

 

On the GTIA 800, the colours are reversed.

 

(for reference, it's a Commodore 1702 monitor)

Edited November 17, 2010 by jacobus

[phaeron]

Also, I've noticed that the 130XE I have shows a slight visible offset between luma and chroma, whereas my 800XL doesn't. Perhaps the analog output path plays a part in determining relative delays, too?

Whatever the cause is, I believe it would also cause a difference in artifact colours (which have been reported to be pink/green on some if not all XEs). Phaeron, can you check the artifact colours on your machines?

 

My 800XL artifacts in green/purple, 130XE in aqua/brown. Captures attached. If you flip back and forth between the images, you can also spot a very slight shift in the luma, about 1/3rd of a hires pixel.

[carmel_andrews]

I am guessing there are more G's then C's out there (for the 400/800)

[flashjazzcat]

I am guessing there are more G's then C's out there (for the 400/800)

No need for guesswork:

 

If it's PAL, 100% on GTIA. Apparently, the early NTSC (1st 18 months?) had CTIA.

 

...Additional to that, there was an option for owners of older machines to have it retrofitted.

Edited November 17, 2010 by flashjazzcat

[atariksi]

I thought GTIA did operate at 7MHz internally, with phase 1 and 2 sync points throughout?

 

No. GTIA gets its ~3.58 MHz clock, and it works internally at that frequency. It does generate the two phases, as just about any other synchronous chip at the time. But two 3.58 MHz clocks don't make a 7.16 MHz one. You would need something like a PLL to double the frequency, something pretty common in modern chips, but certainly not then.

Without a schematic of GTIA, it's a guess then. You could phase shift the 3.58Mhz by half a clock cycle using just timing of the gates and then use both of those clocks. I thought there were some NOT gates bunched up just to get delays in the GTIA.

[Bryan]

There are (rather poor) schematics of GTIA and it does run at 2x the CPU speed (3.58MHz). All high-res graphics (~7.1MHz pixel clock) are created by muxing LUM values during opposite phases of the clock. Edited November 17, 2010 by Bryan

[BillC]

I want to downgrade a GTIA 400 to CTIA. Do I need anything other than a CTIA chip? I'm assuming I can just swap the chips...

 

Why? ... good question - it's on older 400 that was originally CTIA and a) I'd like to see what the difference is like, b) it would be interesting to restore it to the original condition.

 

 

thanks!

If you still want to restore your 400 to CTIA, I found the following website that lists it for $4.99.

http://www.arcadecomponents.com/catalog/item/3054735/2995543.htm

 

As already stated though, most software was designed for diplay on GTIA equipped systems, since only the very early 400/800 came with the CTIA chip.

 

I upgraded my first 400 to GTIA in 82/83 for this reason, and also upgraded the RAM to 64K at the same time.

 

Bill

[jacobus]

I want to downgrade a GTIA 400 to CTIA. Do I need anything other than a CTIA chip? I'm assuming I can just swap the chips...

 

Why? ... good question - it's on older 400 that was originally CTIA and a) I'd like to see what the difference is like, b) it would be interesting to restore it to the original condition.

 

 

thanks!

If you still want to restore your 400 to CTIA, I found the following website that lists it for $4.99.

http://www.arcadecomponents.com/catalog/item/3054735/2995543.htm

 

As already stated though, most software was designed for diplay on GTIA equipped systems, since only the very early 400/800 came with the CTIA chip.

 

I upgraded my first 400 to GTIA in 82/83 for this reason, and also upgraded the RAM to 64K at the same time.

 

Bill

 

Thanks Bill - that is the site that I bought mine from. Unfortunately (for everyone else) I purchased the very last one they had in stock.