4DO: Recent Changes and Future Plans

trapexit

About two years ago I more or less adopted the libretro 4DO core. After fixing a VSYNC issue that many had complained about I ended up almost completely refactoring the code and adding a number of features. After a year’ish break I’m back and have been focusing on accuracy and some experimentation in HLE (high level emulation). Here’s an overview of some of that work and plans for the future.

Adding HLE

The 3DO was ahead of its time in a number of ways. One was that it had an operating system. It has preemptive multitasking, threading, high level memory management, dynamic loading of “folios” (libraries), IPC, IO APIs, and general abstractions to much of the hardware. The OS and most/all software for the platform is written in C and compiled using the Norcroft ARM toolchain from that era. The OS is present in the system’s ROM but also included on each CDROM. The ROM OS is pretty thorough but ultimately a bootloader and bootstraps the environment before handing control off to the software on the CDROM. Many of the core OS functions are called via the ARM SWI (software interrupt) instruction. This makes catching and overriding these calls very easy when combined with knowledge of the ARM procedure call standard.

Catching and overriding some or all of the OS functions would theoretically improve performance and/or enable advanced features. Some of these functions are somewhat complicated but one set of SWI calls were a perfect candidate for HLE: the matrix arithmetic functions. The MADAM graphics co-processor has a set of hardware accelerated 16.16 fixed point matrix arithmetic functions. This is used in a number of 3D games and called regularly. While reworking MADAM emulation in the past it was recognized that the OS could and would check the revision of the MADAM chip and had a fallback to software based matrix functions if it recognized it was running on a prototype system without the matrix hardware and that for some games there was a slight speed increase when switching between the hardware emulation and the software routines. So we know that improving the matrix arithmetic situation could help lower end systems struggling with the LLE and it should also be simple to ensure accuracy.

So we’ve added a new, optional, HLE mode that replaces the emulated hardware or software matrix functions with native fixed point calculations performed in straight C. Games that make heavy use of the matrix hardware run a few FPS faster on lower end systems such as the XU4. The option can be toggled in real time making comparison easy. You can see what games use these functions on the 3DO Development Repo site.

In the future a number of other functions would be interesting to replace such as the DSP and filesystem APIs. The DSP never got a development kit so most (all?) games use standard programs provided by The 3DO Company. Meaning that each of these programs could be statically re-implemented in C instead of using the current interpreter. The DSP is probably 1/3 of the CPU cost to emulation so HLE could make a big impact there. With the filesystem API the host storage device could be used directly allowing easier sharing and backup of save games and offering more space than a real system could have.

VDLP Rewrite

The 3DO has a fairly advanced video display line processor. It has programmable functions which provide a number of features including: managing CLUTs (color lookup tables), performing optional horizontal and vertical interpolation (upscaling from the internal 320×240 framebuffer to 640×480), managing background color, integrating secondary video data streams, etc.

The FreeDO/4DO VDLP emulation was not the best. If you read the patents the system seemed reasonably straightforward but the code not so much.

  • Has a lot of literal values for masks and shifts making it unclear what is being processed.
  • Variable names did not always match the docs.
  • Inadvertently reversed logic that rendered the wrong lines.
  • A constant bodge value used to offset the rendering line. Didn’t have a functional impact but was confusing and ugly.
  • It fails to properly manage the disabling render of a line. This can result in garbage being rendered.
  • Lacks the interpolation to full NTSC or PAL frames.
  • A general lack of PAL support.
  • It failed to properly sync line rendering with libretro’s main callback leading to additional rendering latency.
  • Has an unnecessary step in the rendering pipeline. Rather than taking the internal VRAM framebuffer and directly generating the buffer for the host to display it was copying the data into an intermediate structure which later was converted into a host compatible format. This copying offered no additional functionality and could be removed entirely.
  • Alternative color formats were ignored completely. Only P555 was supported. Though it is unclear if any software use the other formats.

A new VDLP core has been written from scratch to fix some of the above and enable future enhancements. New features include:

  • Lower frame rendering latency
  • Properly synced frame generation with libretro run loop
  • Improved performance due to removal of extra rendering stage
  • Ability to choose any of the libretro pixel formats (XRGB8888, 0RGB1555, or RGB565). Formerly only supported XRGB8888. May improve performance on 16bpp platforms.
  • Forced CLUT bypass mode. The VDLP has a special, per line and per pixel ability to disable color lookups and convert the P555 RGB to 888 RGB by a logical shift left of 3. Many games technically use a CLUT but in fact use a default palette that matches the left shift values. While this may cause color distortions on some games it also should improve performance due to a simpler pixel conversion function.

Interpolation is still on the TODO list. It will add non-insignificant cost to the rendering pipeline but was a significant feature of the platform and would be nice to have for the authenticity.

PAL ANVIL Support

Later revisions of the 3DO had a chip called ANVIL which was the combination of the co-processors MADAM and CLIO. The ROM for those systems are very similar to the previous model’s ROMs except that it appeared to be mirrored to a different memory location. It put a single unconditional jump at bootup into that mirrored location but all other references were to the original memory range. This  memory range was not properly supported nor was the VDLP and general rendering pipeline designed to work with PAL. All of that has been fixed. You can use EU ROMs which will cause EU games to run in one of two PAL resolutions. For the time being the ROM and resolution/field rate need to be selected manually.

A list of games and their supported region modes can be found here. Few games actually render at full PAL resolutions (PAL2). Most are letterboxed NTSC (PAL1).

Future Work

  • New HLE functions as described above
  • VDLP interpolation (dev docs, patent)
  • Increased emulated system DRAM and VRAM. The OS can support up to 14MB of DRAM & 2MB of VRAM or 15MB DRAM & 1MB VRAM. The emulator needs to be rewritten to enable it. This could help with homebrew.
  • Rewrite of the ARM and DSP cores
  • Rewrite of the CEL renderer
  • Removal of the “hacks” / improve accuracy
  • Improve accuracy by adding MADAM memory fence support and proper CPU exceptions such as those related to data alignment
  • Automatic detection of NTSC/PAL modes
  • Configurable hardware revisions of MADAM and CLIO chips
  • Add features to help with homebrew development and debugging
  • Other misc things

Renaming of the Project

Development on the original 4DO projected stopped a number of years ago and while the website is still up the project is effectively dead. It’s been noticed that people regularly believe that the old 4DO project and the libretro core are largely identical however the libretro core has gone under significant restructuring, rewrites, and offers new features. To limit confusion we are planning on renaming the project to Opera in the not too distant future. Opera was the code name for the 3DO project.

Related Work

Optimus (author of OptiDoom, the reworked 3DO Doom port) and I have created a new website dedicated to all things 3DO development. We’re writing homebrew tutorials, documenting the hardware, posting development toolkits and homebrew tools, etc. The hope is to spur interest in the platform and lower the barrier to entry.

Right now there is a very small group of individuals working in the 3DO and M2 space. Whether that be documentation, emulation, or homebrew. We’d like to extend an invitation to any and all interested in the 3DO or M2 to help in any capacity or consider the platforms for their current or future homebrew projects. We’ve got a big TODO list that we would love help in tackling. If you’re just interested in following our progress you can create an account on the wiki and subscribe to updates and/or “Watch” the libretro project.

Beetle PSX Dynarec Update – Switch alpha port plus runahead support – lower latency than original hardware!

Libretro Team


As an addendum to our earlier Beetle PSX dynarec post, a lot has changed in a couple of days:

  • Several important bugfixes have been pushed for ARM v7/AArch64. This should benefit Android users and ARM Linux SBC users.
  • Runahead support is finally working
  • Alpha release Switch version now available

Runahead support – lower latency than original hardware

Runahead is one of RetroArch’s crowning features as a frontend ever since we debuted this revolutionary feature in 2018.

