Jump to content

Photo

Internal ANTIC and GTIA schematics


183 replies to this topic

#101 atariksi OFFLINE  

atariksi

    Quadrunner

  • 5,337 posts

Posted Mon Jan 19, 2009 11:28 PM

Perhaps some kind souls can do some napkin-sketches of what they think may be missing at the edges in the center of the following images. If so, I will draw them into the images, once we have a consensus.


I figured out most of the missing sections, but did you read what Curt just said? He has the full-size original schematics and he is going to publish them shortly. Are you sure is it worth to invest a lot of work on this?
...

Unless someone is going to replicate the chips in some hardware emulation, I think it's useful if someone who has the schematics and understands them can figure out if there are other bits in registers or any test registers that are not documented.

#102 ijor OFFLINE  

ijor

    River Patroller

  • 2,166 posts

Posted Tue Jan 20, 2009 12:19 AM

I figured out most of the missing sections, but did you read what Curt just said? He has the full-size original schematics and he is going to publish them shortly. Are you sure is it worth to invest a lot of work on this?

Unless someone is going to replicate the chips in some hardware emulation, I think it's useful if someone who has the schematics and understands them can figure out if there are other bits in registers or any test registers that are not documented.


I didn't mean it is not worth to study and analyze the schematics. Wasn't that obvious from what I said?
What I meant is that (IMHO) is not worth to spent too much time and effort in cleaning up and completing the "unreadable" schematics, when we'll get soon full high-rez scans of the original.

Btw, I don't think there is any undocumented register, or even bit, in GTIA or in any of the chipset at all. What you have is a couple of things not 100% fully documented, bugs like the one in Antic, and some tricks like Bryan's method for shifting GTIA modes.

#103 UNIXcoffee928 OFFLINE  

UNIXcoffee928

    Stargunner

  • 1,177 posts
  • Location:Sosaria, USA

Posted Tue Jan 20, 2009 12:40 AM

Ah, I did say ALPHA... ha.

Somehow, I missed Curt's post. Did not see that one! Well, that is great news!

Glad that I didn't spend TOO much time on this, then... ha.

Sad to hear that Curt is in the hospital, though, best wishes on a speedy recovery!


In this case, since we will soon have real documentation, I'll just post the last mod that I made before reading about this news, so that the current set will be complete. You'll find it below, with more (previously unreadable) stuff uncovered.

View_02 Mod_02 (Address Data/Player Missile Graphics Segment):

Attached Thumbnails

  • GTIA_FULL_View_02_mod_02.jpg


#104 atariksi OFFLINE  

atariksi

    Quadrunner

  • 5,337 posts

Posted Thu Jan 22, 2009 2:07 AM

I figured out most of the missing sections, but did you read what Curt just said? He has the full-size original schematics and he is going to publish them shortly. Are you sure is it worth to invest a lot of work on this?

Unless someone is going to replicate the chips in some hardware emulation, I think it's useful if someone who has the schematics and understands them can figure out if there are other bits in registers or any test registers that are not documented.


I didn't mean it is not worth to study and analyze the schematics. Wasn't that obvious from what I said?
What I meant is that (IMHO) is not worth to spent too much time and effort in cleaning up and completing the "unreadable" schematics, when we'll get soon full high-rez scans of the original.
...

I never stated that you did. Whichever schematic one can understand whether cleaned up or not.

>Btw, I don't think there is any undocumented register, or even bit, in GTIA or in any of the chipset at all. What you have is a couple of things not 100% fully documented, bugs like the one in Antic, and some tricks like Bryan's method for shifting GTIA modes.

I gave you an example of SYSTEM RESET lock-up which is not documented, but obviously the functionality should be in the schematic.

#105 carmel_andrews OFFLINE  

carmel_andrews

    Quadrunner

  • 13,297 posts
  • Location:from somewhere, anywhere and no where

Posted Thu Jan 22, 2009 3:07 AM

