Stella 2014 Core improvements – now fullspeed on OpenDingux devices, and more

Libretro Team

Written by jdgleaver

Two new core options have been added:

Color Depth (Restart): This allows the user to select between RGB565 and XRGB8888 pixel formats. At present, the core forces XRGB8888, which is very slow on some platforms. Selecting 16-bit colour can significantly improve performance.

Interframe Blending: This enables the (crude) simulation of CRT phosphor ghosting effects. Simple performs a 50:50 mix of the current and previous frames. The Ghosting options accumulate pixels over successive frames, with persistence from 65% to 95%.

The main purpose of Interframe Blending is to alleviate the flickering that is common in many Atari 2600 games, caused when developers used the workaround of toggling sprites on alternate frames to show more simultaneous on-screen objects than the hardware strictly allowed. For example:

  • Setting Interframe Blending to Simple will remove the flashing in Asteroids
  • Setting Interframe Blending to Ghosting (95%) will almost completely remove the flashing in Pac Man

Ghosting can also produce nice effects in games that don’t flash – e.g. Beamrider looks rather special with Ghosting (85%).

Care has been taken to implement these options in a performant manner. With 16-bit colour depth, all Interframe Blending methods run full speed even on an RG350M (OpenDingux) with 2x video filters.

Introducing the RetroArch Open Hardware project

Libretro Team


So ProjectFuture finally materialises! From the beginning, we have been unsatisfied with the general state of the retrogaming scene when it comes to being able to dump and play your own legally bought game cartridges. Solutions exist like the Retrode. There are some big issues with them though that limits their viability as something an average consumer can just buy readily off the shelf:

1. Super expensive.
2. No longer in production/out of stock
3. Rights to the product changing hands between sellers/store owners
4. Because of 3, usually one or two stores can only sell them.
5. The specs are closed so only a select few can assemble and sell them, limiting the ability of DIY homebrewers to make their own device.

While as a general rule of thumb, developers will always tell people to dump their own game cartridges, in reality there is nobody stepping up to the plate to make this either affordable, to integrate it well with existing software, or to make it possible for your homebrew hardware maker to easily build his own.

RetroArch Open Hardware is our attempt to shake up this sector of the retro games market, and our effort to revitalize the DIY market and shift it away from proprietary solutions. Our first Proof of Concept hardware device is an N64 cartridge adapter that you connect to any device with a USB Type-C cable. It will be relatively cheap to assemble and much faster than any existing competing device out there that does the same task.

RetroArch Integration


We have some high-level goals we aim to achieve with this project. We want seamless integration with RetroArch. When you attach this to RetroArch, it should be hopefully as simple to play the game as it is on a real game console when you plugged in the cartridge. That’s the level of integration we are aiming to achieve with this project, and none of the existing solutions out there really fit the bill.

When we mentioned before that we want RetroArch to be its own game console, we pretty much meant it. And being able to take your own game copies with you and run them with RetroArch seems like an obvious next step to take.

We have come up with a completely custom and lean design so that the person aiming to build this for themselves in DIY fashion will be able to build these relatively cheaply. We are convinced the transfer speeds are far in excess of any other similar product out on the market right now, which is just as well considering the biggest N64 game out there is 64MB in size.

The current transfer speed that we are achieving is ~4MB per second on a prototype device. Our target is a transfer speed of approximately ~ 4.5MB per second give or take.

In addition, Switch dock support will be there from Day One, working out of the box.

How does it work?

Attach it to any device and it will mount itself as a Mass Volume Storage device, mapping the cartridge as a bunch of files on the filesystem.

You insert the N64 cartridge into the cartridge reader and you connect it to a PC (or some other device) with a USB Type C-cable. The device will then map the contents of the cartridge itself as a Mass Storage device volume. EEPROM, Flash, ROM, and SRAM are mapped as separate files on this volume. (*)

