One Coder Is Porting Portal To The Nintendo 64

When Portal came out in 2007, developers Valve chose not to release the groundbreaking title on an obsolete Nintendo console long out of production. Nobody cared at the time, of course, but [James Lambert] is here to right that wrong. Yes, he’s porting Portal to the N64.

The port, or “demake,” as [James] calls it, has been under construction for some time. The project has posed some challenges: Portal was developed for PCs that were vastly more powerful than the Nintendo 64 of 1996. Thus, initial concerns were that the console wouldn’t be able to handle the physics of the game or render the recursive portal graphics.

However, hard work has paid off. [James] has chipped away, bit by bit, making improvements to his engine all the while. The latest work has the portals rendering nicely, and the companion cube works just the way you’d expect. There’s also a visible portal gun, and the engine can even render 15 recursive layers when looking through mirrored portals. Sixteen was too much.

Of course, there’s still lots to do. There’s no player model yet, and basic animations and sound are lacking. However, the core concept is there, and watching [James] flit through the not-quite-round portals is an absolute delight. Even better, it runs smoothly even on original Nintendo hardware. It’s a feat worthy of commendation.

We had no idea what [James] had in store back when we featured his work creating real-time shadows on N64 hardware. Now we know! Video after the break.

Continue reading “One Coder Is Porting Portal To The Nintendo 64″

Things Are Getting Rusty In Kernel Land

There is gathering momentum around the idea of adding Rust to the Linux kernel. Why exactly is that a big deal, and what does this mean for the rest of us? The Linux kernel has been just C and assembly for its entire lifetime. A big project like the kernel has a great deal of shared tooling around making its languages work, so adding another one is quite an undertaking. There’s also the project culture developed around the language choice. So why exactly are the grey-beards of kernel development even entertaining the idea of adding Rust? To answer in a single line, it’s because C was designed in 1971, to run on the minicomputers at Bell Labs. If you want to shoot yourself in the foot, C will hand you the loaded firearm.

On the other hand, if you want to write a kernel, C is a great language for doing low-level coding. Direct memory access? Yep. Inline assembly? Sure. Runs directly on the metal, with no garbage collection or virtual machines in the way? Absolutely. But all the things that make C great for kernel programming also make C dangerous for kernel programming.

Now I hear your collective keyboards clacking in consternation: “It’s possible to write safe C code!” Yes, yes it is possible. It’s just very easy to mess up, and when you mess up in a kernel, you have security vulnerabilities. There’s also some things that are objectively terrible about C, like undefined behavior. C compilers do their best to do the right thing with cursed code like i++ + i++; or a[i] = i++;. But that’s almost certainly not going to do what you want it to, and even worse, it may sometimes do the right thing.

Rust seems to be gaining popularity. There are some ambitious projects out there, like rewriting coreutils in Rust. Many other standard applications are getting a Rust rewrite. It’s fairly inevitable that the collection of Rust developers started to ask, could we invade the kernel next? This was pitched for a Linux Plumbers Conference, and the mailing list response was cautiously optimistic. If Rust could be added without breaking things, and without losing the very things that makes Rust useful, then yes it would be interesting. Continue reading “Things Are Getting Rusty In Kernel Land”

An ATTiny board that one of the students developed for this project, etched on single-sided FR4.

Electronics And C++ Education With An ATTiny13

When [Adam, HA8KDA] is not busy with his PhD studies, he mentors a group of students interested in engineering. To teach them a wide range of topics, he set out to build a small and entertaining embedded project as they watch and participate along the way. With this LED-adorned ATTiny13A project, [Adam] demonstrated schematic and PCB design, then taught C++ basics and intricacies – especially when it comes to building low-footprint software – and tied it all together into a real-world device students could take home after the project. His course went way beyond the “Hello world”s we typically expect, and some of us can only wish for a university experience like this.

He shares the PCB files and software with us, but also talks about the C++20 framework he’s developed for this ATTiny. The ATTiny13A is very cheap, and also very limited – you get 1K of ROM and 64 bytes of RAM. This framework lets you make good use of it, providing the basics like GPIO wiggling, but also things like low-power operation hooks, soft PWM with optional multi-phase operation support and EEPROM access. Students could write their own animations for this device, and he includes them in the repo, too!

In educational projects, it pays to keep code direct and clean, cruft-less and accessible to students. These are the things you can only achieve when you truly understand the tools you’re working with, which is the perfect position for teaching about them! [Adam] intends to show that C++ is more than suitable for low-resource devices, and tells us about the EEPROM class code he wrote – compiling into the same amount of instructions as an Assembly implementation and consuming the same amount of RAM, while providing compile-time checks and fail-safe syntax.

We’ve talked about using C++ on microcontrollers before, getting extra compile-time features without overhead, and this project illustrates the concept well. [Adam] asks us all, and especially our fellow C++ wizards, for our opinions on the framework he designed. Could you achieve even more with this simple hardware – make the code more robust, clean, have it do more within the limited resources?

What could you build with an ATTiny13, especially with such a framework? A flashy hairclip wearable, perhaps, or a code-learning RF-remote-controlled outlet. We’ve also seen a tiny camera trigger for endurance races,, a handheld Flappy Bird-like console, and many more!

Modifying Old Fonts In The Name Of Baseball

