Rybags Posted March 22, 2009 Share Posted March 22, 2009 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. Quote Link to comment Share on other sites More sharing options...
ijor Posted March 22, 2009 Share Posted March 22, 2009 (edited) 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 March 22, 2009 by ijor Quote Link to comment Share on other sites More sharing options...
Rybags Posted March 22, 2009 Share Posted March 22, 2009 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. Quote Link to comment Share on other sites More sharing options...
Rybags Posted March 22, 2009 Share Posted March 22, 2009 ... 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"). Quote Link to comment Share on other sites More sharing options...
Bryan Posted April 23, 2009 Share Posted April 23, 2009 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. Quote Link to comment Share on other sites More sharing options...
Rybags Posted April 24, 2009 Share Posted April 24, 2009 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. Quote Link to comment Share on other sites More sharing options...
ijor Posted April 24, 2009 Share Posted April 24, 2009 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. Quote Link to comment Share on other sites More sharing options...
Bryan Posted April 24, 2009 Share Posted April 24, 2009 (edited) Even if we don't need to decipher Antic, I'd love a big picture of the chip! (actually, Pokey and GTIA too!) Edited April 24, 2009 by Bryan Quote Link to comment Share on other sites More sharing options...
Rybags Posted April 24, 2009 Share Posted April 24, 2009 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. Quote Link to comment Share on other sites More sharing options...
Rybags Posted April 24, 2009 Share Posted April 24, 2009 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. 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. Quote Link to comment Share on other sites More sharing options...
ijor Posted April 24, 2009 Share Posted April 24, 2009 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. Quote Link to comment Share on other sites More sharing options...
atariksi Posted July 26, 2009 Share Posted July 26, 2009 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. 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. Quote Link to comment Share on other sites More sharing options...
Rybags Posted July 26, 2009 Share Posted July 26, 2009 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). Quote Link to comment Share on other sites More sharing options...
atariksi Posted July 26, 2009 Share Posted July 26, 2009 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)? Quote Link to comment Share on other sites More sharing options...
Rybags Posted July 26, 2009 Share Posted July 26, 2009 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. Quote Link to comment Share on other sites More sharing options...
Bryan Posted July 26, 2009 Share Posted July 26, 2009 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. Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted July 26, 2009 Share Posted July 26, 2009 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 Quote Link to comment Share on other sites More sharing options...
potatohead Posted July 26, 2009 Share Posted July 26, 2009 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. Quote Link to comment Share on other sites More sharing options...
atariksi Posted July 27, 2009 Share Posted July 27, 2009 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. Quote Link to comment Share on other sites More sharing options...
potatohead Posted July 27, 2009 Share Posted July 27, 2009 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) Quote Link to comment Share on other sites More sharing options...
fox Posted January 13, 2010 Share Posted January 13, 2010 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? Quote Link to comment Share on other sites More sharing options...
ijor Posted November 16, 2010 Share Posted November 16, 2010 Back to the decapping... Yep, it's about time. ANTIC revision E: Quote Link to comment Share on other sites More sharing options...
Bryan Posted November 16, 2010 Share Posted November 16, 2010 Very cool. Thanks! Quote Link to comment Share on other sites More sharing options...
Rybags Posted November 16, 2010 Share Posted November 16, 2010 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 ? Quote Link to comment Share on other sites More sharing options...
fox Posted November 16, 2010 Share Posted November 16, 2010 Cool picture, but I'd prefer schematics. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.