Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
PSX Memory Cards: Sourcing SIO Data Values
#11
(08-30-2017, 04:37 AM)kenshen Wrote: with that define option, why don't you make a separate class with the specific define and any other unique psx code then wrap that into the if statement? in the meantime I have several games in my psx library namely most of the spyro games and medieval and metal gear solid that not only boot but are perfectly playable in pcsx2 as it is right now so I'll test your build.

Even though the PS2 specific and PSX specific functions are independent from each other, they are still called out of the same places. The only reason the emulator is capable of knowing which to run is because they are in the same place and a quick check on the card's isPSX() flag allows the siomode to change to match. Separate the two and I personally think it would be messy. Definitely an option worth exploring, but on the surface it seems like a steep slope.

What I had in mind...

The define is only referenced in two places. In Sio.cpp, it affects SIO Interrupts as we see here:
Code:
#ifdef SIO_INLINE_IRQS
#define SIO_INT() sioInterrupt()
#define SIO_FORCEINLINE __fi
#else
__fi void SIO_INT()
{
if( !(psxRegs.interrupt & (1<<IopEvt_SIO)) )
PSX_INT(IopEvt_SIO, 64 ); // PSXCLK/250000);
}
#define SIO_FORCEINLINE __fi
#endif

And in R3000A.cpp we see another instance:
Code:
#ifndef SIO_INLINE_IRQS
IopTestEvent(IopEvt_SIO, sioInterrupt);
#endif

The latter case is nested in a function called _psxTestInterrupts(). If this function lives up to its name, it shouldn't be a factor in PS2 mode. It's an ifndef, if not defined. So if removing the define is a condition for PSX games being save capable... on paper, that makes the entire ifndef arbitrary, as it would be satisfied every time. In short, cut out the ifndef and just call the function in sequence with the other calls in there.

The former is a little more involved but from what I can tell it centers around this SIO_INT() function. If the define is there, macro it such that SIO_INT() is now sioInterrupt(). If not, create definition for function SIO_INT(). In both cases, macro SIO_FORCEINLINE so that it is now __fi. I have no idea what __fi is, I will have to look into that. But that is beside the point. My thought here is, if we are crudely adhering to "the define is a must for PS2 but a problem for PSX", why not just find all the places SIO_INT() shows up, and replace those with sioInterrupt() when we know it is a PS2 game (the PS2 specific SIO functions), and make SIO_INT() a plain old function declaration without any fancy preprocessor constraints when we know it is a PSX game (the PSX specific SIO functions)? Throw in the #define SIO_FORCEINLINE __fi at the top of the file, and call it done?

That's the concept I have floating in my mind. No idea if I can implement this yet. I am treading into unfamiliar C++ territory here so if I just said anything completely off the wall, feel free to reality check me.
Problems? Check out the development builds for the latest updates.

Mobo: ASUS Prime Z370-A
CPU: Intel i7-8700K (3.7 GHz)
RAM: G.Skill TridentZ, 2x8 GB DDR4 (3000 MHz)
GPU: EVGA GeForce GTX 1070 Ti FTW2 (8 GB)
OS: Windows 10 Pro (64 bit)

Oh yeah Red Pandas are cool too.


Reply

Sponsored links

#12
Just did a quick test of your build, Spyro 2 worked perfectly it saw the memory card formatted and saved to it. Medievil however saw the memory card but refused to let me save or format it, I got to the menu where I could select a memory card slot then when it brought up the format yes/no option it instantly closed it as soon as it appeared.
Reply
#13
(08-30-2017, 08:31 PM)kenshen Wrote: Just did a quick test of your build, Spyro 2 worked perfectly it saw the memory card formatted and saved to it. Medievil however saw the memory card but refused to let me save or format it, I got to the menu where I could select a memory card slot then when it brought up the format yes/no option it instantly closed it as soon as it appeared.

Format option? You can do that in game? I don't know if formatting is defined in the PCSX2 code... did you try formatting the card via the PS2 BIOS, then attempting a save?
Problems? Check out the development builds for the latest updates.

