SD System 3 Randomly Resets

monads

Mr. Big's Thug
10 Year Member
Joined
May 16, 2008
Posts
197
Since I haven't thoroughly tested HuCards it's happened a few times playing CD-ROMS (i.e. Super Raiden & Spriggan) where the system will randomly reset to the main menu. It's as if it looses connection with reading the card after some levels passed.

I'm wondering if it's my file structure or size of sd card? Files are organized by alphabet and by HuCard or CD-ROM (cd game files in each individual folder) using an 256GB Samsung Evo MicroSD card. Anyone else experienced these random in-game resets???
 

ShootTheCore

Bead Banger
Joined
Feb 11, 2015
Posts
1,498
Try disabling the In Game Trigger-it causes problems with some games at the moment. Also, you don't say what kind of PCE you're using, but if you're using a SuperGrafx, flip the compatibility switch in the back-right corner.
 

monads

Mr. Big's Thug
10 Year Member
Joined
May 16, 2008
Posts
197
Thanks for the response! Yes, I do have the In-Game Trigger enabled! I'll disable it. Currently using an unmodded original Core Grafx II system.
 

Yodd

Iori's Flame
20 Year Member
Joined
Feb 7, 2002
Posts
8,214
Thanks for the response! Yes, I do have the In-Game Trigger enabled! I'll disable it. Currently using an unmodded original Core Grafx II system.

Yeah, I have had some wonky side effects with the in game trigger enabled as well. With in enabled, on my copy of Ys III, it plays through the intro and gets to the Continue/New game screen and then just locks up. Turn that option off and everything is groovy.

Def. disable it.
 

SavagePencil

Crazed MVS Addict
Joined
Oct 17, 2005
Posts
135
Also: playing some games on the SuperGrafx can cause resets when it is in "SuperGrafx mode." If you flip the switch to "Compatible Mode" you should be good.

Rayxanber III resets after the second boss in SGX mode, for example.
 

monads

Mr. Big's Thug
10 Year Member
Joined
May 16, 2008
Posts
197
Confirmed!!! Disabling the "In-Game Trigger" appears to have worked not affecting random in-game resets for certain CD-ROMS during play through. Thanks guys!!!
 

neodev

Neosd Tech
Joined
Nov 28, 2016
Posts
256
Confirmed!!! Disabling the "In-Game Trigger" appears to have worked not affecting random in-game resets for certain CD-ROMS during play through. Thanks guys!!!

Confirmed!!! Disabling the "In-Game Trigger" appears to have worked not affecting random in-game resets for certain CD-ROMS during play through. Thanks guys!!!

Let me explain how in game trigger works and why there is a big warning and it may cause issues.
In order for the trigger to work, custom code must be executed on the cpu. At first, I thought I could trap the gamepad read & writes on the fpga and do that transparently, without any extra code executed, but as the gamepad ports are directly connected to the cpu, they read and written value doesn't appear on the bus, so we had to move to a neosd like mode.
The fpga periodically signals the NMI line of the cpu right after exiting vblank. No games or accesories use the NMI signal, so it was 'safe' to use. When the fpga sees an access to the nmi handler address (source of issues 1) that is logical address FFFC, if I remember correctly, that is physical address 1FFC (sourde of issues 2), it swaps the first memory bank to an internal one containing a piece of code that reads the input port (source of issues 3), checks if start+select are pressed and if it isn't just jumps back to the original vector (source of issues 4), disabling the overlay.

So, in well behaved games, it works as intended, but there are several sources of issues:

1) games unintentionally reading from physical address 1FFC will erroneously trigger the overlay, their bank 0 will get replaced, but because it was not an actual nmi trigger, the code won't be executed, the overlay will ne kept on and game will crash if trying to run code from bank 0. The fpga has no way of knowinf hf the access was a data read or a handler address read.

2) in order for nmi be at physical 1FFC, the address bank 7 must be set to memory bank 0. That's the default behavior, but some games change it (I think the NES xxx in 1 do). That makes the trigger code never be executed.

3) in order to keep the executed code to the bare minimum, if expects the gamepad state to be the 'buttons' state, and not the 'dpad' state. That's why the nmi is executed at the end of vblank, as games normally leave the port in that state. If game resets the port, the trigger won't work.

4) jumping back to the original game vector requires it to be implemented and do nothing that interferes with actual game working. Games that have code in the nmi handler that is not just an IRET may fail, as that code was never meant to be executed in user normal working. Why we return to the game code instead of doing an IRET? In some cases, when executing the IRET, the cpu reads from the address twice, so if then fpga disabled the overlay on the first read, the 2nd ond will read garbage and game will crash.

I've been thinking on ways to fix it, and these are the results:
Fixing 1 could be done by injecting the overlay directly into game code, patching the nmi to jump to an area that is always mapped and that has unused space so the fpga could inject its overlay (about 30 bytes) when it's accessed. It's not easy, but it's doable.

About 2, I'm afraid there is no way to fix it, games that remap page 0 won't work.

Fixing 3 is easy, just needs more code to be run on the trap to set the gamepad port to the right state.

Fixing 4 is also doable, the game just needs to jump back to a IRET in a page that is always mapped (like issue 1, but we just need 1 byte)

I think most crashes come from issue 1) but we've never been able to reliably reproduce it so I can capture it in the logic analyzer.

The main problem is that it will need a lot of time to make and test, but we can do that in future firmware updates.
 
Last edited:
Top