Sheet music is displayed on a screen, with the label "AIR" in the center top, and "Bach" to the right.

Reverse Engineering Score Perfect To Rescue Its Files

There are myriad challenges associated with data preservation – bit rot, loss of metadata, and hardware failures, among others – but one of the hardest is making sure that the data remains usable as software goes out of date. [Maarten Tromp]’s father, for instance, had been using the Score Perfect music notation program for years, but since development ceased in 2012, the files would eventually need to be transferred to more modern software. To do this, [Maarten] undertook a four-year project to reverse-engineer the structure of Score Perfect’s files.

Score Perfect was first released in 1990 for Atari and later ported to Windows, and after version four, it switched to a different file format. It had the option to export to MusicXML, but it only exported notes, not chords, lyrics, or other important details. [Maarten] first tried disassembling the program itself to find the file structure; he had hoped that the Visual Basic code might have been compiled to P-code, which is relatively easy to disassemble, but it had been compiled to native code. Interestingly, through version four, the program had been written for Atari and ran in Windows through a simple emulator. It wasn’t fully rewritten for Windows until later. After some investigation into the file-export function with Ghidra, he moved on to reverse-engineering the file format itself.

This consumed the majority of the project’s time. To investigate the file’s structure, [Maarten] would start by creating an empty file in the program, make one change, and compare the difference in the file written. This gradually revealed the organization of information — the file was arranged into blocks containing different kinds of information, such as measures and notes, and tags, which provided supplemental information. Once again, incremental changes revealed the function of most of these, and [Maarten] was eventually able to write a translation program to export Score Perfect files to MusicXML.

We’ve previously seen a similar effort to reverse-engineer the Altium file format. At least in these cases, though, all the necessary information is contained in the files, unlike the reverse-engineering often necessitated by STL files.

Making CO₂ Sensors Fail Visibly, Not Silently

CO₂ buildup in a living area can be a serious problem, and a sensor that fails quietly cannot be relied upon. [William Collis] addressed this important issue by creating CO₂ monitors built to fail visibly.

[William] has a nice home setup that can monitor CO₂ levels in two places, but noticed an important issue: the system always displayed the last known-good sensor reading. An unchanging, healthy-looking number is good! Unless it isn’t, because a flat unchanging number is also exactly what a dead sensor looks like.

The solution was for [William] to change how the sensors are treated so a faulty sensor isn’t hidden behind apparently-good values, and the sensor itself flashes a visible fault LED in the case of a problem.

Each monitor is a Sensirion SCD30 CO₂ sensor, paired with a Seeed XIAO ESP32-C3 running ESPHome to communicate with Home Assistant, an open-source home automation framework. There was no need to rewrite the ESPHome firmware; all his modifications fit within the context of a configuration file and certainly seem to be improvements over the original.

Sensors that can be relied on are important, but if the system itself needs some ruggedizing maybe consider a homebrewed UPS for Home Assistant.

ESP32 Flight Tracker On Apple CRT

Sometimes we’re most taken by what’s on the screen; sometimes the screen itself is the most interesting part of the project. In this case, it’s the latter. That’s no slight against [Virtual-Bet-4566], whose ESP32-based flight tracker looks very nice– but a big part of what it makes it so nice is that it’s displaying the ADS-B flight data on an old green-phosphor monitor from the Apple II days.

He’s using an ESP32-WROOM-32, which gives him both the wifi connection needed to grab aircraft locations and flight details– including photos of individual aircraft, when available from Planespotters.net– but crucially has an 8-bit digital-analong-converter that he’s using to drive the composite input on the old Apple monitor. Not all of the expansive ESP32 family have that feature, but at this point you might as well call ESP32 a brand of MCU than a family given the vast differences between them. Since composite video doesn’t need much power, he’s connected the dev board directly to the monitor. It’s that delicious combination of the old and new that really gets us vibing.

It can show you an image of the plane, but it’s not exactly high-def.

Speaking of vibing, yes, this whole thing was vibe-coded, as [Virtual-Bet] freely admits in the Reddit thread. LLMs seem to be really good at making these flight tracking apps, to judge from other posts on that site, but this one stands out for its display method. He’s also apparently got weather and his own local sensor data incorporated in the wifi-controlled display application, and isn’t interested in sharing the code since you could prompt it yourself. Fair enough.

We’ve seen composite-out from the ESP32 family before, more than once— which is probably how the LLM knew to pull it off–but there’s just something about that green glow.

Story via CircuitDigest.

Borland C++ 2.0 Compiler Source Reconstructed

As the successor to Turbo C++, Borland C++ was a staple of professional IDEs for C and C++ development, starting with the initial 2.0 release in 1991. Being a commercial project the original source code for the toolchains were naturally not made available by Borland, but thanks to the efforts of [Abedegno] we have now got what is claimed to be a byte-perfect recreation, in the sense that the binaries compiled using the toolchain are identical to the original toolchain.

The process of creating the source from the original toolchain binaries is detailed in a separate document, including the use of [Abedgno]’s Claude Code-based Exhume tool to assist in the effort.

Having the source code for BC++ 2.0 available is probably most useful for projects that deal with DOS-based software from the same era, as well as for purely historic interest reason. When BC++ 2.0 was released, the C programming language had only just seen itself standardized in the form of C89, and C++’s initial standard in 1998 was still years away.

Thanks to [Stephen Walters] for the tip.

X Window System On The ESP32

There are a lot of things you can do with an Xserver, but run it on a microcontroller? Well, if that microcontroller is an ESP32-S3, [Sergey Zorin]– and Claude– have got you covered with Woodland X11, a full-featured port of everyone’s favourite XServer.

Now, it is just the core Xserver with no extensions, and currently targeted specifically at the Elecrow CrowPanel Advance 4.3″, a device that packages an ESP32-S3-N16R8 with an 800×480 RGB565 IPS panel and GT911 touch. In this implementation, your finger is the Xcursor. There’s even two-finger scroll implemented, though no keyboard. As you can see in the demo video embedded below, it works well enough for those oldschool X applications like xclock, xcalc and– crucially!– xeyes. What’s the point of an Xserver without googly eyes, anyway?

In reality, you’re not likely to set this up just for Xeyes, but the idea of having bringing Linux applications to a little display via WiFi or — as in the video– wired connection has no limit of use cases. Try that with Wayland!

Considering X11’s vintage, it is perhaps not surprising that it fits on the ESP32-S3, a chip we’ve seen emulate an entire 386 PC before– a PC that could run an Xserver, for you youngun’s.

Thanks to [Sergey] for the tip!

Continue reading “X Window System On The ESP32” →

Using A Toothbrush’s NFC Chip To Unlock A Computer

Depending on which type of electric toothbrush you are using, the replaceable brushes may contain an NFC chip that the handle and possibly base station uses to track various details, such as time spent brushing and when to replace the brush. The Philips Sonicare of [Circuit Helper] is one such unit, with its NFC chip tracking aspects like runtime and pressure.

Unsurprisingly it’s easy enough to read and write this same NFC chip with a PN532 NFC reader and ESP32-S3 MCU. This reveals data fields for everything from brush type, to total runtime and expected lifetime, inviting a bit of experimentation on how certain usage patterns affects these data fields.

This much is perhaps not too shocking, but the fun part is what you can do with the chip after you have figured out how to write to its memory. How to unlock these units and their NXP NTAG213 IC has been figured out a few years ago already, so the hardest part was to figure out what to do with this information.

The demonstrated use case in the video is to unlock an Apple Macbook, which is maybe a bit too niche. Also demonstrated is taking the chip and its antenna out of the brush, which turns out to be quite easy. Perhaps salvaging just this one part of the brush is the more practical and hygienic option, as who doesn’t like building up a strategic supply of ‘free’ NFC chips?

Continue reading “Using A Toothbrush’s NFC Chip To Unlock A Computer” →

Drop-in Vintage CPU Replacements With The TranZPUter Project

One of the struggles with vintage computer systems is that many of the ICs in them have no modern-day version that you can just purchase and drop-in. Creating replacements that use modern-day ICs inside has consequently become a popular direction, with [Philip Smart]’s TranZPUter being one such example.

Standing for ‘transformable ZPU Computer’, the tranZPUter is transformable in the sense that it features an FPGA or MCU and the initial iteration targeting the ZPU Evo CPU design. This has led to a number of variants of this concept, including a version targeting the Z80, the 6502 and 6809. These are based around the RP2350B MCU, using its PIO peripheral to great effect.

Of these the Motorola 6809 is probably the lesser known MPU, having been launched in 1978 as an 8-bit MPU with some 16-bit features that could beat the 6502 in many metrics courtesy of its more advanced hardware. It being more expensive led to it only being used in systems like the TRS-80 Color, Dragon 32/64, SuperPET and a whole range of arcade systems.

If you have any of those 6809-based systems and the MPU gave up the ghost, you can drop in the Pico6809 board featuring said RP2350B MCU as well as an ESP32 co-processor. Currently it targets the Dragon 32/64 systems, adding not just a fresh MPU, but also adds virtual floppy and cassette devices as well as network support as options.

Overall it seems like a pretty extensive project that might already have found purchase within the retrocomputing community.