I remember reading or hearing somewhere that Antic is only partly programmable, does that mean that they disabled something in the chip (at the design/production stage) or was it a 'technology limitation' that you could only have access to so muich of Antic's progammability

#106 ijor OFFLINE  

ijor

    River Patroller

  • 2,166 posts

Posted Thu Jan 22, 2009 8:58 AM

I never stated that you did. Whichever schematic one can understand whether cleaned up or not.


Sorry again for the misunderstanding. You know, many times I have troubes understanding your point. Possibly is the combination of your somewhat strange English, and my weak English.

So if you were asking if I can see any undocumented registers on GTIA, then no. I can't see any undocumented register or bit at all on GTIA or on POKEY (we don't have ANTIC schematics yet). There are, of course, all sort of possible tricks (such as the ones we were discussing), most of them being completely useless and sometimes not very reliable.

I gave you an example of SYSTEM RESET lock-up which is not documented, but obviously the functionality should be in the schematic.


Didn't check your code, and I don't have an 800 to test it. What exactly it does? Does it actually disable RESET NMI on ANTIC? Or it just traps the NMI OS vector/warmstart fast enough?

If the latter, then this has nothing to do with hardware or schematics. It is just an OS issue in the 800, and purely software in the XL.

If you actually found an undocumented ANTIC behavior, can you please post a minimally reduced example (no music, etc), to describe exactly how RESET NMI is disabled.

#107 atariksi OFFLINE  

atariksi

    Quadrunner

  • 5,337 posts

Posted Thu Jan 22, 2009 11:37 AM

I never stated that you did. Whichever schematic one can understand whether cleaned up or not.


Sorry again for the misunderstanding. You know, many times I have troubes understanding your point. Possibly is the combination of your somewhat strange English, and my weak English.

So if you were asking if I can see any undocumented registers on GTIA, then no. I can't see any undocumented register or bit at all on GTIA or on POKEY (we don't have ANTIC schematics yet). There are, of course, all sort of possible tricks (such as the ones we were discussing), most of them being completely useless and sometimes not very reliable.

...

There was some document floating around CGIA or something that contained test register(s) initialized at boot time. So I thought perhaps some of these other chips had some bits or registers used internally or never documented.

>>I gave you an example of SYSTEM RESET lock-up which is not documented, but obviously the functionality should be in the schematic.

>Didn't check your code, and I don't have an 800 to test it. What exactly it does? Does it actually disable RESET NMI on ANTIC? Or it just traps the NMI OS vector/warmstart fast enough?

>If the latter, then this has nothing to do with hardware or schematics. It is just an OS issue in the 800, and purely software in the XL.

>If you actually found an undocumented ANTIC behavior, can you please post a minimally reduced example (no music, etc), to describe exactly how RESET NMI is disabled.

Actually, the challenge was to make it more like do music, color effects, etc. while disallowing RESET rather than locking it up with a static image or something like that. It does lock-up the reset (on A800/A400)-- the music plays without a hitch and colors rotate even if you keep pressing RESET. On 800XL if you press RESET, it just continues to play voice #0 (the constant tone) and then actually does the WARM reset.

#108 atariksi OFFLINE  

atariksi

    Quadrunner

  • 5,337 posts

Posted Thu Jan 22, 2009 11:38 AM

I remember reading or hearing somewhere that Antic is only partly programmable, does that mean that they disabled something in the chip (at the design/production stage) or was it a 'technology limitation' that you could only have access to so muich of Antic's progammability


They would have to enable write-to read-only registers to get access to some of the internal registers that it has...

#109 Rybags OFFLINE  

Rybags

    Gridrunner

  • 15,993 posts
  • Location:Australia

Posted Thu Jan 22, 2009 8:04 PM

"Partly programmable" means it's not a full-fledged Co-processor, since it only has Mode, Load and Jump type instructions.

