TLB

Discuss topics related to development here.
Post Reply
User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

TLB

Post by MarathonMan » Sat Dec 21, 2013 3:22 pm

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. :D

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: TLB

Post by Snowstorm64 » Sat Dec 21, 2013 3:53 pm

Awesome! That would be a beautiful Christmas present for us! :D
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

Re: TLB

Post by MarathonMan » Sat Dec 21, 2013 7:09 pm

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.

User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

Re: TLB

Post by MarathonMan » Sat Dec 21, 2013 7:22 pm

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. :D

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: TLB

Post by Snowstorm64 » Sat Dec 21, 2013 7:35 pm

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.
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
juef
Posts: 31
Joined: Sun Oct 27, 2013 10:19 pm

Re: TLB

Post by juef » Sun Dec 22, 2013 9:21 am

MarathonMan, you all make it sound so easy! :D 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)!

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: TLB

Post by Snowstorm64 » Sun Dec 22, 2013 9:38 am

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.
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?
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

Re: TLB

Post by MarathonMan » Sun Dec 22, 2013 1:09 pm

juef wrote:MarathonMan, you all make it sound so easy! :D 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. :D

Thank you for the kind words, though.
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?
Yes, I too think there is another commonly occurring bug, similar to the FPU bug that prevented several ROMs from booting in the past.

User avatar
Iconoclast
Posts: 47
Joined: Fri Oct 04, 2013 8:00 pm

Re: TLB

Post by Iconoclast » Sun Dec 22, 2013 9:46 pm

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.
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?

User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

Re: TLB

Post by MarathonMan » Mon Dec 23, 2013 2:45 am

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?
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.

User avatar
Iconoclast
Posts: 47
Joined: Fri Oct 04, 2013 8:00 pm

Re: TLB

Post by Iconoclast » Mon Dec 23, 2013 1:53 pm

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.

User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

Re: TLB

Post by MarathonMan » Mon Dec 23, 2013 3:35 pm

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.
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. :(

User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

Re: TLB

Post by MarathonMan » Sat Dec 28, 2013 12:32 pm

TLB bugs fixed. :D
Attachments
mario64-2.png
mario64-2.png (114.93 KiB) Viewed 9229 times
mario64.png
mario64.png (100.28 KiB) Viewed 9230 times

User avatar
Christian010
Posts: 5
Joined: Mon Nov 18, 2013 9:38 pm

Re: TLB

Post by Christian010 » Sat Dec 28, 2013 1:04 pm

Awesome!! :D :D

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

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

User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

Re: TLB

Post by MarathonMan » Sat Dec 28, 2013 1:07 pm

Christian010 wrote: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!

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: TLB

Post by Snowstorm64 » Sat Dec 28, 2013 1:26 pm

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

Super Mario 64 <3!
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!
Don't forget FlashRAM save support, that is needed for Majora's Mask (my favourite Zelda all-time) to work properly. :P
Last edited by Snowstorm64 on Sat Dec 28, 2013 3:55 pm, edited 2 times in total.
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
juef
Posts: 31
Joined: Sun Oct 27, 2013 10:19 pm

Re: TLB

Post by juef » Sat Dec 28, 2013 2:09 pm

This is simply incredible! :D

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: TLB

Post by Snowstorm64 » Sat Dec 28, 2013 6:33 pm

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")
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

Re: TLB

Post by MarathonMan » Sun Dec 29, 2013 2:03 am

Snowstorm64 wrote: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.

User avatar
Iconoclast
Posts: 47
Joined: Fri Oct 04, 2013 8:00 pm

Re: TLB

Post by Iconoclast » Sun Dec 29, 2013 4:52 pm

MarathonMan wrote: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. :P
All in due time....

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: TLB

Post by Snowstorm64 » Sun Dec 29, 2013 7:34 pm

Iconoclast wrote:
MarathonMan wrote: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. :P
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?
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
Iconoclast
Posts: 47
Joined: Fri Oct 04, 2013 8:00 pm

Re: TLB

Post by Iconoclast » Sun Dec 29, 2013 7:54 pm

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.

User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

Re: TLB

Post by MarathonMan » Sun Dec 29, 2013 8:28 pm

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?
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. :D

User avatar
ShadowFX
Posts: 86
Joined: Sat Oct 05, 2013 2:08 am
Location: The Netherlands

Re: TLB

Post by ShadowFX » Mon Dec 30, 2013 6:35 am

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?
"Change is inevitable; progress is optional"

OS: Windows 10
Specs: Intel Core i7-7700K @ 4.2GHz, 16GB DDR4-RAM, NVIDIA GeForce GTX 1080 Ti
Main build: AVX (official)

User avatar
Snowstorm64
Posts: 303
Joined: Sun Oct 20, 2013 8:22 pm

Re: TLB

Post by Snowstorm64 » Mon Dec 30, 2013 9:45 am

Thanks for the replies. Every, minor too, improvements are always useful, so keep going on optimizing RSP/RDP ;)
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?
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.
OS: Debian GNU/Linux Jessie (8.0)
CPU: Intel i7 4770K @ 3.5 GHz
Build: AVX (compiled from git)

User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

Re: TLB

Post by MarathonMan » Mon Dec 30, 2013 2:46 pm

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.
Snowstorm64 wrote:Thanks for the replies. Every, minor too, improvements are always useful, so keep going on optimizing RSP/RDP ;)
Of course. :lol: Latest version should give everyone at least a extra VI or two, if not more. Lots of SSE and RSP wizardry.

User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

Re: TLB

Post by MarathonMan » Mon Dec 30, 2013 8:45 pm

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

User avatar
Christian010
Posts: 5
Joined: Mon Nov 18, 2013 9:38 pm

Re: TLB

Post by Christian010 » Wed Jan 01, 2014 10:10 pm

That sounds great!! :D

Has all the regression bugs been fixed? :?:

User avatar
MarathonMan
Site Admin
Posts: 691
Joined: Fri Oct 04, 2013 4:49 pm

Re: TLB

Post by MarathonMan » Fri Jan 03, 2014 10:24 am

Christian010 wrote:That sounds great!! :D

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.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest