Pauser cart?

[+Propane13]

How hard would it be to make a "pause-button" cartridge for the 2600?

 

Something that goes between the cartridge and the system, with a switch on the outside.

 

Seems that the 2 things necessary to do would be:

1) save the current state of the program counter

2) start a counter in internal HW, and poll INTIM repeteadly; see if it changes, if so, then save the amount of time that it ran until it timed out

3) Loop and waste time (some crappy kernal that displays "pause"

 

When the pause switch is flipped again:

1) Restore INTIM to its value

2) Restore PC

3) Go!

 

Seems that paddle information (cap charges) don't make much sense to pull. Not WSYNC/scnaline info, as worst-case, there may just be one screen flip before the next VSYNC-- and that's 1/60th of a part of a frame that's lost.

 

Would something like this even be architectually feasible? Or is my hardware skill lacking?

 

-John

[Urchlay]

How hard would it be to make a "pause-button" cartridge for the 2600?

 

Something that goes between the cartridge and the system, with a switch on the outside.

 

Seems that the 2 things necessary to do would be:

1) save the current state of the program counter

 

How?

 

The only ways I know of to read the program counter on a 6502 are to either trigger an interrupt or perform a JSR.

 

The 6507 hasn't got interrupts, so you can't do it that way... too bad, because this is the kind of job interrupts are tailor-made for.

 

All the following is likely to be impractical or just plain wrong: I've got a programmer's view of the 6507, and I'm not a hardware guy... Still, I might give somebody some ideas (used to call this "brainstorming"), so here goes...

 

What would the switch actually do? All I can think of is that it could enable the ROM in your pause cartridge and disable the ROM in the game cart... but that would just result in the CPU starting to run code in your cart at whatever the program counter happens to point to (effectively, a random jump to somewhere in your code space). Not useful...

 

As far as I know, there's no way to look at the cartridge port pins and tell which fetches are reading code and which are reading data, either...

 

Hm. Here's an idea... your switch causes all fetches from the cart address space to return $EA (the opcode for NOP). Assuming the first read was an instruction fetch, the 6507 would just keep running NOPs. Unfortunately the program counter would keep incrementing... maybe instead of NOPs it could return a JMP that jumps to itself. Or a JSR that jumps to your pause-cart ROM.

 

Still, there's no way to tell code from data... if the game program is loading data from the game ROM, and you return the opcode for NOP or JMP instead of the expected data, you stand a good chance of glitching the game (possibly it would recover).

 

Maybe a better approach would be to modify the console itself: replace the 6507 with a 6502 on a daughterboard (which plugs into the 6507 socket). Most of the 6502's pins would be routed to the same pin on the 6507 socket, but the NMI line would go to your pause switch. The switch would have to stop the 6502 (like WSYNC does), bank in some ROM that replaces the cartridge ROM, and trigger an NMI. The onboard ROM code would have to avoid using any RAM or changing any CPU state (it could be a JMP that jumps to itself)... but it would *also* have to save the program counter somewhere! So you'd have to add some RAM as part of the mod, too. It would end up costing more than the Atari and would require an awful lot of work (which I don't know how to do). So scratch this idea, I guess.

 

Although... STA WSYNC, as I understand it, actually disconnects (or grounds?) the 6507's clock input. Is there any reason your pause switch couldn't just do the same thing? The CPU would just sit there, not running, until you release the switch and reconnect the clock (the TIA would display vertical bars or a blank screen, like it does if you power up an Atari with no cart in it). I don't know, but there may be some limit on how long the 6507 can maintain its internal state without the clock line. I remember someone talking about that on [stella]... This would still be a mod to the console, but a dead simple one (just drill a hole, mount a switch, wire it to the appropriate place, perhaps you'd need to cut a trace or lift a pin somewhere)... assuming it'd work.

 

2) start a counter in internal HW, and poll INTIM repeteadly; see if it changes, if so, then save the amount of time that it ran until it timed out

 

Probaly this isn't really needed. If you can restore the program counter, flags, and registers, the ROM should "recover" on its own (this is based on my experiments with Stella's debugger and "frying" support, real hardware is of course different, disclaimer disclaimer yadayada).

 

Mostly INTIM is used either to time overscan/vertical blanks (in which case, saving it would be pointless: the TV won't wait for the TIA to finish the frame), or for I/O, like sending data to the Atarivox/Savekey (again, the device wouldn't wait for you to finish, if you paused in the middle of I/O).

