Here's a circuit to allow you to pause an Atari 2600: http://www.victortrucco.com/Atari/AtariPausa/EsquemaPausa.jpg
(Full article at http://www.victortrucco.com/Atari/AtariPausa/atariPausa_en.asp)
I'm pretty good at understanding / designing logic circuits, but still a little sketchy on all the implications of capacitors and some other analog effects. Usually if I stare at a logic circuit schematic long enough, I'll eventually figure it out, but this one has me stumped.
An unmodified console essentially has pins 2 & 3 of the jumper bridged. Normally a pin on the TIA chip will briefly halt the CPU every so often by bringing the RDY pin low (for DMA or memory refresh, not 100% sure). Since there are only certain windows of time where it's valid to deassert RDY, the circuit takes advantage of the existing operation and waits for the TIA to pull the line low, and then doesn't let it go back high if the switch is closed. Open the switch back up, and gates C and D should begin passing the TIA output through to the CPU again.
The only thing I can't figure out is how pin 2 is ever pulled hi. It looks to me like diode D4 will allow the switch to pull the pin lo, but should block current flow in the opposite direction so that pull-up R2 can't do its job. I'm willing to accept that it could initially be high based on less-well-defined behavior of the logic gates when power is applied, and the cap would help hold a steady bias… but I wouldn't mind hearing comment on that as well.
Supposedly this circuit works, and many have implemented it… But the reason I'm looking into it is that a friend just built the circuit as shown (twice), and it's not working for him. The Atari works fine when powered up with the switch open, and it pauses when the switch is closed. But never comes out of pause when the switch is opened. And that's exactly what I would expect from this circuit, so it makes me think maybe I'm not too far off.
Or is there something about the circuit that allows the pin to be pulled high that I'm just missing? Is this a borderline case where it may or may not work depending on the specific components used?
A couple other small points I'd like to check my understanding of:
- Function of pull-down R1… Diodes D1 and D2 only allow the TIA and NAND B output to pull pin 1 input hi, so this biases it lo
- Purpose of pull-up R3… Perhaps the TIA output is open collector and RDY pin is pulled hi internally… so this is needed to bias this node hi?
- Purpose of C1… Probably debounce
- Choice of values for R1 / R3… Any obvious reason R3 is 1.5K and R1 is 1K? IF TIA output is open collector, these form a voltage divider, I'm thinking not sufficient to hold pin 1 input low. If the TIA pin is always driven, these values shouldn't matter much. Are the resistors perhaps helping to set the initial state of the circuit?
EDIT:
- is D4 even needed? Shouldn't this work fine if D4 is bridged?
Best Answer
I've not personally built this circuit, but I understand the theory behind it. The other answer correctly notes that it relies upon the default-pullup behavior of TTL logic; when using other logic families, it may be necessary to add a separate pull-up resistor.
I should further mention that even with such adjustments the circuit may still have a couple of issues--one hardware, and one software. With respect to hardware, the 6507 only allows READY to be asserted or deasserted in particular timing windows relative to the phi0 clock. The circuit as shown will delay the assertion of RDY until a valid moment (the falling edge of RDY received from the TIA) but its deassertion will occur on a random phi0 clock edge. Once the 6507 sees RDY asserted, it will sample it once each clock to determine if it is still asserted. If the level changes just as it is being sampled, it is possible that parts of the 6507's internal logic may decide to proceed to the next processing step while others may not. If the first byte of an opcode was fetched from e.g. address 0x17FF, the RDY line will control whether the next cycle should re-fetch 0x17FF or should advance to 0x1800. It would be theoretically possible that if RDY changes at just the "wrong" time, some bits of the next address would behave as they would if RDY was low and some would behave as if it were high. Oops.
From a software perspective, there are two ways that software can judge the passage of time: the TIA's horizontal position and the RIOT timer. Quite a few games make simultaneous use of both (they set the RIOT at the top of the displayed frame; even if they expect to know where they are during the frame, using the RIOT to time when the beam reaches the bottom will allow a consistent frame rate to be maintained even if code "slips" by a line). If a game looks for the end-of-frame time with something like:
and if the branch crosses a page boundary, it's possible that the code may hang there because once the RIOT has counted to zero in divide-by-64 or divide-by-1024 mode, it will switch to divide-by-one mode. If that had occurred and the RIOT reached the code when the LDA would read e.g. 21, then the next read would occur 8 cycles later so it would read 13, then 5, then 253, 245, 237, 229, ..., 21, 13, 5, 253, etc.
I do not doubt that there are many games with which the circuit will work fine most of the time, though I'd expect the hardware issue to crop up occasionally. Trying to use the circuit to pause the game so you can fetch your camera to photograph your world-record-breaking performance, however, may not be the best idea, since it may pick that moment to fail.