Jump to content

Photo

Internal ANTIC and GTIA schematics


183 replies to this topic

#151 Rybags OFFLINE  

Rybags

    Gridrunner

  • 16,000 posts
  • Location:Australia

Posted Sun Mar 22, 2009 9:47 AM

Yep, I remember your post about it... I just wanted to confirm some stuff like the behaviour in certain situations.

I was uncertain about VSync in that I thought maybe Antic sent HSync commands too during those 3 scanlines but it appears it doesn't. But like you stated previously, the Sync component of the Video signal is derived internally in GTIA by HSync XOR VSync.

I've noticed that behaviour to be correct also when you force GTIA's horizontal timing to be upset - VSync still gets generated in the correct place, but the brief pulses back to Blanking Level retain whatever timing you've previously imposed on HSync.

#152 ijor OFFLINE  

ijor

    River Patroller

  • 2,166 posts

Posted Sun Mar 22, 2009 10:18 AM

I was uncertain about VSync in that I thought maybe Antic sent HSync commands too during those 3 scanlines but it appears it doesn't.


ANTIC can't send HBLANK code during VSYNC, at least not without some redesign of GTIA logic. If ANTIC would send HBLANK, then GTIA would not receive VSYNC anymore (there is no AN code for combining HBLANK & VSYNC). So the sync pulses would be altered.

Please note that BLANK and SYNC are different things, SYNC is just a small portion of the blank time. This is true both for HBLANK/HSYNC and VBLANK/VSYNC. What might be a bit confusing is that ANTIC sends HBLANK (not HSYNC), but it send VSYNC (not VBLANK).

But like you stated previously, the Sync component of the Video signal is derived internally in GTIA by HSync XOR VSync.


Yes, and this might be useful perhaps, because you can "simulate" VSYNC with HSYNC and the other way around.

Edited by ijor, Sun Mar 22, 2009 10:42 AM.


#153 Rybags OFFLINE  

Rybags

    Gridrunner

  • 16,000 posts
  • Location:Australia

Posted Sun Mar 22, 2009 10:31 AM

Unsure about simulating VSync. GTIA generates the HSync pulse on demand e.g. you transition from DMACTL=00 to DMACTL=03. I would guess that the HSync pulse itself is of about 8 machine cycles duration which would be pretty close to the 4.7 microseconds +- 0.2 that I have in a specs doc here.

I don't think I've tried it... you might be able to force a continual pulse by toggling DMACTL between 00 and 03 quickly enough.

As for the VSync pulse... you can just set DMACTL to 3, then you can do whatever you want with the luma signal.


Another thing... I'm not 100% certain of this and I don't know if it's even important - there seems to be no "Blank Level" in the A8 video signal... where you'd expect to find it, the outputted signal is the same as Black.

#154 Rybags OFFLINE  

Rybags

    Gridrunner

  • 16,000 posts
  • Location:Australia

Posted Sun Mar 22, 2009 10:58 AM

... you might be able to force a continual pulse by toggling DMACTL between 00 and 03 quickly enough.


Just tried... I kinda forgot about the Refresh DMA upsetting things.

A loop with a whole bunch of STA/STY (3,0) in DMACTL - no good.

Broken lines too with a loop of 10 inline INC $D400 (DMACTL always reads as $FF so it's a cheap "store FF then 00").

#155 Bryan OFFLINE  

Bryan

    Quadrunner

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

Posted Thu Apr 23, 2009 3:27 PM

Back to the decapping...

I would be willing to contribute $$$ to decapping an Antic. Perhaps we could eventually do NTSC/PAL and possibly the two refresh length variations to get an idea of what areas were changed.

#156 Rybags OFFLINE  

Rybags

    Gridrunner

  • 16,000 posts
  • Location:Australia

Posted Thu Apr 23, 2009 7:39 PM

I suspect PAL/NTSC would have minimal difference in Antic... the only difference really is the number of non-display lines before/after VSync.

GTIA is probably a different story altogether - does anyone know how the colour phase inversion is acheived? From my playing around it seems that if you insert the wrong number of extra HSync pulses, you get a situation of the phase inversions being reversed which causes the next frame to have all the wrong colours.

#157 ijor OFFLINE  

ijor

    River Patroller

  • 2,166 posts

Posted Thu Apr 23, 2009 8:22 PM

Back to the decapping...


I agree, but I'd say to wait a couple of weeks more (we waited so long that it should not harm :) ). Curt commented somewhere else he would have some free time next month (May). He didn't mention specifically he would post the ANTIC schematics though.

I would be willing to contribute $$$ to decapping an Antic. Perhaps we could eventually do NTSC/PAL and possibly the two refresh length variations to get an idea of what areas were changed.


We already have funds for a single decap. If we want all the ANTIC versions, then contributions would be welcome. But I agree with Rybags that chances that the differences are the obvious and known ones.

GTIA is probably a different story altogether - does anyone know how the colour phase inversion is acheived? From my playing around it seems that if you insert the wrong number of extra HSync pulses, you get a situation of the phase inversions being reversed which causes the next frame to have all the wrong colours.


Hmm, interesting. Can you post code and a screenshot? Does it happen on the TV (and not just on a capture)?

I can see that something like this could happen on specific scan lines. If you mess with HSYNC, then you could mess with the color burst generation by GTIA. But this should not happen at the "frame level". GTIA has no vertical history, it has no vertical counter, and it has no concept of vertical position whatsoever (except odd and even for VDELAY). Furthermore, each HBLANK pulse on the ANx signals resets the whole GTIA state machine (except again, the even/odd state).

And the color burst is generated on each and every scan. So the only idea that comes to mind is that this have something to do with the PAL phase inversion (the TV gets confused by the wrong HSYNC), and should not happen on NTSC.

#158 Bryan OFFLINE  

Bryan

    Quadrunner

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

Posted Thu Apr 23, 2009 8:30 PM

Even if we don't need to decipher Antic, I'd love a big picture of the chip!

(actually, Pokey and GTIA too!)

Edited by Bryan, Thu Apr 23, 2009 8:32 PM.


#159 Rybags OFFLINE  

Rybags

    Gridrunner

  • 16,000 posts
  • Location:Australia

Posted Thu Apr 23, 2009 8:38 PM

I planned to check what goes on with Colourburst with my 'scope anyway, so I might look into it later. It can only sample at 10 MHz, so that might just be sufficient to see what's going on.

The colour messup occurs with both TV and cap-card. On the TV, it sometimes corrects itself by halfway down, but I found instances of that usually occurred when a HSync train was skewed (ie a "useless" type of field).

I also found it occurs when you insert an extra single HSync pulse - I'll have to experiment to verify that though.

My capture card (like many) combines 2 fields and displays at 25 FPS, so what you see there is more of a striped effect, where on TV it's a case of every second field having the wrong colours.

#160 Rybags OFFLINE  

Rybags

    Gridrunner

  • 16,000 posts
  • Location:Australia

Posted Fri Apr 24, 2009 12:53 AM

Tested phase inversion when fiddling with extra HSyncs - as I suspected, it does invert when you generate extra pulses, so my reckoning is that GTIA must take care of that for us.

On a normal Atari display, the colour signal phase is the same for each scanline for all fields. Remembering here that we have the 288p type display which doesn't conform fully to any official standard.

With normal PAL, we actually have 4 distinctly different fields because of the phase angle diffrence. i.e. for a particular scanline on an odd or even field, it can be phased normally, or inverted.

Phase_error_1.JPG Phase_error_2.JPG

Note the screen is distorted because I've just thrown a HSync pulse in the middle of a scanline. I'm doing this only every second frame, so as to upset the colour phase sequencing from what is expected.
First one is capture card, second one a photo of the TV. Colours should be default background, and border Green.

#161 ijor OFFLINE  

ijor

    River Patroller

  • 2,166 posts

Posted Fri Apr 24, 2009 3:23 PM

Even if we don't need to decipher Antic, I'd love a big picture of the chip!(actually, Pokey and GTIA too!)


Yeah, me too.

Tested phase inversion when fiddling with extra HSyncs - as I suspected, it does invert when you generate extra pulses, so my reckoning is that GTIA must take care of that for us.


I don't think this has much to do with GTIA. It seems to be a pal phase inversion issue, which is not handled by GTIA. It is either related to the board phase inversion circuit, or it is the pal delay line in the display/capture device.

#162 atariksi OFFLINE  

atariksi

    Quadrunner

  • 5,337 posts

Posted Sat Jul 25, 2009 10:44 PM

Tested phase inversion when fiddling with extra HSyncs - as I suspected, it does invert when you generate extra pulses, so my reckoning is that GTIA must take care of that for us.

On a normal Atari display, the colour signal phase is the same for each scanline for all fields. Remembering here that we have the 288p type display which doesn't conform fully to any official standard.

With normal PAL, we actually have 4 distinctly different fields because of the phase angle diffrence. i.e. for a particular scanline on an odd or even field, it can be phased normally, or inverted.

Phase_error_1.JPG Phase_error_2.JPG

Note the screen is distorted because I've just thrown a HSync pulse in the middle of a scanline. I'm doing this only every second frame, so as to upset the colour phase sequencing from what is expected.
First one is capture card, second one a photo of the TV. Colours should be default background, and border Green.


Is there a way to run a PAL Atari in America? I want to see the PAL color mixing/altering effect. Perhaps, I have to swap out the GTIA chip.

#163 Rybags OFFLINE  

Rybags

    Gridrunner

  • 16,000 posts
  • Location:Australia

Posted Sat Jul 25, 2009 11:00 PM

Supposedly, PAL colour phase inversion is handled external to GTIA...

Maybe you could build a board with a PAL colour circuit on it. Luma should remain the same. Then just run it through S-Video.

What you'd end up with is a kind of "PAL60" output, of course though it would still be 525 lines. Some TVs are tolerant to off-spec signals such as that. I've created custom modes on my computer's video card that are out of spec and the TV handled them OK.

Capture cards also tend to be tolerant if you go off-spec a bit.

I think if you just put a PAL Antic in (remember, it handles the frame rate, number of scanlines), you'd just end up with PAL resolution at slightly faster timings, but still in NTSC signal format (regardless of which GTIA you run).

#164 atariksi OFFLINE  

atariksi

    Quadrunner

  • 5,337 posts

Posted Sat Jul 25, 2009 11:14 PM

Supposedly, PAL colour phase inversion is handled external to GTIA...

Maybe you could build a board with a PAL colour circuit on it. Luma should remain the same. Then just run it through S-Video.

What you'd end up with is a kind of "PAL60" output, of course though it would still be 525 lines. Some TVs are tolerant to off-spec signals such as that. I've created custom modes on my computer's video card that are out of spec and the TV handled them OK.

Capture cards also tend to be tolerant if you go off-spec a bit.

I think if you just put a PAL Antic in (remember, it handles the frame rate, number of scanlines), you'd just end up with PAL resolution at slightly faster timings, but still in NTSC signal format (regardless of which GTIA you run).


Perhaps, I can buy a PAL Atari from Ebay and run the output through some sort of converter? It's easy to convert the power supply.

What's the 288P refer to? 288 visible scanlines of the 312? So NTSC is 240p (240 of 262)?

#165 Rybags OFFLINE  

Rybags

    Gridrunner

  • 16,000 posts
  • Location:Australia

Posted Sat Jul 25, 2009 11:32 PM

You need to leave the signal from the PAL computer alone... remember, it's the TV receiver that does the PAL colour blending, not the computer.

288P is just a defacto phrase referring to the 288 scanline progressive that PAL home computers/consoles tend to output. In the NTSC case, you could say 240P or 262P.

As for the power supply - probably not worth the bother. Just use one of your existing ones. Although I'm not sure of the case for 400/800/1200XLs which have 9V AC... possibly the internal power board is slightly different between PAL/NTSC.

#166 Bryan OFFLINE  

Bryan

    Quadrunner

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

Posted Sun Jul 26, 2009 11:04 AM

Is there a way to run a PAL Atari in America? I want to see the PAL color mixing/altering effect. Perhaps, I have to swap out the GTIA chip.


Get a monitor that handles NTSC and PAL. The JVC TM-A13SU shows up on ebay quite a bit.

#167 SeaGtGruff OFFLINE  

SeaGtGruff

    Quadrunner

  • 5,566 posts
  • Location:South Carolina, USA

Posted Sun Jul 26, 2009 12:19 PM

288P is just a defacto phrase referring to the 288 scanline progressive that PAL home computers/consoles tend to output. In the NTSC case, you could say 240P or 262P.

I think 240p would probably be used for NTSC home computers or game consoles, as the number given in this type of notation is usually for the number of scan lines containing picture information, not the total number of lines in the frame.

Michael

#168 potatohead OFFLINE  

potatohead

    River Patroller

  • 4,404 posts
  • Location:Portland, Oregon

Posted Sun Jul 26, 2009 3:12 PM

Most capture cards display PAL. The one I use does, and it displays a full interlaced frame.

The only downside is a bit of latency, not good for gaming, but plenty good for development / tech related uses.

#169 atariksi OFFLINE  

atariksi

    Quadrunner

  • 5,337 posts

Posted Mon Jul 27, 2009 1:16 PM

Most capture cards display PAL. The one I use does, and it displays a full interlaced frame.

The only downside is a bit of latency, not good for gaming, but plenty good for development / tech related uses.


Perhaps, the live video window may work in PAL mode on these certain Thinkpad models. They do an overlay rather than digitize the picture so it should be able to do 25/30fps.

#170 potatohead OFFLINE  

potatohead

    River Patroller

  • 4,404 posts
  • Location:Portland, Oregon

Posted Mon Jul 27, 2009 1:27 PM

Most capture cards display PAL. The one I use does, and it displays a full interlaced frame.

The only downside is a bit of latency, not good for gaming, but plenty good for development / tech related uses.


Perhaps, the live video window may work in PAL mode on these certain Thinkpad models. They do an overlay rather than digitize the picture so it should be able to do 25/30fps.


Actually, I'm using a USB HD capture device. The thing does 60FPS+, and can show full interlaced video properly, dot crawl and all. The latency comes from the OS level buffering that is required. It's about 150-300ms.

In a preview window, for adjusting the device properties, there is no latency, but it's small.

For a lot of things, that's not a big deal. For code testing, hobby stuff, it's actually pretty great. I use it with the VCS, Color Computer 3, and various Propeller boards. Signal tolerance is great, and it will render out of spec stuff very nicely. (good for driver code tweaks)

#171 fox OFFLINE  

fox

    Moonsweeper

  • 255 posts
  • Location:Poland

Posted Wed Jan 13, 2010 2:41 AM

Those files originally came from me from www.atarimuseum.com The scans are low res and not of the best quality.

I've been meaning to do newer updated scans of all of the chip docs and repost them.


Any news?

#172 ijor OFFLINE  

ijor

    River Patroller

  • 2,166 posts

Posted Mon Nov 15, 2010 8:48 PM

Back to the decapping...


Yep, it's about time. ANTIC revision E:

AnticWholeDieBw.jpg

#173 Bryan OFFLINE  

Bryan

    Quadrunner

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

Posted Tue Nov 16, 2010 5:43 AM

Very cool. Thanks!

#174 Rybags OFFLINE  

Rybags

    Gridrunner

  • 16,000 posts
  • Location:Australia

Posted Tue Nov 16, 2010 5:48 AM

Now for what's what... I bet the large block on the left is the charcode/bitmap data buffer.

Any idea what the total component count would be? Somewhere around 3-5,000 ?

#175 fox OFFLINE  

fox

    Moonsweeper

  • 255 posts
  • Location:Poland

Posted Tue Nov 16, 2010 7:06 AM

Cool picture, but I'd prefer schematics.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users