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

[HatCat]

All I can really do is keep trying that method with different emulators I guess.

Originally Posted by MarathonMan

Now you feel my pain.

Remember that it could also be things like the branch delay slots, too, since you changed the operation of those. Many times in my simulator all my instructions have been flawless, but there's been some corner-case with the control flow logic that was just a little off.

I really don't think it could be that major of a bug, as branch delay slots.

It even goes in-game into TWINE 007, with flawless gfx.
The MusyX audio ucodes for games like that have flawless audio.

It's only the standard ABI audio microcodes like Mario64 and, later on, the custom one done by Conker's, that eventually start scratching the audio.
Even so, gfx are perfect in Conker's, but nonexistent in Mario64.

If it was a bug with branch delay slots I really don't think any games would be booting, with any graphics.

I don't suppose removing the `static` keyword, for things like `static short VR[32][8]` or `static ... VCO,VCC,VCE` could at all affect any algorithms on the vector half?

[MarathonMan]

Originally Posted by BatCat

If it was a bug with branch delay slots I really don't think any games would be booting, with any graphics.

After some of the bugs I've had lately, I trust nothing.

Originally Posted by BatCat

I don't suppose removing the `static` keyword, for things like `static short VR[32][8]` or `static ... VCO,VCC,VCE` could at all affect any algorithms on the vector half?

No, absolutely not.

[HatCat]

So frustrating.

I just ran the compilation under Visual Studio "/Wall" this time, and it found only one warning to give me (but repeatedly throughout my code due to multiple instances) that GCC's "-Wall" wasn't: something about--

// const signed int offset = -(inst.W & 0x00000040) | inst.R.func;


warning C4146:
    unary minus operator applied to unsigned type, result still unsigned

So I added "signed SW: 32" after the "unsigned W: 32" to help guarantee the sign-extension.

const signed int offset = -(inst.SW & 0x00000040) | inst.R.func;

Doesn't fix a damn thing.

I'm out of warnings to nag me!
I checked my opcode tables too to make sure that I didn't mis-map any RSP operations.

And I briefly checked even the x86 output for SRL/SRA/SRLV/SRAV: the sign-extended and zero-extended shift intentions correspond as I intended, so no bug there.

[MarathonMan]

Hey, if you ever get bored you can always look for my bugs too, eh?

[HatCat]

No joke.

I am so tired of focusing my mind on the SAME THING!

I even just finished, a couple episodes of Dragonball Z.

Because I can't stand going back into the past and rewinding to fix old things.
What I like to do is go forward, in the direction to mend the biggest, real weaknesses (like inevitably slow speed), than minor screwups I accidentally'd.

I would much rather be analyzing RSP bugs in your code than mine right now, frankly.
'Course I haven't gotten it to compile yet because I didn't fetch the source off your repo to try to compile it in MinGW64 yet. I am lazy with installing things / doing things for the first time and at least at first was hoping to remove this bug from my conscious.

[MarathonMan]

Originally Posted by BatCat

No joke.

I am so tired of focusing my mind on the SAME THING!

I even just finished, a couple episodes of Dragonball Z.

Because I can't stand going back into the past and rewinding to fix old things.
What I like to do is go forward, in the direction to mend the biggest, real weaknesses (like inevitably slow speed), than minor screwups I accidentally'd.

I would much rather be analyzing RSP bugs in your code than mine right now, frankly.
'Course I haven't gotten it to compile yet because I didn't fetch the source off your repo to try to compile it in MinGW64 yet. I am lazy with installing things / doing things for the first time and at least at first was hoping to remove this bug from my conscious.

I still need to port one or two RSP-related changes to conform to the SSE2 subset, too, as it requires SSSE3 right now.

[HatCat]

You mean to your SSE2 fork of my plugin?

Oh I'm not too interested about that anymore. Chances are it probably would have grown exponentally faster once things like LWC2 and SWC2 were vectorized, but ultimately the only thing I can guarantee to map to SSE instructions (without having to worry about unaligned scalar addresses etc.) are the pure vector operations anyway, which, once I achieve my rewrite of the 2-D vector function pointer (function of 6-bit func sub-opcode, of the 4-bit element bit field to not have to delay branching for which way to vectorize semi-scalar-encoded target vector elements) I'm pretty sure GCC is capable of throwing SSE2 in there for me without having to ask it anyway.

Or maybe you just meant, your emulator can be changed to use different limitations of SSE enhancements.

But I cannot think to even start this !! with this bug on the loose...
currently going back to the file input/output debugger method you defined again out of desperation >.<

[oddMLan]

Originally Posted by BatCat

Being told to fuck off is one of my favorite motivations!

FUCK OFF! FUCK OFF! FUCK OFF! FUCK OFF! FUCK OFF! FUCK OFF! FUCK OFF! FUCK OFF! FUCK OFF! FUCK OFF! FUCK OFF! FUCK OFF! FUCK OFF! FUCK OFF! FUCK OFF! FUCK OFF! FUCK OFF! FUCK OFF! FUCK OFF! FUCK OFF! FUCK OFF! FUCK OFF! FUCK OFF! FUCK OFF!

Tell me if you need some more

[HatCat]

That's the spirit!
I'll need more once I figure out this damn bug but I can't celebrate with them motivations till then.

I would suggest maybe MarathonMan could use some of those but I think he already got a large spewing of them from his sound system, DMEM disintegration bug caused by interfacing between the CPU/PIF and the RCP or something like that.
So yeah already got a similar message like that.

When I'm ready to smack myself for taking so long to find this bug you can send one twice as big.

[HatCat]

Small update, but no fix yet (progress though!).

Thought I almost had it!!
But false alarm.

I gave the file I/O crazy idea a second try and somehow it's no longer unpredictable, at least not under Mupen64 CPU interpreter. ;P

Stable, way way older version of RSP emulator (different plugin I played with) based on Project64 1.4 RSP interpreter by zilmar claimed that my new RSP beta had the very first difference extremely early on in the file.

Its output was something along the lines of:


This was extremely early on in the very first task type, which made disassembling this very easy.

I did a hand-written version off my automated RSP disassembler syntax generator of this code segment:

off   inst        Interpretation     
--- -------- ------------------------
000 34210001 ORI     $at, $at, 0x0001
004 0900041A J       0x4001068
008 20010FC0 ADDI    $at, $0, 0x0FC0
068 8C220004 LW      $2, 4($at)
06C 30420002 ANDI    $2, $2, 0x0002
070 10400007 BEQ     $2, $0, 7
074 00000000 SLL     $0, $0, 0
090 8C220018 LW      $2, 24($at)
094 8C23001C LW      $3, 28($at)
098 2063FFFF ADDI    $3, $3, 0xFFFF
09C 401E2800 MFC0    $s8, $c5
0A0 17C0FFFE BNE     $s8, $0, -2
0A4 00000000 SLL     $0, $0, 0
0A8 40800000 MTC0    $0, $c0
...

So I'm like, wow, so LW is my bugged opcode? No way.

Turns out I was right to doubt though.
Project64 2.0 RSP interpreter agrees that my result was correct.

my beta   :  SR[2] = 0x00339AC0
zilmar 2.0:  SR[2] = 0x00339AC0
zilmar 1.4:  SR[2] = 0x0033A2C0

So, I got the debugger working accidentally.
But, false alarm.
Just gotta fix that on my way-old version's side and I can continue tracking to what should really be the bugged instruction point.