Game Dodecahedron Runs AArch64 Assembly

Operating systems are great things to have for general purpose computing, but sometimes they can just get in the way. There’s RAM overhead and processor cycles required for all that operating, after all. For something like a game system, it seems unnecessary. The NES certainly did well enough without an OS, as did its various successors for several console generations.

[Inkbox] wanted to get back to those heady days by programming bare-metal games for a Rasberry Pi 3 that had sat unused since 2016. Games are on cartridge, running bare metal, in assembly — as God and Masayuki Uemura intended. Also, the console is a dodecahedron, because the name GameCube was already taken.

The GitHub link above doesn’t exactly have documentation, at least as of this writing, so you’ll need to watch the video to get the full details. The dodecahedron form factor might not be ideal for packing away in a bag, but as a handheld we have to admit it does look comfortable to hold. Two faces of the dodecahedron get a half-dozen buttons each, which are wired to a GPIO pin on the Pi via a Schmitt trigger for hardware debounce. Like all good consoles, it uses cartridges, these ones being adapted from SD cards on large PCBs derived from a project we featured before.

That all sounds great, but it’s the assembly programming we’re really interested in — skip to around the seven-minute mark in the video for that. Ultimately it’s a build video, so not the ideal tutorial for ARM assembly programming, but it might not be a bad introduction for some. Unfortunately you don’t get line-by-line of the PacMan game he put together — but he does have it in the repository for you to examine. The repo also has STLs if you want to make a dodecahedron of your own.

Of course he’s got a RetroPi cartridge as well, loaded with emulators, and we suspect that’s mostly how this GameDodecahedron will get used. Still, we’ll always have a soft spot for assembly code and projects that use it — be it on ARM, good old 6502, the open-source RISC V architecture, or even the absolute monster of op codes that is x86.

Continue reading “Game Dodecahedron Runs AArch64 Assembly”

Haiku Isn’t Just For X86 Anymore, Boots On ARM In QEMU

Ever since it was called OpenBeOS, Haiku has targeted the x86 platform. That makes good sense: it’s hard enough maintaining a niche system on ubiquitous hardware. But x86 isn’t the only game in town anymore. Apple’s doing very well on ARM, Linux runs on oodles of ARM SBCs, and even Windows uh, exists, on that architecture, so why not Haiku? That’s what [smrobtzz] figured, and thanks to his work you can now run Haiku on ARM, in QEMU.

There’s no image available as yet — you still need to bootstrap your own from a working system, and ironically that system cannot be Haiku. [smrobtzz] apparently used MacOS, which makes sense as his ultimate goal is apparently to go where only Aishi Linux has gone before and boot Haiku on his M1 MacBook. There had been previous efforts to get Haiku going on Raspberry Pi hardware, which seems logical considering how lightweight the operating system is, but they’re apparently nowhere near booting either. QEMU is a good start.

Interestingly, according to the ports page, Haiku is “functional” on both RISC V QEMU and the now-discontinued HiFive Unmatched SBC. We don’t seem to have covered it, but that milestone happened five year ago. Given how most RISC V boards currently available are a bit slow for modern desktop Linux, Haiku would likely be a breath of fresh air. The BeOS-descended system might be single user, but it’s snappy.

We reported a couple of years back that Haiku was daily-drivable on x86 ,it’s only gotten better since then, assuming you choose the right hardware. Hardware support is always the hard part about alternative OSes, but Haiku users are absolutely spoiled compared to fans of MorphOS, which still only runs on G4 or G5 PowerPC, and even then not only some hardware.

UEFI On ARM? More Likely Than You Think

Now, Rock 5 ITX+ is no x86 board, sporting an ARM Rockchip RK3588 on its ITX form-factor PCB, but reading this blog post’s headline might as well give you the impression. [Venn] from the [interfacinglinux.com] blog tells us about their journey bringing up UEFI on this board, thanks to the [EDK2-RK3588] project. Why? UEFI is genuinely nice for things like OS switching or system reconfiguration on the fly, and in many aspects, having a system management/configuration interface for your SBC sure beats the “flash microSD card and pray” traditional approach.

In theory, a UEFI binary runs like any other firmware. In theory. For [Venn], the journey wasn’t as smooth, which made it very well worth documenting. There’s maybe not a mountain, but at least a small hill of caveats: having to use a specific HDMI port to see the configuration output, somehow having to flash it onto SPI flash chip specifically (and managing to do that through Gnome file manager of all things), requiring a new enough kernel for GPU hardware acceleration… Yet, it works, it really does.

Worth it? From the looks of it, absolutely. One thing [Venn] points out is, the RK3588 is getting a lot of its features upstreamed, so it’s aiming to become a healthy chip for many a Linux goal. From the blog post comments, we’ve also learned that there’s a RPi UEFI port, even if for a specific CPU revision of the Model 5B, it’s still a nifty thing to know. Want to learn more about UEFI? You can start here or here, and if you want a fun hands-on example, you could very well start by running DOOM.

One ROM to rule them all.

Software Defined Retro ROMs

Here’s something fun from our hacker [Piers]: Software Defined ROMs.

In this series of three videos, [Piers] runs us through what a software defined ROM is, how to make them, and then how to use them.

As [Piers] explains, one frustration a retro technician will face is a failed ROM chip. In the era he’s interested in, there are basically three relevant kinds of ROM chip, all 24-pin Dual Inline Package (DIP):

  • 2364 ROM chip: 8KB; 1x chip-select line
  • 2332 ROM chip: 4KB; 2x chip-select lines
  • 2316 ROM chip: 2KB; 3x chip-select lines

Continue reading “Software Defined Retro ROMs”

Daisy Chain Of Hacks Lets New Arm Board Run Doom

Running DOOM on ARM? Old hat. Running Doom (2016) on an ARM SBC? Well, that’s a bit more interesting, and [Interfacing Linux] shows us how with this handy guide, and in a video embedded below.

The ARM SBC in question is the Radxa Orion O6, which claims to be the world’s first open source ARMv9 motherboard. It has a 12-core ARM9.2 SoC from Cix, and crucially for gaming, a PCIe x16 slot to fit a graphics card. There’s onboard graphics in the SoC, of course, but that’s only going to cut it for old DOOM, not Doom (2016).

Obviously there is no ARMv9 build of this nine-year-old classic. Thus, a certain degree of hacking is required. An x86 emulation layer called FEX is used to run Steam, which includes the Proton compatibility layer to sit between the Linux system and the Windows system calls the games are making.

So, again: Windows games, running via a compatibility layer on a Linux system running on an x86 emulator, running on another Linux system, running on ARM hardware. Yeah, we’d call that a hack, and just possibly cursed. The amazing thing is that it works. As long as you use a PCI 3.0 graphics card, anyway; apparently newer ones don’t work, or at least not the one [Interfacing Linux] had to try. (Some report better luck with newer NVIDIA cards.) Which is a pity, because every game tested is GPU-throttled on this system. Considering the CPU should be handling all the emulation, that just goes to show how GPU-heavy even 10-year-old games are.

[Interfacing Linux] seems to enjoy running things where they should not; we just wrote up their SteamOS console.

This isn’t the first time a Radxa board has shown up on Hackaday either, but they don’t seem to be nearly as popular as the fruit-flavoured competition for the sort of projects we usually see. If you’ve got a good project using one of these powerful ARM boards– or anything else, don’t hesitate to send us a tip!

 

 

Screen shot of Mongoose Wizard.

How To Build An STM32 Web Dashboard Using The Mongoose Wizard

Today from the team at Cesanta Software — the people who gave us the open-source Mongoose Web Server Library and Mongoose OS — we have an article covering how to build an STM32 web dashboard.

The article runs through setting up a development environment; creating the dashboard layout; implementing the dashboard, devices settings, and firmware update pages; building and testing the firmware; attaching UI controls to the hardware; and conclusion.

The web dashboard is all well and good, but in our opinion the killer feature remains the Over-The-Air (OTA) update facility which allows for authenticated wireless firmware updates via the web dashboard. The rest is just gravy. In the video you get to see how to use your development tools to create a firmware file suitable for OTA update.

Continue reading “How To Build An STM32 Web Dashboard Using The Mongoose Wizard”

Zynq-7000 banner.

Building A Custom Zynq-7000 SoC Development Board From The Ground Up

In this series of 23 YouTube videos [Rich] puts the AMD Zynq-7000 SoC through its paces by building a development board from the ground up to host it along with its peripherals. The Zynq is part FPGA and part CPU, and while it has been around for a while, we don’t see nearly as many projects about it as we’d like.

[Rich] covers everything from the power system to HDMI, USB, DDR RAM, and everything in between. By the end, he’s able to boot PetaLinux.

Continue reading “Building A Custom Zynq-7000 SoC Development Board From The Ground Up”