Results 1 to 7 of 7

Thread: SD System 3 Randomly Resets

  1. #1
    N00b of Syougi monads's Avatar
    Join Date
    May 2008
    Location
    neoland

    Posts
    204

    SD System 3 Randomly Resets

    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???

  2. #2
    Big Bang Pro Wrestler
    ShootTheCore's Avatar
    Join Date
    Feb 2015
    Location
    Logan UT USA

    Posts
    1,026
    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.

  3. #3
    N00b of Syougi monads's Avatar
    Join Date
    May 2008
    Location
    neoland

    Posts
    204
    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.

  4. #4
    . Yodd's Avatar
    Join Date
    Feb 2002
    Location
    Cincinnati, OH

    Posts
    3,007
    Quote Originally Posted by monads View Post
    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.
    Terraonion Team Member

    Check out Todd's Nerd Cave on Youtube!

    Follow me on Twitter @ToddsNerdCave

  5. #5
    Crazed MVS Addict
    SavagePencil's Avatar
    Join Date
    Oct 2005
    Location
    Seattle, WA USA

    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.

  6. #6
    N00b of Syougi monads's Avatar
    Join Date
    May 2008
    Location
    neoland

    Posts
    204
    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!!!

  7. #7
    Quote Originally Posted by monads View Post
    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!!!
    Quote Originally Posted by monads View Post
    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 by neodev; 04-05-2018 at 11:01 AM.
    NEOSD - The ONLY Neo Geo MVS & AES Flash Cart - TEAM Member


Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •