Graphing Calculator Gets USB-C Upgrade

Unlike Texas Instruments, whose graphing calculators have famously not made technological improvements in decades despite keeping the same price tag, HP has made a few more modern graphing calculators in the last few years. One of which is the HP Prime which boasts hardware from the mid-2010s including an ARM processor, a color screen, and rechargeable lithium battery. But despite this updated hardware it’s still using micro-USB for data and charging. [David] wanted to fix that by giving this calculator a USB-C port.

The first steps were disassembling the calculator case and removing the micro-USB port. The PCB is glued to the LCD screen which isn’t ideal, but he was able to work on it with everything attached. The parts are small enough to need a microscope, and with a hot air station he was quickly able to remove the USB port. His replacements from a generic online retailer were able to be soldered without much effort, but there was one major complication. The new USB-C ports didn’t account for the “On The Go” mode supported by micro-USB and were shorting a pin to ground which put the calculator into “host” mode instead of acting as a device. But using the microscope and cutting a trace on the PCB disabled this mode permanently and got the calculator working properly.

As far as modernizing calculators go, it seems like the HP Prime checks a lot of boxes, with the major downside that the LCD screen and more powerful processor means that the battery needs to be charged more often than the old TI calculators. Rather than carry a dongle around everywhere, [David] found this to be a much more efficient change to his trusty HP. If you’re still stuck using TI calculators, though, there are a few ways to modernize those as well like this build which adds a lithium battery or this one which ports a few Game Boy games to the platform.

A New Golden Age Of Browser Games

Arguably, the golden age of browser gaming occurred in the 00s mostly revolving around Adobe Flash. This was an era with high creativity and a low barrier of entry, and also decentralized from gatekeeping app stores. Sadly, these times have passed us by as the security concerns around Flash led to its discontinuation and most casual gamers have migrated to the app store for their fix. But that doesn’t stop some from continuing to bring gaming to the browser, even if those games were never intended for it in the first place like this browser port of Celeste.

Celeste is an indie platformer where the player climbs a mysterious mountain while confronting her inner struggles. Originally meant for consoles and PC, a group of friends including [velzie], [bomberfish], and [Toshit] aka [r58Playz] took this as a challenge especially after seeing someone else’s half finished web port of this game. Most of the build revolves around WebAssembly (wasm) and around “cursed” .NET runtime hacks which also allow the port to run the community-made Everest mod loader. It uses a multithreaded and JIT compiling version of mono-wasm backported from .NET 10 to .NET 9 to maximize performance. The team actually first started by porting Terraria to the browser, and then moved on to this Celeste port from there.

The port of Celeste can be played here, and their port of Terraria is also available, although may not support a ton of Hackaday traffic so some patience is advised. There are also GitHub repositories for Celeste and Terraria as well.  With impressive ports of relatively modern games moving into the browser, perhaps we’re entering a new golden age of browser gaming; we’ve also seen things like Minecraft implemented in only HTML and CSS lately as well.

Factorio Running On Mobile

As a video game, DOOM has achieved cult status not just for its legendary gameplay and milestone developments but also because it’s the piece of software that’s likely been ported to the most number of platforms. Almost everything with a processor can run the 1993 shooter, but as it ages, this becomes less of a challenge. More modern games are starting to move into this position, and Factorio may be taking a leading position. [Point Substantial] has gotten this game to run on a mobile phone.

The minimum system requirements for Factorio are enough to make this a challenge, especially compared to vintage title like DOOM. For Linux systems a dual-core processor and 8 GB of memory are needed, as well as something with at least 1 GB of VRAM. [Point_Substantial]’s Xiaomi Mi 9T almost meets these official minimum requirements, with the notable exception of RAM. This problem was solved by adding 6 GB of swap space to make up for the difference.

The real key to getting this running is that this phone doesn’t run Android, it runs the Linux-only postmarketOS. Since it’s a full-fledged Linux distribution rather than Android, it can run any software any other Linux computer can, including Steam. And it can also easily handle inputs for periphreals including a Switch Pro controller, which is important because this game doesn’t have touch inputs programmed natively.

The other tool that [Point_Substantial] needed was box86/box64, a translation layer to run x86 code on ARM. But with all the pieces in place it’s quite possible to run plenty of games semi-natively on a system like this. In fact, we’d argue it’s a shame that more phones don’t have support for Linux distributions like postmarketOS based on the latest news about Android.

Thanks to [Keith] for the tip!

Macintosh System 7 Ported To X86 With LLM Help

You can use large language models for all sorts of things these days, from writing terrible college papers to bungling legal cases. Or, you can employ them to more interesting ends, such as porting Macintosh System 7 to the x86 architecture, like [Kelsi Davis] did.