Playing the game should be as easy as just loading the ROM from this device. So already even without the aforementioned RetroArch integration, it already works. But our hope is that with the RetroArch integration, we finally get the promise of a true cross-platform game console where you can take your games library with you, whether it’s digital or physical, and just use it across the devices that you already have RetroArch on. This is the dream and promise we have been slowly building towards – the power lies in the user’s hands, not that of any corporation or organization.

* – This might be subject to change. We are still considering whether to change this to a dedicated protocol to allow using cartridge hardware in an emulator core without just reading all of the cart as one big contiguous ROM file.

Prototype


This project has been ongoing now for the better part of a year. We have some internal prototypes and so far we can definitely confirm high success rates with our own cartridge collection. SRAM support already works in the firmware, but no EEPROM/FlashROM support yet. Your SRAM should work as long as your SRAM battery is not dead yet anyway. Some of these cartridges are over 20+ years old by now after all so an SRAM battery being dead is not an unlikely prospect at this point.

Some cartridges will need their cartridge connectors cleaned in order to work properly with this device. It’s a common problem among N64 game preservationists that I’m sure should not be news to anyone at this point.

Q&A


I’m sure there will be many questions in response to this article. We will remain tight lipped for now until we feel the time is right to release more details. We hope that RetroArch Open Hardware will be a contagious project that will see many contributors and participants working towards one common goal – being able to interface with the games media they’ve bought for all these decades and just being able to make it work with the software they’re already using without having to buy new closed-spec proprietary devices that lock you out of the software you’re already using. Free software is one thing, but it’s only as good as the hardware you’re running it on. Consider this our valiant effort of trying to get both sides in order.

For now, here is a gallery of screenshots to a few of our prototypes, brought to you by Sasa and m4xw.




LowRes NX – A new fantasy console core

Libretro Team



Written by Timo Kloss

We recently released a LibRetro core of LowRes NX. Most of you probably never heard about it before, so what is LowRes NX? You may know the fantasy consoles PICO-8 or TIC-80. These are retro style platforms to develop and play little games, but without actual hardware. Something like emulators for invented consoles. LowRes NX is based on the same idea, but has some significant differences.

Imagine LowRes NX as a handheld game console with a d-pad, two action buttons and a little rubber keyboard below a slidable touchscreen. LowRes NX was inspired by real 8- and 16-bit systems and simulates chips for graphics, sound and I/O, which actually work like classic hardware. It supports hardware sprites as well as hardware parallax scrolling, and even offers vertical blank and raster interrupts to create authentic retro effects.

The programming language of LowRes NX is based on second-generation, structured BASIC. It offers all the classic commands, but with labels, loops and subprograms instead of line numbers. Graphics and sound are supported by additional commands and you can even access the virtual hardware directly using PEEK and POKE. You have complete control over the program flow, there is no standard update function to implement.

LowRes NX includes all the tools you need: The Character Designer for editing sprites, tiles and fonts, the Background Designer for tile maps and screen layouts, as well as the Sound Composer for music and sound effects. All of these are just normal BASIC programs. You can change and improve them or even create your own custom editors.

LowRes NX has stand-alone applications for MacOS, Windows, Linux and iOS, which can be used to develop new games (even on iPhone). Although the LibRetro core doesn’t support development, it’s finally a way to play your games on many previously unsupported platforms.

Have a look at the website, where you can play all games made by the community online:
https://lowresnx.inutilis.com/

Where do you get LowResNX for RetroArch?

You can get it from RetroArch’s built-in Core Installer on the following supported platforms:

  • Android
  • Windows
  • Linux
  • macOS (x64/ARM)
  • 3DS
  • GameCube
  • Wii
  • WiiU
  • Switch (libnx)
  • PlayStation2
  • PSP
  • PS Vita

RetroArch 2021 Hardware Roadmap Q1/Q2

Libretro Team

2020 has been a year of accelerated growth for RetroArch, but 2021 looks set to surpass it by far! Here is what we are able to reveal of our current roadmap for now, but best believe us when we say this is only the tip of the iceberg!

Xbox Series

RetroArch raised a lot of heads last year when people figured out how to run it on the new Xbox Series consoles. Every Xbox console supports UWP (Universal Windows Platform), and every Xbox console can become a devkit by paying a one-time Developer fee, so this is not really reliant on any jailbreak/hack in the traditional sense. So all you have to do to make something be able to ‘run’ on an Xbox is to simply port your software to UWP, which is how RetroArch ended up being ojn Xbox. A good thing in our view, and it lets homebrew developers do what they want with the device from within a sandboxed environment. We hope more console manufacturers take a page out of Microsoft’s playbook there since the cat and mouse game that other companies like to play with their proprietary game consoles really has stopped making sense for a long time now.

We have made some significant improvements to the UWP (Universal Windows Platform) port that will definitely benefit Xbox users. Reading and writing to files used to be very slow in previous versions. It should be much faster now thanks to some generous improvements by contributor driver1998. We also intend to fix some of the display issues that might be going with certain hardware rendered cores like PCSX2 later on, there are some unfortunate menu rendering bugs right now when that core is running which shouldn’t be happening.

We are only providing RetroArch UWP as a stock version on our website that will run on both PC (Windows) and Xbox. We are not affiliated with the distribution of it anywhere else.

Apple Silicon – Mac M1


We’re happy to announce that RetroArch will start supporting the latest ARM-based Macs soon as a first-class citizen.

Right now, there are only three Mac devices you can buy that sport an ARM-based Apple M1 processor:

  • Macbook Air (2020)
  • Macbook Pro 2013 (2020)
  • Mac Mini (2020)

Features:

  • This will be a separate version from the currently existing Intel version. Metal will be the default video driver, since unlike RetroArch for Mac Intel, backwards compatibility is not a concern here.
  • It will require its own separate cores because of the processor architecture switch (ARM64/AArch64). This has been consuming quite a bit of time on our end building up the core library. So far, we have nearly 70 cores ready on our buildbot and more to come. NOTE: You won’t be able to run cores built for Intel RetroArch Mac on this new separate version.
  • There is no OpenGL support right now in the current Mac ARM64 version. However, while OpenGL has been deprecated for a while, it still works just fine on these ARM-based Macs, so we’d still like to find a way to include it so you can switch between the Metal and GL video driver.
  • Some dormant MoltenVK interfacing code has existed for a while in RetroArch but never really used before. We’d like to return to this. Once complete, it would allow us to run Vulkan-based cores on RetroArch Mac.

We’re impressed with the performance of these new Macs. While there is currently a lack of software on the platform in general, everything we have been able to run on them has so far exceeded our expectations in terms of performance. Expect RetroArch to run lovely on these new devices. It’s quite something when a laptop not only matches but exceeds modern Intel Core-based desktops in terms of CPU performance while being relatively noiseless but that seems to be mostly what we’re getting here. Everything runs great on RetroArch and with great frame pacing, and thanks to the Metal driver you’ll be able to use the slang shaders.

DE10-Nano


RetroArch will appear on the DE10-Nano this year. It’s basically an open source FPGA alternative to the likes of proprietary FPGA retro game consoles like the Analogue devices.

This port will rely in large parts on a member that we are collaborating with called Booger.

So far, RetroArch on DE10-Nano will be a plain-Jane port. RGUI works, it uses SDL for video, it works with gamepads, and it can run only software-based libretro cores for now (in other words, anything that is not an OpenGL/Vulkan-based hardware context core).

In terms of image enhancement, you are limited to basic software video filters, as there is no GPU, so the advanced stackable GLSL/Slang shaders in RetroArch remains a pipe dream for FPGA users unfortunately.

At RetroArch, we are building a platform. We do not think of our project as an emulator. Our stated goal is for this platform to be all-pervasive when it comes to being able to run it on as many different devices as possible. Giving people the choice to do with their hardware what they want is always the number one priority.

The DE10-Nano is an Intel SoC FPGA that can be bought off the shelf, and it’s currently intended as hardware subsidized for students. DE10-Nano right now is very much in a hobbyist realm where you need to source all these parts together and cobble them together to make them all work. There is also no affiliation between Intel and the homegrown efforts of these FPGA hardware cores. There’s a limited amount of places to buy this hardware from. The actual non-FPGA part of the hardware (ARM SoC) is rather weak compared to most modern ARM hardware. As mentioned before, there is also no GPU on the DE10-Nano, so OpenGL/Vulkan-based cores are not going to be able to be used on it. It’s important to keep expectations in check with regards to what will be able to be ran on it.

We don’t believe the future of emulation is necessarily going to end up either being software-only or hardware-only. Both are valid approaches and both have clear ups and downs. We think instead it will be complimentary, and that’s the way we want to approach it. We see a lot of possibilities for RetroArch as a platform on this, just like we do on other platforms. And the good thing about RetroArch is that precisely because it’s more than just an emulator, it doesn’t really matter, as a platform we can go whichever way the wind is blowing.

As ever with our project, whatever the DE10 Nano port can be and will be is going to depend in large part on where the community takes it. That’s the power of open source.

Below is a sneak peek of RetroArch running on DE10-Nano via HPS framebuffer on a CRT with TinyOS³.

Our new Libretro Infrastructure is now going live! (Plus Dosbox Pure out for Android/Mac/Windows)

Libretro Team

Our team has pushed an inhuman amount of effort over the holidays into making sure we can finally make the big switch in our infrastructure that we have been building up to ever since the server hack this past September.

And while it nearly looked like we might not have anything to show for it before the New Year, looks like we finally have something ready for you guys!

Thanks to the increase in Patreon earnings, we have finally been able to ditch the old dusty buildbot infrastructure and move over to a completely modern, built-from-scratch infrastructure. How it works is that we have our own Gitlab server now that mirrors all the repositories on our Github organization. This server is considerably beefier and more expensive than anything we have had before, and is able to cut through the cores and RetroArch workload like butter.

Where can I download stuff?

Same place as before – buildbot.libretro.com.

What’s ready so far?

The following platforms are ready to go (and already have up-to-date nightly RetroArch builds, tho a build could be missing here and there):

  • Android (*)
  • Emscripten (Web Player)
  • macOS (64bit – cores only) (**)
  • Linux (64bit)
  • OpenDingux (for RG350/GCW Zero/others)
  • Nintendo 3DS
  • Nintendo GameCube
  • Nintendo Wii
  • Nintendo WiiU (***)
  • Nintendo Switch
  • Sony PlayStation2
  • Sony PlayStation Portable
  • Sony PlayStation Vita
  • Windows (32bit/64bit) (****)

* – See the paragraph ‘Special notes on Android builds’.

** – Nightly builds for macOS still have to be added.

*** – For the first time, the WiiU version has everything out of the box that you need. In the past, assets would not be pre-installed and it would be very tedious and cumbersome to have to install them to the right place. This is all taken care of for you now. As a consequence though, the nightlies are a lot bigger to download now.

**** – The Windows nightly builds right now do not include Nvidia Cg support (old deprecated standard for shaders) and there is no installer yet. We hope to work something out there soon.

What’s next?

There is stuff still remaining to be done that we hope to sort out over the coming days/weeks. This includes:

  • ARM Linux cores
  • MacOS (64bit – binaries)
  • MSVC 2003/2005/2010 cores
  • RetroArch for older Windows versions (requires MSVC2003/2005/2010)

There are also still some cores missing here and there. There are a couple of reasons for this. One of them is that we still need to setup some .gitlab-ci.yml files for these repositories. All of that will come shortly though we hope.

We are of course also going to be releasing a new stable soon – 1.9.1.

What will all this mean for the user?

  • Faster build times
  • More platforms supported
  • Faster stable releases