[mos6507]

I think it's possible but it would take a lot of extra hardware in the cart to analyze what's going on in the VCS.

[supercat]

I think it's possible but it would take a lot of extra hardware in the cart to analyze what's going on in the VCS.

 

It might not be too hard if one expects that the TIM64T etc. locations will be used for nothing other than writing the timer values, they will be written with an STA abs, STX abs, or STY abs instruction, and the Z flag will always be clear. These assumptions probably apply to 99% of the carts out there.

 

When such a memory store is observed, output "D0 FB" on the bus. Start a divide-by-76 counter the first time the circuit is triggered. When the user hits the unpause control, keep outputting "D0 FB" until the divide-by-76 counter is in the same phase as the first time.

[Robert M]

The device should monitor the address lines for for a write to VSYNC with a 1 in bit 1 of the data bus indicating the program is beginning vertical sync. All VCS programs must activate vertical sync this way. If the pause button is being pressed, then the pause device swaps out the cartridge ROM. The next instruction fetch is forced to zero (BRK), and then on the second instruction fetch after the write to VSYNC, the pause ROM is the source for all opcode fetches. This assumes that their are 4 bytes available on the stack.

 

BRK_HANDLER:

PHA ;save A to stack consuming 4th byte. 3 bytes are used by the BRK vector

TXA

TSX

; TODOs: Save the X register copy in A to the stack overwriting the status register copy in the BRK frame.

; - Adjust the return vector for the BRK to return to the correct address in the cartridge ROM also change it to use RTS instead of RTI.

; - Use A and X and no RAM for all pause ROM code.

; - When pause is released, the pause software goes to the write to VSYNC, restores A and X from the stack and jumps to an RTS instruction

; that also triggers the pause hardware to swap out in place of the catridge ROM.

 

NOTE:

If you put a SARA chip in the Pause hardware you can save a copy of the zp RAM thus opening the possibilty of a VCS game genie.

pause the game. Save its state to the SARA ram. Restart play. If you die, pause and restore the game from the Sara RAM. It might not

work for bankswitched games, and definitely not for games with extra RAM.

You could edit the saved RAM image while paused to produce game genie effects. Or save the whole game state to a flash device to restore later.

The pause hardware could insert a blank frame every other frame. Producing a flickering slow motion feature.

There are other possibilities.

 

A big challenge is the mechanical issue of producing a pass through cart. It would need to fit all the different consoles, yet it would be nice to have it latch onto the case of the console for more support.

 

Cheers!

Edited December 13, 2006 by Robert M

[Albert]

This would be very cool if it could be built inexpensively and worked with most games.

 

..Al

[jpfalcon2003]

Would be cool for the harder games like Road Runner or Double Dragon

[D.Yancey]

 

A big challenge is the mechanical issue of producing a pass through cart. It would need to fit all the different consoles, yet it would be nice to have it latch onto the case of the console for more support.

 

Agreed! Some carts are so touchy in the slot that the slightest movement or vibration will crash your game--ie. Activision carts in particular. I had this problem with carts that required touching the console during game play like Starmaster and Ghostbusters.

 

I would recommend putting the actual toggle switch mounted on a cable so you could activate it without disturbing the console.

[Albert]

 

A big challenge is the mechanical issue of producing a pass through cart. It would need to fit all the different consoles, yet it would be nice to have it latch onto the case of the console for more support.

 

Agreed! Some carts are so touchy in the slot that the slightest movement or vibration will crash your game--ie. Activision carts in particular. I had this problem with carts that required touching the console during game play like Starmaster and Ghostbusters.

 

I would recommend putting the actual toggle switch mounted on a cable so you could activate it without disturbing the console.

