Quake In 276 KB Of RAM

Porting the original DOOM to various pieces of esoteric hardware is a rite of passage in some software circles. But in the modern world, we can get better performance than the 386 processor required to run the 1993 shooter for the cost of a dinner at a nice restaurant — with plenty of other embedded systems blowing these original minimum system requirements out of the water.

For a much tougher challenge, a group from Silicon Labs decided to port DOOM‘s successor, Quake, to the Arduino Nano Matter Board platform instead even though this platform has some pretty significant limitations for a game as advanced as Quake.

To begin work on the memory problem, the group began with a port of Quake originally designed for Windows, allowing them to use a modern Windows machine to whittle down the memory usage before moving over to hardware. They do have a flash memory module available as well, but there’s a speed penalty with this type of memory. To improve speed they did what any true gamer would do with their system: overclock the processor. This got them to around 10 frames per second, which is playable, but not particularly enjoyable. The further optimizations to improve the FPS required a much deeper dive which included generating lookup tables instead of relying on computation, optimizing some of the original C programming, coding some functions in assembly, and only refreshing certain sections of the screen when needed.

On a technical level, Quake was a dramatic improvement over DOOM, allowing for things like real-time 3D rendering, polygonal models instead of sprites, and much more intricate level design. As a result, ports of this game tend to rely on much more powerful processors than DOOM ports and this team shows real mastery of their hardware to pull off a build with a system with these limitations. Other Quake ports we’ve seen like this one running on an iPod Classic require a similar level of knowledge of the code and the ability to use assembly language to make optimizations.

Thanks to [Nicola] for the tip!

Getting PCIe Working On The New Pi 5

After the Pi 4 released, a discovery was quickly made that the internals of the popular single-board computer use PCIe to communicate with each other. This wasn’t an accessible PCIe bus normally available in things like desktop computers for expansion cards, though; this seemed to be done entirely internally. But a few attempts were made to break out the PCIe capabilities and connect peripherals to it anyway, with varying levels of success. The new Pi 5 seems to have taken that idea to its logical conclusion and included a PCIe connector, and [George] is showing us a way to interface with this bus.

The bus requires the port to be enabled, but once that’s done it’s ready to be used. First, though, some support circuitry needs to be worked out which is why [George] is reverse engineering the system to see what’s going on under the hood. There are a few handshakes that happen before it will work with any peripherals, but with that out of the way a PCIe card can be connected. [George] removed the connector to solder wires to the board directly in order to connect a proper PCIe port allowing a variety of cards to be connected, in this case a wireless networking card and an old Firewire card. This specific build only allows Gen 1 speeds, but the bus itself supports faster connections in theory with better wiring and support circuitry.

While it might not be the prettiest solution, as [George] admits, it does a great job of showing the inner workings of this communication protocol and its use in the new, more powerful Raspberry Pi 5. This makes a lot of things more accessible, such as high-speed PCIe HATs allowing for a wide range of expansion for these popular single-board computers, which wouldn’t have been possible before. If you’re still stuck with a Pi 4, though, don’t despair. You can still access the PCIe bus on these older models but it’ll take a little bit more work.

Thanks to [CJay] for the tip!

Continue reading “Getting PCIe Working On The New Pi 5”

The Ease Of Wireless Charging, Without The Wait

Historically, there have been a few cases of useful wireless power transmission over great distances, like a team at MIT that was able to light up a 60 W bulb at several meters, and of course Nikola Tesla had grand dreams of drawing energy from the atmosphere. But for most of us wireless power is limited to small, short-range devices like cellphone chargers. While it’s not a lot of work to plug in a phone when it needs a charge, even this small task can be automated.

This build begins with a 3D printed cradle for the smartphone to sit in. When the device detects that the phone has been placed in the cradle, it uses a linear actuator to drive a custom-built charging cable into the phone’s USB port. Similarly, when the phone is lifted from the cradle the cable is automatically removed. It appears that there is some play in the phone’s position that lets the charger be plugged in smoothly, and the project’s creator [Larpushka] points out that the linear actuator is not particularly strong so we don’t imagine the risk of damage is very high.

While wireless charging still may have the edge when it comes to keeping debris out of the port, we still really enjoy a project like this that seems to be done for its own sake. There are some improvements that [Larpushka] plans to make, but for now we’re delighted by this build. For anyone looking to add true wireless charging to any phone that doesn’t have it, though, it’s not too difficult to accomplish either.

Talking To A Texas Instruments Calculator

Texas Instruments is a world-class semiconductors company, but unfortunately what they are best known for among the general public is dated consumer-grade calculators thanks to entrenched standardized testing. These testing standards are so entrenched, in fact, that TI has not had to update the hardware in these calculators since the early 90s. They still run their code on a Z80 microcontroller, but [Ben Heck] found himself in possession of one which has a modern ARM coprocessor in it and thus can run Python.

