Bounty to add dynarec core for Wii U port of either Beetle PSX or PCSX-R emulator [$470]

[roflcopter777]

Just to reemphasize the bounty goal for this project:

• Dynamic recompilation can add support for a Playstation core.
• Full speed dynarec on the Wii U using the PCSX-R/PSX core or really; this can eventually lead the way to future cores such as well. All in all, the ultimate goal is getting PSX running full speed on the Wii U. That's all this is focusing on.

Update 4-25-18: Title of thread bounty has been changed to reflect that it should be PCSX-R or any PSX core that has a dynarec core.

The ultimate goal, is once more, full speed dynarec on the Wii U of any PSX core that RetroArch currently uses, this can eventually lead the way to future cores in being ported, That's all this is aiming for.

---

Update: Spoke with developer of WiiSX-R, a PCSX port on the Wii, Mystro256 who stated the Dynarec is publicly available on GitHub, and since Wii and Wii U both use PPC, I figure I'd link both on here:

PPC source https://github.com/Mystro256/wiisxr/tree/master/ppc Main WiiSX-R GitHub https://github.com/Mystro256/wiisxr

Disclaimer: The end goal is getting as much support as possible, the higher the donations the better, to support those who write the PPC dynarec. Thank you for your understanding.

It's well-established that the Wii U is more powerful than what the Virtual Console has shown, notably with NERD (Nintendo European Research and Development)'s efforts in their Nintendo DS emulation. There is untapped potential in the Wii U hardware and showing it is more than capable in running respective emulators for Nintendo 64 and Playstation (Mupen64 and PCSX-R). With that said, I wish to open this as a bounty to rally the support of those interested and wanted to throw my own hat into the ring, and I know of some other people who would be interested in contributing to see the Wii U to its full emulation potential.

• If this bounty amount is not enough, it can be increased to twice the amount or 150 dollars USD.
• Dynamic recompilation can add support for Beetle PSX/Playstation.

The end goal is to unlock the power of the Wii U, but also adding support for a plethora of cores that have not been possible.

The end goal to any developer who is assigned to this task:

• Full speed dynarec on the Wii U using the PCSX-R core, this can eventually lead the way to future cores in being ported, but the ultimate goal is getting PSX running full speed on the Wii U. That's all this is aiming for.

--- There is a **[$120 open bounty](https://www.bountysource.com/issues/44566014-bounty-to-add-dynarec-core-for-wii-u-port-of-beetle-mednafen-psx?utm_campaign=plugin&utm_content=tracker%2F296058&utm_medium=issues&utm_source=github)** on this issue. Add to the bounty at [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F296058&utm_medium=issues&utm_source=github).

[embercold]

Oh, with a framerate like that I could probably manage to get it to stable 60 fps without using a real dynarec, just some preprocessing. Though this option I'll use only if everything else fails. That aside, does the sound work at all? It'll stutter like crazy, I know, but I'm not looking forward to fixing yet another plugin.

[Ploggy]

Audio works.. it stutters like you say but seems ok, I think cd audio is missing though.. But you said you had to remove that before?

[embercold]

@Ploggy Yes, the Wii is missing the pthread library, so I had to cut it off early on. Luckily, it's been ported to devkitPro sdk recently, so it won't be a problem. It just weren't a priority till now. It's also a prerequisite for offloading graphics onto another core, which will yield a couple extra fps, I think. upd: Note that I don't put much hope into getting the classic Wii run smoothly yet - I estimate it'll require extra two weeks of work at my pace, and I'd rather have the WiiU running first. Still, it's a good platform for debugging, if anything.

[Ploggy]

The fact your looking into the Wii at all is commendable. I'm personally all about the WiiU :P but I'm sure there's alot of people who would like to see a pcsx-rearmed Core running smoothly on the Wii :) There's always WiiSX of course but I'd guess that's quite abit behind pcsx-rearmed by now.

[hizzlekizzle]

exciting stuff! Congrats on the breakthroughs, embercold :)

[Ploggy]