m4xw will later be writing an article that goes into technical details on our new server, but here is a layman’s person breakdown on what this all boils down to.

Faster build times as a result of being able to run cores and RetroArch builds in parallel now. The old infrastructure was nearly completely sequential and it made things much slower than it used to be. But of course this is only half the story – the server specs have also been doubled, explaining why things are considerably faster.

Thanks to a massive increase in storage space and a reduction in server load, we can also now support more platforms. With the old server, we were running against the limit pretty hard on how many more platforms we could add before we would run out of disk space yet again. We thankfully no longer have these problems.

The faster stable releases alone is a big one. With the old buildbot infrastructure, it would take over an entire day to push out new binaries for RetroArch. It imposed a huge amount of stress on the entire team as every single time we ran these scripts, something would invariably go wrong for whatever reason. We leave all that behind today, after having had to deal with this for years on end. What this means is that you’ll likely no longer have to see announcements on our Twitter saying something is bound to be released and then it takes another day or two for it to finally arrive.

Also, for us as developers, the new infrastructure is a dream to work with, greatly reduces our workload, it’s no longer just a collage of scripts but uses modern technologies. What it means is that we have to do less fighting with our infrastructure and have more time to spend on our actual project instead.

What will all this mean for the contributor?

In the past, if we wanted to add a new core to our buildbot, somebody would send a PR to the libretro-super repository to add this core to one of the ‘recipes’.

This is all officially obsolete as of now. None of this is used anymore. Instead, the way it works now is:

  • You create a .gitlab-ci.yml file in a core repository (random example here). It needs to be in the root directory of your repository. You specify all the platforms here that the core should be building for.
  • We then add this repository as a CI mirror to our Gitlab server.
  • If all goes well, it spits out builds and these will then be available for download on buildbot.libretro.com

Libretro-super is now no longer used as a key part of our infrastructure like it was before. That doesn’t mean it’s completely useless. It can still be useful for the regular user to build stuff for personal use, and we will continue to update it. But it is no longer a fundamental part of our infrastructure like before, more a user convenience tool for building cores.

So, in other words, you don’t need to send anymore recipe update PRs to libretro-super in order to add new cores to our buildbot. Instead, you add a .gitlab-ci.yml file, then you talk to us and we add your repo to the Gitlab server.

Special notes on Android builds

Read our dedicated news article here on the Android builds

The nightly build that can be downloaded on our site right now is the non-Play Store version. The non-Play Store version is the version of RetroArch you have used up until this point, with a Core Downloader that connects directly to our build infrastructure. Because we don’t have to care about uploading this APK to the Play Store anymore, it can be a tad bigger than 100MB and therefore contain all the assets that we previously had to strip to save on space.

The Play Store version will be rolled out very soon and there are some big changes that were made in order to conform to the Google Play Store’s new guidelines. Some of it we think you will love while there are also some caveats.

The Play Store version’s Core Downloader contain a curated selection of cores hosted by Google’s servers (due to Play Store’s policies). More on that in the article. The user of course will always have the option of grabbing the non-Play Store build on our website which still has the Core Downloader that connects to our build infrastructure.

Special thanks

Special thanks to all the people that helped participate in this tremendous server migration: m4xw, jdgleaver, gblues, farmerbb, Steel01, fjtrujy, frangarcj, Xer Shadow Tail, and any others that participated. We would not have been able to make it without you!

And above all else, a huge shoutout to our Patrons who helped bring all this into reality! Without you guys, there is no way any of this could have been done, and we’d still be stuck with a slowly decaying infrastructure that was just impossible to salvage! A huge thank you, and with your monthly support the Libretro/RetroArch project will go into 2021 stronger than ever before!

Oh, and one last thing…

Dosbox Pure out now on the buildbot for Android/Mac/Windows!

We have just added Dosbox Pure for Windows, Mac (x64) and Android to our buildbot. Grab it from the Core Downloader as usual, and have fun! If you’d like to learn more about Dosbox Pure, read our dedicated article here.