Most systems more complex than the Atari 2600 will display a reaction to input after one or two frames have already been shown. For example, Super Mario Bros on the NES always has one frame of input latency on real hardware. Super Mario World on SNES has two frames of latency.

Runahead allows RetroArch to “remove” this baked-in latency by running multiple instances of a core simultaneously, and quickly emulating multiple frames at a time if input changes. This strategy has some analogs to frame rollback, similar to how GGPO handles high-lag connections. For it to work reliably, you need to figure out the amount of lag frames a game has, and then set Runahead frame count to that value. When done correctly, not only can you eliminate any perceptible lag, you can actually achieve latency that is quantifiably lower than when played on the original hardware [yes, with a CRT]. Surely that is the stuff of miracles on display technologies that have inherent far higher latency than any CRT screen, plus all the added additional latency of modern day PC OSes on top of the typical overhead brought about by emulators.

So up until now, runahead was not possible on Beetle PSX. Why not? For one, runahead relies on savestates. If serialization and savestates are well implemented, runahead can be used on a libretro core. Second, for runahead to run at fullspeed at any amount of frames, your hardware has to meet the demands of running a game at well above fullspeed. So the lower the FPS, the less conducive that core will be for runahead purposes even IF savestates are well implemented.

A couple of days ago, runahead would not work with the dynarec. This required some modifications. Zach Cook has since managed to fix these issues, and now we can use runahead just fine.

How to use it

First, make sure that you set Hardware Renderer to ‘Software’. Unless you are using a very high end CPU from the last two years, we recommend you leave Internal GPU Resolution at 1x. Combining the dynarec with runahead is a very CPU intensive task. You need all the headroom you can get.

To tinker with runahead settings, go to Quick Menu -> Latency.

Enable ‘Run-Ahead To Reduce Latency’, and set ‘Number of Frames To Run Ahead’ to a value of your choosing. For runahead to run as intended, this value shold match the amount of lag frames of the game.

NOTE: ‘Runahead Use Second Instance’ can give a big performance improvement. Consider always enabling it unless you have reason not to (for instance, some game related issue requires you disable it for whatever reason)

Alpha Switch version available

m4xw has done a quick port of Beetle PSX with the dynarec to the Switch port. He has already uploaded a build that you can try – you’ll have to pass the time with this core until we start deploying this on the buildbot properly.

To use this, extract the contents of this archive into /retroarch/cores/ (assuming RetroArch is already installed).

Performance has dramatically improved over interpreter before – just as an indication, Pepsi Man reportedly runs at fullspeed at 2x software rendering. But be sure to put this build through its paces yourself!

Parallel N64 with Parallel RSP dynarec release – fast and accurate N64 emulation is now here!

Libretro Team

Hot on the heels of our Beetle PSX dynarec public beta release, here comes another bombshell, this time targeting that other big 5th generation console, the Nintendo 64.

ParaLLel N64 is back with a vengeance, and this time Parallel RSP coupled with Angrylion Plus RDP is the enabling technology for a big performance jump in low-level accurate N64 emulation.

Parallel RSP

We have released today a new version of Parallel N64 for Windows and Linux that adds back the Parallel RSP dynarec. This together with multithreaded Angrylion makes Parallel N64 the fastest LLE N64 emulator by far.

We have also added missing bits and pieces to Parallel RSP that allows for several games to work, such as World Driver Championship, Stunt Racer 64, and Gauntlet Legends. On top of that, we also optimized some parts in Angrylion RDP Plus which resulted in greatly enhanced core/thread utilization on a 16-core Ryzen CPU. It should also similarly scale well downwards.

Just to illustrate how dramatic of a difference all these performance-focused enhancements make: on an underpowered 2012 Core i5 laptop, the following games are capable of being played at fullspeed: Resident Evil 2, Mario Kart 64, 1080 Snowboarding, Doom 64, Quake 64, Mischief Makers, Bakuretsu Muteki Bangaioh, Bust-A Move 2 Arcade Edition, Kirby 64 – The Crystal Shards, Mortal Kombat Trilogy, Forsaken 64, Harvest Moon 64.

