-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Writing or porting a dynarec for Mednafen/Beetle Saturn #127
Comments
Is that dynarec PIC-compliant? I think that is an issue that is preventing us from using the x86/x64 dynarec right now in our Yabause core. Can you maybe see if it's possible to overcome that obstacle first before we consider this an option for this core? |
Made a bounty out of this and injected a $100 into it - https://www.bountysource.com/issues/64538981-writing-or-porting-a-dynarec-for-mednafen-beetle-saturn Whichever approach we take, consider that a vote of confidence already. I think my preference would go towards the Yabause dynarec approach, however, we have to be sure that it's PIC-compliant at least. |
Also, I made a smaller bounty for getting the Yabause x86/x64 dynarec working for the Yabause core as well - It's not much but it should be an easy $50 to fetch at least assuming there is not a lot of work involved. It's completely separate from this bounty too, and could serve as a stepping stone towards this one, the main event. |
@nayslayer I haven't compared them or anything, but I understand Kronos (a fork of Yaba Sanshiro) has a PIC-compliant dynarec that may be more attractive for porting: |
It's important to note we have a Kronos core too. https://github.com/libretro-mirrors/Kronos Only problem is that both the Yabause and Kronos cores don't seem to start up for me right now when running them in RetroArch. I believe the issue lies in the threading implementation right now. |
A potential upside to making your own dynarec is that the Sega 32x uses the SH2 and the Dreamcast uses its successor, the SH4. If your dynarec would end up being the most accurate SH2 dynarec, then emulation of those two systems might benefit by this development as well. Also, if you intend to tackle the Saturn's m68k, perhaps you could reuse code from Blastem? It's supposedly very accurate and fast. |
Hey. I've skimmed both dynarecs and found out that Kronos's is still rudimentary compared to Yabause's - it seems to be more of a reassembler than a recompiler, with no optimizations to speak of. Or was I looking the wrong way? It's also written in C++ which is twinaphex's cryptonite, so... :) Yabause's is also interesting in how its dynarec is encapsulated behind a small API: if adding it to an existing interpreter-only emulator proves viable, sharing dynarecs between emulators will likely be the next great thing, both for users and maintainers. But for now I'll focus on getting the Yabause core's dynarec to work. This doesn't mean I'm abandoning the project of writing a dynarec from scratch, ofc. |
@nayslayer Sounds like a good plan. However you want to approach it is fine by me/us :) |
@nayslayer i don't see which part of https://github.com/FCare/Kronos/tree/extui-align/yabause/src/sh2_kronos is C++, however it is not exactly a dynarec, but the author performed some tests and it seems his code performs about the same as original yabause dynarec and YabaSanshiro dynarec, and his code is pure C and cross-platform... PS : https://github.com/FCare/Kronos/tree/extui-align/yabause/src/sh2_dynarec_devmiyax , which is C++ indeed (it's actually the YabaSanshiro dynarec), is not in use in Kronos |
FYI, there was a tiny bit of groundwork starting in the latest update of Mednafen for a x64 dynarec specifically for the DSP microcode that runs on the sound chip. |
FX-8300 CPU can't run some games at full speed on mednafen saturn. Dynarec is welcome. |
I'm checking in as promised. The past two days I've been getting the hang of Saturn's SH-2 CPU specs, an I believe it's a great CPU to write a recompiler for. To summarize, its complexity is just below a PSX's MIPS core: there's no MMU so it can be made really fast, but there are some annoying addressing modes similar to those of 8086.
Still, I don't really care about Saturn itself, as I'm trying a novel approach with quite a bit of upfront complexity, and it'll be a miracle if I get something extremely basic and inaccurate working in six weeks or so (and I've already transcribed most of the instructions' specs in two days). Such efforts have a moderate risk of failure, too.
There's yet a shortcut: Yabause already has a mature recompiler (based on mupen64plus's to no one's surprise). While its not as accurate as Mednafen's trying to be, it can be useful to those who lack the hardware to use it. It also supports x86, x86_64 and arm32 targets.
So, what do you say? Should I make a detour and port the existing recompiler, or should I carry on and continue writing my own?
The text was updated successfully, but these errors were encountered: