timali

I wouldn't be surprised. If it weren't, a lot of games would be broken. Hence I'm pretty sure it's correct. This one is actually interesting. First off, hardware will never show fractional playfield pixels since they are latched every 4 clocks. However, I believe there is a race condition on at least one playfield pixels; on real hardware, the winner is not consistent. At least that was TJ's explanation for a screen anomoly in THRUST which seems to be affected by temperature. COOL! This was actually one of the detailed hardware questions I had! According to my interpretations of the schematics, the data coming from the playfield section is latched on the falling edge of H@1. The data it uses comes directly from the data bus if CPU @2 is high because the playfield latches are transparent in this state. Unfortunately, the CPU does not guarantee valid data on the data bus until the falling edge of CPU@2, so if H@1 falls low while the CPU@2 remains high, invalid data is used to generate the playfield output. I think this happens every third playfield pixel or so. I believe you answered one of my questions with this. Thank you! As the author of Strat-O-Gems, I will state that Z26 emulates the color changes pixel-perfect; if it didn't, Strat-O-Gems would not work properly. 1000846[/snapback]

I think some of these questions are best suited for this forum: 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]

I think some of these questions are best suited for this forum: 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]

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?

I'd like to ensure my understanding of the system clocks is accurate. I can upload a timing diagram later, but for now, here's how I understand it: The CPU phase 2 clock (Q2) is aligned with the TIA color clock (OSC or CLK) as shown on the Stella's Programmer manual pae 46. To summarize, the rising edge of Q2 happens in a valley of CLK. Then CLK rises, falls, and rises. Q2 falls to 0 in the middle of this CLK high, then CLK drops 0, then high, then low, and the whole thing repeats. Now by looking at the write timings on page 47, I see that the CPU does not present valid data on the bus until somewhere in the middle of the high portion of Q2, and so am I correct in concluding that the actual write is issued on the falling edge of Q2? I assume the main TIA horizontal timing clocks (HQ1 and HQ2) are as Andrew Towers describes in his "TIA Hardware Notes: A Small Opus on the TIA." He describes the shapes of these pulses, but not their phase with respect to the other clocks. Because HQ1 and HQ2 are derived from CLK, I assume that the phase is such that the rising edge of HQ1 exactly corresponds to a rising edge of CLK. Is this so? Another potential problem is that I can't understand what all the inverters with enables and all the NOR gates with enables do. For example, the CPU phase 2 signal comes in on a pin on the TIA. The first thing it does is pass through a series of inverters, with the ouput of one inverter going to the enable of another. Now if I understand this correctly (a BIG if), then it appears that sometimes the gates will be left in a high Z state. What is the purpose of the inverters/feedback to enable construct? I see something similar with the HQ1 and HQ2 signals. They are derived from dividing the CLK signal by 4 using two flip flops, but right after that they pass through NOR gates, but the enable on this NOR gate is also controlled by another NOR gate. What in the world is the purpose of doing the enable like that?

For detailed questions you should contact Adam Wozniak. He is currently working on a 2600 on a FPGA and I guess he knows every little detail. There is also a mailing list, but its quite silent there... I think Adam has TIA VHDL code available that might answer some of your questions if you take a look at it. http://cuddlepuddle.org/mailman/listinfo/fpga2600 1000687[/snapback] Thanks. I've joined their mailing list and asked some questions. Hopefully I'll hear something back!

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.