forums.ps2dev.org

I've been noticing some weird behavior for a while but haven't been able to track it down until now. Something was overwriting 0x80000000-0x800000FF on EE with what seemed to be garbage. After eliminating causes I finally tracked it down to the padman rpc in ps2sdk, mainly the "padx" version. not only was the arg not being passed to the init function, it is also not a mode! it is actually an EE-side address that something(I don't know what yet, don't know if I care to bother reversing the rest) is DMA'd to. This is done regardless of if you do padopen/etc. Sooo, long story short the RPC server on IOP was being passed "0"(usually) which resulted in a DMA being transfered and trashing the first part of EE RAM. My fix was to add a 256-byte buffer to the rpc client and pass the address of that.

FYI, the first 256 bytes of EE RAM are 2 exception vectors...

Nasty bug!

Would this also explain why padx did not work for some people (myself included) ?

padx works for me, though I suspect it's still a bit fucked. I don't think the "init" RPC call it makes is really init, for one. I don't know what the data area it sets up is for but I suspect this is more of an "open" call... maybe if I get bored one day I'll finish sorting it, but for now at least it won't trash the TLB Refill and Perf Counter exception vectors anymore.

Herben wrote:padx works for me, though I suspect it's still a bit fucked. I don't think the "init" RPC call it makes is really init, for one. I don't know what the data area it sets up is for but I suspect this is more of an "open" call... maybe if I get bored one day I'll finish sorting it, but for now at least it won't trash the TLB Refill and Perf Counter exception vectors anymore.

This bug reminds me of a problem we've seen in uLE, where the gamepad initialization also seemed to ignore some arguments (and I guess it really did, from what you say). Instead the result would be dependent of whether or not any disc was in the CDVD tray, and on whether that disc was a CD or a DVD. Quite insane of course, since there should be no connection between those things, but with one disc type we got analog init and with the other disc type we got digital init.

Note that this particular error only affected Dev1 booting, so it had nothing to do with the real content of those discs, as they were not involved in the booting at all... When relaunching the same copy of uLE another time, using uLE itself to do it, then that problem would not occur at all.

I don't really understand what happened there, but it might somehow be related to the argument handling you fixed.

Btw: Is that fix also in the current SVN updates ?

Best regards: dlanor

it could be that your problem was related to that, try and find out then let me know. ;)

yes, I've committed my changes to SVN.