When Apple created the Macintosh lineup in the 1980s, it based the computer around Motorola’s 68K CPU architecture. These 16-bit/32-bit CPUs were plenty capable for the time, but the platform ultimately didn’t have the same expansive future as Intel’s illustrious x86 architecture that underpinned rival IBM-compatible machines.

[Kelsi Davis] decided to port the Macintosh System 7 OS to run on native x86 hardware, which would be challenging enough with full access to the source code. However, she instead performed this task by analyzing and reverse engineering the System 7 binaries with the aid of Ghidra and a large language model. Soon enough, she had the classic System 7 desktop running on QEMU with a fully-functional Finder and the GUI working as expected. [Kelsi] credits the LLM with helping her achieve this feat in just three days, versus what she would expect to be a multi-year effort if working unassisted.

Files are on GitHub for the curious. We love a good port around these parts; we particularly enjoyed these efforts to recreate Portal on the N64. If you’re doing your own advanced tinkering with Macintosh software from yesteryear, don’t hesitate to let us know.

Another Doom Port To The Atari ST

Last week, we examined a Doom port for the venerable Atari ST. As is so often the way with this thing, one netted another, and [Steve] wrote in to inform us about a different version under the name DOOM8088ST.

The port is so named because it’s based on Doom8088, which was originally written for DOS machines running Intel 8088 or 286 CPUs. Both ports are the work of [FrenkelS], and aims to bring the Doom experience into the far more resource constrained environment of the Atari ST. There is only very limited sound, no saving, and it only supports Doom 1 Episode 1. Still, it’s quite recognizable as Doom!

Doom8088ST is tunable to various levels of performance, depending on what you’re running it on. Low mode (30 x 128) is suitable for stock Atari ST machines running at 8 MHz. It’s described as having “excellent” framerate and is very playable. If you’ve got an upgraded ST or Mega STe, you can try Medium (60 x 128), which has greatly improved visuals but is a lot heavier to run.

Files are on Github for those interested to run or tinker with the code. Don’t forget to check out the other port we featured last week, either, in the form of STDOOM. Video after the break.

Continue reading “Another Doom Port To The Atari ST”

Command And Conquer Ported To The Pi Pico 2

A couple of months back, Electronic Arts did something uncharacteristically benevolent and released several of the old Command and Conquer games under the GPLv3. Logically, we knew that opened the doors up to the games being ported to new operating systems and architectures, but we admit that it was still a little surprising to see Command and Conquer: Red Alert running on the Raspberry Pi Pico 2.

[Charlie Birks] documented the process of getting the 1996 game up and running on the microcontroller in a series of Mastodon posts spanning a few days in March. Seeing the incremental progress made each day makes for interesting reading, as he moves from the game just barely starting up to being able to complete missions and eventually even get multiplayer going between two Picos.

As [Charlie] clarifies, he’s technically using the Pimoroni Pico Plus 2 W, which takes the RP2350B from the official Pico 2, adds 8 MB of PSRAM, and bumps the onboard flash to 16 MB. The upgraded specs and an SD card are required to get the game running, as content that would have originally been held in RAM on the computer must instead be pulled from flash.

For an even more streamlined experience, he eventually slaps the Pico Plus 2 W into the Pimoroni Pico VGA Demo Base — which provided not only an integrated SD card slot, but (as the name implies) VGA output.

It’s still early days, but [Charlie] has been pushing all of his code changes into his fork of Red Alert on GitHub for anyone who wants to play along at home. If you get his fork compiled and running on your own Pico, we’d love to hear about it in the comments.

Smallest USB Device… So Far

For better or worse it seems to be human nature to compete with one another, as individuals or teams, rather than experience contentedness while moving to the woods and admiring nature Thoreau-style. On the plus side, competition often results in benefits for all of us, driving down costs for everything from agriculture to medical care to technology. Although perhaps a niche area of competition, the realm of “smallest USB device” seems to have a new champion: this PCB built by [Emma] that’s barely larger than the USB connector pads themselves.

With one side hosting the pads to make contact with a standard USB type-A connector, the other side’s real estate is taken up by a tiny STM32 microcontroller, four phototransistors that can arm or disarm the microcontroller, and a tiny voltage regulator that drops the 5V provided by the USB port to the 3.3V the STM32 needs to operate. This is an impressive amount of computing power for less than three millimeters of vertical space, and can operate as a HID device with a wide variety of possible use cases.

Perhaps the most obvious thing to do with a device like this would be to build a more stealthy version of this handy tool to manage micromanagers, but there are certainly other tasks that a tiny HID can be put to use towards. And, as far as the smallest USB device competition goes, we’d also note that USB-A is not the smallest connector available and, therefore, the competition still has some potential if someone can figure out how to do something similar with an even smaller USB connector.

Thanks to [JohnU] for the tip!