I suppose I'll get around to that soon.

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?Snowstorm64 wrote: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.
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.juef wrote: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)!
Yes, I too think there is another commonly occurring bug, similar to the FPU bug that prevented several ROMs from booting in the past.Snowstorm64 wrote: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?
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?MarathonMan wrote: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.
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 wrote: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?
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.Iconoclast wrote: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.
There's some regressions in the cache code (as well as some bugged RDP stuff) that worked in prior versions.Christian010 wrote:Don’t you think this version deserves to be the 0.2?
Don't forget FlashRAM save support, that is needed for Majora's Mask (my favourite Zelda all-time) to work properly.MarathonMan wrote: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!
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.Snowstorm64 wrote:Remember my compatibility list? I have tested again those games and have annotated the changes:
No use beginning to even fathom compromising the terrible originality of the MAME RDP code.MarathonMan wrote:There's some regressions in the cache code (as well as some bugged RDP stuff) that worked in prior versions.
RDP isn't vectorized, if I understand correctly? Damn. So could we see a lot of speed improvements by vectorizing the entire RDP?Iconoclast wrote:No use beginning to even fathom compromising the terrible originality of the MAME RDP code.MarathonMan wrote:There's some regressions in the cache code (as well as some bugged RDP stuff) that worked in prior versions.
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....
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).Snowstorm64 wrote:RDP isn't vectorized, if I understand correctly? Damn. So could we see a lot of speed improvements by vectorizing the entire RDP?
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.ShadowFX wrote: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.ShadowFX wrote: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?
Of course.Snowstorm64 wrote:Thanks for the replies. Every, minor too, improvements are always useful, so keep going on optimizing RSP/RDP![]()
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.Christian010 wrote:That sounds great!!![]()
Has all the regression bugs been fixed?
Users browsing this forum: No registered users and 1 guest