-
Why RetroArch?
04/03/2016 at 16:33 • 0 commentsIn this project log I will try to explain why having a pure RetroArch/libretro approach is technically cleaner.
The libretro API is there to separate the frontend (graphical interface) and the backend (the emulators). Adding an external frontend on top of it makes little sense, since it is an additional layer that can't take advantage of the low level API.
For example, with a frontend like RetroArch, you can display the current game in a small window while navigating the menu. This is not a very usefull feature, but it could become useful in the future to preview shaders.
Now, let think about effort duplication. Emulator hackers spend a lot of time trying to optimize emulators for the RPi. We end up with a ton of different versions, all with their graphical interface baked in.
If instead of that people focus on improving the libretro version of those emulators, this would benefit not only the RPi, but also all the platforms where RetroArch runs: PSP, Wii, iOS, etc
All the effort spent in including individual games on a distro like RetroPie and a frontend like EmulationStation could be instead spent in simply porting those games to libretro. This would make those games compatibles to every device supported by RetroArch. This would also make those games cleaner, by separating the content and the GUI.
Same goes for controller support. With a pure libretro distro, you get a centralised gamepad management. What works for games works for the menu. While with EmulationStation, the joypad code is duplicated. This is bloated.
Graphical contexts are another example. RetroArch already does the work of setting up the context like VideoCore or Mali or X11. External frontends have to duplicate that code.
There is no doubt that libretro should become the target platform if we want cleaner software.
Now I will try to explain why Lakka is better:
- Cross compilation : compile the whole distro in 2 hours on your PC and get the image.
- Compressed auto expandable image : the OS image is 150mb.
- Robustness : a read only system allows monolithic updates like firmware updates of commercial game consoles
- Centralisation : a single git repo to store all the package recipies, patches, configs
- Pure libretro : no bloat, consistency, no effort duplication, better integration with the GUI, better integration with the emulator developer community
- Portability : Lakka supports more than 10 ARM boards, plus PC, with a single code base
-Jean-André
-
Prototype PCB
03/29/2016 at 19:02 • 5 commentsAfter having successfully tested the display, the multiplexed buttons and the buzzer on a breadboard, we made a prototype PCB. This will allow [Jean-André] to work on the software while I work on the next PCB.
As our display uses most of the inputs, we used a trick to connect the 12 buttons using only 4 GPIOs. Usually, Charlieplexing uses N GPIOs with N/2 inputs and N/2 outputs to read
buttons. By adding diodes and using the N GPIOs as both outputs and inputs, we can read
buttons!
The PWM audio output is smoothed out by an RC filter and the left and right channels are mixed to mono in ALSA. We use a simple NMOS transistor to drive the buzzer but we will replace that with a 1.5W-3W amplifier and a proper speaker in the next version.
-David
-
Display
03/25/2016 at 14:38 • 3 commentsAs some have noted, we use a very special way to update our screen. I thought I could into some of the details about that.
Most projects with small screens use an interface like composite or SPI (PiTFT for example) because that is much easier to setup and use very few GPIO pins. The problem of composite is that it is not very sharp and the problem of SPI is that you cannot output the GPU directly to it so you have to use software which introduces some lag.
In our project we use the HDMI/DPI mode which enables us to have a very fast output with no CPU usage.
DPI is awesome
The main reason is because it’s wonderfully stupid.Thanks to the work of [Robert Ely], [Gert van Loo], [Dom Cobley] and the advice of [wpt-nathan], we were able to configure the interface in RGB565 which leaves us eight pins for SPI, the buttons, the backlight and PWM audio.
-David
-
Lutro and picolove
03/19/2016 at 11:03 • 0 commentsCurrently working on making picolove and libretro-lutro compatibles.
Picolove is an implementation of PICO-8 using the LÖVE game framework.
Lutro is a clone of LÖVE targetting the libretro API.This effort should result in the ability of running PICO-8 cartridge directly in RetroArch, our frontend.
-Jean-André