Jump to content
IGNORED

Atari 800 - CTIA or GTIA?


DonutCity

Recommended Posts

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

 

To find out quickly, POKE 623,64. If nothing happens, it's the old CTIA.

I would suspect that the CTIA only had the Rev. A OS, but don't have any info on that.

 

CTIA also has different artifacting for slim lines in high resolution as well.

 

Unknown if you can detect the difference in software. The only way I could think would be to put a PM graphic on a fat pixel and test for a collision.

  • Like 1
Link to comment
Share on other sites

I would say that if you factored in the XLs and XEs, that over 95% of 8-bit machines have the GTIA. Additional to that, there was an option for owners of older machines to have it retrofitted.

 

I think the screwed in covers came about once the 800 came standard with 48K. In the early days, RAM expansion was in 8K increments, plus the OS was modular in aniticipation of enhancements later on.

Link to comment
Share on other sites

Ok, maybe a reach here - is there any way what's the "easiest" way to tell...

977311[/snapback]

 

 

10 GRAPHICS 9

20 GOTO 20

 

If you get a black screen, you have the newer GTIA chip. If you get a blue screen, you have the older CTIA chip. Of course you would need a BASIC cart.

 

The original source of this info

Edited by Almost Rice
  • Like 1
Link to comment
Share on other sites

  • 4 years later...

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!

Link to comment
Share on other sites

Unknown if you can detect the difference in software. The only way I could think would be to put a PM graphic on a fat pixel and test for a collision.

This article describes how to detect GTIA by software.

 

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.

If you get it working, please share the results. There is a report stating that in CTIA player/missle graphics was not aligned with playfield graphics. I'd like to see how it looks and verify whether it affects detecting collisions between P/M and playfield graphics.

 

I'd like to de-cap both a CTIA and GTIA and see if the CTIA is significantly different. I've heard rumors that the CTIA was a stop-gap release because the GTIA modes weren't yet working right.

IMHO it's true. Notice that support for GTIA modes 9, 10 and 11 was already built in OS rev. A, that's before GTIA was released.

Link to comment
Share on other sites

Honestly, since most of the A8's ever released came with GTIA and many of those that didn't have long since been upgraded or disposed of, it's not going to be very useful at all. If you were contemplating writing software that requires a CTIA, there's not going to be many people that can use it. Even finding a CTIA to do the downgrade with is going to be challenge as most of them are probably gone by now. You might accidentally stumble on one if you were to start collecting 400's and 800's with low serial numbers, but that may take a long time and could be extremely expensive if you don't find one in your first few buys.

Edited by OldAtarian
Link to comment
Share on other sites

  • 2 weeks later...

I found a CTIA here but sadly, it looks like I bought the very last one.

 

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

 

I installed it in my 16K 400, but as that the Acid test requires 48K, I had to move it to an 800. The downgrade appears to be perfectly successful (see picture)

 

post-11281-128944215537_thumb.jpg

 

The results of the Acid test are here. Not sure what tests to subject it to next (suggestions welcome)

Link to comment
Share on other sites

Since you've got a CTIA, we'll need you to settle a myth relating to the PMG positioning.

 

Can you run this in Basic and get a screenshot:

 

10 GRAPHICS 0:SETCOLOR 2,3,2
20 POKE 704,136:POKE 53248,68
30 POKE 53261,255
40 COLOR 160:PLOT 0,0:DRAWTO 39,20

 

sorry about the quality - crap-o-matic camera

 

post-11281-128950032355_thumb.jpg

Link to comment
Share on other sites

I did some more testing with my CTIA 800, this time just trying a series of common games. The only problem I noticed (so far) is with Galaxian (the Atari version) which is totally messed up. Just to be sure, I tried it from the same source on a GTIA 800 and it works perfectly.

 

post-11281-128951218455_thumb.jpg

 

Every second or so, the aliens with 'ears' would return to normal, and the normal ones beside them would grow 'ears'. Back and forth. The player's ship is near the top of the screen (above the horizontal bar) and is subject to collisions.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Based on the photo he already posted, I'd say it looks like there *is* a single hi-res pixel offset. It's hard to say for sure, but it does look like the left edge of a block is peeking out from the PM stripe.

 

Michael

post-7456-128952730052_thumb.png

Link to comment
Share on other sites

There is a report stating that in CTIA player/missle graphics was not aligned with playfield graphics. I'd like to see how it looks and verify whether it affects detecting collisions between P/M and playfield graphics.

 

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.

Link to comment
Share on other sites

I checked jacobus' Acid800 results again, and if there were a detectable shift between PM and PF graphics, the ANTIC: Character Control test should have failed since it uses the sprites to scan the playfield. This tests both lores modes (4-7) and hires modes (2-3), so the hires collision bits don't appear to be skewed, either.

Link to comment
Share on other sites

I checked jacobus' Acid800 results again, and if there were a detectable shift ...

 

It makes sense to me, phaeron.

 

I am guessing that the shift is on the signal that in the schematics is called /40CHR (it seems to me that is the name). This is the signal that generates the high-rez graphics. It bypasses collision logic completely, it goes directly to the LUMA output logic. If that is correct, then it shouldn't be detectable by software.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...