I'm a little scared to write this message :P How are things going? I saw your latest commit, "Final cleanups before getting shelved"? have you hit another roadblock?

[Ploggy]

@embercold I managed to compile your latest commits :) The Graphics have made a big improvement! No more LSD visuals :) There are some weird texture issues here and there and it looks like there's vertical scanlines :P

Here's a vid of MegaMan in action. https://youtu.be/sPR1Wcr7CYM

[jrb00]

Yessss this was the kinda news I needed after a day like today. Thanks @embercold @ploggy!

[MarceloMachadoxD]

• astonishing, amazing... Its incredible progress... Clap clap clap

Em ter, 3 de ago de 2021 19:24, jrb00 @.***> escreveu:

Yessss this was the kinda news I needed after a day like today. Thanks @embercold https://github.com/embercold @Ploggy https://github.com/Ploggy!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/libretro/RetroArch/issues/4852#issuecomment-892205926, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGZ2DGZIBHXJONEUJIIGJLT3BUANANCNFSM4DJFBOQQ .

[embercold]

It's fine now, sorry for worrying you. I've really had a setback - there were a pair of outright nasty bugs that I spent literally days pinning down (there was a faulty byte order swapping function responsible for those vertical lines, and an another where DMA6 stored a list terminator ignoring the host byte order). I couldn't put any ETA on them, I was frustrated, so I didn't check in. Now, the graphics part is done with, and I can move on to the good stuff. I've updated my dropbox folder with the latest cores. Thank you for your patience!

[pcercuei]

@embercold are you going to integrate Lightrec? It doesn't support big-endian officially, but I had it working at some point on PPC big-endian, in a separate branch, so it should be pretty easy to get it to work.

[embercold]

@pcercuei Oh, hey there! Great work on the lightrec - It was most curious watching you guys brainstorming back then. Now, yes, I'll at least try to - I'm more or less acquainted with the codebase, and it'd be interesting to see how it compares against the pcsx's approach. From what I've seen, managing multithreading and making it use custom W^X switching without breaking any compatibility will be trickier than the actual BE/PPC work.

[Ploggy]

Outstanding! the Graphics are looking amazing :) All the games I've tested are great! I'm glad your still around :) I was a little worried when I saw you last Commit message :P I thought that was it lol There is a small issue with FMV sequences (as you can see in a couple of the the pics below) I would take more screenshots, but it would just be pics of games looking as they supposed to :)

As always, Thank You very much for your work :)

[embercold]

@Ploggy Hey, mate! I apologize for not replying sooner - I wasn't in the right frame of mind for communicating. Now, on your screenshots, there are vertical bands on some title screens. I know of the problem - it's likely a byte order issue again - but I'll move on to more important things for now. I'm very angry with how much time the gpu plugin cost me, so I need a change of pace.

[Ploggy]

@Ploggy Hey, mate! I apologize for not replying sooner - I wasn't in the right frame of mind for communicating. Now, on your screenshots, there are vertical bands on some title screens. I know of the problem - it's likely a byte order issue again - but I'll move on to more important things for now. I'm very angry with how much time the gpu plugin cost me, so I need a change of pace.

Hi. No probs at all. :) In the grand scale of issues it's extremely minor.. it doesn't effect gameplay at all. You work on whatever you need to :)

[embercold]

@Ploggy Here's a new new batch of builds for you to test. Admittedly, I didn't get much work done today, but I got rid of the graphical glitch in title screens, re-enabled the Wii dynarec, and finally made a half-assed hack job of an attempt to get the dynarec running on the WiiU, using aliaspider's method of running the generated code from MEM0. Please keep your expectations low, though: the ppc_dynarec still crashes in some games (e.g. Crash Bandicoot seems playable, and Spyro freezes during the opening), and I have no idea if the WiiU build is supposed to work at all. But if you do manage to get in-game, I'd like to hear of framerates and possible visual glitches.

[vaguerant]

@embercold I'm not Ploggy, but I was interested and tested the Wii U build. The core itself runs, but loading a game, it immediately stack dumps.