A 2012 Core i5 desktop CPU like the Core i5 3570k should be more than capable enough of playing the vast majority of N64 games at fullspeed with Angrylion+Parallel RSP, with only rare exceptions like Star Wars Episode 1 Racer being too much for it.

Dramatically lowering the performance ceiling like this has vast implications for the viability of low-level accurate N64 emulation, and opens the door for more people to enjoy bug-free N64 emulation, previously the preserve of only the most overpowered PCs.

Right now, only Linux and Windows are able to enjoy the benefits of Parallel RSP due to the LLVM dependency. This might solve itself later on, though.

How to get it

On Windows: Just downloaded the latest Parallel N64 core from RetroArch’s Online Updater menu. You can either download it from Core Updater, or you can select ‘Update Installed Cores’ if you already had a prior version of Parallel N64 installed.

On Linux: Download the latest Parallel N64 core from RetroArch’s Online Updater menu. You can either download it from Core Updater, or you can select ‘Update Installed Cores’ if you already had a prior version of Parallel N64 installed.

IMPORTANT: On Linux, the situation is a bit more complicated. If you find that the core won’t load on your Linux distribution, it is because LLVM on Linux normally links against libtinfo. For the version of Parallel N64, you will need to make sure you have libtinfo5 installed.

On Ubuntu Linux, you can do this by going into the terminal and typing in the following:

sudo apt-get install libtinfo5

Consult the documentation of your Linux distribution’s package manager for more details on how you can download this package. Once installed, the core should work. If you have a more recent version of libtinfo already installed, creating a symlink for libinfo5.so might be enough.

How to use it

Go into Quick Menu -> Options.

Make sure that ‘GFX Plugin’ is set to ‘angrylion’, and ‘RSP Plugin’ is set to ‘parallel’.

Restart the core.

Explanation of the options

Angrylion (VI Mode) – The N64’s video output interface ‘VI’ would postprocess the image in a very elaborate way. We will explain all of the modes down below:

VI Filter: – All VI filtering is being applied with no omissions.

VI Filter – AA+Blur – Only anti-aliasing + blur filtering by the VI is being applied.

VI Filter – AA+DeDither – Only anti-aliasing + dedithering filtering by the VI is being applied.

VI Filter – AA Only – Only anti-aliasing by the VI is being applied.

Unfiltered: – This is the fastest mode. There is no VI filtering being applied of any sort, the color buffer is being directly output.

Depth: – The VI’s depth buffer as a grayscale image

Coverage: – Coverage as a grayscale image

Angrylion (Thread sync level) – With most games it is fine to leave this at ‘Low’. Low will be the fastest, with High being significantly slower. Games which need Thread sync level set to High to prevent rendering glitches include but are not limited to Starcraft 64, Conker’s Bad Fur Day and Paper Mario.

Angrylion (Multi-threading) – You will want to always enable this. When it is disabled, Angrylion will be entirely single-threaded. It will be much slower in single-threaded mode.

Increased compatibility for Parallel RSP

The following games will now work with Parallel RSP:

* World Driver Championship
* Gauntlet Legends
* Stunt Racer 64
* Mario no Photopie (graphics fixed)

Performance tests

NOTE: All these tests were performed with the game Super Mario 64 (USA). Exact scene being tested can be seen in the screenshot down below.


* Cxd4 means the Interpreter RSP core. This was previously the only option you could use in combination with Angrylion – it needs an LLE RSP core, it cannot work with a HLE RSP core.
* All the VI Filter tests are done with Thread Sync Low.

Test hardware: Desktop PC – AMD Ryzen 9 3950x, Windows 10 (16 cores, 32 HW threads)

RSP Mode VI Filter VI Filter – AA+Blur VI Filter – AA+DeDither VI Filter – AA Only Unfiltered – Thread Sync Low Unfiltered – Thread Sync Mid Unfiltered – Thread Sync High
Cxd4 174 VI/s 176 VI/s 175 VI/s 178 VI/s 180 VI/s 175 VI/s 92 VI/s
Parallel RSP 235 VI/s 238 VI/s 238 VI/s 240 VI/s 245 VI/s 235 VI/s 106 VI/s

Test hardware: Desktop PC – Intel Core i7 7700k @ 4.2GHz, Windows 10 (4 cores, 8 HW threads)

RSP Mode VI Filter VI Filter – AA+Blur VI Filter – AA+DeDither VI Filter – AA Only Unfiltered – Thread Sync Low Unfiltered – Thread Sync Mid Unfiltered – Thread Sync High
Cxd4 95 VI/s 96 VI/s 96 VI/s 99 VI/s 104 VI/s 96 VI/s 86 VI/s
Parallel RSP 139 VI/s 145 VI/s 144 VI/s 151 VI/s 170 VI/s 146 VI/s 121 VI/s

Test hardware: Desktop PC – Intel Core i5 3570k @ 4GHz, Windows 7 x64 (4 cores, 4 HW threads)

RSP Mode VI Filter VI Filter – AA+Blur VI Filter – AA+DeDither VI Filter – AA Only Unfiltered – Thread Sync Low Unfiltered – Thread Sync Mid Unfiltered – Thread Sync High
Cxd4 89 VI/s 92 VI/s 91 VI/s 95 VI/s 103 VI/s 103 VI/s 97 VI/s
Parallel RSP 118 VI/s 124 VI/s 121 VI/s 128 VI/s 145 VI/s 145 VI/s 133 VI/s

Test hardware: Laptop PC – Intel Core i5 3210M @ 2.50GHz, Ubuntu Linux 19.04 (2 cores, 4 HW threads)

This is a 2012 Lenovo G580 laptop.

RSP Mode VI Filter VI Filter – AA+Blur VI Filter – AA+DeDither VI Filter – AA Only Unfiltered – Thread Sync Low Unfiltered – Thread Sync Mid Unfiltered – Thread Sync High
Cxd4 39 VI/s 39 VI/s 42 VI/s 41 VI/s 43 VI/s 39 VI/s 39 VI/s
Parallel RSP 52 VI/s 55 VI/s 54 VI/s 58 VI/s 67 VI/s 66 VI/s 61 VI/s

We recommend for a configuration as low-end as this that you just keep VI Overlay to ‘Unfiltered’.

The majority of games on a configuration this low-end experience dips below full-speed, however, there are a fair few games right now which already run at fullspeed. This is by no means a definitive or exhaustive list but here’s the ones for which I can confirm run at fullspeed with very rare dips if at all:

Resident Evil 2, Mario Kart 64, 1080 Snowboarding, Doom 64, Quake 64, Mischief Makers, Bakuretsu Muteki Bangaioh, Bust-A Move 2 Arcade Edition, Kirby 64 – The Crystal Shards, Mortal Kombat Trilogy, Forsaken 64, Harvest Moon 64

Currently known issues

* Do not use ‘Sync to Exact Content Framerate’ for Angrylion + Parallel RSP. You won’t get good results.
* Recompiling blocks the first time can lead to a very slight stutter. Thankfully this only happens the first time, and never happens afterwards for the runtime duration.
* On Linux there might be dependency issues related to libtinfo5. Read the section ‘How to Get It’ where we try to explain how to solve this problem at least for Ubuntu Linux. NOTE: This situation might resolve itself in the future in case we move away from LLVM for the RSP part.

Beetle PSX Dynarec – Public Beta Out Now! Fast and accurate wins the race!

Libretro Team

We are delighted to announce that the Beetle PSX dynarec bounty is finally entering its public beta stage and is available to the public right now!

The dynarec project for Beetle PSX would not be where it is today without the combined efforts of simias, pcercuei and Zach Cook!