Mobo: ASUS Prime Z370-A
CPU: Intel i7-8700K (3.7 GHz)
RAM: G.Skill TridentZ, 2x8 GB DDR4 (3000 MHz)
GPU: EVGA GeForce GTX 1070 Ti FTW2 (8 GB)
OS: Windows 10 Pro (64 bit)

Oh yeah Red Pandas are cool too.


Reply
#14
(08-31-2017, 04:12 AM)pandubz Wrote: Format option? You can do that in game? I don't know if formatting is defined in the PCSX2 code... did you try formatting the card via the PS2 BIOS, then attempting a save?
On ps2 and ps1 systems whenever you got a fresh memory card, the card would come unformatted and every game would give you the option to format it. Something that works in Spyro 2 in pcsx2 but not medieval
Reply
#15
(08-31-2017, 04:52 AM)kenshen Wrote: On ps2 and ps1 systems whenever you got a fresh memory card, the card would come unformatted and every game would give you the option to format it. Something that works in Spyro 2 in pcsx2 but not medieval

Today I learned. I always did card formats via BIOS before even launching games. Both on the physical system and emulator.
Problems? Check out the development builds for the latest updates.

Mobo: ASUS Prime Z370-A
CPU: Intel i7-8700K (3.7 GHz)
RAM: G.Skill TridentZ, 2x8 GB DDR4 (3000 MHz)
GPU: EVGA GeForce GTX 1070 Ti FTW2 (8 GB)
OS: Windows 10 Pro (64 bit)

Oh yeah Red Pandas are cool too.


Reply
#16
Hey, thanks for your work so far Smile

Code:
_psxTestInterrupts()
This is a function name from the early PCSX2 days. It actually means to test IOP interrupts.
It is very much required in PS2 mode.


Code:
IopTestEvent(IopEvt_SIO, sioInterrupt);

This is the thing. I don't know if there is just one SIO or if there's more. Furthermore, are PSX and PS2 using the same SIO even if there are more SIO units?
In any case, at some point the signals have to reach the same pin on the Memory Card / Pad connectors. So if there's 2, they will get muxed somewhere and that mux would be switched when PS1 mode initializes.
If there's just one SIO for both modes, then PS1driver still has to switch this unit into PS1 mode.
We can use this for a proper mode detection flag because once the console is in PS1 mode, it can only return to PS2 mode via a system reset.
Reply
#17
Ok, I made forward progress but at the same time am trying to put out two huge fires.

The good news: Came up with a neat little way to make the interrupt mode "switchable" in Sio.cpp.

The bad news:
- Currently using mcd->IsPSX() as the switch control, and because even PS2 games constantly probe PSX cards, the function is firing CONSTANTLY in PSX mode, and even worse I am trying to debug message it to make sure it is only firing when it is supposed to, so it is giving the EE and IOP interpreters a run for their money on "Quite possibly the slowest thing in the universe".
- PSX games are no longer responding to controller input. Considering how little I did to actually alter information flow (other than changing function names and moving existing code into functions away from defines, I barely did anything here), this is mildly concerning, making me think that SIO is more fubar'd than I originally wanted to think it was.

I am hoping the second problem is only a symptom of the first. So, to fix the first problem, I need a way to tell if the actual game, not just the card SIO happens to be probing, is PSX or not. And from my searches on Github and in VS, I can't seem to find any sort of bool or flag. So, does anyone know what I could look for that would be an indication?

