The 7800 timing circuit demystifed

[+batari]

I think I've finally correctly mapped out the infamous timing circuit on certain 7800s.

 

Some previous efforts I have found are incorrect, including the one posted on AA here among other places and copied here (sorry, Lab Rat, aka jsoper.)

 

Here is what is correct: The circuit does go in between U11 pin 10 and U4 pin 10. The RC does resemble a high-pass filter and that removing C64 will fix it (the result will be as if the above pins were connected.) Late model units have a 0-ohm resistor between the two pins above, bypassing the circuit. U4 pin 10 goes to A12.

 

What is not correct: The cap does not loop back, it has a resistor to GND, "D1" is not literally D1 but the latched output of the 74174, which is TIAEN (i.e. set 2600 mode).

 

While it does resemble a high-pass filter, that's not quite what's happening. The resistor is 1k and the cap is 100 pF. In order for signals to "pass" (which means here that their logic levels are never marginal or low) by my calculations, they need to be larger than 4.36 MHz. Since no signals will ever "pass," it's not really functioning as a high-pass filter, but a simple RC delay.

 

What it is really doing:

 

When phi2 is high (pin 12 on the schematic), the cap is discharged, and it's charged when it goes low. The function of the circuit is to change A12 from 1 to 0 under certain circumstances.

 

By my estimate, A12 will go low about 600ns after every address change and go back high about 100ns later, which will occur before the next address change.

 

2600 Dark Chambers has a STA $EF7F,x instruction to clear SC RAM. I don't know if this is the problem but it is suspicious. I'm guessing that the problem with early 7800s is they have gate delays on A12. It's possible that these gate delays cause the write timing of the above to miss the data valid window. As I understand, address changes don't always occur at the same time relative to the phi2 clock, and they can be off by ±100ns or so.

 

By making A12 go low before the end of the cycle, perhaps this fixes the write timing or forces a latching of the data while it is still valid. I could be wrong about this.

 

I think the reason that Supercharger and FE don't like the circuit is because they both count address bus changes. Every cycle will cause two address transitions instead of one.

 

The reason I did all this work is because I'm trying to get Harmony to work with this goofy console. Wish me luck.

Edited July 28, 2009 by batari

[GroovyBee]

Thanks for sharing the results of your investigation batari.

[Shawn]

Very nice to finally know exactly what the issue directly is.

[+batari]

I spent the weekend working on Harmony code based on my analysis above and found something that didn't add up. The good news is now everything is working, including Supercharger, FE, and Pitfall II on an evil 7800.

 

As it turns out, only minor changes were needed in Harmony code to account for this.

Edited July 28, 2009 by batari

[+Mitch]

I hate not being able to edit when corrections need to be made.

 

I just gave you permission to edit your first post if you still want to update it.

 

Mitch