#110 eru OFFLINE  

eru

    Chopper Commander

  • 199 posts
  • Location:Amsterdam, The Netherlands

Posted Thu Feb 5, 2009 3:33 PM

I can verify that GTIA's timing is buggy. I wrote a program many years ago that created the that Gr. 9/10 HIP effect using only graphics 9. I discovered that by flipping PRIOR a few times during the hblank, I was able to get a 1/2 pixel shifted version of it, so I alternated it on every other line then alternated the lines on the next frame. It looked great!

Hey Bryan,

I'm curious - do you still have the code doing GR9 shifted by 1/2pixel around? We would like to verify it, perhaps with some tweaks we can come up with code that works on all machines - that would rule, opening very cool possibilities.

Thanks in advance!

#111 Bryan OFFLINE  

Bryan

    Quadrunner

  • 10,926 posts
  • Cruise Elroy = 4DB7
  • Location:Chesaning, MI

Posted Fri Feb 6, 2009 7:41 AM

I can verify that GTIA's timing is buggy. I wrote a program many years ago that created the that Gr. 9/10 HIP effect using only graphics 9. I discovered that by flipping PRIOR a few times during the hblank, I was able to get a 1/2 pixel shifted version of it, so I alternated it on every other line then alternated the lines on the next frame. It looked great!

Hey Bryan,

I'm curious - do you still have the code doing GR9 shifted by 1/2pixel around? We would like to verify it, perhaps with some tweaks we can come up with code that works on all machines - that would rule, opening very cool possibilities.

Thanks in advance!


I've got to dig it out of some old boxes. I'm going to try to find it this weekend and post it. I've also got to figure out which XL can show the pictures so I can take some snapshots.

I don't know if I posted this before but there's another interesting GTIA effect I discovered. When you change from 320 mode to GTIA 10 (9 colors) in mid-line, you may see the high order color bits represented twice where the mode change occurs.

Let's say you want to go from 320 mode to GTIA mode 10 in the middle of a line, and you want the color to be $8 (COLBK). You put the value into the bitmap and stuff PRIOR at the right time. You may or may not see bit 3 (1000) in the 320 mode graphics before the GTIA 10 pixel appears. This is because a mode 10 pixel is delayed and is using data that is a 160 pixel late. On my machine, the extra 320 pixel shows up at first as a white stripe, and disappears once the machine has been on for a few minutes.


edit: to clarify...
We send 0 pixels to the 320 portion of the screen, then enter mode 10 at the * and show color 8:

00000000 00000000 00000000 * 10001000 10001000...

The first 1 bit may show up as both a white dot in the 320 portion and the color of the first GTIA mode pixel. On my machine, the white dot disappears after a while, though.

This means that some of the internal timings of GTIA mode operations fall very close to a clock boundary. This is probably the same thing that's shifting mode 9 pixels.

-Bry

Edited by Bryan, Fri Feb 6, 2009 7:46 AM.


#112 ijor OFFLINE  

ijor

    River Patroller

  • 2,166 posts

Posted Fri Feb 6, 2009 11:43 AM

Let's say you want to go from 320 mode to GTIA mode 10 in the middle of a line, and you want the color to be $8 (COLBK). You put the value into the bitmap and stuff PRIOR at the right time. You may or may not see bit 3 (1000) in the 320 mode graphics before the GTIA 10 pixel appears. This is because a mode 10 pixel is delayed and is using data that is a 160 pixel late. On my machine, the extra 320 pixel shows up at first as a white stripe, and disappears once the machine has been on for a few minutes.
...
This means that some of the internal timings of GTIA mode operations fall very close to a clock boundary. This is probably the same thing that's shifting mode 9 pixels.


That doesn't surprise me. And now that you mention, I realize that this behavior is even expected.

I don't think this has much to do with the GTIA mode timing. It is possibly more related to the LUM outputs. LUM outputs are not really synchronized. They can't be fully synchronized to the clock because, on high rez mode, these outputs change at twice the rate of the GTIA clock.

