TLB

[MarathonMan]

It has come to my attention by using PJ64 that several ROMs (including Super Mario 64!) are not working because of CEN64's missing TLB support.

I suppose I'll get around to that soon.

[Snowstorm64]

Awesome! That would be a beautiful Christmas present for us!

[MarathonMan]

This went much smoother than I expected... (so far)...

TLB-mapped data accesses are now being resolved correctly. Or at least they appear to be.

Unfortunately, it doesn't seem to have impacted any ROMs. Perhaps I need to implement TLB-mapped instruction accesses, or perhaps there is a bug somewhere.

[MarathonMan]

TLB code accesses are now in place as well. Still, not a lot of ROMs impacted... must be a bug somewhere.

Bomberman 64 is now working, anyways.

[Snowstorm64]

Meanwhile, Paper Mario returns an error when it comes at main menu:
rdp_process_list: rdp_cmd_ptr overflow: length 0x2e480 rdp_cmd_ptr 0x0AL lib: ReleaseALC: 1 device not closed

EDIT: I couldn't reproduce this error, that's odd...

EDIT2: Mario Party2 doesn't boot anymore. I don't know if this is related to the recent commits.

[juef]

MarathonMan, you all make it sound so easy! I mean, there's very little time between those posts of yours

Seriously though, congratulations on yet other incredible achievements (SPLiT's Nacho PD, OoT fixed, and apparently a bunch of other games soon-to-be-fixed as well)!

[Snowstorm64]

Meanwhile, Paper Mario returns an error when it comes at main menu:
rdp_process_list: rdp_cmd_ptr overflow: length 0x2e480 rdp_cmd_ptr 0x0AL lib: ReleaseALC: 1 device not closed

EDIT: I couldn't reproduce this error, that's odd...

EDIT2: Mario Party2 doesn't boot anymore. I don't know if this is related to the recent commits.

I was thinking, since Paper Mario's screen is turned black due to that overflow, is it possibile that this may be same cause of several roms that at boot have a black screen?

MarathonMan, what do you think of this?

[MarathonMan]

MarathonMan, you all make it sound so easy! I mean, there's very little time between those posts of yours

Seriously though, congratulations on yet other incredible achievements (SPLiT's Nacho PD, OoT fixed, and apparently a bunch of other games soon-to-be-fixed as well)!

Well I already have had the TLB data structure sitting around in the repository for quite some time... I just never "wired it up", so to speak.

Thank you for the kind words, though.

I was thinking, since Paper Mario's screen is turned black due to that overflow, is it possibile that this may be same cause of several roms that at boot have a black screen?

MarathonMan, what do you think of this?

Yes, I too think there is another commonly occurring bug, similar to the FPU bug that prevented several ROMs from booting in the past.

[Iconoclast]

Unfortunately, it doesn't seem to have impacted any ROMs. Perhaps I need to implement TLB-mapped instruction accesses, or perhaps there is a bug somewhere.

Just figured I would make sure, but, you know how with Super Mario 64 on PJ64 the emulation is hung up if "Use TLB" was not checked--but only after a small delay since the successful boot happens anyway? Well is that the same timing of the fault here for CEN64?

The vast majority of games, of course, immediately fail to even boot if they use TLB where it's not supported, but with Super Mario 64 there is a delay until just after the 3-D text logo fades out, and before the 3-D mario head pops in. Is that the same timing for the crashing here on CEN64, or might it be controlled by something other than TLB?

[MarathonMan]

The vast majority of games, of course, immediately fail to even boot if they use TLB where it's not supported, but with Super Mario 64 there is a delay until just after the 3-D text logo fades out, and before the 3-D mario head pops in. Is that the same timing for the crashing here on CEN64, or might it be controlled by something other than TLB?

I wouldn't be surprised if it was due to something else, but I haven't been able to narrow it down if it is. I was trying to trace 1080 Snowboarding earlier today since that seems to not need the TLB in PJ64, but alas, I could not find where it goes wrong. For some reason, the VR4300 eventually starts executing out of RSP IMEM... but the bytes are all 0xFFs? It only happens several millions of instructions in, so tracing it is more or less a crapshoot.

[Iconoclast]

But, for several millions of instructions, couldn't you just add a check every cycle or whatever to compare the RSP's IMEM to check if a few bytes are set to 0xFF (not the whole 4K I guess since that's intensive) and then trace backwards from that point to see, by the stage of what VR4300 operation, the IMEM got filled with 0xFF? Or is that not enough information to extract to isolate the cause to what may probably be something else instead, like the lack of audio interface emulation in the RCP memory map?

Worst case, I guess you might have to find different games that initiate the IMEM to nothing but a bunch of crap bytes, fewer instructions deeper into the starting execution. Most of them will probably average out to the same delay you found for 1080, of course, but there is always that special, weirdly-designed N64 ROM out there for some edge condition or another, like those weird RSP boot tasks poked to the IMEM for NUS-CIC-6105 carts.

[MarathonMan]

But, for several millions of instructions, couldn't you just add a check every cycle or whatever to compare the RSP's IMEM to check if a few bytes are set to 0xFF (not the whole 4K I guess since that's intensive) and then trace backwards from that point to see, by the stage of what VR4300 operation, the IMEM got filled with 0xFF? Or is that not enough information to extract to isolate the cause to what may probably be something else instead, like the lack of audio interface emulation in the RCP memory map?

Worst case, I guess you might have to find different games that initiate the IMEM to nothing but a bunch of crap bytes, fewer instructions deeper into the starting execution. Most of them will probably average out to the same delay you found for 1080, of course, but there is always that special, weirdly-designed N64 ROM out there for some edge condition or another, like those weird RSP boot tasks poked to the IMEM for NUS-CIC-6105 carts.

The problem is, even with MESS (which boots the ROM), RSP IMEM gets cleared with 0xFFs after it finishes executing in that region. So both CEN64 and MESS blow out RSP IMEM after they finish the initial pass. MESS, however, never tries to execute data out of the RSP IMEM in the next step (it looks like it goes to handle an interrupt or something instead). CEN64 just goes back into RSP IMEM, when it shouldn't. At least, this looks like what is happening... I haven't been able to determine much more than this.

Debugging assembly is hard.

[MarathonMan]

TLB bugs fixed.

[Christian010]

Awesome!!

Great work MarathonMan, lots of rooms should be benefited from this.

Don’t you think this version deserves to be the 0.2?

[MarathonMan]

Don’t you think this version deserves to be the 0.2?

There's some regressions in the cache code (as well as some bugged RDP stuff) that worked in prior versions.
I want to fix those regressions before slapping a v0.2 label on things, but v0.2 will be here soon!

[Snowstorm64]

I have just....all over my desktop...

Super Mario 64 <3!

There's some regressions in the cache code (as well as some bugged RDP stuff) that worked in prior versions.
I want to fix those regressions before slapping a v0.2 label on things, but v0.2 will be here soon!

Don't forget FlashRAM save support, that is needed for Majora's Mask (my favourite Zelda all-time) to work properly.

[juef]

This is simply incredible!

[Snowstorm64]

Remember my compatibility list? I have tested again those games and have annotated the changes:

21/10/2013 vs 28/12/2013 (Data cache, TLB, CP1 opcodes....)

Some games that saw improvements:
*Super Mario 64 (from "Game crashes at main menu" to "Playable, some graphical issues"
*Rayman 2 - The Great Escape (The game doesn't seem hang anymore, but now it has weird issues that severely ruin gaming experience, especially in the flying ship scene. However there has been an improvement overall)

...And games that are affected by regressions:
*Bomberman64 (from "Playable" to "Black Screen" NOTE: was playable with TLB implemented, but with last commits doesn't work anymore)
*Glover ( from "Playable, some graphical issues" to "Black Screen")
*International Superstar Soccer 64 (from "Playable, mempak issues" to "Black Screen")
*International Superstar Soccer '98 (Same as before, but also controls don't work)
*Jet Force Gemini (Same as before, but also control don't work)
*Mario Party 2 (from "Playable, some weird issues, some graphical issues, game may hangs at some point" to "Black Screen")
*Mega Man 64 (from "Playable, some graphical issues" to "Black Screen")
*Mortal Kombat 4 (Same as before, but hangs after main menu)
*Pilotwings 64 (from "Playable" to "Black Screen")
*Star Wars - Shadows of the Empire (from "playable" to "game hangs at Lucasfilm's copyright")

[MarathonMan]

Remember my compatibility list? I have tested again those games and have annotated the changes:

Yup, these are most likely all broken with one of the recent VR4300 commits that I'm trying to fix before slapping a v0.2 label on it.

[Iconoclast]

There's some regressions in the cache code (as well as some bugged RDP stuff) that worked in prior versions.

No use beginning to even fathom compromising the terrible originality of the MAME RDP code.

It will take weeks--no, months--to not only vectorize everything, but make things more apt to work with on bettering overall.

You might as well leave it to me.
All in due time....

[Snowstorm64]

There's some regressions in the cache code (as well as some bugged RDP stuff) that worked in prior versions.

No use beginning to even fathom compromising the terrible originality of the MAME RDP code.

It will take weeks--no, months--to not only vectorize everything, but make things more apt to work with on bettering overall.

You might as well leave it to me.
All in due time....

RDP isn't vectorized, if I understand correctly? Damn. So could we see a lot of speed improvements by vectorizing the entire RDP?

[Iconoclast]

I haven't specifically checked the RDP branch of MarathonMan's code network in a while, but last I remember from his words on the general status of things (and to my own general knowledge of them), there is no way that the RDP has been vectorized, by anybody (probably even MooglyGuy, though he alluded to having it done some time).

It is way too massive of a code base full of a colossal variety of things that SIMD vector math could have been applied to, so it will take a very long time to efficiently have everything done in even a SSE2 style. I'm sure MarathonMan is much more busy fixing core CPU bugs after focusing so much on speed first, before he'll have the time to make a significant impact on the mess that is the MESS RDP code.

[MarathonMan]

RDP isn't vectorized, if I understand correctly? Damn. So could we see a lot of speed improvements by vectorizing the entire RDP?

I vectorized the easy pickings from the RDP. I also applied some optimizations that were low-hanging fruit and some things that Iconoclast and I discussed (and some things that he implemented, and gave to me in a copy of source that may or may not have been released elsewhere).

Overall, though, the RDP leaves a lot to be desired.

It's basically been passed through the hands of at least three or four people who were, to be fair, mostly concerned with accuracy and respectable performance. Nobody, to the best of my knowledge, has gone over the entire thing with a fine toothed comb and gone balls-to-the-wall optimization, especially where vectorization is concerned (heck, until CEN64 came to be, a vectorized implementation of the RSP had never been attempted -- Iconoclast and myself were the first in that regards, too...).

As it stands right now, the RSP is probably the most time-consuming component of CEN64 per my measurements. Sometimes, the VR4300 can suck up more juice, but there's not a lot to be done that can help in that regards. OTOH, I had ~10% boost in overall performance today by hoisting loads out of the RSP vector unit and making more effective use of the processor.

I look forward to your wizardry, Iconoclast.

[ShadowFX]

Wow, much improvements since last I checked. I guess another complete compatibility run through is in order once most of the regressions are ironed out. We could also check the more problematic titles or those that are affected frequently. Any recommendations as to which titles those could be?

[Snowstorm64]

Thanks for the replies. Every, minor too, improvements are always useful, so keep going on optimizing RSP/RDP

Wow, much improvements since last I checked. I guess another complete compatibility run through is in order once most of the regressions are ironed out. We could also check the more problematic titles or those that are affected frequently. Any recommendations as to which titles those could be?

Most notably Donkey Kong 64 and every other Rare titles. Also, Earthworm Jim 3D has severe graphical issues, Top Gear Rally has collision detection issues, Mario Party often crashes during minigames. Due to lack of FlashRAM save support, Majora's Mask has weird issues and Pokémon Snap can't save. Rayman 2 has camera issues in the flying pirate ship. Other games simply hang or don't start without Memory Pak.

[MarathonMan]

Wow, much improvements since last I checked. I guess another complete compatibility run through is in order once most of the regressions are ironed out. We could also check the more problematic titles or those that are affected frequently. Any recommendations as to which titles those could be?

I'd hold off on a compatibility test until v0.2... there's a few known bugs that are preventing some ROMs from even booting.

Thanks for the replies. Every, minor too, improvements are always useful, so keep going on optimizing RSP/RDP

Of course. Latest version should give everyone at least a extra VI or two, if not more. Lots of SSE and RSP wizardry.

[MarathonMan]

Cache bug regressions from TLB are now fixed. At least Bomberman is able to boot again.

[Christian010]

That sounds great!!

Has all the regression bugs been fixed?

[MarathonMan]

That sounds great!!

Has all the regression bugs been fixed?

Not sure. The RDP one still exists (i.e, Doom 64 intro), but I might just revert the changes that caused that since they are optimization-related bugs.