It's the end of an era...or the start of a new one. The first prototype version of Pyra, a handheld gaming system based on open source technologies, started to reach pre-order customers on December 23 after more than five years in development.
Pyra's basic design closely resembles the Nintendo DS product line: it's a clamshell product with a 5-inch display on top and a directional pad, face buttons and other gaming related input methods underneath. There are some changes, though, with the most obvious being the inclusion of a backlit keyboard beneath those buttons.
The device is based on a Texas Instruments OMAP 5 system-on-a-chip that includes two Arm Cortex-A15 processors clocked at 1.5GHz, two Arm Cortex-M4 processors, a PowerVR SGX544-MP2 graphics card and a Vivante GC320 2D Accelerator. Pyra can also be configured with 2GB or 4GB of memory and 32GB of eMMC storage.
Pyra's display boasts a 720p resolution--which isn't uncommon for a display of that size--and it's also equipped with a resistive touchscreen like the ones found in Nintendo's recent handhelds. The device also has built-in Wi-Fi and Bluetooth wireless support as well as a headset port, built-in microphone and HDMI video out.
All of that hardware is used to power Debian Linux. According to the project website, Pyra "is running a full desktop OS" and is "not crippled in any way." That means the device should be able to double as an itty-bitty productivity machine in addition to allowing people to play games made available for that particular Linux distribution.
Work on Pyra started in February 2014. Finally shipping the first prototypes to pre-order customers is an important milestone worth celebrating. It doesn't mean work on the project's anywhere near done, however, as its developer said in a forum post that there are many problems with the current prototype that need to be addressed.
Still, an open source project without significant financial backing reaching its first pre-order customers is exciting. Will most people rush to replace their current handhelds with Pyra when it officially debuts? Of course not. But that's not the point; the project showcases the possibilities afforded by open source technologies.
Of course, the Pi 4 is known for burning a lot of power, so maybe you'd have to down-clock it to get some half-decent battery life. But, even after that, it's still run circles around these guys, and it's also 100% open source.
But, I'm left wondering just how many gamers really care about whether their platform is open source. I'm guessing their main use case is just to play pirated ROMs in emulators of ancient consoles and arcade kiosks.
I mean.. If the intended purpose of this is just to be an incredibly weak box that defaults to running full desktop linux... then I would say that it is very much crippled in a lot of ways - all the way to its core concept even.
If this were designed to make a dedicated platform for homebrew developers to have a dedicated platform to make games in low-level languages/bare-metal/ assembly: awesome. Have the bootstrap point directly to an SD card or something easily removable as if it were a cartridge and let programmers do whatever (maybe this actually does that?). Also provide an ecosystem of tools and community to support it, which is the actually important part.
That's a cool concept. That makes sense. Things like that should exist on modern hardware, I think there is some demand for it as old platforms like C64 are getting new development because of that type of simplicity.
But this doesn't sound like that... The fact that there are multiple upgradable configurations tells me that simplicity was not their stated goal.
I mean, what is the point of using an open-source(?) CPU/GPU if the OS is going to get in the way of interacting directly with the hardware? People who just want to make a linux game with OpenGL or whatever can use pretty much any hardware in the world - almost all of which is more powerful... so I guess I'm missing the point.
Anyway, Vulkan is about providing low-level access to the hardware. But it's not simple, because neither is the hardware. If you wanted simplicity, you'd be better off using OpenGL.
I guess I mean simplicity in the sense that there is no abstraction of the hardware, therefore you have direct register and memory access. Being able to just make the computer exactly what you want (good or bad) and having the ability to literally never need to pass a pointer into a function. Everything is explicit. I mean, obviously Assembly (or more reasonably a mix of assembly and C) is not a simple language to read/write, even with good comments and fixed hardware. But I'm saying that's sort of the point. It would give an open handheld console a point.
People who just want to use open tools to make or play a game don't need this 500 Euro handheld, they probably already own several other more powerful devices - or they can just get a raspberry pi and put it into a portable case. People who need to make a game in 2020 don't even need to understand how their engine renders graphics, or even how their computer works.
That's why I think an open handheld is more interesting as a hobby than something anybody would actually want to use. The fun is instead giving yourself a limitation and then proving you can overcome it - then making friends who want to do the same and sharing the process with them. It would be about making a game not playing it.
It's probably a very limited appeal, but at least appealing to a specific neiche is some number of people. I doubt very many people thought they could learn how to program a microcontroller until Arduino made it easier, and now there's tons of projects people can easily get running and hopefully learn the basics of electronics. Maybe thats what I want: "Like Arduino but for games". And by want, I mean want to exist. I once programmed breakout in assembly using a monochromatic LCD, potentiometers, a beeper, and an 8052. It was an awesome experience that I never want to repeat. But I think it would be cool if people could experience the highs of that process in an easier to digest, toutorialized, and more social format.
It's like, I don't know, martial arts. Most people don't practice martial arts because it is the most effective combat or self-defense strategy in almost any situation in the modern world. They learn and practice it for the sake of learning and practicing it, for sport. And if somebody learns a skill that does end up being helpful later, I'm sure they are glad that they knew it.
We might as well start turning bare-metal programming into an ancient tradition now. Because, eventually in the future everybody who learned computers in the pre-DOS era will retire. Then who will be left to program our hardware libraries?
I grew up plugging values into VGA card registers and scribbling in video card memory. However, if you tried the same thing with a modern GPU (even the Power VR and Vivante units in this SoC), it'd take years to even try to make sense of it all, and you'd end up just re-implementing a thin driver of sorts, just so you could have a hope of doing something useful with it.
Exactly. That's why this thing makes no sense. If the Pi didn't exist, it'd be a different story... but it does.
I half-suspect that people were just bummed about the demise of Maemo. I had a Nokia tablet that ran it, and it was pretty cool to have a Linux handheld, back then (in 2008). It was also based on a Ti OMAP SoC, which I think is more than coincidental. Why else would you use that thing?
Yeah, so use a SNES emulator.
Even today, there are still people making things that run on C64 (even competing and showing off to each other):
http://www.pouet.net/prodlist.php?platform%5B%5D=Commodore+64&page=1
Sadly, today's kids will have to do this in emulators, or using vintage hardware.
I don't know about that. Most people don't have access to firearms or have to be in places where they can't have them (e.g. kids in school). And most self-defense situations don't call for lethal violence, anyway.
Usually electrical engineers, who start their education by understanding how the hardware is designed and implemented. From there, it's fairly straight-forward to see how to program it.
I agree that modern hardware is more-or less incomprehensible - although I often blame that on a severe lack of documentation available to hobbyists. For example you can't even read the full SD card spec without working for a company that pays a lot of money for a license to it. That's what makes the open source and community aspects so important. Anybody can go buy an ARM development board from Atmel or STMicro.. but the user experience is usually very poor or at least off-putting. that's the problem Arduino tried to improve so I am hopeful a similar concept could work for a general use microprocessor.
I would want an open system where users would have to start from scratch like when you buy a random dev board from a manufacturer that clearly has never run their own demo code on the board. The user wouldn't be expected to write their own drivers, they just should be open and available to anyone with a want or need to know how they work.
Yes! I think that is really awesome and is partly what I'm getting at. But the problem with retro computing is that, well, it's old vintage hardware. They have been breaking over time and many of those computers used proprietary hardware that is out of print and difficult to source.
There are still a lot of exciting developments in that space though as people try to make old-style computers using new hardware.
https://hackaday.com/2019/03/02/the-8-bit-guy-builds-a-16-bit-computer/
Although, the purism to old hardware is not quite what I am trying to describe.
Software emulation of old hardware is somewhat the polar opposite of what I mean.
Instead of trying to build an old computer with new parts, I want to see a new computer built with modern open hardware and software that can be enjoyed for the same reasons that retro computing is appealing... and coincidentally I think that will end up looking more like a retro game console or C64 than how PCs are currently built.
It doesn't necessarily need to run BASIC or CGA graphics or a 4 voice MIDI controller.. the real itch is for something that people can learn and understand in the same way that children in the 80's could learn their c64.
I think that retro computing enthusiasts are trying to scratch that same itch, but they are chasing it through a layer of nostalgia that I simply don't have. There is a need for that same feeling of learning and discovery, but I think or at least hope there is a way to get there without
I don't know if there are off the shelf parts available where such a thing is possible without designing custom hardware - and even if you open source your design or maybe there is an open design out there... you would be right back at many of the same problems that some of these other groups are facing by limiting themselves to the 8-bit era. Especially with the GPU.
But, who knows how something like that would really work out. At least it would be its own thing instead of yet another way to run linux.
What don't you like about emulators? You just like the touchy-feely aspects of vintage HW?
Some emulators are seriously good. I recently saw a demo simultaneously running on a Vectrex console and an emulator. The emulator got all the special effects nearly perfect. It was still incredibly neat to see the real hardware, but I imagine a lot of that was because I'd never seen a true vector graphics display (or, at least not after I was old enough to know what it was).
Well, FPGAs can save you all the trouble of fabbing ASICS. You could put down a soft core for the CPU and even a small GPU. The main issues would be licensing IP for the memory controller & display controller, as I recently read about a RISC-V CPU where they open-sourced the core design, but had to license some IP for the memory controller.
I still have to wonder how much you're really gaining over just using something like SDL. It seems pretty low-level, but with a lot of the sharp edges rounded off.
Oh, I like emulators just fine. They definitely have their place and I wouldn't look down on anybody using an emulator over vintage hardware to develop retro software. And I think it's really cool that people actually are doing that.
Just a drawback to an emulator in this context is that it is recreating old hardware that already exists, and the fun I'm having with this thought experiment at this point is the hardware design in itself.
Its a matter of distilling down why retro computing is appealing (other than nostalgia), then speculating on what a computer built today to have that same appeal would look like. Then from there, what the software ecosystem would look like.
Personally I feel the lack of an OS, is a part of it - at least in the sense that the old systems could boot essentially instantly and the user had as much control over the hardware as they wanted. I also feel that the hardware, while not easier to use than an API, was easier to understand. I agree a modern system would need to be as easy to program as possible and good tools to interface with the hardware would be essential. I just think if somebody wants to manually poke a register or a memory address, they should be able to.
They also had great manuals, were affordable for the time, and most importantly had software support - not just in games or programs to buy but in the sense that anybody could write and run basic (BASIC) programs without jumping though any hoops.
Is it possible to do it a way that avoids IP licensing issues down the line? I'm not sure.
In my mind it would be ideal if, once the design is in place, anybody could build their own at home (if they wanted) without dependence on any single centralized developer or distributor.
There's pros and cons if the design were to be an FPGA SoC. It would make for a much simpler board and hardware revisions could essentially be distributed online. It gives the design the ability to be ported to new FPGAs as hardware avaliability changes. But you do lose that physicality... I don't know if it would matter to a user but from a hardware development standpoint, licensing designs sounds like more of a hassle than buying an existing SoC.
I wouldn't foresee a purely FPGA design, but that's definitely something to look into