Jump to content
JAC!

Internal ANTIC and GTIA schematics

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
... 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").

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

 

post-7804-1240555792_thumb.jpg post-7804-1240555799_thumb.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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

 

post-7804-1240555792_thumb.jpg post-7804-1240555799_thumb.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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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)?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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 ?

Share this post


Link to post
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.

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