New LLE RSP Plugin (accurate, fast but untested?)

[GPDP]

Ah, that explains the message I would get when booting OoT. I was wondering if it was really making use of JPEG decompression during boot.

On another note, I really expected Rogue Squadron to give me a OStype.task message as well, but it does not. The menu screen only seems to work in some manner in Jabo's plugin, though.

[HatCat]

Oh cool. I didn't know it was used in OOT after the boot phase for mid-game decompression. I just thought the 00000004 task at OOT boot-up was like a peripheral thing, like store into SR $at and check an external value to see if some 64DD extension was installed or something. I thought it was just some hidden beta thing (and maybe it still is), but there really are (other) JPEG tasks used later on.

Like I said just haven't played with the HLE version of my plugin thoroughly enough to find that.

Originally Posted by bsmiles32

*The only exception I know of is a small rsp task found during booting of OoT, which stores ve12 into dmem[0x10-0x1f].

And regarding that task, I did the deskwork for that SP task here.
http://dl.dropboxusercontent.com/u/1...64_startup.txt

The DMA stuff there I wrote might be wrong though.
That was back before I finished understanding SP DMA when I used to learn about the RSP by rewriting the z64 RSP plugin.

[Edit]
Now I get what you meant.
You were talking about this instruction as I wrote it out in my deskwork:

080 E80C2001 SQV     $v12, 16($0)

Stores the 128-bit quadword from general-purpose VR 12 to DMEM+0x010 .

Looking back at it now, I think this task is a lot less special than I make it sound.
It probably was just for initializing the JPEG decoder head of some field.

Originally Posted by GPDP

On another note, I really expected Rogue Squadron to give me a OStype.task message as well, but it does not. The menu screen only seems to work in some manner in Jabo's plugin, though.

Rogue Squadron is easy to emulate on the RSP.
It uses just basic task types and runs faster than many other games in LLE gfx.

It wouldn't work in HLE if you don't have proper HLE support for the custom graphics microcode tho.

[GPDP]

Originally Posted by FatCat

Rogue Squadron is easy to emulate on the RSP.
It uses just basic task types and runs faster than many other games in LLE gfx.

It wouldn't work in HLE if you don't have proper HLE support for the custom graphics microcode tho.

I've tried it with Jabo's, z64gl, and SoftGraphic. The menu screen only works in Jabo's (although shifted downwards), but the in-game graphics are pretty screwy, whereas the graphics are great with z64gl, and good in SoftGraphic, although the latter does not seem to support the game's hi-res mode even when it's toggled. Strange, as Perfect Dark's hi-res mode does work, although the latter only seems to increase horizontal resolution, whereas RS increases both vertical and horizontal.

[HatCat]

Different games are harder than others to emulate on the RDP, but there really is nothing that complex relatively about Rogue Squadron on the RSP.
I have worked through many bugs or reversions of the RSP where many other games would have bugs and not Rogue Squadron.

[bsmiles32]

Stores the 128-bit quadword from general-purpose VR 12 to DMEM+0x010 .

^ This. In all honesty I don't know the real purpose of this ucode, by I guess it is security related.

[angrylion]

Funnelcube demo by marshallh spams with message boxes sayng something about MTC0.

[HatCat]

Originally Posted by angrylion

Funnelcube demo by marshallh spams with message boxes sayng something about MTC0.

Just had a look into this finally.

You had me worried there for a second.
At first I thought you might have meant MTC0 system control CPU loop updates on the status register (specifically the special bits like HALT).

The exact message I'm getting with funnelcube is "MTC0\nCMD_START".

You can find that print code at `$rsp/su/cop0/mtc0.h` at line 126:

        case 0x8:
            if (*RSP.DPC_BUFBUSY_REG) /* lock hazards not implemented */
                message("MTC0\nCMD_START", 3);
            *RSP.DPC_START_REG = SR[rt];
            *RSP.DPC_CURRENT_REG = SR[rt];
            *RSP.DPC_END_REG = SR[rt]; /* NEW, not in PJ64/MAME */
            if (SR[rt] & 07) /* All DMA transfers must be 64-bit-aligned. */
            {
                message("MTC0\nCMD_START", 1);
                *RSP.DPC_START_REG &= 0xFFFFFFF8;
                *RSP.DPC_CURRENT_REG &= 0xFFFFFFF8;
                *RSP.DPC_END_REG &= 0xFFFFFFF8;
            }
            return;

Simply remove the error message printer line of code I highlighted in red, and you should be all set.

the message("$any string", 1); means it is not really an error, just an extremely unusual thing to execute on the RSP.
message(x, 0) means it's debug only,
message(x, 1) means it's very unusual/unseen but most likely correct
message(x, 2) means I was not able to test it, but I *think* it's correct
message(x, 3) means I have no idea what to do (things like reserved opcodes).

The second parameter of my `message` call is what I call the priority level, and you can control which messages are ignored / not compiled in to the dll by raising/lowering the `MINIMUM_MESSAGE_PRIORITY` macro in `$rsp/config.h`, or simply removing the error line like I said.

zilmar's method of emulating MTC0 on CMD_STATUS:

	case 8: 
		*RSPInfo.DPC_START_REG = RSP_GPR[RSPOpC.rt].UW; 
		*RSPInfo.DPC_CURRENT_REG = RSP_GPR[RSPOpC.rt].UW; 
		break;

My method is more stable than that!
RSP 1.7.0.9 interpreter for PJ64 only unconditionally updates the DPC START and CURRENT reg's. My method uses the documented algorithm and updates DPC_END_REG as well as forcing 64-bit DMA alignment. (My RSP interpreter is not only the fastest but the most accurate to my knowledge. )

So do let me know if the fcube demo runs any better/worse on either RSP plugin, once the error message is voided.

[HatCat]

Sorry to not post a binary update.

There is nothing to update to the plugin in this thread yet apart from angrylion's find that a game uses 64-bit DWORD-unaligned DMA addressing for DPC CMD_START, which I will now comment in the source code that funnelcube demo uses this problem (as well as remove the error).

Before I post an updated binary with only one change I was thinking I would re-interpret some of MarathonMan's wisdom and figure out some branch-free ways to static-condition-code clamp signed accumulator elements for VMAD* etc. When I update at least one other thing I update the binary; until then make source changes locally.

[angrylion]

How do you know that writes to DPC_START_REG also update DPC_END_REG? From hardware tests? How do you know that the RSP forces 64-bit alignment for data written to DPC_START_REG? I have a testrom that shows that the CPU writes data to DPC_START_REG without forcing alignment, so writing an unaligned address crashes the RDP.

[HatCat]

Originally Posted by angrylion

I have a testrom that shows that the CPU writes data to DPC_START_REG without forcing alignment, so writing an unaligned address crashes the RDP.

Strictly the MIPS CPU its self, or the RSP CPU?

With the RSP CPU the documented algorithm (however not legally re-publishable that one can type on here) indicates that the value read from SR[rt] is forced to & ~07 (zero the low 3 addressing bits) before being read out to DPC_START, DPC_CURRENT, DPC_END.

However, no, I have no other test resources nor any way of testing on the actual ROM, so any information like one of the test ROMs breaking on the actual machine but not this RSP virtual machine is appreciated.