In the run-up to RetroArch 1.1 – what’s ‘new’ pt. 4 (PowerPC Mac)

Libretro Team

We’ve been away for half a year so there is a lot to talk about in this new upcoming release. Rest assured I’m working hard as hell to meet the Christmas sweet spot.  It will take a couple of blog posts to go through it all. So let’s start with the first one. I’m putting these articles out now because I really don’t fancy having to write all this stuff later on in the holidays when I drop this stuff.

In this blog post, let’s talk about something else than cores that’s going to be new in v1.1

Continue reading “In the run-up to RetroArch 1.1 – what’s ‘new’ pt. 4 (PowerPC Mac)” →

In the run-up to RetroArch 1.1 – what’s ‘new’ pt. 3

Libretro Team

We’ve been away for half a year so there is a lot to talk about in this new upcoming release. Rest assured I’m working hard as hell to meet the Christmas sweet spot.  It will take a couple of blog posts to go through it all. So let’s start with the first one. I’m putting these articles out now because I really don’t fancy having to write all this stuff later on in the holidays when I drop this stuff.

In this blog post, let’s talk about some more about new cores and some fixes to existing cores

Continue reading “In the run-up to RetroArch 1.1 – what’s ‘new’ pt. 3” →

In the run-up to RetroArch 1.1 – what’s ‘new’ pt. 2

Libretro Team

We’ve been away for half a year so there is a lot to talk about in this new upcoming release. Rest assured I’m working hard as hell to meet the Christmas sweet spot.  It will take a couple of blog posts to go through it all. So let’s start with the first one. I’m putting these articles out now because I really don’t fancy having to write all this stuff later on in the holidays when I drop this stuff.

In this blog post, let’s talk about some other new cores you can expect.

Continue reading “In the run-up to RetroArch 1.1 – what’s ‘new’ pt. 2” →

In the run-up to RetroArch 1.1 – what’s ‘new’ pt. 1

Libretro Team

We’ve been away for half a year so there is a lot to talk about in this new upcoming release. Rest assured I’m working hard as hell to meet the Christmas sweet spot.  It will take a couple of blog posts to go through it all. So let’s start with the first one. I’m putting these articles out now because I really don’t fancy having to write all this stuff later on in the holidays when I drop this stuff.

In this blog post, let’s talk about one of the big new cores you can expect – gpSP.

gpSP

There has been some complaints in the past that the Game Boy Advance libretro cores are a bit too slow on some older systems. So people with lower-performance devices should probably be glad by the arrival of this core.

This is a Game Boy Advance emulator written by Exophase originally for the PSP.  It was a fast and reasonably compatible GBA emulator that later on made an appearance on platforms like iOS and Android by unofficial porters.

Exophase stopped working on this emulator around 2009 and ever since then the codebase has been gradually decaying. The interpreter CPU core was broken on 64-bit CPUs, the x86 dynarec was 32-bit only, and there is just no central repository that aimed at making this a reasonable first-class citizen that could compete against things like VBA-M and bgba.

So the libretro core is an attempt to do all that. It uses as a base notaz’ gpsp repo but strips out the Pandora/Raspberry Pi/GP2x-specific code and aims for a more general-purpose codebase. We managed to get the ARM dynarec working on Android with some code edits, and we also fixed a few bugs that was preventing the interpreter core from working on Intel 64bit architecture.

Performance-wise, the main substantial difference is when the dynarec is enabled obviously. This core should be substantially faster right now on ARM 32bit systems (Android/iOS/Blackberry, etc) than VBA-M and the VBA-Next cores ever did. It should be fast enough on Raspberry Pi and low-end Android devices like the Xperia Play. The 32-bit x86 dynarec should also be very beneficial for users that don’t mind putting up with 32bit code. Getting a 64-bit dynarec up and running is something that is on the installment plan (for me anyway).

Savestates should work but don’t expect to be able to use savestates from other gpSP-based emulators like Gameboid or whatever.  We had to change the savestate format/size during our 64bit compatibility patches, so this is unavoidable. Though really you shouldn’t expect savestates made with non-libretro based cores to be compatible with libretro cores necessarily anyway, so let’s not pretend like this is an issue.

As for how the performance is like with the interpreter? It varies from game to game. Games like Tekken Advance and Super Mario Advance are actually slower with the interpreter core than the same games on VBA Next, but then you have the odd exceptions like Metroid, Zelda, Wario Land, Donkey Kong Country games and Astro Boy where the performance with interpreter gpSP is at least twice as fast as VBA Next. Hopefully in the long run we can fix these remaining bottlenecks with interpreter core so that there is a nice counterweight to VBA-based emulators that is at least substantially faster even with just the interpreter core.

So what’s done?

– Runs on Android with the dynarec.

– Runs on 32-bit Intel with the dynarec.