[Ploggy]

@Ploggy Here's a new new batch of builds for you to test. Admittedly, I didn't get much work done today, but I got rid of the graphical glitch in title screens, re-enabled the Wii dynarec, and finally made a half-assed hack job of an attempt to get the dynarec running on the WiiU, using aliaspider's method of running the generated code from MEM0. Please keep your expectations low, though: the ppc_dynarec still crashes in some games (e.g. Crash Bandicoot seems playable, and Spyro freezes during the opening), and I have no idea if the WiiU build is supposed to work at all. But if you do manage to get in-game, I'd like to hear of framerates and possible visual glitches.

Hey, sorry to say but all the games I've tried on WiiU crash and throws a DSI Error, the Code is always the same no matter what game I try. On the Wii side I've had better luck :) Bust a Move 2 = 30FPS avg Colin McRae Rally = 30FPS avg Pandemonium = 38 FPS avg Megaman X 4 = 29 FPS avg Mortal Kombat Trilogy = 31 FPS avg R-Type Delta = 20 FPS avg No graphical glitches that I could see :) (and no Vertical lines either) ;)

EDIT: @vaguerant sniped meh :P

[embercold]

@vaguerant @Ploggy Thanks! That's at least something to work with. The "malformed instruction" is likely a misnomer, it seems that the memory region isn't marked for execution. Maybe I forgot to do something, or maybe the method itself is unsound. Next time we'll check if the official method for executable memory works. Now, about the Wii framerates, does it mean that the games are running at half speed and the sound is stuttering?

[vaguerant]

Just to confirm, games run again if you disable the dynarec in core options. Since you can't get to those without loading a game (which doesn't work), I just went to sd:/retroarch and edited my retroarch-core-options.cfg to add:

pcsx_rearmed_drc = "disabled"

[Ploggy]

@vaguerant @Ploggy Thanks! That's at least something to work with. The "malformed instruction" is likely a misnomer, it seems that the memory region isn't marked for execution. Maybe I forgot to do something, or maybe the method itself is unsound. Next time we'll check if the official method for executable memory works. Now, about the Wii framerates, does it mean that the games are running at half speed and the sound is stuttering?

Sound does stutter like crazy :P (I added a few more games ^^) FPS increase slightly in menus and loading screens but when ingame they all tend to hover around 30 FPS

EDIT: ok I found a game with some graphic glitches :P Grand Turismo 2 = 30 FPS

[embercold]

Well, okay? I never expected it to be that easy anyway, but couldn't help taking pot shots at the problem :3 We're done testing for today, thanks. I need some more in-depth knowledge of the WiiU to continue anyway. The Wii is likely crippled by the software renderer performance, but I'll try to do some tests just to be sure.

@Ploggy That's a good one with Granny Turismo 2! Now I wonder how THAT could've happened (upd: except, yes, it's likely that I messed up porting the recompiler).

[Ploggy]

Just to confirm, games run again if you disable the dynarec in core options. Since you can't get to those without loading a game (which doesn't work), I just went to sd:/retroarch and edited my retroarch-core-options.cfg to add:

pcsx_rearmed_drc = "disabled"

Thanks for the tip :) but I had to edit the PCSX-ReARMed.opt file in the retroarch/config/PCSX-ReARMed folder :) Confirmed no more vertical lines in FMV sequences on WiiU ;)

[ashquarky]

wow, PROG exceptions actually work! I always thought the exeception handler missed those.

I mentioned the complexity of JITing on the WiiU above, though I did also get a proposal together that seems liked for an API to hide it in libretro-common. something along the lines of:

• get jitmem size/restrictions on allocation
• allocate/free maybe-executable memory (can't use regular malloc/free)
• lock an allocation for writing (W^X)
• unlock an allocation (for executing) (^WX)

Wii U would only be able to provide one large allocation, which I understand is how most emulators work anyway, but the idea is to accommodate lots of platforms and at least mprotect systems can allocate arbitrarily. I'll probably file another issue about this later and start work on it.

Going forward with the hacky answer for now, I think that memory area should be rwx in most homebrew setups today (note vaguerant is using the HBL channel, and ploggy is using the RetroArch forwarder channel), and the exception handler actually has separate handling for unmapped/non-executable memory areas, so the CPU really does think it's been fed a malformed instruction. I suspect it's a caching issue - the Wii U's caches, much like the Wii's, aren't coherent, so it's possible the instructions are caught up in the data or instruction cache and the CPU is seeing old memory. Note the Wii's DCFlushRange and ICInvalidateRange, which gets everything sync'd up. The Wii U actually has very similar functions (identical?) - I'd suggest putting those in and seeing if it gets the JIT further.

[embercold]

@Ploggy Here's a new core for you to test. It doesn't have a dynarec, rather, I cooked a pair of manifest files that'll hopefully enable the official codegen api for the core. What I need is for you to tell me what the cgenmode field in the osd message says. This exact core requires that all of the files are present in the same folder (don't forget to get rid of them once you're done), and it's preferable that you try to to run it both through the retroarch and the homebrew loader or something. As with the previous try, I don't expect much success from this.

@QuarkTheAwesome Yeah, I've disabled those funcs before trying the previous approach, as it's tiring to do dynamic function load all the time, but the code buffer was written by the core anyway. Maybe it'll work if I get them back. Anyway, do you know if the approach I lifted from aliaspider's ppsspp fork - allocating a heap at 0x00802000-0x01000000, which is supposed to be MEM0, and immediately treating it as RWX memory - is supposed to work at all? Because it doesn't make sense to me. My best guess is that this is related to how the vWii works - apparently it allows the entire Wii address space to be RWX.

For now I have two options to get a real dynarec going: either I get the official codegen API working, or I use the GX exploit to write to an array within the core's code segment. The API is much much more preferable, being official, managing the W^X crap for me and all, but there seems to be a reason why nobody uses it. The exploit will likely be unstable, fw version dependent, or will be limited to Homebrew Launcher to work. It's also an exploit, so it'll be guaranteed to crash with no explanation if misused. No good material for a common api here.

Of course I can get this exact core running full speed by writing a cached interpreter. This is outside the issue, so I won't get the cake? If I can't manage this, then I maybe try to pull some competent wiiu homebrewer to finish the job.

[Ploggy]

@embercold Testing your new build from HBL and from the Retroach\core folder both show cgenmode=0 I guess that's bad?

[embercold]

@Ploggy Well, yes, it means that the official API is unavailable. Again, I didn't put much stock in this method. I'll go with the exploit next - this is practically the only method for a true dynarec remaining.

[Ploggy]

Damn, I really hope this GXploit method works then if its the last chance for Dynarec.. I saw you mention you could probably achieve fullspeed PS1 emulation with a Cached Interpreter, which of course is awesome, but the hope (my hope) was whatever path you made to get Dynarec running on WiiU could eventually be used be others to bring other Cores that require Dynarec to run fullspeed on WiiU :)

@QuarkTheAwesome didnt you (may have been someone else) say that full access can be had with Aroma?

[ashquarky]

please don't put an exploit in a libretro core! I'm trying to say that the "MEM0" (I don't think it's actually mapped to MEM0) approach will work fine for most Wii U setups and is okay for development at least, and I'm planning on adding an abstraction to retroarch/libretro-common for a more robust solution. There is a reason it's mapped as RWX sometimes, it's long and historical, I'll write it up in another message but yeah. I would strongly suggest trying it with your existing code and adding a DCFlushRange/ICInvalidateRange pair of calls before jumping to it, it'll almost certainly make a difference to those errors. On Wii U, you should be able to just add the signatures without any extra dynamic loading guff, since the core is statically linked it'll pick up the version in RetroArch itself. Will follow up with a more detailed message, just wanted to be like "nooooooo!!" quickly, haha

[ashquarky]

So, the deal with the RWX/MEM0 thing, in all its long and historical goodness:

