TIA Schematics and Timing

timali · January 15, 2006

I think some of these questions are best suited for this forum:

Hello all. I've been writing this 2600 emulator for a while now, and I've been looking at the TIA schematics to resolve som subtle timing issues when writing the TIA registers during the active scanline. I do have some questions regarding certain gate structures in the schematics, the phase of all the clocks in the system, and the write timing of the 6502 to the TIA in general. Is this the appropriate place to ask such things, and if so, is there anyone here who may know these things? I've read many documents on the Web describing the TIA, but unfortunately many seem contradictory, or simply do not have this kind of detail. Thanks.

1000583[/snapback]

You might get somewhat better discussion on the emulation forum, though your questions span multiple disciplines so it's not clear where they best belong.

Doing a 2600 emulator is hard, because programmers push the system beyond its original design. There are many things which in the original design would have been "don't-care"s, but since programmers have found that some of them behaved in a predictable and useful (albeit sometimes strange) fashion those behaviors now need to be matched precisely.

I think Z26 is probably pretty good, though there are a few things I know of where its emulation is off:

-1- The "READY" line on the 6507 affects read accesses only, not write accesses. On real hardware, an "INC WSYNC" performed near the start of a scan line will behave the same as "STA WSYNC". Performed right near the end, it may cause code to start one cycle later than it would with the "STA". On Z26, "INC WSYNC" will delay code execution until the start of the scan line AFTER the next one. I know of no games that rely on this behavior except for programs that test whether they're running under emulation.

-2- Changing NUSIZx during the actual display of a sprite will change its size mid-draw. The only game I know of that makes use of this is Meltdown.

-3- If a RESPx or RESMx performed near the end of a scan line, the first "copy" of player or missile in question will not be displayed until the electron beam has done a nearly-full sweep. If the first copy of a player or missile wraps, the portion that wraps will be displayed in Z26 even though real hardware would not display it.

In general, though, I'd suggest that if you try to match Z26 you won't be too far off.

1000597[/snapback]

I have heard that Z26 is very accurate, so I have been using it as a reference. Thanks for pointing out the differences between Z26 and the real hardware, as I do not have access to a real 2600 (lost my ebay bid...). Do you know of any other differences between Z26 and the real hardware?

I knew about the read/write issue with the RDY line, and it's a good thing many programs don't rely on it, because I didn't emulate it when I was writing the CPU core. I did emulate some of the extra IO R/W the 6502 does like when it executes INC $1234. First the data at $1234 is read, then the original data is actually written back $1234, and then the incremented data is written back to $1234. Does anything use these extra reads/writes that you know of?

Issue 2) and 3) that you mention are exactly the kind of thing I'm having trouble with because I don't have a real Atari to test, and who knows if Z26 does it perfectly or not. That's exactly why I'm tring to base my emulator straight from the TIA schematics.

One simple and silly question I have is that if I do a RESM0 and then a RESP0 after a STA WSYNC with no HMOVEs anywhere, according to the Stella Programming Manual, the objects should appear at the first pixel of the next scanline. Testing with Z26 showed the missile to appear on the third pixel, while the player appeared on the fourth. Looking through the TIA schematics does show a delay of 2 CLK after the START signal for missiles, and 3 for players, but Stella P.G. makes no mention of this. Is this behavior indeed correct?

Another issue is with changing the playfield while it is being drawn. My original implementation changed the playfield bits as soon as they were written, but Yar's Revenge showed errors doing this. Testing with Z26 showed that while the playfield registers may be modified at any time, actual graphics output reflecting these changes only ever occurred every 4 pixels, and the delay amount (4, 8, or even 12 pixels later) varied depending on the exact clock cycle. The TIA schematics show that the output from the playfield section is gated by the HQ1 and the HQ2 clock, which would indeed result in this behaviour. Unfortunately, I found a post somewhere directly contradicting this saying that a playfield update can reesult in partial playfield blocks being drawn. Now I'm not sure what to believe. (By the way, implementing the HQ1 and HQ2 gating algorithm fixed YAR's revenge.)

It also seems that modifying a color register takes visible effect on the next pixel after the write. Is this true?

1000778[/snapback]