An Open Source Game Console

Howdy, folks!

I’ve finally managed to get (somewhat) settled into my new place in Oregon, so now it’s time to update the blog!

I’ve been following several Open Source hardware projects over the last few months (it’s easy to find free time during the pandemic… who knew?) and one of the most promising (and interesting!) I’ve seen is the “Icestation-32” console, which is an attempt to recreate 16-bit era graphics on an FPGA.

The benefit of using an FPGA rather than an embedded microcontroller-class chip is having the flexibility to improve upon a design as time goes on. This provides significantly more flexibility than having to substitute a entire component as your project becomes more complex.

The Open Source hardware project currently targets iCE40 and ECP5 boards which each have an Open Source toolchain to assist with deployment on the board of your choosing. Need I also mention that the CPU driving the game console is RISC-V based? 🙂

If you are interested in getting into game development, AND you happen to have an itch to explore what’s “under the hood” of a game console, I wholeheartedly recommend taking a look at this repository and getting familiar with its internals. You never know what form inspiration may take, eh?

Until next time!

Cheers! 🙂

Update: 8-14-20

Howdy, folks!

I’ve finally received my PinePhone! Yay! 😀

Now I have both a lightweight, powerful laptop, and a smartphone that I can do development with. I’m in the process of replacing the OS on the smartphone, though… UBPorts is incredibly limiting if you’re someone who likes to use GCC and compile all of your tools from source. I’d recommend Mobian, since I’m a desktop Debian user.

In other news, my quest for developing my own game console has borne some fruit! It turns out that there’s a new Hardware Description Language that actually allows you to create software-oriented algorithms into an optimized hardware description. This essentially lets developers stop thinking in signals and switches all the time, and instead focus upon program flow, which is a big relief. The language also lets you optimize parts with Verilog if you need it, which provides a degree of flexibility for performance considerations.

Besides that, I have a lot of movement going on in my life right now, so I apologize for the lack of consistent posting. Rest assured, however, that exciting things are on the horizon!

Until next time! 🙂

Cheers!

Update: 6-1-20

Howdy, folks! 😀

I’ve recently received my Pinebook Pro, and so far I am really enjoying it! The machine has a 1920×1080 display, operates at 5V, and has a pretty streamlined Manjaro Linux OS pre-installed.

All of that being said, I realized that if I want to play some games on this machine, I will have to resort to emulation of some sort. I found out that there’s already a Linux distribution called Recalbox which contains everything a ROM enthusiast could ever hope for.

However, seeing as I am hopelessly obsessed with Hardware Independence, and want to flex my mind-muscles a little, I thought it would be fun to write my own emulator from scratch. To make things even more interesting, I’m not going to try writing an emulator in software, no, no, no…

…I’m going to attempt to create one in “Hardware”!

That’s right! During my time in school I’ve already been exposed to FPGA development using Verilog, and I realized that if I want to get even better at creating my own circuits, then I need to start up some projects relating to digital circuit design. Spinning up my own game console capable of emulating the systems I grew up with sounds like a perfect way to kill two birds with one stone:

1. I get to learn more about digital design and hardware development.
2. I get to entertain myself with my new hardware that can play games!
3. Everything is Open-Source! (So, I guess that makes it “three birds”.)

*ahem*

So, what I’m noticing as I dive into the process of writing hardware with Verilog is that there is plenty of source code, but very few tutorials gluing everything together. So, while this is a little uncomfortable for me, I realize that there is also an opportunity here to fulfill a need. I am going to document the process of creating a game console from scratch with Verilog, which I intend to simulate with Verilator.

So, what is Verilator? Verilator provides a cycle-accurate model of your design as well as C++ hooks so you can add additional functionality to your model while evaluating your circuit as a userspace application. I’ve discovered from my initial research that it is possible to incorporate the SDL2 library into a design, which means that I can leverage the SDL2 library to handle user-facing devices while interfacing with the simulated device model at the same time.

So now the question is… what “game console” am I going to develop?

Right now I have my eyes fixed upon the original 8-bit NES, due to its simpler CPU and Graphics Processing capabilities. This is knowledge that I want to develop regardless, and it makes sense to pick a project that will give me some foundational knowledge that I can begin to build upon. Once complete, there are other directions I can go; I can cover the Gameboy series of hardware, or I can look at other consoles, but regardless of whatever I choose, I think I would like to graduate my knowledge to a point where I can implement something on-par with the original Sony Playstation. This is a piece of hardware that has a much more comprehensive GPU implementation, and is more feature-complete when compared with competitive modern graphics architectures we see on the market today. At this point, I would be happy to design my own System-on-a-Chip from scratch!

*whew*

I’m very excited by the opportunities here! I will begin posting as soon as I make headway with this new project. Expect tutorials on project planning, specifications, formal verification, and the like in the near future.

Until next time!

Cheers! 🙂

Update: 3-22-20

Howdy, folks! Hope you’re all staying safe and/or warm! 🙂

I still haven’t received my Librem5 smartphone yet, but, this is understandable due to the COVID-19 pandemic that the world is currently dealing with, and the fact that the phone is manufactured in China. >_<

I have also ordered a Pinebook Pro from PINE64, which only costs $199. The website indicates that orders will be shipped out by May. So, once we finally make it there, either I will have a 64 bit ARM laptop, or (hopefully) smartphone to tinker with.

I have also recently purchased a $40 Android tablet that I am looking into root-hacking so that I can get a Linux distribution running upon it as well. However things may pan out, I want to get started with my “Linux mobile” game development series so people can begin to migrate away from x86/x86-64 hardware.

So, why migrate away? Recently, more vulnerabilities have been published (more variations of side-channel attacks) that demonstrate that x86-based processors are not that secure. As a hardware developer, it seems clear to me that Intel’s relatively unchallenged market position made the organization overconfident and complacent when it manufactured the majority of their chips, and now AMD joins them. Note that most ARM-based mobile devices contain an A53 processor which is not vulnerable. However, a list of ARM-based processors that *are* vulnerable can be found here.

So, please bear with me as I try to get a Linux mobile environment set up. I think it’s very important to find a cost-effective, open-source solution for everybody. One I have found that, I will begin this new journey into a world of post-x86 game development. 🙂

Oh, yeah! Once RISC-V becomes more mainstream, I will probably being using RISC-V hardware exclusively. So, I’ll make sure to write articles that educate readers about it as well.

Until next time!

Cheers! 🙂

New News for a New Year

Howdy, folks! It’s been a while!

I’ve recently returned to school to pursue an education in Materials Science, so that has been occupying most of my time. However, now that I’ve got the rhythm of my next semester down, I think I can squeeze in some room for side projects and open-source contributions!

On that note, I’ve recently purchased a Librem 5 smartphone! Once I receive it, I plan on seeing how simple game development would be on this device. If it bears fruit, I intend to start writing a series of tutorials dedicated to Linux mobile game dev! 😀

I hope all of my readers are having a wonderful start to the New Year! 2020 should be very promising for us all!

Until next time!

Cheers! 🙂

 

Blender 2.80 Released

Hello! 😀

Finally, after four years of development, the Blender foundation has released version 2.80 of the legendary open-source 3D modeling and animation software, Blender. A list of features and things to look forward to can be found at this link.

If you’re eager to get your hands on this new hotness, you can also download it here.

Happy 3D modeling and animating! 😀

Cheers!

GodotEngine GSoC 2019 Report #1 Published

Hey hey hey! 😀

I was browsing through the GodotEngine website today and noticed a new News item regarding the engine’s Google Summer of Code projects. There seem to be a lot of cool features coming along which will hopefully find their way into the engine soon! I know I recently posted about the Vulkan backend that’s being developed, but the usability improvements that are being discussed here have the potential to catapult the engine’s popularity into the realm of proprietary engines like Unity3D and Unreal. *fingers crossed*

Exciting days ahead! 🙂

Cheers!

–UPDATE!–

The second half of the GSoC Projects covered can be found here. 🙂

GodotEngine Vulkan Progress Report #1 Published

Howdy, partners! 🙂

Juan Linietsky from the GodotEngine team just published an update regarding their efforts to update the engine’s underlying architecture so that it has proper Vulkan support. Of note is commentary on the sheer length of writing Vulkan initialization code as it applies to displays, as well as “halfway” progress made on the 2D portions of the engine.

The article, which discusses several aspects of working with Vulkan, indicates that most of the “Godot 3.x feature set” will be rewritten by October. Given that that’s only three months away, that’s a very promising sign!

I know I’m looking forward to trying out the new Vulkan renderer on my machine when it’s ready, so I will keep you all updated as things progress! 😀

Cheers! 🙂

LMMS 1.2.0 Released

Finally, after four years of development, the LMMS Digital Audio Workstation has been officially updated to version 1.2.0! This update brings about major UI improvements, tons of bug fixes, and the application itself is now distributed as an AppImage for those of us using GNU/Linux. You can just download it and give it a go. Convenient! 🙂

The LMMS AppImage can be downloaded directly from the LMMS website, or you can grab the application’s source over on Github, if you prefer.

Happy music-making, everyone!

Cheers! 🙂

Godot 3.1 Released

Howdy, folks!

After a long development cycle, version 3.1 of GodotEngine has finally been released! Included are vast improvements to the renderer, which now allows users to switch between (Open)GLES3 and GLES2 with the click of a button, and enabling more platforms to be targeted!

GodotEngine’s main developer, Juan Linietsky, has written that the game engine will have proper Vulkan support in an upcoming release. I know I can say that this will finally unify the engine’s underlying architecture, which is a benefit that will be passed on the end users.

…

In the meantime, I’ve been tinkering with OpenMW, which is the open-source re-implementation of the Gamebryo game engine (which was the platform utilized for Bethesda Softworks’ “The Elder Scrolls III: Morrowind”.) By studying its architecture, it has provided some inspiration about how to approach large, open-world, first-person RPG development.

Until next time!

Cheers! 🙂