The Wii U has a completely different memory layout than the Wii - you can see a pretty outdated table here (the Description column is showing its age). Generally everything is in MEM2 - MEM1 and MEM0 are both used for like, GPU textures and things. The wiki calls MEM0 "Some sort of hardware communication area" which I find very entertaining.

Current wiiu homebrew (including RetroArch) uses the .rpx format, which is the same as what games use. The OS loads the code and data segments into different memory areas with different permissions, as you would expect from a W^X system.

Before 2017, HBL didn't support .rpx files, and instead used a custom .elf format. How this worked is that when you first ran whatever exploit to get homebrew going, it would poke into the kernel and add a new memory mapping for 0x00800000, which normally doesn't exist in Wii U mode. This mapping pointed to some unused bit of MEM2, and notably was RWX. .elf files could then be loaded in and ran from that area. Modern versions of HBL still do this for backwards compatibility reasons.

Since RetroArch/PPSSPP are .rpx homebrews, they don't have any code or the like in the old HBL area, but the mapping is still there, and still RWX, which is why they can drop JIT code in it. The heap is just for convenience, I suppose.

The reason I was a bit antsy on this when discussing it before is that homebrew environments are starting to drop support for .elf homebrew, and therefore also removing the RWX mapping. This is true of e.g. Aroma. To make up for it, Aroma enables the official codegen api. Some versions of the HBL channel also do this (as far as I know).

(Aroma actually does have an rwx mapping at that address, but it's used to store plugins, and overwriting it would go very badly. I kinda wish it had been moved to a new address, but hey.)

Anyway, that's why that, for Backwards Compatibility, most homebrew'd Wii Us have an RWX mapping at that address, but you can't rely on it since soon that will stop being the case. Should be fine for development though, and it does work for PPSSPP.

[ashquarky]

I had a go myself, and can confirm that commenting out the #ifndefs on line 39 and 2917, applying #12758 to your RetroArch tree and building does make the -rec branch not crash. Black screen though, and I don't know nearly enough about the PSX to actually investigate that further.

[Ploggy]

@QuarkTheAwesome can you upload that build? I wouldn't mind testing it to see if it black screens my end :)

[embercold]

@QuarkTheAwesome The only code that matters in this case is recompiler memory allocation. If the code is correct, but it crashes anyway, then the method itself is unsound. The recompiler is somewhat broken at this point, but at the very least it runs the firmware and the Crash Bandicoot game all right.

Moreover, I don't think that getting an entire exploit into a core would work - it'll likely interfere with whatever the user used to launch RA. I'm thinking of using the existing HBL exploit. Do you think this handy little syscall will be available for software to use? Or maybe we can wait a year or two for someone enabling the codegen memory :)

@Ploggy I've made the adjustment, you can get the build from this dropbox folder. Again, you really shouldn't put your hopes in this one.

upd: as for me, I'm now trying to restore the multithreading on the Wii so that I could start porting the lightrec.

[Ploggy]

@embercold hehe yea blackscreen (no OSD though?) anyway was worth a shot. :P Nice, if you manage to restore the multithreading on Wii, will that translate to the WiiU too?

@QuarkTheAwesome the build you tested had a blackscreen but showed the OSD? (I saw your pic on the discord)

[embercold]

@Ploggy Most of the work will translate, yes. What I'm making is a polyfill, basically, an implementation of the missing libraries using libogc functions. These tend to be small, so once I'm done with the interfaces, I'll likely have both the Wii and WiiU versions done fast. Then I'll have to test and maybe repair the multithreaded gpulib.

[Ploggy]

@Ploggy Most of the work will translate, yes. What I'm making is a polyfill, basically, an implementation of the missing libraries using libogc functions. These tend to be small, so once I'm done with the interfaces, I'll likely have both the Wii and WiiU versions done fast. Then I'll have to test and maybe repair the multithreaded gpulib.

Ok, thanks for the explanation :) sounds like Multithreading could give you another nice FPS bump too :)

