Skip to content
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

Open
nayslayer opened this issue Oct 10, 2018 · 11 comments
Open

Writing or porting a dynarec for Mednafen/Beetle Saturn #127

nayslayer opened this issue Oct 10, 2018 · 11 comments
Labels

Comments

@nayslayer
Copy link

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?

@inactive123
Copy link
Contributor

inactive123 commented Oct 13, 2018

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.

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?

@inactive123
Copy link
Contributor

inactive123 commented Oct 13, 2018

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.

@inactive123
Copy link
Contributor

@nayslayer

Also, I made a smaller bounty for getting the Yabause x86/x64 dynarec working for the Yabause core as well -

libretro/yabause#51

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.

@hizzlekizzle
Copy link

@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:
https://github.com/FCare/Kronos

@inactive123
Copy link
Contributor

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.

@anothername99
Copy link

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.

@nayslayer
Copy link
Author

nayslayer commented Oct 19, 2018

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.

@hizzlekizzle
Copy link

@nayslayer Sounds like a good plan. However you want to approach it is fine by me/us :)

@barbudreadmon
Copy link

Or was I looking the wrong way? It's also written in C++ which is twinaphex's cryptonite, so...

@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

@hiddenasbestos
Copy link
Contributor

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.

@crocket
Copy link

crocket commented Oct 4, 2021

FX-8300 CPU can't run some games at full speed on mednafen saturn. Dynarec is welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

7 participants