SavagePencil
Posts: 70
Joined: 13 Apr 2018, 17:02

Suggestion for an improved In-Game Reset?

08 Jul 2019, 17:21

Cribbing a bit from how the UperGrafx appears to do it, would it be possible to do the in-game reset detection in the BIOS/System Card screens instead of attempting to steal cycles at runtime? To be clear, the user experience here would be:

1. User holds Run and presses Select.
2. The game's normal reset logic kicks in here. The SSDS3 isn't doing anything.
3. User goes back to the System Card screen.
4. IGR logic engages for the System Card and sees them continuing to hold the buttons for X frames and then jumps back to the SSDS3 menu.

What I'm not sure of is how this would work with HuCard emulation. I don't know if the standard reset logic gives the BIOS a chance to kick in, or if a HuCard reset is just a "jump to $0000."

Anyway, it's food for thought. It could potentially make IGR consistent.

User avatar
neodev
Posts: 291
Joined: 09 Apr 2018, 14:47

Re: Suggestion for an improved In-Game Reset?

09 Jul 2019, 13:42

Yes, athough that will only work for CD games. HuCard games don't have a BIOS or common routines that check Start + Select for reboot. Some games do that, some other don't, but they use their own code for that.
Also the intention of IGR is that in the future, an in game menu could be added, with cheats, savestates and so on, but it first needs a stable controller capture code.

SavagePencil
Posts: 70
Joined: 13 Apr 2018, 17:02

Re: Suggestion for an improved In-Game Reset?

09 Jul 2019, 15:33

The current IGR is stealing cycles on VBlank, is that right? I’m guessing you need about a dozen instructions to preserve context, check the controller state, branch, and restore context. Is that right?

User avatar
neodev
Posts: 291
Joined: 09 Apr 2018, 14:47

Re: Suggestion for an improved In-Game Reset?

09 Jul 2019, 16:56

well, not exactly vblank. IGR takes over NMI vector. What it does every 2 seconds is checking the VSYNC line on the cart and when it goes low to high (end of vblank), it signals an NMI and hijacks the NMI vector (that games don't use, but just in case, only hijacks it while it keeps the NMI line down). The NMI handler is overlaid on the ROM area, and pushes A to stack, reads the input port and if start + select are pressed, signals a value inside the fpga, then checks if the value was signalled before and if so, that means start+select was hold for 2 checks (between 2 and 4 seconds), then resets to the menu. If they aren't pressed, A is popped, and returns from nmi.

SavagePencil
Posts: 70
Joined: 13 Apr 2018, 17:02

Re: Suggestion for an improved In-Game Reset?

09 Jul 2019, 17:20

That makes sense. Instead of returning, could the NMI handler inject a HALT instruction (can't remember the 6502 mnemonic) to pause things if Start + Select were detected? Or is the NMI interrupt vector itself what causes the instability?

Shame that the controller pins aren't available on the expansion bus.

User avatar
neodev
Posts: 291
Joined: 09 Apr 2018, 14:47

Re: Suggestion for an improved In-Game Reset?

09 Jul 2019, 17:36

I still don't know what's exactly causing the issue. As it's random, I can't set a trigger on the FPGA an analyze the signals or trace the execution. Maybe it's altering the sync and games that use hsync interrupt miss one and fail, or maybe modifying the gamepad registers cause some trouble with the values expected in the game, I don't know yet.

Return to “Super SD System 3 General Discussion”