BTW, this is probably one of the main technical reasons why GTIA doesn't support any color at all on high rez. It would be very difficult without a half color clock crystal/oscillator.

#113 atariksi OFFLINE  

atariksi

    Quadrunner

  • 5,337 posts

Posted Sat Feb 7, 2009 5:10 AM

I can verify that GTIA's timing is buggy. I wrote a program many years ago that created the that Gr. 9/10 HIP effect using only graphics 9. I discovered that by flipping PRIOR a few times during the hblank, I was able to get a 1/2 pixel shifted version of it, so I alternated it on every other line then alternated the lines on the next frame. It looked great!

Hey Bryan,

I'm curious - do you still have the code doing GR9 shifted by 1/2pixel around? We would like to verify it, perhaps with some tweaks we can come up with code that works on all machines - that would rule, opening very cool possibilities.

Thanks in advance!


I've got to dig it out of some old boxes. I'm going to try to find it this weekend and post it. I've also got to figure out which XL can show the pictures so I can take some snapshots.

I don't know if I posted this before but there's another interesting GTIA effect I discovered. When you change from 320 mode to GTIA 10 (9 colors) in mid-line, you may see the high order color bits represented twice where the mode change occurs.

Let's say you want to go from 320 mode to GTIA mode 10 in the middle of a line, and you want the color to be $8 (COLBK). You put the value into the bitmap and stuff PRIOR at the right time. You may or may not see bit 3 (1000) in the 320 mode graphics before the GTIA 10 pixel appears. This is because a mode 10 pixel is delayed and is using data that is a 160 pixel late. On my machine, the extra 320 pixel shows up at first as a white stripe, and disappears once the machine has been on for a few minutes.


edit: to clarify...
We send 0 pixels to the 320 portion of the screen, then enter mode 10 at the * and show color 8:

00000000 00000000 00000000 * 10001000 10001000...

The first 1 bit may show up as both a white dot in the 320 portion and the color of the first GTIA mode pixel. On my machine, the white dot disappears after a while, though.

This means that some of the internal timings of GTIA mode operations fall very close to a clock boundary. This is probably the same thing that's shifting mode 9 pixels.

-Bry


For Graphics 10, it looks like there's enough internal delay that there's a color clock delay consistently through all the 8-bit machines and models. So, if that delay can be simulated in Graphics 9 through toggling some registers on a scanline, then it should work for all the 8-bit machines and models.

#114 atariksi OFFLINE  

atariksi

    Quadrunner

  • 5,337 posts

Posted Sat Feb 7, 2009 5:13 AM

Let's say you want to go from 320 mode to GTIA mode 10 in the middle of a line, and you want the color to be $8 (COLBK). You put the value into the bitmap and stuff PRIOR at the right time. You may or may not see bit 3 (1000) in the 320 mode graphics before the GTIA 10 pixel appears. This is because a mode 10 pixel is delayed and is using data that is a 160 pixel late. On my machine, the extra 320 pixel shows up at first as a white stripe, and disappears once the machine has been on for a few minutes.
...
This means that some of the internal timings of GTIA mode operations fall very close to a clock boundary. This is probably the same thing that's shifting mode 9 pixels.


That doesn't surprise me. And now that you mention, I realize that this behavior is even expected.

I don't think this has much to do with the GTIA mode timing. It is possibly more related to the LUM outputs. LUM outputs are not really synchronized. They can't be fully synchronized to the clock because, on high rez mode, these outputs change at twice the rate of the GTIA clock.

BTW, this is probably one of the main technical reasons why GTIA doesn't support any color at all on high rez. It would be very difficult without a half color clock crystal/oscillator.


GTIA does support color in hi-res (320-wide) mode using 60Hz display. Of course, you get more colors at same bandwidth at cost of refresh rate (30Hz interlaced).

#115 supercat OFFLINE  

supercat

    Quadrunner

  • 6,401 posts

Posted Sat Feb 7, 2009 2:46 PM

Btw, I don't think there is any undocumented register, or even bit, in GTIA or in any of the chipset at all. What you have is a couple of things not 100% fully documented, bugs like the one in Antic, and some tricks like Bryan's method for shifting GTIA modes.


I would expect there to be lots of undocumented registers, but for them not to be memory mapped; most of them will typically work together to mimic the behavior of documented "registers" that don't actually exist in the documented form.

I'm not familiar with the CTIA/GTIA, but to borrow some examples from the original TIA...

-1- The documentation shows that each sprite has a divide-by-160 counter. The documentation does not show that each sprite actually has a cascaded divide-by-four and a divide-by-forty. Usually, the cascaded counters behave like a divide-by-160, but the synchronization logic gets tripped up if a sprite is reset within a small window of its normal trigger point.

-2- The documentation states that there is a pulser circuit which adds and subtracts pulses. It does not mention that the subtraction of pulses is achieved by delaying the end of hblank, nor does it mention that there is a four-bit counter that counts once every four pixel clocks except that if it's sitting at zero it will remain there until the next HMOVE. The documentation also does not mention that each sprite has a latch which turns its pulser on and off, and that this latch may be 'jammed'.

-3- The documentation does not describe the particular behavior of the shift registers used in the audio generation circuitry. Though it accurately describes what any particular AUDCx mode will do in isolation, the description is not sufficient to know what will happen if AUDCx is changed while a sound is playing.

All of those behaviors are the result of incompletely-documented registers. I'm sure many more examples could be found for the TIA.

#116 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • 11,163 posts
  • Location:Baden-Württemberg, Germany

Posted Sat Feb 7, 2009 3:59 PM

Bryan... your mentioned 9/9 HIP would be interesting... as we would get away of the "HAM-Amiga" like pixel setting difficulty... if you can dig out your source and it would work on most of the machines... I guess we have a new gfx mode called "BRY". ;)

#117 ijor OFFLINE  

ijor

    River Patroller

  • 2,166 posts

Posted Sat Feb 7, 2009 4:00 PM

I would expect there to be lots of undocumented registers, but for them not to be memory mapped; most of them will typically work together to mimic the behavior of documented "registers" that don't actually exist in the documented form.
...
All of those behaviors are the result of incompletely-documented registers


I think it was obvious that I was talking about memory mapped registers. And I think it is more than obvious, that in any chip like these would be lots of additional registers, latches or flip-flops.

However, in the case of the two custom chips that we have schematics (GTIA & POKEY), most if not all of the memory mapped register correspond directly to registers in silicon.

But yes, of course that not every single minute aspect is fully documented. I don't see how this would be possible without publishing the schematics.

#118 atariksi OFFLINE  

atariksi

    Quadrunner

  • 5,337 posts

Posted Sun Feb 8, 2009 1:56 PM

Btw, I don't think there is any undocumented register, or even bit, in GTIA or in any of the chipset at all. What you have is a couple of things not 100% fully documented, bugs like the one in Antic, and some tricks like Bryan's method for shifting GTIA modes.


I would expect there to be lots of undocumented registers, but for them not to be memory mapped; most of them will typically work together to mimic the behavior of documented "registers" that don't actually exist in the documented form.

I'm not familiar with the CTIA/GTIA, but to borrow some examples from the original TIA...

-1- The documentation shows that each sprite has a divide-by-160 counter. The documentation does not show that each sprite actually has a cascaded divide-by-four and a divide-by-forty. Usually, the cascaded counters behave like a divide-by-160, but the synchronization logic gets tripped up if a sprite is reset within a small window of its normal trigger point.

-2- The documentation states that there is a pulser circuit which adds and subtracts pulses. It does not mention that the subtraction of pulses is achieved by delaying the end of hblank, nor does it mention that there is a four-bit counter that counts once every four pixel clocks except that if it's sitting at zero it will remain there until the next HMOVE. The documentation also does not mention that each sprite has a latch which turns its pulser on and off, and that this latch may be 'jammed'.

-3- The documentation does not describe the particular behavior of the shift registers used in the audio generation circuitry. Though it accurately describes what any particular AUDCx mode will do in isolation, the description is not sufficient to know what will happen if AUDCx is changed while a sound is playing.

All of those behaviors are the result of incompletely-documented registers. I'm sure many more examples could be found for the TIA.


It was ijor who stated what you quoted not me (atariksi). I think you got the "/quote" stuff interleaved improperly.

#119 Bryan OFFLINE  

Bryan

    Quadrunner

  • 10,926 posts
  • Cruise Elroy = 4DB7
  • Location:Chesaning, MI

Posted Sun Feb 8, 2009 2:01 PM

Okay, here the stuff I've found so far. I also have a bunch more pictures on a disk somewhere...

Since it uses flicker, the photos don't really show the increase in resolution well. There are two versions of each picture. One is taken before I heat up the GTIA and one after. If someone can get a better picture taken, that would be great. Back when I wrote this, my machine didn't need heating but my current XL does. I don't know if it can be made to be stable.

I've included an ATR of a BASIC XE program for displaying the CACTUS.VZI picture and an executable that displays the wagon. If I find more picture files, I'll post them.

Attached Thumbnails

  • cactus1.jpg
  • cactus2.jpg
  • wagon1.jpg
  • wagon2.jpg

Attached Files

  • Attached File  bry.zip   34.67KB   123 downloads


#120 Bryan OFFLINE  

Bryan

    Quadrunner

  • 10,926 posts
  • Cruise Elroy = 4DB7
  • Location:Chesaning, MI

Posted Sun Feb 8, 2009 6:40 PM

BTW, please let me know if you have any success getting this to work on your system. I used a heat gun on its low setting to heat up the GTIA.

#121 potatohead OFFLINE  

potatohead

    River Patroller

  • 4,404 posts
  • Location:Portland, Oregon

Posted Sun Feb 8, 2009 6:41 PM

Those pictures are nice.

#122 Shawn Jefferson OFFLINE  

Shawn Jefferson

    Stargunner

  • 1,987 posts
  • Location:Victoria, Canada

Posted Sun Feb 8, 2009 11:33 PM

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

#123 Rybags OFFLINE  

Rybags

    Gridrunner

  • 15,993 posts
  • Location:Australia

Posted Sun Feb 8, 2009 11:45 PM

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

062D: 8D 0A D4  STA $D40A  ;WSYNC
0630: EA		NOP
0631: EA		NOP
0632: EA		NOP
0633: EA		NOP
0634: EA		NOP
0635: EA		NOP
0636: A9 01	 LDA #$01
0638: 8D 1B D0  STA $D01B  ;PRIOR
063B: A9 41	 LDA #$41
063D: 8D 1B D0  STA $D01B  ;PRIOR
0640: 8D 0A D4  STA $D40A  ;WSYNC
0643: CA		DEX
0644: D0 E7	 BNE $062D


#124 Rybags OFFLINE  

Rybags

    Gridrunner

  • 15,993 posts
  • Location:Australia

Posted Mon Feb 9, 2009 1:00 AM

Sadly, looks like it's a no-go here. I've even tried varying the delay slightly for the initial setting of GPRIOR to 1.

Haven't "heated up" my GTIA, although my 130XE has been running without power-down for the best part of a week.

#125 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • 11,163 posts
  • Location:Baden-Württemberg, Germany

Posted Mon Feb 9, 2009 4:22 AM

yeah. Went into the kernel code, too... but haven't tried that yet on my 130xe PAL plus 800XL pal tonight.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users