183 replies to this topic

[atariksi]

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.

[ijor]

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.

[UNIXcoffee928]

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

• 

[atariksi]

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.

[carmel_andrews]

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

[ijor]

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.

[atariksi]

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.

[atariksi]

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...

[Rybags]

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

[eru]

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!

[Bryan]

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.

[ijor]

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.

[atariksi]

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.

[atariksi]

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).

[supercat]

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.

[Heaven/TQA]

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".

[ijor]

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.

[atariksi]

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.

[Bryan]

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

• 
• 
• 
• 

Attached Files

•  bry.zip   34.67KB   123 downloads

[Bryan]

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.

[potatohead]

Those pictures are nice.

[Shawn Jefferson]

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

[Rybags]

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

[Rybags]

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.

[Heaven/TQA]

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