If you are on Android, Windows, Linux and/or macOS, all you have to do to get the latest core is to open RetroArch, go to Online Updater, and either select ‘Update Installed Cores’ (if you already installed the Beetle PSX core before), or install the Beetle PSX and/or Beetle PSX HW cores separately.

What’s this all about?

In 2017, we started a bounty for Beetle PSX, our own heavily modified fork of Mednafen PSX that has pretty much become its own thing at this point. Mednafen PSX is a highly accurate PlayStation1 emulator. However, unlike emulators like ePSXe, it only has a CPU interpreter, which means that the emulator is fairly slow and is therefore not really usable on anything but desktop PCs and high end mobile phones. The bounty was created on BountySource in hopes of attracting someone who could add a dynamic recompiler to Beetle PSX so that it could run much faster and therefore be a viable emulator on lower end hardware, such as mid range mobile phones, game consoles, older PCs, etc.

What pcercuei and Zach Cook have come up with is a Lightrec-based dynamic recompiler implementation. Zach Cook has done most of the integration of Lightrec in Beetle PSX, while pcercuei did Lightrec itself. Lightrec is pcercuei’s dynamic recompiler for MIPS that uses GNU Lightning as the backend. There should be working implementations for nearly all system architectures, from x86 (64bit/32bit) to MIPS and ARM (64bit/32bit). It bears mentioning that pcercuei also already has Lightrec hooked up to PCSX Reloaded, and used this as a testbed.

Platforms

The dynarec is available for the following platforms:

  • Linux
  • Windows
  • Android *
  • MacOS *

We are able to confirm that the performance gains for x86 and x86_64 are significant, as you can see down below (see Performance tests). We don’t know what the results are for ARM Linux, let us know how it performs!

* Performance right now is pretty bad for the Android and macOS platforms. We hope that after the public beta test, performance will improve a lot for these platforms. So while there is a framerate gain, it isn’t anywhere near what it should be.

How to use it – what the options do

First, update your Beetle PSX cores. We already explained before but we’ll repeat it here for the sake of it –

If you are on Android, Windows, Linux and/or macOS, all you have to do to get the latest core is to open RetroArch, go to Online Updater, and either select ‘Update Installed Cores’ (if you already installed the Beetle PSX core before), or install the Beetle PSX and/or Beetle PSX HW cores separately.

Once you’re on the latest core, you’ll notice that a lot more options show up now when you go to Quick Menu -> Options. We’ll go over these options and we’ll explain what they do.

NOTE: The dynarec is disabled by default – the default setting is still ‘Beetle Interpreter’. So if you’re wondering why things aren’t automatically faster, set it from Disabled to ‘Max Performance’ in Quick Menu -> Options.

CPU Dynarec – [Max Performance|Cycle Timing Check|Lightrec Interpreter|Disabled (Beetle Interpreter)]

Dynamically recompile CPU instructions to native instructions. Much faster than interpreter, but CPU timing is less accurate, and may have bugs.

Disabled (Beetle Interpreter) – This is the default setting, dynarec is disabled. This uses the default Beetle interpreter that has been used in Beetle PSX all up to this point. It’s faster than Lightrec Interpreter (for now) but much slower than any of the dynarec modes. We don’t recommend you use this unless ‘Max Performance’ or ‘Cycle Timing Check’ won’t work well for you on the game you’re trying to play.

Max Performance – Dynarec enabled with all features enabled. Should be the fastest option, but some games might require the ‘Cycle Timing Check’ mode instead.

Cycle Timing Check – Dynarec enabled, but with cycle timing check which makes it a fair bit slower. Some games might need this setting in order to work properly, so if you find that Max Performance has bugs with a game, try this mode instead.

Lightrec Interpreter – This is the slowest mode right now. It’s basically in the same ballpark as Beetle Interpreter but the Beetle one is actually faster. It’s basically Lightrec running in CPU interpreter mode instead of dynarec mode. We don’t recommend you use this.

Dynarec Code Invalidation – [Full/DMA Only [Slightly faster]]

Some games require a Full invalidation, some require DMA Only.

Dynarec DMA/GPU Event Cycles – 128 (Default) – can go up to 512

How many cycles can pass in the CPU before a GPU or DMA update is checked. A higher number will be faster, but also more likely to cause bugs or crashes. This option has much less impact on performance with Beetle Interpreter than any of the dynarec modes.

Performance tests

Test hardware: Desktop PC – Core i7 7700k, Windows 10

Game Beetle Interpreter Dynarec – Max Performance Dynarec – Max Performance (w/ DMA/GPU Event Cycles High) Dynarec – Cycle Timing Check Dynarec – Lightrec Interpreter
Tekken 3 151fps 223fps 252fps 209fps 117fps
Ridge Racer Type 4 132fps 323fps 325fps 289fps 132fps
Final Doom 216fps 401fps 456fps 359fps 142fps
Final Fantasy VIII 185fps 384fps 426fps 269fps 149fps
Rockman X3 211fps 414fps 450fps 319fps 152fps

Test hardware: Laptop PC – Core i5 3210M, Ubuntu Linux 19.04

Game Beetle Interpreter Dynarec – Max Performance Dynarec – Max Performance (w/ DMA/GPU Event Cycles High) Dynarec – Cycle Timing Check Dynarec – Lightrec Interpreter
Tekken 3 83fps 117fps 126fps 110fps 78fps
Ridge Racer Type 4 105fps 159fps 173fps 143fps 87fps
Final Doom 128fps 204fps 235fps 181fps 99fps
Final Fantasy VIII 128fps 232fps 277fps 152fps 97fps
Rockman X3 141fps 235fps 266fps 182fps 107fps

Currently known issues

* PGXP right now is disabled if you use any of the Dynarec modes. So don’t bother enabling PGXP modes for now when you use the Dynarec modes, you’ll just lose performance while gaining absolutely nothing. We hope that we are able to come up with a solution for this later.

* Make sure ‘Renderer’ is set to ‘Software’ if you want to use runahead. We recommend for runahead purposes you stick to 1x Internal GPU Resolution as even with the dynarec enabled, it can still be stressful on the CPU to go any higher than 1x with software rendering.

* If you are using the Android version and want to report bugs right now, please DO NOT use the Vulkan renderer right now. It currently has a couple of bugs on Android that the software renderer doesn’t have. So we advice you to use the software renderer for now on Android. On top of that, the software renderer right now is faster than Vulkan on Android, so you’re advised for now to use this during the public beta period.

Currently known compatibility issues

These are the current compatibility issues I have been able to notice on Windows.

Parasite Eve 2 (USA) (Disc 1)
Won’t continue from start with dynarec. It will freeze at the ‘Published by Square Electronic Arts’ screen.

There is a workaround for this – set CPU Overclock to 300%. The game will run too fast but it will at least be playable.

Brave Fencer Musashi (USA)
Hangs at ‘New Game’ – first world screen

There is a workaround for this – set CPU Overclock to 300%. The game will run too fast but it will at least be playable.

Gex – Enter The Gecko (USA)
Crashes after PSX copyright screen

Time Commando (USA)
Corrupted background graphics. Background graphics in this game are streaming FMV with polygon models on top.

Street Fighter Ex Plus Alpha (USA)
If you lose a fight and then select Continue, it will hang

Vanishing Point (USA)
It crashes once inside a race – with both full max or dma only

Battle Arena Toshinden 1 (USA)
It runs too fast.

WORKAROUND: By setting CPU to 90%, you can workaround this issue.

Alone In The Dark – One Eyed Jack’s Revenge (USA)
Crashes after the PSX copyright screen

Viewpoint (USA)
Crashes after the PSX copyright screen

Another big announcement at the end of the weekend

We have even bigger things for you in store by the end of this week. So stay tuned, because we have lots more to talk about very soon! It’s time to get the 5th gen out of the way and have it preserved for posterity!