08-26-2017, 10:09 PM
I apologize in advance if this isn't a fitting place for this discussion; I feel like Github isn't the place for casual discussion. Let me know if this needs moved.
Why I started this nonsense:
Savestate stability problems after many many cumulative hours played (suggests bad game design causing memory leaks or gradual destabilization of savestates for PSX).
The short of what I've already done:
Modified GUI to allow PSX memory card creation. The PSX memory card code already existed, all I had to do was make a way to create them and plug in a few numbers for the card size. BIOS recognizes it, allows formatting, no problems in the memory cards GUI either.
The problem:
The one PSX game I have been able to boot without too much fuss, Digimon World 3, still will not detect PSX memory cards. Upon investigation in Sio.cpp (debug messages more plentiful than nitrogen in our atmosphere), PSX load/save operations seem to only fire the various SIO functions with a data value of 129 in decimal, or 0x81 hexadecimal. From what I can tell, the proper PSX data values should be handled if encountered (taken from "SIO_WRITE sioWriteMemcard(u8 data)"):
Notable, the "SIO_WRITE sioWriteMemcard(u8 data)" function contains a case for this data value (0x81), but it has no break, and overflows down to share a result with several other cases:
Another notable thing is that there is also a "SIO_WRITE sioWriteMemcardPSX(u8 data)", however I do not see calls to this while running a PSX game. Funny enough, I saw a few stray calls tossed in while running a PS2 game, though.
The last note, and a bit of an offhand one, is that the data value 66 (0x42) is CONSTANTLY, regardless of whether a load/save is being attempted, being plugged into "static void sioWrite8inl(u8 data)". The only time I see this hex as a case is in "SIO_WRITE memcardWrite(u8 data)":
I wonder, in the back of my mind, if this means anything.
Some attempted solutions:
Forcefully changing the siomode variable to try and steer control into "sioWriteMemcardPSX", away from "sioWriteMemcard". Sure enough, the function calls changed, but no other behavior changes. After all, the data being passed in wasn't changing.
Breakpointing and following the call stack. However, the call stack falls out of scope rather quickly.
Debug messages on both of these functions indicates that 129 (0x81) is being passed in to both; this number is originating from something deeper and passing through these unmodified. While I did find instances in PCSX2 code where "sioWrite8inl" was called, attempting to breakpoint these yielded no result, and debug messages had no console output.
The question:
Does anyone have any insight as to what the hell could be making these calls? I'm led to believe something "down in the metal" is not working as intended and only making these calls with 129 as the data. I would like to find out why but if the call stack is going to drop off like this and only leave me with assembly code, I don't think that's feasible.
The other thing is, remember that offhand comment about 66 (0x42)? Could that be more important than I think? The rapid fire calls makes me think perhaps it is, but I have no idea why it would be called outside of a save/load operation, then.
edit: swapped screenshot with one that isn't murdered by display scaling
Why I started this nonsense:
Savestate stability problems after many many cumulative hours played (suggests bad game design causing memory leaks or gradual destabilization of savestates for PSX).
The short of what I've already done:
Modified GUI to allow PSX memory card creation. The PSX memory card code already existed, all I had to do was make a way to create them and plug in a few numbers for the card size. BIOS recognizes it, allows formatting, no problems in the memory cards GUI either.
The problem:
The one PSX game I have been able to boot without too much fuss, Digimon World 3, still will not detect PSX memory cards. Upon investigation in Sio.cpp (debug messages more plentiful than nitrogen in our atmosphere), PSX load/save operations seem to only fire the various SIO functions with a data value of 129 in decimal, or 0x81 hexadecimal. From what I can tell, the proper PSX data values should be handled if encountered (taken from "SIO_WRITE sioWriteMemcard(u8 data)"):
Code:
// If the PS2 commands fail, it falls back into PSX mode
case 0x52: // PSX 'R'ead
case 0x53: // PSX 'S'tate
case 0x57: // PSX 'W'rite
siomode = SIO_MEMCARD_PSX;
break;
Code:
case 0x81: // Checked right after copy/delete
case 0xBF: // Wtf?? On game booting?
case 0xF3: // Reset?
case 0xF7: // No idea
MemcardResponse();
siomode = SIO_DUMMY;
break;
The last note, and a bit of an offhand one, is that the data value 66 (0x42) is CONSTANTLY, regardless of whether a load/save is being attempted, being plugged into "static void sioWrite8inl(u8 data)". The only time I see this hex as a case is in "SIO_WRITE memcardWrite(u8 data)":
Code:
case 0x42: // Write
memcpy(sio.buf, header, 4);
once = true;
break;
Some attempted solutions:
Forcefully changing the siomode variable to try and steer control into "sioWriteMemcardPSX", away from "sioWriteMemcard". Sure enough, the function calls changed, but no other behavior changes. After all, the data being passed in wasn't changing.
Breakpointing and following the call stack. However, the call stack falls out of scope rather quickly.
Debug messages on both of these functions indicates that 129 (0x81) is being passed in to both; this number is originating from something deeper and passing through these unmodified. While I did find instances in PCSX2 code where "sioWrite8inl" was called, attempting to breakpoint these yielded no result, and debug messages had no console output.
The question:
Does anyone have any insight as to what the hell could be making these calls? I'm led to believe something "down in the metal" is not working as intended and only making these calls with 129 as the data. I would like to find out why but if the call stack is going to drop off like this and only leave me with assembly code, I don't think that's feasible.
The other thing is, remember that offhand comment about 66 (0x42)? Could that be more important than I think? The rapid fire calls makes me think perhaps it is, but I have no idea why it would be called outside of a save/load operation, then.
edit: swapped screenshot with one that isn't murdered by display scaling