Memory Card problems

[avih]

Thanks for testing.

@avih: Can you commit the wololo patch? Seems to be working fine so far.

r5706

[KrossX]

Yay! Thanks.

I hope that does it.

[KrossX]

So, MGS3 still has problems. Here's a build + patch.

I assume transfers happen via DMA or some chained commands, since there's no reset once it's setted up until it's done. So, once each step of the transfer is done, the next step is marked with 0x81 0xCMD. After each step is done, I search for 0x81 to start a new step.

Good enough for most stuff that send clean input data after a step is done. Usually all 0x00's or 0xFF's if I remember correctly. MGS3 however, sends garbage. A 0x81 "flag" is found in that garbage and confuzes ma'code that goes "Wtf cmd??".

So, I tried some fix that got convoluted really quickly and instead just made the "unknown command" part fail better so that it continues searching for 0x81 instead. Very simple and seems to work, but warnings would still show up so I moved them to DevCon.

[avih]

So what's the main difference to the old code? how did the old memory cards code work well before?

[rama]

Okay, I'll commit the fix for now (so others can test, too) and I think we need to try out some example elfs on this.

Done.
https://code.google.com/p/pcsx2/source/detail?r=5710

[KrossX]

So what's the main difference to the old code? how did the old memory cards code work well before?

Old code has all devices merged in one write, so it has different variables to keep track of each device activity. Lots of manual lengths and such, and a variable flag for the DMAwrite function (which I should properly check). The code works well due to better coders and possibly lots of proper testing.

New code switches from device to device according to reset commands, and uses sent packets to acquire lenghts. Having the devices separate made it super easy to add the PSX memcard part for example. Main focus of this however, was the multitap and port quirks. It clearly needed thorough testing, and lots of it.

Okay, I'll commit the fix for now (so others can test, too) and I think we need to try out some example elfs on this.

Done.
https://code.google.com/p/pcsx2/source/detail?r=5710

I was hoping to find a way to ensure when a transfer step ends or when another begins first. Though I suppose more visibility for testers is welcomed.

[rama]

The old code was based on earlier PSX emu code (PCSX) and then evolved for some years until stuff just worked (as well as it did ).

[KrossX]

Testing build!

Is a tryout at getting the step length for transfers. I gotta go, so I don't have time to test it.

#EDIT: siopacket.dmacSize1 would've helped, but is never filled. =S

[KrossX]

New build for the step-length-guess-tryout.

I tested that same MGS3 and could load, save and load that save too. It'll trigger KELOGS in case of unknown command.

I'll clean stuff for a patch in the mean time.

#EDIT:

Added patch, cleaned up and put some comments in there while at it.

[avih]

KrossX, generally speaking, other than being able to save/load with the new builds, should there be any concerns regarding compatibility with pcsx2 1.0? i.e. that 1.0 can load from a save which was made with a new build, and vice verse?