RetroArch and LibRetro do not share any copyrighted content.
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:
Super expensive.
No longer in production/out of stock
Rights to the product changing hands between sellers/store owners
Because of 3, usually one or two stores can only sell them.
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.
You know how badly we want to bring RetroArch to Steam. For now, we are evaluating what we have. Steam recently announced a new feature, PlayTest, an alternative version of this Beta access. We have published our PlayTest version to an access request. To obtain this version, you can go to our store page and click "Request Access" located there. This version will have the same features as the main version. DLCs will come as download. It is newest build with these cores included;
We're trying to get more people on RetroArch's Steam test. We would love to invite everyone, but there are regulations we need to follow... Tomorrow we will distribute the keys on www.libretro.com as first come, first served. We prepared dozens of keys! You can use this link for countdown or you can mark on your calendar this date: 20.10.202 Tuesday GMT 18:00 (06:00PM)
You can find the latest news from us by following the links below!
Those who know us know how much we love to make new improvements almost every day. In this case, we have made the following major and minorupdates.
We have updated RetroArch to the latest improvements. You can see the latest technical improvements here.
We have increased file Size limits for SteamCloud.
Added new save file type for SteamCloud.
Changing behavior of “gl” and “glcore” video drivers.
Let's take look for "gl" and "glcore" video drivers changes.
What are they ?
“gl” and “glcore” are 2 video drivers available on desktop computer :
“gl” is an OpenGL 2.0+ driver, when used with a version above 3.0 it’s called OpenGL Compatibility and can support up to OpenGL 4.6, but some GPU drivers don’t have that OpenGL Compatibility mode.
“glcore” is an OpenGL 3.1+ driver, it’s also called OpenGL Core, it supports up to OpenGL 4.6.
OpenGL is one of graphics API that can be used to draw 3D with you GPU, it is the most widely supported by devices and emulators.
What changed ?
Until now, when launching a core with an OpenGL renderer, RetroArch would consider both “gl” and “glcore” video drivers as valid choices, meaning you could launch a core internally using OpenGL Compatibility with the “glcore” video driver, and a core internally using OpenGL Core with the “gl” video driver. It’s not possible anymore, now cores will try to force the video driver matching what they want. This change only concerns platforms with OpenGL Core support, meaning platforms like android and many others aren’t concerned.
Why was this change needed ?
Maybe you are one of the lucky guys who didn’t encounter major issues with the previous behavior, but there are actually several reasons to change this :
some cores will glitch if the video driver doesn’t match the context they are requesting
cores will usually perform faster if you use the video driver they expect
OpenGL compatibility isn’t reliable for cores that require OpenGL versions above 3.0, because some GPU drivers don’t support this, so it’s safer to force OpenGL Core in those cases
to be honest, it makes more sense like this, it leverages user experience, and we shouldn’t ignore what is requested by the core
The first thing you should make sure, is that the setting “Allow cores to change video drivers” is turned on (that’s the default), as far as i know turning this setting off was used as a workaround for some of the issues fixed by those commits, so i don’t see a scenario anymore where it could be anything but harmful.
You should do if those changes prevent a core from working on your setup, is to mention @barbudreadmon on github or discord so that he can look into your issue.
Last but not least, there are 2 settings you might optionally consider changing :
if you are currently using the setting “shared hardware context”, you should probably consider turning it off, it adds rendering latency while it shouldn’t be necessary anymore with those changes (the cores that actually require this setting will force it).
if your GPU is less than 15 years old and your platform supports “glcore”, you should probably consider using “glcore” over “gl” as default OpenGL video driver, it generally produce better overall results.
You can find the latest news from us by following the links below!
We heard your complaints about the last key giveaway, so this time we come better prepared. On Saturday (9/26/2020) we will be handing out new keys for RetroArch Steam beta at https://libretro.com/
We are giving away new Steam beta testing keys tomorrow for RetroArch tomorrow (9/22/2020) at exactly 20:00 GMT+1. The link will go live on this URL and you can use this link to see it on your local time.
We are happy to present one of the expected features, Steam Cloud backups. With this feature, you will be able to back up some files in your RetroArch directory to your Steam Cloud.
#Discussions_QuoteBlock_Author
RetroArch/saves // saves folder retroarch.cfg // main configuration file RetroArch/states *.state // every state file RetroArch/config *.opt // dlc options *lpl // history entries
In order for the Steam Cloud sync to work correctly, default directories shouldn't be changed to other locations.
New beta testing keys will be available on 9/8/2020 at exactly 19:55 GMT (Greenwich Mean Time) +1. If you need to know what time this is in your specific timezone, visit this link here.
As you probably already know, a year ago we announced that RetroArch would be releasing on Steam. We have worked hard on this for a fair while now. The process is slower than expected due to reasons beyond our control.
It’s been a lengthy process and we have had to significantly retool things to conform to Steam’s policies and guidelines, one of which is no Core Updater (just like on Google Play now).
While we wait for our release candidate build to be manually approved by Steam (which we’ve been told is a lengthy process), in the meantime we will start giving away beta testing keys. We want to gather as much feedback as possible from users so that the final experience on Steam lives up to people’s expectations.
So with that in mind, we are giving away keys for our first beta test version, Beta 1.