What would it take to get a dynarec into beetle-saturn?

Yabasanshiro standalone runs good on my trimui brick, full speed with frame skip one (30/60 actual frames). Don’t know if that’s supposed to be the best it can do. That’s a 2.0ghz A53 quad core there. Didn’t notice any crashes (?)

1 Like

That core version (3.4.2) is from a old 2019 build based on the same version as the stand alone emulator from that same year. So many new features got added to Yaba like vulkan support since then. It’s way out of date but does work for the most part.

2 Likes

That’s similar to the performance I’ve seen on ARM devices. Works fine with one frame skip.

The problem is that this needs to be updated to work with newer emulators and newer operating systems (64-bit). Also I am seeing some random crashes in Yaba Sanshiro 1.9.0.

1 Like

It’s true that retroarch core runs a lot slower, at least on brick. Standalone keeps a full pace by skipping 1 frame while core is stuck on 40 fps and doesn’t look like frame skipping, it’s just slower. It’s acceptable to run standalone and skip 1 frame, i wouldn’t expect miracles anyway on a little handheld. If it could reach full speed i would take it lol

Relevant to this thread, there’s a new Saturn emulator in dev to watch:

4 Likes

I finally had some time to look into this a bit more. I wasn’t able to build YabaSanshiro to debug it, however I did succeed in compiling Yabause 0.9.15. This revealed that the dynarec crashes at the same point when starting a new game in Burning Rangers, similar to YabaSanshiro.

The cause of the crash is a bug in the register allocator, which fails to allocate enough registers for a certain instruction. This is easy to fix, and Burning Rangers seems to work fine with the fix applied, but I’m surprised that this apparently obvious bug went unreported and unfixed for years.

I think having working Saturn emulation on handheld devices would be great, but clearly this is going to take a lot more work to test and debug. Does anyone really care about Saturn emulation, or is this just not worth the effort?

Ymir looks interesting, but I couldn’t get it to build from source as it seems to have dependencies on some very recent stuff. Ymir clearly isn’t going to work on something from Anbernic or Trimui, and probably not on Android either.

2 Likes

I did when i wrote those yabasanshiro and kronos libretro ports years ago, but it was honestly a bit of a disappointment after i noticed multitap support was kinda broken. My main motivation was to create a mini-pc replacement for my dead saturn (which has bomberman, 2 multitaps, and a load of gamepads).

I think saturn still has a huge fanbase.

1 Like

Lots of people love the Saturn, they just have accepted “Saturn is too hard to emulate”. It makes sense to have a good Saturn emulator, these beasts are getting older/prone to failure, expensive and games prices have skyrocketed.

Currently, I use Beetle Saturn and Mednafen on Windows and the Poco Pad (Android).

Both can run most games full speed, but I can’t ignore the input lag on either. On Swanstation, for instance, it has so many enhancements, fixes and the ability to use runahead (core options), to reduce even further an already acceptable latency.

With Saturn, the story is different, it always remembers me I’m playing these games with added latency, and I feel that in each input.

With that, all I’m saying is that probably many like me want a fast and accurate Saturn emulator, with improvements many other cores/emulators have.

But for now, we have to accept the current state, while wishing for things to get better with time. And yes, I play lots of Saturn games and it was the console which, besides gaming, inspired me to start drawing, learning English, Japanese, and getting into new genres I never had before it, such as FPS, RPGs, Strategy, Adventure and much more.

If, at some point, dynamic recompilation gets implemented, it will probably be a milestone, but I also know SSF for a long time and while it’s quite fast for a Saturn emulator, running on anything dual core, it still suffers from input lag. So, this is something we still need to see to believe, I mean, if dynarec will and possibly will, not only make this core run on more modest machines, with reduced latency.

Btw, Saturn.emu, which is based on Mednafen Saturn for Android, run chd games and I’m quite impressed that this mid range tablet can actually run 99% of the games I throw into it full speed.

1 Like

For the reminder, original hardware had massive input lag, guardian force was infamous with its ~10 frames of input lag, and cotton was barely better. Emulation seemed to leverage them to 3 for some reason (probably inaccurate smpc emulation) the last time i tested.

2 Likes

This is something I’d love to test myself, since I don’t have original hardware to compare, I wonder if someone had done that so far. I know Capcom games have added latency on purpose, such as Street Fighter Alpha and many more, I mean, on arcades and their ports.

Now, from memory, I’m not able to remember exactly how these games felt.

Still, it makes us wish for a faster Saturn emulator that will possibly benefit from reduced input latency options. Rayman run almost full speed with runahead at 2 in my PC, but it will stutter from time to time, even though the game responsiveness is greatly improved.

If I play Street Fighter Alpha 3 on Swanstation and set run ahead to 2 or 3, I’m pretty sure it plays better than on original hardware, because these games had that extra “weight” on pupose. The PSP port is even worse (real hardware), like Metal Slug 7 compared to Metal Slug XX port on the PSP, the NDS feels so much better to play, specially on MelonDS, as Desmume is abysmal in comparison.

It turns out i mistook guardian force saturn with its stv counterpart, the saturn version had a normal input lag of 3 frames.

I know tests exist because i saw them years ago, and i’m pretty sure 3 frames was considered low on original hardware. Sadly, questions about emulators and remakes are flooding search engine results nowaday so i couldn’t find that source anymore.

2 Likes

I talked about this on kronos’s discord and it seems 2 frames is the theoretical limit hardware-wise if you properly optimize your game for saturn’s smpc. I only got vague answers when i asked about games actually achieving those 2 frames though :sweat_smile:. Also, it seems only achievable on 2D games, 3D games need an additional frame.

2 Likes

What about PS/N64 games, say a 60FPS 3D game such as Tekken 3 and maybe F-Zero 64? Have anyone tested them? Maybe Virtua Fighter and other 3D fighters on the Saturn would be good to measure input lag?

Some time ago I overclocked Quake II on the PS1, via Swanstation, the game has unlocked frame rates so we can reach 60 FPS and it’s transformative compared to how it plays originally, one thing that is very noticeable is the input lag that is vastly improved. I may have a footage of that still.

With that, I believe that when PCs get better and they are already so fast today, we’ll be able to even surpass these Saturn/N64 input lag issues, like we can with the PS1.

Edit: Here it is:

https://youtu.be/pSCllF_9EqA

BTW, when I mentioned improving input lag with Quake II on PS1, it’s the lag inherent from the game’s own performance and not run ahead or preemptive frames and the such, this is mostly due to the console 3D capabilities with specific game engines.

If anyone wants to try this, this patch gets the dynarec working on x86-64 in Yabause 0.9.15 (tested on Ubuntu 24.10)

https://paste.debian.net/1378050/

Changes:

  1. Changed the asm code to use PIC (PLT and rip-relative)
  2. Moved the code generation buffer so that call/jmp can use 32-bit offsets
  3. Changed all the other pointers to 64 bits
  4. Fixed some stack alignment which is needed for SSE/SSE2
  5. Fixed the calls to MappedMemory* which changed in Yabause 0.9.15
  6. Added the call to new_scsp_exec which is needed since version 0.9.15
  7. Fixed the crash in Burning Rangers (register allocation in load_alloc)
  8. Applied the Qt5 compatibility patches from debian (HexValidator)

I tried a bunch of games and all seem to work fine with dynarec enabled.

Surprisingly, Linkle Liver Story seems to work, which is one game that is reported to have issues with accurate emulation of the CPU cache. So I’m not sure which games actually need that. Also, surprisingly, the HLE BIOS works.

Yabause 0.9.15 is outdated and definitely has some bugs, but the goal here was just to see if the dynarec would work, and it seems to work fine.

Speedup is around 5-10 FPS in some parts, but where the SH2 is not used much there is little difference.

Some games which crash YabaSanshiro 1.9.0 do work in Yabause 0.9.15, including Magic Knight Rayearth and Panzer Dragoon. However, I see some random crashes in both emulators. When I investigated the crashes in Yabause 0.9.15, most were in the VDP2 code.

Would it be more productive to try to fix YabaSanshiro, or work on another emulator?

4 Likes

The yabasanshiro core is abandonned (5 years behind upstream) and in a pretty horrible state (stability issues), the only reason someone would ever want to use it is due to the lack of alternatives for arm devices, and using standalone would still be highly recommended in that case. Fixing it for x86-64 seems like a waste of time since there are better options there (beetle-saturn, kronos).

1 Like

The only thing I would want for that outdated core is to get it to work with the vulkan driver just so I can use my slang shader presets on them on a Android device other than that probably no point if it’s not being updated to the current upstream version.

That’s what I’m thinking. The only reason I tested this on x86-64 is that it was much easier to debug than on ARM. Having demonstrated that the dynarec works and is compatible with the majority of games, I don’t see much reason to spend more effort on yabause or yabasanshiro.

My original plan was to put a dynarec into beetle-saturn for some speed improvement. While that still seems possible, it’s not a simple drop-in replacement for the existing SH2 core. The SH2 core needs a bunch of callbacks for handling memory mapping, timing, interrupts, etc, and all that would need to be reworked.

Dynarec in kronos on x86-64 would be doable as it’s based on yabause, but I don’t know how useful that would be since a major goal here would be to get something working on ARM or Android.

2 Likes

You can ask the author if he is interested at https://github.com/FCare/Kronos, however, as previously said, the cached sh2 interpreter in kronos is supposedly quite fast already.

I’m not sure, as FCare has indicated that he is prioritizing other projects.

I tried building Kronos, but I get “Cannot initialize Glew” when I run it. Maybe I’m missing something obvious, but libglew-dev is installed. I can try tracking down why gl is apparently not getting initialized properly, but even if I can get this working on x86, many of the ARM platforms that I would want to run this on have limited OpenGL support, so I’m wondering if I’m just wasting my time with this.

Basically, getting Saturn emulation at a playable speed on a wide range of platforms seems to run into two major issues

  1. Most newer emulators don’t support a dynamic recompiler
  2. Most newer emulators have increased dependence on OpenGL or Vulkan which isn’t supported well on some platforms

So this leaves a bunch of outdated cores which are buggy and don’t support many games.

One possible path forward is to combine the software renderer from mednafen/beetle with the dynarec from yabause. Despite not having been updated in more than ten years, the dynarec seems to work for the most part, although there is the issue of missing support for arm64.

Maybe there is some other path to getting this working that I’m missing?