If you want to see it, I am trying to push commits to my repo (https://github.com/RedPanda4552/pcsx2), but I do not know when they will be up. My Git shell is having an existential crisis and seems hung up on the push command so I will leave it sitting overnight here. I commented out the debug messages in Sio.cpp this time as not to throttle the life out of the emulator, if you choose to run it.

Edit: My Git shell thinks it has diverged from Github, even though it hasn't, so I may be starting from scratch. Brilliant.
Problems? Check out the development builds for the latest updates.

Mobo: ASUS Prime Z370-A
CPU: Intel i7-8700K (3.7 GHz)
RAM: G.Skill TridentZ, 2x8 GB DDR4 (3000 MHz)
GPU: EVGA GeForce GTX 1070 Ti FTW2 (8 GB)
OS: Windows 10 Pro (64 bit)

Oh yeah Red Pandas are cool too.


Reply
#18
(09-01-2017, 07:17 AM)pandubz Wrote: Ok, I made forward progress but at the same time am trying to put out two huge fires.

The good news: Came up with a neat little way to make the interrupt mode "switchable" in Sio.cpp.

The bad news:
- Currently using mcd->IsPSX() as the switch control, and because even PS2 games constantly probe PSX cards, the function is firing CONSTANTLY in PSX mode, and even worse I am trying to debug message it to make sure it is only firing when it is supposed to, so it is giving the EE and IOP interpreters a run for their money on "Quite possibly the slowest thing in the universe".
- PSX games are no longer responding to controller input. Considering how little I did to actually alter information flow (other than changing function names and moving existing code into functions away from defines, I barely did anything here), this is mildly concerning, making me think that SIO is more fubar'd than I originally wanted to think it was.

I am hoping the second problem is only a symptom of the first. So, to fix the first problem, I need a way to tell if the actual game, not just the card SIO happens to be probing, is PSX or not. And from my searches on Github and in VS, I can't seem to find any sort of bool or flag. So, does anyone know what I could look for that would be an indication?

If you want to see it, I am trying to push commits to my repo (https://github.com/RedPanda4552/pcsx2), but I do not know when they will be up. My Git shell is having an existential crisis and seems hung up on the push command so I will leave it sitting overnight here. I commented out the debug messages in Sio.cpp this time as not to throttle the life out of the emulator, if you choose to run it.

Edit: My Git shell thinks it has diverged from Github, even though it hasn't, so I may be starting from scratch. Brilliant.
I'd suspect the Second problem is a symptom of the first, I don't know about pcsx2 specifically but when I code video games sometimes I messed up the flow of data making the game loop be severely over encumbered IE. too many things firing off at once, and input would stop responding. Hope that helps at all
Reply
#19
I am officially at a loss.

The slowdowns from my attempt to clean up SIO interrupts seem to be spawning out of the air being pulled in to my laptop. Even commenting out all interrupt attempts, the emulator is just bogged down beyond belief. VS CPU profiler says the main threads (that end up executing game code) are the ones doing the bulk of the work. Can't find any SIO related stuff in there.

For now going to try to regress back to the original hack and take a fresh approach to the situation.

Edit 1: The boat isn't sinking anymore but it did catch fire again.

Ok, slowdowns appear to be only in the VS debugger, whereas compiling a release build and running outside runs normally. Strange to say the least.

Nonetheless, the same issues stand. No controller input when a PSX card is inserted, no idea if the interrupt code is working as intended.

Commit is finally up: (https://github.com/RedPanda4552/pcsx2)

Edit 2: Commence irony

I personally find this hilarious but I appear to have found the key to the controller input cutting out.

Pretty much all SIO functions end by calling an interrupt. There's the PS2 interrupt routine which has been proven to work well and is what currently always runs. The PSX interrupt routine was there but buried behind a #define. It turns out, that PSX interrupt is key to PSX memcard IO but breaks PSX controller input.

Yes, the secret is running the PS2 interrupt routine for controllers, and PSX interrupt routine for memcards.

Oh, and suddenly PSX cards are not being detected even with the changes. NEATO!
Problems? Check out the development builds for the latest updates.

Mobo: ASUS Prime Z370-A
CPU: Intel i7-8700K (3.7 GHz)
RAM: G.Skill TridentZ, 2x8 GB DDR4 (3000 MHz)
GPU: EVGA GeForce GTX 1070 Ti FTW2 (8 GB)
OS: Windows 10 Pro (64 bit)

Oh yeah Red Pandas are cool too.


Reply
#20
Be careful when making changes, even with Git I've had voodo bugs appear out of nowhere. It's easy to loose track of what you're doing and loose the working branh you had before.
Reply




Users browsing this thread: 1 Guest(s)