Ever wanted to reset a SNES with the controller?

[poorstudenthobbyist]

No?

Me neither. But I made a circuit that lets you do it.

Hard to make? Not really. Is it neat? Kinda. But is it helpful? Barely.
Naturally that means I'll probably document it on my site for a few people to look at briefly at some point.

[Nikku4211]

Actually, this is a cool idea, since I play my SNES games on my bed while the console itself is on the other side of my bedroom.

[lidnariq]

Had a friend in college who really wanted this for ... some game ... on his NES. Don't remember which game it was that he'd wanted to reset it rather than go through the menus.

Looks like you've got two serial-to-parallel shift registers, appropriate logic (since the on-the-wire signal is active low, maybe an OR gate) and ... some kind of one-shot, like a 555 or a 74'123.

[poorstudenthobbyist]

Actually, this is a cool idea, since I play my SNES games on my bed while the console itself is on the other side of my bedroom.

Yeah, it's got its uses! Paired with my wireless SNES controller I made like five years ago, there's some good laziness potential here haha. I just don't normally find myself resetting all that much.

Looks like you've got two serial-to-parallel shift registers, appropriate logic (since the on-the-wire signal is active low, maybe an OR gate) and ... some kind of one-shot, like a 555 or a 74'123.

I'll draw out a schematic when I get a chance and post it here, but you've got it mostly right. A basic description:

- Two 74HC595 shift registers to decode serial controller data to parallel, grabbed from controller PCB on the front of the console.
- Wired outputs of shift registers corresponding to the buttons for the reset function to OR gates (74HC32) to create one output that would activate when (at least) Start+Select+L+R were pressed (but you can obviously choose whatever button combo you want).
- Took this combined output to trigger an edge-triggered monostable 555 circuit, with output used to pull pin 26 on the SNES cartridge connector (/RESET) to GND for ~0.25 seconds. Important that it is edge-triggered - a normal one-shot will hold the reset line down until you cycle power, since the trigger never gets un-triggered
- Logic inversion and miscellaneous transistors used where necessary.
- Only five wires from the controller input PCB and one wire from pin 26 on cartridge connector were needed.

Ultimately a little PCB that sits on top of the controller port PCB would be easy - only need to route a wire from the cart connector to the board.

I did notice a bit of trouble with my multicart, sometimes the 555 wouldn't trigger immediately, I think there's some interaction on the /RESET line I need to investigate, might be screwing up the RC on the 555. It does work though, just a little glitchy. No problems on normal carts.

[Nikku4211]

Actually, this is a cool idea, since I play my SNES games on my bed while the console itself is on the other side of my bedroom.

Yeah, it's got its uses! Paired with my wireless SNES controller I made like five years ago, there's some good laziness potential here haha. I just don't normally find myself resetting all that much.

Now we just need to give the SNES some wi-fi and call it the SCES Z: Super Corona Entertainment System for gen Z.

[poorstudenthobbyist]

Here's the schematic. Only real notable thing that I didn't mention was using one of the four unused pins on the shift register to keep the 555 un-triggered. At start-up, the shift register pins start out at GND, so as soon as you turn on the console, the circuit thinks you have every button pressed. So you gotta disable that until the shift register starts up. I used a NOR gate to invert the signal just cause that's what was convenient.

[calima]

Peak laziness. I recall someone asking for that for the N64, and having the same reaction. Jesus people, you muricans so fat you can't walk three meters without having a heart attack.

[Gilbert]

Peak laziness.

But but but this is one of the innovations of the PC-Engine!
The console did not come with a reset button and intentionally encouraged game developers to implement (soft) reset with controller input.

It's debatable whether this was a good idea though, as its combination (Select + Run) was very easy to (accidentally) pull off and expect destruction of friendships in competitive multi-player games when one of the players decides to rage reset the game!

[poorstudenthobbyist]

Peak laziness. I recall someone asking for that for the N64, and having the same reaction. Jesus people, you muricans so fat you can't walk three meters without having a heart attack.

or or or we're so resourceful that we'll spend a few hours making a device to improve our standard of living by an infinitesimal amount!
No, wait, that's just what engineers do

[tepples]

If it were "hold Select+Run for 60 frames", or it were I+II+Select+Run like the gesture in Game Boy games and NES falling block games, it wouldn't have been so easy to trigger by accident.