[carnage702]

nice to see this progressing, atleast if the wii version works we can overclock it with wiivc injection incase the wiiu version gets issues xD and with wiiu gamepad support too xD

[Ploggy]

@embercold Great news the Dynarec DOES work :) the Build @QuarkTheAwesome made with the fixes he suggested work fine I'm not sure why the latest test you provided crashed for me. While the Dynarec does work, some games see an improvement while others seem to perform worse :P I guess that's where the tweaking comes into play? :)

I've made a games comparison with "Rec on" and Rec off"

Bust A Move 2 (has no background music) Rec on=48 FPS Rec off=43 FPS (the FPS doesn't really convey the speed improvement, its quite noticeable) Castlevania Rec on=54 FPS Rec off=45 FPS Colin McRae Rally Rec on=24 Rec off=40 (this is one of those games that actually performs worse with Rec on) Cool Boarders 2 Rec on=44 Rec off=45 (this games FPS doesnt convey the games speed difference, the game does run faster with Rec on even tho the FPS suggests its slower) Megaman X4 Rec on=54 Rec off=45 Mortal Kombat Trilogy Rec on=59 Rec off=48 (feels fullspeed, no background music though) Pandemonium! Rec on=54 Rec off=47 R-type Delta Rec on=(fluctuates wildly) Rec off=38 (definitely worse with Rec on)

Those are the games I've tested so far :) It's great.. the Dynarec WORKS!! lol

[ashquarky]

@embercold I submitted some fixes to your branch, it seems to work fine on Wii U. not the fastest yet but it's great progress!

[embercold]

@Ploggy @QuarkTheAwesome Sweet! You've really lived up to your name today, Quark, probably saving me days of work. On my end, I hope to finish the polyfill and lightrec work this Monday, then I can go on optimizing, if it's necessary.

Now, there can be any number of reasons to the recompiler being slower than the interpreter, but I suspect thrashing: PSX games tend to hotswap their code, so the simple thing that is ppc_dynarec may be forced to flush its code often, starting anew every frame at worst. From what I've seen, lightrec sidesteps this problem by running the code using its built-in interpreter while it's recompiling, so I expect it to do better. This is all hypothetical, though, and I'll definitely need to do some tests to confirm.

[embercold]

The Wii polyfill is done, as is the threaded gpulib. The latter makes no sense whatsoever for the Wii, at it only has one core available, so it's expected to turn the game into a slideshow (more than it is already anyway). The CD audio did work but it's either broken or unstable? It's not a priority for now. I also stopped pretending that I care about the GC. The Wii build is available from my dropbox. Building the core will now require the LIBOGC variable to point to libogc root.

I'll be doing the WiiU polyfill and Lightrec next. Hopefully I'll get to finish the issue this week, as I'm getting antsy. Hell, I spent more time on this already than I did on a cycle-accurate psxcpu interpreter last month!

[Ploggy]

Hey @embercold :) Is there any setting I have to enable for this polyfill? because with this new build all the games I've tested so far are all the speed as the last Wii build you provided? I have seen the new Threaded Rendering Option but as you said its pointless to enable on Wii due to the Single Core CPU I think its probably for the best to retire the GC port. It's hard enough getting Wii and WiiU working. I'm looking forward to the WiiU ployfil, Lightrec and Threaded gpulib additions :)

[embercold]

@Ploggy For now you can test whether the CD audio and threaded rendering are working at all. The Wii build, while useless for gaming, may still reveal bugs which will carry over to WiiU. In a day I hope to get lightrec going, though admittedly, I've yet to write any code for it.

upd: Oh, cool! libretro headers already have the necessary WiiU functions in them. Hopefully I can get threads going on the WiiU today.

[Ploggy]

Hey @embercold sorry for the late replay I had to sleep. On Wii there are two Threaded Options.. The one that you added to the Game Options Menu called "Threaded Rendering and one in the Video Settings called "Threaded Video" If I have both Threaded Rendering and Threaded Video enabled the same time Pcsx_Rearmed Core becomes unstable and crashes alot more, so the tests will be with only your Threaded Rendering option enabled :) (actually it seems just having Threaded Rendering enabled makes the Wii Core more unstable too)