I don't think you'd easily be able to make a cartridge that could "latch" onto the console as there is such a variety of 2600-compatible consoles (2600, 2600 Jr., 7800, 5200 VCS Adapter, Gemini, Coleco Expansion Module #1, Intellivision VCS Adapter, Sears Telegames II, and so forth..)

 

An infrared or wireless remote control would be pretty neat.

 

..Al

[keilbaca]

 

A big challenge is the mechanical issue of producing a pass through cart. It would need to fit all the different consoles, yet it would be nice to have it latch onto the case of the console for more support.

 

Agreed! Some carts are so touchy in the slot that the slightest movement or vibration will crash your game--ie. Activision carts in particular. I had this problem with carts that required touching the console during game play like Starmaster and Ghostbusters.

 

I would recommend putting the actual toggle switch mounted on a cable so you could activate it without disturbing the console.

I don't think you'd easily be able to make a cartridge that could "latch" onto the console as there is such a variety of 2600-compatible consoles (2600, 2600 Jr., 7800, 5200 VCS Adapter, Gemini, Coleco Expansion Module #1, Intellivision VCS Adapter, Sears Telegames II, and so forth..)

 

An infrared or wireless remote control would be pretty neat.

 

..Al

 

They all have a 6507 in it, that's all that matters when it comes to the pause cart.

 

Now, getting this to work on the brazilian pirates where they use a 6502, that could be a different story.

[+batari]

A cart that displays "pause" would be nice, but all you really need is switch that grounds the CPU's RDY line. Should be a really easy mod.

[YOK-dfa]

Wasn't there some brazilian 2600 clone that had a pause button? Did anyone ever found out how they did it?

[Thomas Jentzsch]

Wasn't there some brazilian 2600 clone that had a pause button? Did anyone ever found out how they did it?

IIRC they used a different CPU (6502 instead of a 6507).

[keilbaca]

Wasn't there some brazilian 2600 clone that had a pause button? Did anyone ever found out how they did it?

IIRC they used a different CPU (6502 instead of a 6507).

 

The Onyx Jr.

 

It used a 6502, and CPUWIZ AFAIK did duplicate the circuit, but to duplicate it, it would cost a good bit ($50 and above), and a lot of work would have to be done to it. It would only work on the 7800, the 7800 uses a 6502 for the 2600.

 

As for grounding the RDY line, data cannot be writing to the RAM, or else the game will get corrupt and you'd have to restart the game. The pause switch above used a circuit to make sure that there was no data writing to the ram before it paused.

Edited December 13, 2006 by keilbaca

[+batari]

Wasn't there some brazilian 2600 clone that had a pause button? Did anyone ever found out how they did it?

IIRC they used a different CPU (6502 instead of a 6507).

 

As for grounding the RDY line, data cannot be writing to the RAM, or else the game will get corrupt and you'd have to restart the game. The pause switch above used a circuit to make sure that there was no data writing to the ram before it paused.

The RDY line does not halt the processor until the write completes. This is how the chip was designed.

[keilbaca]

Wasn't there some brazilian 2600 clone that had a pause button? Did anyone ever found out how they did it?

IIRC they used a different CPU (6502 instead of a 6507).

 

As for grounding the RDY line, data cannot be writing to the RAM, or else the game will get corrupt and you'd have to restart the game. The pause switch above used a circuit to make sure that there was no data writing to the ram before it paused.

The RDY line does not halt the processor until the write completes. This is how the chip was designed.

 

Which pin is it? I'll try it... but I'm almost positive I grounded it before and the whole game just quit.

 

Question... how about if I put a switch in between the RDY pin and the next place in line on the motherboard... would that have any kind of effect?

 

If grounding the RDY line does work... then a cart can be made with a simple circuit and a passthrough grounding the RDY pin, and a switch on the side or back of the cartridge.

Edited December 13, 2006 by keilbaca

[+batari]

Which pin is it? I'll try it... but I'm almost positive I grounded it before and the whole game just quit.

 

Question... how about if I put a switch in between the RDY pin and the next place in line on the motherboard... would that have any kind of effect?

I think that would have the opposite effect, i.e. the CPU wouldn't be allowed to halt even when the TIA tries to (as needed when doing a STA WSYNC.)

If grounding the RDY line does work... then a cart can be made with a simple circuit and a passthrough grounding the RDY pin, and a switch on the side or back of the cartridge.

Worth a try. Looking it up, pin 3 is RDY, and incidentally, pin 2 is GND, so just poke a screwdriver between the 2 pins and see what happens. Don't worry, there's no chance of damage since the RDY line is only driven low and goes high via a pullup.

 

EDIT: Just tried it, and sometimes it works! Though sometimes it doesn't... could just be a debounce problem though.

Edited December 13, 2006 by batari

[keilbaca]

Which pin is it? I'll try it... but I'm almost positive I grounded it before and the whole game just quit.

 

Question... how about if I put a switch in between the RDY pin and the next place in line on the motherboard... would that have any kind of effect?

I think that would have the opposite effect, i.e. the CPU wouldn't be allowed to halt even when the TIA tries to (as needed when doing a STA WSYNC.)

If grounding the RDY line does work... then a cart can be made with a simple circuit and a passthrough grounding the RDY pin, and a switch on the side or back of the cartridge.

Worth a try. Looking it up, pin 3 is RDY, and incidentally, pin 2 is GND, so just poke a screwdriver between the 2 pins and see what happens. Don't worry, there's no chance of damage since the RDY line is only driven low and goes high via a pullup.

 

EDIT: Just tried it, and sometimes it works! Though sometimes it doesn't... could just be a debounce problem though.

 

 

Half the time working is better than none at all >_>

 

I have the perfect Atari I can try this on...

Edited December 13, 2006 by keilbaca

[Albert]

Half the time working is better than none at all >_>

 

I have the perfect Atari I can try this on...

Yeah, but you wouldn't want to take a chance and pause a game you had been playing for a while (and intended to continue playing) unless it was pretty reliable.

 

..Al

[keilbaca]

Half the time working is better than none at all >_>

 

I have the perfect Atari I can try this on...

Yeah, but you wouldn't want to take a chance and pause a game you had been playing for a while (and intended to continue playing) unless it was pretty reliable.

 

..Al

 

Well yeah, it'd be an emergency pause switch.

[+Propane13]

Ok, so this idea of a JSR to capture the PC intrigues me.

 

What if there are 2 banks of code (i.e. an 8K cart).

Bank one is all a JSR to the bankswitch code

 

<START>

ORG $F000

JSR SOMEWHERE

JSR SOMEWHERE

....

 

SOMEWHERE:

LDA $FFF9 ; jump banks

 

JSR SOMEWHERE

JSR SOMEWHERE

....

<END>

 

SOMEWHERE could be defined as NOOP opcodes (i.e. $EAEA).

If this were the case, then when the pause switch is executed, the bank is hardware switched to the new cart, and is suddenly in this new code.

It will either hit a JSR or a NOP.

 

Almost 1/3 case:

JSR SOMEWHERE

 

Almost 1/3 case:

NOP

JSR SOMEWHERE

 

Almost 1/3 case:

NOP

NOP

JSR SOMEWHERE

 

I say "almost" because there is a chance that the cart happens to be at location SOMEWHERE. That's what makes things a little unreliable, but with quite a low probability.

 

So, to mitigate this NOP issue (which gets us close to the PC, but not possibly off by one or two), there could also be a timer circuit to determine how many commands are run on this 4K bank before it gets switched. Based on that number, one or two could be subtracted from the PC.

 

Once in the new bank, save operations could happen to internal RAM on the chip or something (to save a register or the accumulator value), and some graphics could go on screen that say "paused".

 

Or, maybe there's a way with hardware to force a JSR on the data lines, regardless of what's on the PC's address lines. That could force a JSR.

 

Or, maybe I'm just crazy and don't understand hardware too well.

 

Comments?

 

-John

[YOK-dfa]

I have little hardware knowledge of microprocessors, but aren't most of them driven by a timer 'crystal' that generates clockpulses? Would it be a possibility to cut a wire from the clockpulse-generator to the CPU as a pause switch? (has the downside that the entire screen would probably go blank)

[keilbaca]

I have little hardware knowledge of microprocessors, but aren't most of them driven by a timer 'crystal' that generates clockpulses? Would it be a possibility to cut a wire from the clockpulse-generator to the CPU as a pause switch? (has the downside that the entire screen would probably go blank)

 

cutting the clock completely will kill the game.

 

I tried that.

[Uzumaki]

http://www.atariage.com/forums/index.php?s...ost&p=50313

 

Really old post, people have tried for hardware pause with no luck. Software hack to add pause is probably the only option on a 2600.

[+batari]

http://www.atariage.com/forums/index.php?s...ost&p=50313

 

Really old post, people have tried for hardware pause with no luck. Software hack to add pause is probably the only option on a 2600.

Nobody there said grounding the RDY line wouldn't work, just that the TIA kept running so you'd get some stripes and/or noise during pause. Everything goes back to normal once the switch is released. If you turn off the television during pause, this wouldn't matter.

 

I'm going to try a real switch and see if it works any better.