– 64bit compatibility patches so that interpreter core runs on 64bit CPUs.

– Savestates work, SRAM works, most general features you’d expect from libretro, etc.

What still needs to be done in the future?

– Get the ARM dynarec working on iOS which requires some more patches. For now, the iOS port is using the interpreter so performance is not yet as great as it should be.

– Find some way to drop support in for Normatt’s open-source BIOS replacement so that users don’t necessarily have to use the ‘official’ GBA BIOS.

– Make the performance with the interpreter core a lot more even across games. Some games getting easily twice the performance as VBA Next while some games are actually 100fps lower than VBA Next seems to indicate that there is room for improvement here.

– Do the same as what I did with VBA Next/VBA-M cores and just ‘bake in’ the needed ‘assets’ that this emulator needs. Right now it needs a file called ‘game_config.txt’ present in the system directory which enables some idle loop optimization speedhacks among other things. This should all just be baked into the core later on.

– Make it big-endian compatible so it can run on consoles and PowerPC-based Macs.

– (If I have time to waste) write a PPC dynarec so we can really have a fast GBA core on PowerPC-based targets.

Hyperkins’ Retron5 – continuing licensing problems

Libretro Team

Yesterday, Hyperkin responded to our earlier article by acknowledging that they indeed did do what we claimed them of having done. In response, they posted a raw source code dump of the video game emulator software in question, confirming they were indeed infringing copyright and violating licenses.

http://www.nintendolife.com/news/2014/09/hyperkin_responds_to_accusations_of_infringing_on_the_rights_of_emulator_creators

http://retron5.in/node/9

However, they did not open source the code taken from the RetroArch project that is used within Hyperkin’s own frontend software.

By using RetroArch’s GPLv3 code, they are not only violating the license but breaking clauses that prohibit “Tivoization”

Today, Hyperkin posted another statement regarding the allegations of RetroArch code, admitting that code is indeed used in their product shipped in all versions of their firmware below the most recent release.

https://www.retro5.net/viewtopic.php?f=11&t=57&sid=638613d1c1de4fc414c15cc2654597e1&start=10#p267

I’d like to clarify one point regarding the allegations over at libretro.com: we are not using any of RetroArch in our “frontend” (libretron.so). While it is true that a few ASM functions from RetroArch were previously found in our frontend library, these were merely remnants of old test code which we unfortunately forgot to remove. The offending code has been removed as of the v2.0 update. We’re sorry that this code was left in the binary up until recently; it was merely an oversight on our part. Furthermore as you will see from the source release of the emulator cores, we have our own interface between the frontend and the core plugins, totally different from that used by RetroArch itself.

As our frontend does not include any code from the RetroArch frontend then it does not fall under GPLv3 as they claim, and thus is not bound by any of the anti “TIVO-ization” stuff.

We believe that previously distributed copies of Hyperkin’s firmware now fall under GPLv3 licensing and anti-tivoization terms and must be open sourced in order to adhere to the license. Also, we do not know the legality of selling a product with a firmware containing GPLv3 code in a TIVOized state, and then removing that GPLv3 code later on in a successive firmware update to effectively TIVO-ize it. That is something for FSF lawyers to ponder.

Visual evidence of RetroArch’s code in use by Hyperkin’s frontend binaries can be found here:
– http://imgur.com/a/i56YF
– http://www.libretro.com/index.php/retroarch-license-violations/ (see middle section titled “RetroArch”)

This can be compared against this codebase snapshot (they based the code’s inclusion on this snapshot of the code) –

https://github.com/libretro/RetroArch/tree/2be201ecf39077c864d06089a5b48aa97b170f8d

They’ve also alluded to using forced firmware updates to make sure the user cannot run original copies of the GPL software they bundle on this device, further adding to the TIVoization claims –

http://www.gamnesia.com/articles/gamnesias-exclusive-scoop-on-the-upcoming-retron-5#.VCKBh-IvBhE

Q: Assuming someone does break into it, how are you going to deal with that?
A: We do provide firmware updates through SD card support. If we start noticing people hacking and things like that—which I’m not against whatsoever; that’s the times we live in now, where if you could hack something, you’re a genius—we can release firmwares at any moment that would be required to start playing games. With that, you know, we can limit the control on that. – See more at: http://www.gamnesia.com/articles/gam…5#.VCKBh-IvBhE

There is another problem with what was stated here –

https://www.retro5.net/viewtopic.php?f=11&t=57&sid=638613d1c1de4fc414c15cc2654597e1&start=10#p267

They claim they no longer have any RetroArch code in their latest firmware and that  they have their own API that they use to dynamically link the core against their frontend (unreleased and closed-source). The problem with this is that their API appears to be not GPL-compatible.

For evidence, download the ZIP contained in here  (RetronN5Source-20140923.zip) and look at engine/retronCommon.h.

http://retron5.in/node/9

This API would need to be under a GPL-compatible license to be compatible with FCEU and VBA. Furthermore, it’s unknown what license the ‘frontend’ is licensed under, and since it’s closed-source and kept concealed, there’s no way of knowing if it infringes on the GPL license or not.

A core being exposed to the frontend through an API like this constitutes a combined work, because it is not a ‘well-separated work’ as per the terms stated here –

http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem

The core doesn’t do anything without the frontend, and the frontend links to this core dynamically through dynamic linking. The core is reliant on the frontend to do the audio/video/input processing, without which nothing would be displayed on the screen, no input would be received by the core, and no audio samples would get output.

Therefore, we believe that their latest acknowledgements raises even more questions as to the level of compliance they’ve demonstrated so far with the GPL license. It raises therefore even more questions than it solves, further adding to the already quite considerable list of problems with this device.

Non-commercial cores – SNES9x Next

And of course, the fact that the two non-commercial cores are still being shipped with the device is another problem altogether. The license for SNES9x states specifically:

https://github.com/snes9xgit/snes9x/blob/master/docs/snes9x-license.txt

Permission to use, copy, modify and/or distribute Snes9x in both binary
and source form, for non-commercial purposes, is hereby granted without
fee, providing that this license information and copyright notice appear
with all copies and any derived work.
This software is provided ‘as-is’, without any express or implied
warranty. In no event shall the authors be held liable for any damages
arising from the use of this software or it’s derivatives.
Snes9x is freeware for PERSONAL USE only. Commercial users should
seek permission of the copyright holders first. Commercial use includes,
but is not limited to, charging money for Snes9x or software derived from
Snes9x, including Snes9x or derivatives in commercial game bundles, and/or
using Snes9x as a promotion for your commercial product.
The copyright holders request that bug fixes and improvements to the code
should be forwarded to them so everyone can benefit from the modifications
in future versions.
Super NES and Super Nintendo Entertainment System are trademarks of
Nintendo Co., Limited and its subsidiary companies.

 

“Commercial users should seek permission of the copyright holders first” – refer to Hyperkin’s Retron5 licensing software page here –

http://retron5.in/node/9

They used the SNES9x Next fork specifically. This is a fork that I created specifically to serve as a libretro core. My list of contributions extends to the following:

– Added game-specific speedhacks to make them fullspeed for low-power systems like the Nintendo Wii and PlayStation3. This includes games like Final Fantasy III/VI, Star Fox, Star Fox 2, Super Mario World 2: Yoshi’s Island, and numerous other cores which were previously too slow on such devices.

– Added SuperFX overclocking code to make it possible to run SuperFX games at faster rates.

– Converted the entire codebase from C++ to C89.

– Wrote the libretro API integration parts together with Themaister/Hans-Kristian Arntzen. (NOTE: Libretro is licensed under the MIT license)

As you can guess, they have never sought my permission to use this in their commercial product. And they will never get it either. They are expressly forbidden by me (one of the copyright holders) to use this version of SNES9x in their commercial product. I’m still awaiting a response from the rest of the upstream SNES9x devs but I can’t expect their reaction will be that much different.

I will be taking steps of my own accord to ensure that this situation will be rectified.

Non-commercial cores – Genesis Plus GX

The Genesis Plus GX developers have been made aware of the facts as well and they can make their own moves as to how to deal with this.

On SNES9x Next however, I have considerable copyright claims and therefore I am in an ideal position to clamp down on this misuse of its code.

Last parting message

This can be read from Hyperkins’ response to our earlier article on Nintendolife.com –

It has always been our intention to release the relevant source code for the open source emulators used within RetroN 5. We have not been as quick as we could have been, since we have been busy improving the RetroN 5 user experience. The relevant source code has now been released. From this point forward we will not only keep our copy of this code updated for those who wish to obtain the latest version, but also submit patches for any fixes that we implement back to the original projects so that the entire community may benefit. Hyperkin will continue to endeavor to fulfill the licenses of any project used within RetroN 5 and any other software we write.

If Hyperkin is indeed serious about this, they will save my time and the time of the Genesis Plus GX developers by pre-emptively (and immediately) stripping the non-commercially licensed SNES and Genesis cores from their product. We’d rather be busy doing actual development that users benefit from and that benefits the community instead of having to go to the trouble of sending a bunch of Cease & Desist notices.

Also, let it be known that as of this moment I have contacted the FSF regarding the GPL violation matters because there remains too many unanswered and unsolved problems for us to be thoroughly satisfied. Our beef is not with the product – if Hyperkins’ Retron5 was put out in a honest way and in a way that wouldn’t infringe upon the licenses of these emulators, they would be legally allowed to use it in this way. As it stands, they did not do their homework before putting this product out and their actions so far reek of negligence, irresponsibility and a calculated move to reap the rewards of copyleft code without having to honor the license’s terms.