With Threaded Rendering enabled (Sync/Async) the MEM2 numbers fluctuate pretty fast, with it disabled it barely moves suggesting the Threaded Renderer is working? :) (it does stutter more too) ;)

Background music is now working in Bust A Move 2 and in Mortal Kombat Trilogy!!

[embercold]

@Ploggy Great, thanks. I don't know about the core crashing - it's entirely possible that the core itself relies on the details of multithreading as it is implemented on the PC - it this is the case, I'll have to scale down its use until the core's stable. Good catch on the MEM2 memory usage - I'll look into it. CD audio, though, I'll likely make sequential, rather than threaded - this will have a negligible performance loss on anything not running from a spinning disc.

Today I've tried to re-enable threading on the WiiU. Still no lightrec, unfortunately. I'm running blind here, so the build may not do anything at all, but here it is, in my dropbox. Hopefully I'll get cemu running Retroarch so that I won't have to bother you for testing every small thing.

[Ploggy]

@Ploggy Great, thanks. I don't know about the core crashing - it's entirely possible that the core itself relies on the details of multithreading as it is implemented on the PC - it this is the case, I'll have to scale down its use until the core's stable. Good catch on the MEM2 memory usage - I'll look into it. CD audio, though, I'll likely make sequential, rather than threaded - this will have a negligible performance loss on anything not running from a spinning disc.

Today I've tried to re-enable threading on the WiiU. Still no lightrec, unfortunately. I'm running blind here, so the build may not do anything at all, but here it is, in my dropbox. Hopefully I'll get cemu running Retroarch so that I won't have to bother you for testing every small thing.

It's no problem I don't mind testing anything you post, it all helps the end goal :) I'm getting this Core crash whenever I enable Threaded Rendering: (happens on both Sync/Async)

[embercold]

@Ploggy Well, that's still something to work with, even if I can't make head or heels of this debug dump? Does it work at all without threaded rendering? Does CD audio work? Does it work if you disable the recompiler?

[Ploggy]

@QuarkTheAwesome any idea what that DSI Error above refers to?

Games tested With Dynarec = Enabled and Threaded Rendering = Disabled: Bust A Move 2 now freezes at a loading screen just before start the first stage. Mortal Kombat Trilogy Says "CD Error" before selecting Mortal Kombat Megaman X 4 works, same performance as before :) Forsaken - No background music from what I can tell. (I made a quick vid.. Ear Rape Warning) https://youtu.be/ABidyF71958 I'm having a hard time confirming if the Background music bug is fixed since the few games that had the issue are some of the games that are freezing :P (could be related perhaps?) CoolBoarders 2 - game freezes at a loading screen just before the first stage starts. (All the games that freeze tend to freeze at loading screens)

Threaded Rendering will cause a Core crash regardless if the Dynarec is on or off, there something definitely not right there. Overall this build is more unstable than the last, I'm sorry its not a good news update today :/ .

[embercold]

It's fine, actually, I now have at least some idea what new functions are faulty. I'll review those, and if nothing seems amiss, I'll just move on to lightrec work. This past month had nothing but hitting what seemed to be brick walls at the time, then bouncing to other tasks for a while, so it's just work as usual. That's it for today, thanks.

[ashquarky]

For future reference, the first line of the stack trace suggests that the crashing function is video_thread_main, and "bad read from unmapped memory at 00000008" suggests reading from a null pointer - but it's 8 and not 0, so it's probably a struct (ptr->thing where ptr is null) or ptr[2] or something like that. On the plus side, it looks like you actually made a thread and ran it! so that's neat.

Getting RetroArch running in an emulator is already a bit awkward because of how it depends on the HBL memory mapping (which doesn't exist in decaf at least, no idea w/ Cemu), and well, the dynarec depends on that right now as well haha Still curious if it works in Cemu though.