Baseball is in full swing again, and having recently accepted a position with Major League Baseball, [Ty Porter] is warming up with a big contribution to the MLB LED Scoreboard project — modifying 20-some old fonts to support baseball’s ‘ꓘ’ character that indicates a special strikeout with a called third strike (meaning the batter didn’t take a swing).

The problem is that Major League Baseball-the-entity recently deprecated the original data source for the scoreboard project. This called for a huge refactor of the codebase, including previously-patched fonts which were now showing either the font’s default no-character character, or nothing at all.

Fortunately, BDF font files are fairly human-readable and make reference to bitmap, which is an actual bitmap in hex. [Ty] settled on Unicode A4D8 (ꓘ), a character from the Tibeto-Burman language Lisu that certainly looks good enough to this baseball fan. Then it became a matter of mirroring the bitmap for ‘K’. [Ty] tried a few things like reversing the nibbles and looking up each one in a table, but that also mirrors the padding, which is bad news.

Then he tried not reversing the nibbles and just looked them up in a table, but this approach dropped and added bits unintentionally. Finally, he tried reversing the order, looking up the reversed nibble, and shifting each byte until there was no padding. This worked for most of the 20 fonts [Ty] patched. The others fell in line with some manual work.

Not much of a baseball fan? You’re almost guaranteed to like this one, especially if you hate mayo.

A modern Tamagotchi PCB design and built-up prototype

Classic Tamagotchi Is Reincarnated In Modern Hardware

If you thought that Tamagotchis were a late ’90s fad that has faded from most people’s memory by now, you’d be wrong: the franchise is still alive and well today, with new models being released regularly. But even the original model from 1996, known as Tamagotchi P1, is being kept alive by a small group of enthusiasts. When ROM dumps of the original hardware began floating around the internet a couple of years ago, even those without the real thing could run these virtual pets in an emulator.

But the whole idea of the Tamagotchi hardware was that it was portable enough to carry around anywhere. If you’re among those who missed that part of the Tamagotchi experience, you’ll be pleased to know that [JC] designed OpenTama: a portable hardware platform that runs an emulated version of the original Tamagotchi P1 software. It’s about as close as it gets to those first-generation virtual pets, but with several additions that make your life easier.

The software platform is [JC]’s TamaLib which we featured last year; in effect it’s an open-source emulator that allows the Tamagotchi ROM to run on a variety of modern hardware platforms. It also contains several additional options like the ability to save and restore your progress or to select customized ROMs. The OpenTama hardware, meanwhile, is a proper 21st-century reimplementation of the original: a small, egg-sized PCB sporting an STM32 microcontroller driving an LCD or OLED display, powered by a 100 mAh battery that can be recharged through a USB-C port.

OpenTama is not limited to the TamaLib software, either: as an open-source general-purpose platform, it can also be used as a learning tool for embedded programming, so if you’ve always wanted to program your own virtual pet, or are simply looking to build a fancy egg timer, OpenTama’s GitHub page is the way to go. We’ve seen quite a few neat Tamagotchi-like projects recently: this 3D-printed one comes with a nice retro LCD screen, while this one’s giant size ensures you don’t forget to feed it.

Continue reading “Classic Tamagotchi Is Reincarnated In Modern Hardware”

How To Hide A Photo In A Photo

If you’ve ever read up on the basics of cryptography, you’ll be aware of steganography, the practice of hiding something inside something else. It’s a process that works with digital photographs and is the subject of an article by [Aryan Ebrahimpour]. It describes the process at a high level that’s easy to understand for non-maths-wizards. We’re sure Hackaday readers have plenty of their own ideas after reading it.

The process relies on the eye’s inability to see small changes at the LSB level to each pixel. In short, small changes in colour or brightness across an image are imperceptible to the naked eye but readable from the raw file with no problems. Thus the bits of a smaller bitmap can be placed in the LSB of each byte in a larger one, and the viewer is none the wiser.

We’re guessing that the increased noise in the image data would be detectable through mathematical analysis, but this should be enough to provide some fun. If you’d like a closer look, there’s even some code to play with. Meanwhile as we’re on the topic, this isn’t the first time Hackaday have touched on steganography.

Hacking Toy RC Cars With The HackRF One

The origin story for many who’d call themselves a member of the hacker community usually starts with taking things apart as a child just to see how they worked. For [Radoslav], that trend doesn’t seem to have slowed down, and he’s continued taking toys apart. Although since it’s his daughters little radio controlled car, he stuck to a non-destructive teardown. The result? He’s able to control the car with his laptop through a HackRF One SDR transceiver as shown in the video below the break.

[Radoslav] is no stranger to reverse engineering embedded devices, IoT gadgets, and probably more. So he started with what information was publicly available about the radio control interface in use. Many electronic devices sold in the US must be certified by the FCC (Federal Communications Commission) and prominently display their ID number, and this toy was no exception. The FCC database gave [Radoslav] enough information to know that the communication protocol is modulated with GFSK, a type of Frequency Shift Keying.

He fired up his favorite radio signal analysis tool and and got to work on the protocol itself. Along the way he found that communication between the car and controller is bidirectional but also very easy to get around. The result is that he can drive the car around with his laptop- definitely a cool hack, but for this one, the journey was surely the goal, not the destination.

If hacking on RC cars really gets your wheels turning, you might like this little RC car that can drive on the ceiling. Or if you’re feeling a bit hungry, check out how you can use the HackRF to nab a table at your local restaurant.

Continue reading “Hacking Toy RC Cars With The HackRF One”