PCSX2 bug(s)?

[ateste]

Oops. Missed one for TC2:

Code:

        cdvd.PwOff |= 1<<Irq_CommandComplete;
        psxHu32(0x1070)|= 0x4;
        hwIntcIrq(INTC_SBUS);

        cdvd.Ready = CDVD_READY2;

(1)
        cdvd.Status = CDVD_STATUS_PAUSE; // check (rama)

        HW_DMA3_CHCR &= ~0x01000000;
        psxDmaInterrupt(3);

(1) Add line to CDVD


Now everything should work out.

[aaa801]

@aaa801: oh i know that : its because EE cache is not implemented in recompiler.

actualy thats wrong
it just happens to work with ee cache with one version of the game
theres actualy another problem hiding somewhere

[andutrache]

actualy thats wrong
it just happens to work with ee cache with one version of the game
theres actualy another problem hiding somewhere

It works with only one game because the EE cache is not completely implemented. No other problem.
DOA games need EE cache emulation PERIOD.

[refraction]

To be fair there is something else wierd going on, it's quite odd that one version works fine, but the rest dont

[ateste]

Lilypad pseudo-pad fix for TotA (not PCSX2 SIO core bug)
http://forums.pcsx2.net/Thread-Savestate...trol-stuck
http://forums.pcsx2.net/Thread-LilyPad-0...#pid197444


Minor CDVD improvement?

Code:

cdvdWrite04

    CDVD_LOG("cdvdWrite04: NCMD %s (%x) (ParamP = %x)", nCmdName[rt], rt, cdvd.ParamP);

    cdvd.nCommand = rt;
#if 1
    cdvd.Status = cdvd.Spinning ? CDVD_STATUS_SPIN : CDVD_STATUS_STOP; // checkme
#else
    cdvd.Status = CDVD_STATUS_STOP; // check (rama)
#endif

@aaa801
Sorry, don't have DOA2. Maybe someday.

What's this bug though? Bad geometry or emu crasher?


@rama
Do you have info on where TotA CDVD bug hits (or USA memcard)? Played some bit and got nothing with hang. Tried IRC a few times but no one there.

[pseudonym]

Kind of found the cause for the dead or alive 2 crash. It does two rpcs in a row (although I say in a row there are of course a lot of instructions between the actual SIF invocations) and the second is still running when it tries to call the first, so it waits on it. However, it uses the same buffer for the arguments and the return structure so when the second returns it overwrites the arguments to the second call. MUCH copying later part of that return structure (a hardware clock id, around 800 million in decimal) ends up as the size argument to a memcpy which overwrites the stack of another thread causing that thread to attempt to resume at FFFFFFFF when it wakes up.

Not sure yet why this code is reliable on a real PS2, but it can be bypassed by making the call blocking (a one word patch). My version (SLUS-20071) does however black screen after this, I don't know if it's one which worked with the interpreter+cache.

EDIT: And yes, the answer to why it's reliable (or semi-reliable, this is fault prone on real hardware because if you write to an address sharing the same low bits the cache will writeback on its own) on the real PS2 MAY be that the cache writeback occurs after the SIF transfer back to the EE, but if so patching the game is a better solution than implementing the cache and making everything 100x slower. Also, probably a better patch is to fiddle with the flow in that function a bit so that it blocks on the existing rpc at the top of the function. It blocks at some point in the function regardless of the arguments.

[ateste]

Interesting CDVD find:
http://cdvdmania.com.ru/downloads.html

See 'Pseudo-code for SCE's IRX modules - cdvdman'
- explains HOWTO register (data read mode)
- Read08 = CDVDreg_PWOFF (irq status: $01 = data ready, $02 = cmd complete, $04 = data end (ex. ReadTOC))
(see intrh_cdrom)
- cdvdman_speedctl ($83 value partly explained)
- lots of other stuff


Sadly find nothing that fixes SMT Nocturne BREAK yet.

Code:

CDVD(000266d4 272278f2): cdvdWrite04: NCMD CdRead (6) (ParamP = b)
CDVD(000266d4 272278f2): CdRead > startSector=1141183, nSectors=16, RetryCnt=100, Speed=18(83), ReadMode=3(0) (1074=38a09)
CdRead: Reading Sector 1141183(16 Blocks of Size 2048) at Speed=24x
CDVD(000266d4 272278f2): CdSeek Begin > Contiguous block without seek - delta=0 sectors
CDVD(000266d4 272278f2): CdSeek Time = 10240
CDVD(000266d4 272278f2): cdvdRead04(NCMD) 6
CDVD(0000b99c 2722a0f2): Cdvd Interrupt = 1 (readed), 10 (left)
CDVD(0000b99c 2722a0f2): READ SECTOR 1141183 (BCR 100;20)
CDVD(00004e74 2722c900): Cdvd Interrupt = 1 (readed), f (left)
CDVD(00004e74 2722c900): READ SECTOR 1141184 (BCR f0;20)
CDVD(0000b99c 2722f100): Cdvd Interrupt = 1 (readed), e (left)
CDVD(0000b99c 2722f100): READ SECTOR 1141185 (BCR e0;20)
CDVD(0000b99c 27231900): Cdvd Interrupt = 1 (readed), d (left)
CDVD(0000b99c 27231900): READ SECTOR 1141186 (BCR d0;20)
CDVD(000261e4 272330da): cdvdRead05(NReady) 0
CDVD(0002622c 272330e0): cdvdWrite07(Break) 1
*PCSX2*: CDVD BREAK 1
*PCSX2*: BREAK HACK = 01
CDVD Break Call

Tried auto-inc return value 00-FF for NReady. No hits. Unlesss game does watchdog check on:
"cdvdRead13(Unknown) 4"

[rama]

Sorry, long weekend
I'm on irc now.

[aaa801]

Kind of found the cause for the dead or alive 2 crash. It does two rpcs in a row (although I say in a row there are of course a lot of instructions between the actual SIF invocations) and the second is still running when it tries to call the first, so it waits on it. However, it uses the same buffer for the arguments and the return structure so when the second returns it overwrites the arguments to the second call. MUCH copying later part of that return structure (a hardware clock id, around 800 million in decimal) ends up as the size argument to a memcpy which overwrites the stack of another thread causing that thread to attempt to resume at FFFFFFFF when it wakes up.

Not sure yet why this code is reliable on a real PS2, but it can be bypassed by making the call blocking (a one word patch). My version (SLUS-20071) does however black screen after this, I don't know if it's one which worked with the interpreter+cache.

EDIT: And yes, the answer to why it's reliable (or semi-reliable, this is fault prone on real hardware because if you write to an address sharing the same low bits the cache will writeback on its own) on the real PS2 MAY be that the cache writeback occurs after the SIF transfer back to the EE, but if so patching the game is a better solution than implementing the cache and making everything 100x slower. Also, probably a better patch is to fiddle with the flow in that function a bit so that it blocks on the existing rpc at the top of the function. It blocks at some point in the function regardless of the arguments.

i believe it was the japanese one that worked on ee cache mode,
the one we have is the ntsc one

[ateste]

Rather than 'complain' at #pcsx2dev, just going to blab here.


1) CDVD reading bug?
(already mentioned at IRC; just making a hard log here for others to read)

cdvdReadSector

Code:

    if (bcr < cdvd.BlockSize) {
..
..
        }


    if( (HW_DMA3_CHCR & 0x01000000) == 0 ) {
        //MessageBox( 0,L"DMA3 TRANSFER OFF!!!", L"CDROM", 0);
        CDVD_LOG( "CDVD READ - DMA3 transfer off (try again)" );
        return -1;
    }

There's a -small- chance that a game (like TotA) hits a dma3 drain. Resets the bcr first. And a read IRQ triggers right after that. (before the new madr + chcr is set).

Meaning dma3 is off but code allows a read transfer occurs. This can break something. Potentially in theory.

Felt like harping about this again anyway.


2) IPU bug?

http://forums.pcsx2.net/Thread-Chatter
(Smackdown - Shut Your Mouth PAL - main menu movies)

Symptom:
Press START at title screen. Loading screen occurs with WWE logo. Movie begins playing and dies. Logs say:
'ipu0interrupt'
'ipu0interrupt'
..
..
'ipu0interrupt'
'ipu0interrupt'
'ipu0interrupt'

Code:

; death loop - check BUSY
eDis(0010b888 ca7c1f83): nop
eDis(0010b88c ca7c1f83): nop
eDis(0010b890 ca7c1f83): nop
eDis(0010b894 ca7c1f83): bltz    v0, 0xFFFFFFEC
eDis(0010b898 ca7c1f83): nop

v1 = 10002010 --> IPU $10 (IPU_CTRL)
v0 --> 81003f00
eDis(0010b880 ca7c1f8c): lw    v0, 0x0000(v1)
eDis(0010b884 ca7c1f8c): nop

So presumably when the IPU1 or IPU0 is off, BUSY goes down. Otherwise we hits this stupid loop and game locks up.

So a temp hack (too tired to care about a real fix right now)

Code:

        ipucase(IPU_CTRL): // IPU_CTRL
        {
            ipuRegs.ctrl.IFC = g_BP.IFC;
            ipuRegs.ctrl.CBP = coded_block_pattern;

            if (!ipuRegs.ctrl.BUSY)
                IPU_LOG("read32: IPU_CTRL=0x%08X", ipuRegs.ctrl._u32);


            // Smackdown - Shut Your Mouth PAL movies
            // - TEST HACK: IPU1 done ==> BUSY off (otherwise hang)
            if( ipu1dma.qwc == 0 ) ipuRegs.ctrl.BUSY = 0;
            if( ipu0dma.qwc == 0 ) ipuRegs.ctrl.BUSY = 0;


            return ipuRegs.ctrl._u32;
        }

Makes it all the way in-game to actual match.