[Pokun]

Unfortunately the official code, which is part of the official joypad reading routine, is used almost universally by most games. It requires holding RUN and and then edge-triggering SELECT, but there is no delay and is still very easy to do on accident. I have done it several times myself as part of a kind of tic that just flew into me. Not fun.

Code: Select all

;joyena       - bitmap mask of which pads 1~5 are allowed to perform soft reset
;joy          - input states for pads 1~5, read for button hold actions
;joytrg       - 0-1-transitions for pads 1~5, read for button trigger actions

pad_read:
...

.soft_reset_check:
  clx
.loop_sr:
  lda <joyena
  and .sreset_tbl,x
  beq .next              ;if pad not allowed to perform soft-reset, next pad
  lda <joytrg+0,x
  cmp #$04
  bne .next              ;if SELECT not newly pressed, next pad
  lda <joy+0,x
  cmp #$0C
  bne .next              ;if not holding RUN and pressing SELECT, next pad
  jmp [$FFFE]            ;else, soft-reset
.next:
  inx
  cpx #$05
  bcc .loop_sr           ;if not all pads are tested, test next pad

  rts
  
.sreset_tbl:             ;table that is compared with joyena
  .db $01,$02,$04,$08,$10

This is from my own code (pceas/nesasm syntax), but I'm pretty sure it's about identical to the official routine.

Ever wanted to reset a SNES with the controller?

Never. Isn't that what the RESET button is for? It should be big enough to poke with the controller end.

[Gilbert]

If it were "hold Select+Run for 60 frames", or it were I+II+Select+Run like the gesture in Game Boy games and NES falling block games, it wouldn't have been so easy to trigger by accident.

Yeah, it should be a good idea if it is not that easily triggered, and it's actually in the game code, so any game developer can change this in their games if they want.
But as Pokun pointed out the quick "Select + Run" combo was the official way to do this on the system and it's in the code of the official dev. kit, so at least 90% of games still did that unfortunately.

[poorstudenthobbyist]

Here's a fun problem.

So, when I do this with my original Link to the Past cart, it works fine.
When I do this with Link to the Past on my custom board, it works fine.
When I do this with Sim City 2000, it works fine.
When I do this with Tales of Phantasia, it works fine.

But... when I do this with Donkey Kong Country, the shift register input is, well, shifted by one button. Usually. Sometimes for a split second, it'll snap back to a normal position (you can actually see me struggle with this in the video - I thought I wasn't pressing all the buttons at once, but I was actually hitting the buttons just fine, it just wasn't doing it correctly until I was holding it down long enough that it glitched to the right point).

So when this happens, Up becomes Start, and Start becomes Select, etc. Except... this behavior doesn't happen in the actual game. The game plays perfectly fine, no jumbled inputs. It's just the output of MY shift registers.

However.... checking on an oscilloscope shows absolutely no difference in the data coming into the shift register. Just the output pins. And just on MY shift registers. Trigger on the latch pulse, checking the datastream. All input is the same between games.

The behavior doesn't change even if I disconnect the /RESET line - so I'm not even directly affecting any signals on the SNES itself. I'm only reading the controller data, and turning on some LEDs.

Soooo I dunno what's going on. I've got decoupling caps all over the place, and the signal on the scope doesn't look noisy at all. The ONE thing I noticed, is that Link to the Past for example, takes a while to start polling for controller data. Donkey Kong Country starts polling nearly as soon as you turn on the console. There might be something there.

It's not the worst thing in the world (thankfully it's not messing up the button inputs on the SNES, that'd be a real problem), but I mean it's weird that it only happens with certain games. DKC2 does the same thing.

[lidnariq]

If this were the NES instead of the SNES, I'd wonder about the exact reading pattern, since the NES always an asynchronous "load" signal and the shift register has to work with that. But the SNES almost always uses the auto-read functionality, loading in 16 bits on all four players...

So even though I think it unlikely, how does the STROBE pin behave on DKC vs other games?

[poorstudenthobbyist]

By strobe, do you mean what I label as "latch" in my schematic?
My oscilloscope shows the exact same traces when measuring the latch and data pins, triggering on latch, no matter what game it is. Unless you mean a different pin from the SNES console and not on the controller port.

Unless of course something is changing between latch pulses, and I'm missing it on the scope.