While he’s not sure exactly what implementation of Python the calculator is running, he did tear it apart to try and figure out as much as he could about what this machine is doing. The immediately noticeable difference is the ARM coprocessor that is not present in other graphing calculators. After some investigation of test points, [Ben] found that the Z80 and ARM chips are communicating with each other over twin serial lines using a very “janky” interface. Jankiness aside, eventually [Ben] was able to wire up a port to the side of the calculator which lets him use his computer to send Python commands to the device when it is in its Python programming mode.

While there are probably limited use cases for 1980s calculators to run Python programs, we can at least commend TI for attempting to modernize within its self-built standardized testing prison. Perhaps this is the starting point for someone else to figure out something more useful to put these machines to work with beyond the classroom too. We’ve already seen some TI-84s that have been modified to connect to the Internet, for example.

Thanks to [Nikša] for the tip!

Continue reading “Talking To A Texas Instruments Calculator”

Change Desktop Environments On… IOS?

While Apple’s modern operating systems may seem like they exist independently of the rest of the computing world, they are actually close cousins of modern versions of Linux. The primary link between the two is that Apple’s offerings are Unix-based and even though Linux isn’t Unix in the strict sense, it’s built to be extremely Unix-like. Plenty of Linux software is POSIX-compliant, meaning it is effectively compatible with true Unix. But what can we do with that information? Well, to start, we can run Linux desktop environments on top of an iOS install on your favorite iPhone or iPad.

To be sure, we will be filing this hack in the “because you can” category. [Torrekie], the creator of this project, has plenty of builds (Google translate from Chinese) where the boundaries between things like Linux and Unix are either blurred or nonexistant. In this particular project, a jailbroken iOS device is essentially gifted a ported version of XFCE which is able to run fairly well on iOS thanks to its compatibility with Unix environments. Details on how this was accomplished are sparse without a full investigation of the source code right now, but you can head over to the repository if you are curious enough to try this for yourself. [Torrekie] does note that this will only work with iOS devices that have been jailbroken using the “unc0ver” jailbreak only though.

To be sure, the relationship between modern Apple operating systems and Linux is about as close as modern Porsches and the Volkswagen Beetle, but either way the two are close enough to get interesting and impressive mashups like this project. For now only time will tell if using XFCE on iOS will be useful for anyone, but other projects bridging the gap between Linux and Apple are sure to be more immediately fruitful.

The Doom computer game rendered with HTML checkboxes

Play DOOM Using Web Browser Checkboxes (Finally)

If you’ve ever felt the need to render DOOM using nothing but web browser checkboxes, [Andrew Healey] has you covered with his recent port of the first-person shooter. Naturally, this gets our tick of approval.

Yes, you read that right. You can now play DOOM in a 160 x 100 grid of HTML-generated checkboxes, much like this: ☑. The secret sauce for this project is partly derived from the fascinating Checkboxland project by fellow hacker Brian Braun, who uses HTML checkboxes to generate a variety of artistic demos.

[Andrew Healey] also made use of Cornelius Diekmann’s port of DOOM using WebAssembly, which we recently covered here on Hackaday. A smattering of code ties both projects together, and the end result is DOOM at 160×100 resolution, rendered entirely with HTML checkboxes.

The port can be played here using Chrome or Edge (other browsers may have issues if they do not support the zoom property in CSS). The source code is also available over on GitHub.

While the resolution and color palette aren’t what we have come to expect from DOOM, it’s likely that the graphics could be further improved by tinkering with the dithering and threshold settings. Higher resolutions may also be possible with further optimization.

We would be hard pressed to pick our favorite port of DOOM, as the list is becoming quite long. However for something completely different, check out our story on how DOOM was brought to Twitter.

Continue reading “Play DOOM Using Web Browser Checkboxes (Finally)”

DOOM Played By Tweet

Getting DOOM to run on hardware it was never intended to run on is a tradition as old as time. Old cell phones, embedded systems, and ancient televisions have all been converted to play this classic first-person shooter. This style of playing games on old hardware might be passé now as the new trend seems to be the ability to play this game on more ethereal platforms instead. This project brings DOOM to Twitter.

The gameplay is a little nontraditional as well. To play the game, a tweet needs to be sent with specific instructions for the bot. The bot then plays the game according to its instructions and then tweets a video. By responding to this tweet with more instructions, the player can continue the game tweet-by-tweet. While slightly cumbersome, it does have the advantage of allowing a player to resume any game simply by responding to the tweet where they would like to start. Behind the scenes of the DOOM-playing Twitter bot is interesting as well and the code is available on the project’s GitHub page.

While we’ve seen plenty of DOOM instances on all kinds of hardware, it’s safe to say we’ve never really seen a gameplay experience quite like this one. It may stay as a curiosity, but DOOM porters are always looking for something else to run this classic game so it may eventually branch out or develop into something more user-friendly like this cloud-based Atari 2600.