A Much Faster Mac On A Microcontroller

January 11, 2026 by Jenny List 6 Comments

Emulating older computers on microcontrollers has been a staple of retrocomputing for many years now, with most 8-bit and some 16-bit machines available on Atmel, ARM, or ESP32 platforms. But there’s always been a horsepower limit, a point beyond which a microcontroller is no longer enough, and a “proper” computer is needed. One of those barriers now appears to have been broken, as microcontroller-based emulation moves into the 32-bit era. [Amcchord] has the Basilisk II emulator ported to the ESP32-P4 platform, providing a 68040 Mac able to run OS8.1. This early-1990s-spec machine might not seem like much in 2026, but it represents a major step forward.

The hardware it uses is the M5Stack Tab5, and it provides an emulated Mac with up to 16 MB of memory. Remember, in 1992 this would have been a high-spec machine. It manages a 15 frames per second refresh rate, which is adequate for productivity applications. The emulator uses the Tab5’s touchscreen to emulate the Mac mouse alongside support for USB input devices. To 1990 hackers, it’s almost the Mac tablet you didn’t know you would want in the future.

We like this project, both because it’s advancing the art of emulation on microcontrollers, and also because it delivers a computer that’s useful for some of the things you might have done with a Mac in 1992 and could even do today. Pulling this out on the train back then would have blown people’s minds. There’s even a chance that MacOS on something like this would turn a few heads in 2026. It’s certainly not the first emulated Mac we’ve seen though.

A UI-Focused Display Library For The ESP32

January 9, 2026 by Lewin Day 13 Comments

If you’re building a project on your ESP32, you might want to give it a fancy graphical interface. If so, you might find a display library from [dejwk] to be particularly useful.

Named roo_display for unclear reasons, the library is Arduino-compatible, and suits a wide range of ESP32 boards out in the wild. It’s intended for use with common SPI-attached display controllers, like the ILI9341, SSD1327, ST7789, and more. It’s performance-oriented, without skimping on feature set. It’s got all kinds of fonts in different weights and sizes, and a tool for importing more. It can do all kinds of shapes if you want to manually draw your UI elements, or you can simply have it display JPEGs, PNGs, or raw image data from PROGMEM if you so desire. If you’re hoping to create a touch interface, it can handle that too. There’s even a companion library for doing more complex work under the name roo_windows.

If you’re looking to create a simple and responsive interface, this might be the library for you. Of course, there are others out there too, like the Adafruit GFX library which we’ve featured before. You could even go full VGA if you wanted, and end up with something that looks straight out of Windows 3.1. Meanwhile, if you’re cooking up your own graphics code for the popular microcontroller platform, you should probably let us know on the tipsline!

Thanks to [Daniel] for the tip!

Drive 1024×600 Pixels Via I2C With An ATtiny85

January 8, 2026 by Tyler August 10 Comments

If you need to drive a big screen for a project, it’s fair to say your first thought isn’t going to be to use the ATtiny85. With just 512 bytes of RAM and 8 kilobytes of flash memory, the 8-bit micro seems a little cramped to drive, say, a 10″ screen. Yet that’s exactly what [ToSStudio] is doing with TinyTFT_LT7683: 1024 x 600 pixels of TFT goodness, over I2C no less.

With the right TFT controller, this little micro-controller can do magic.

The name kind of gives away the secret: it won’t work on just any TFT display. It’s using properties of the LT7683 display driver, though if you don’t have one of those, the RA8875 is also compatible. Those drivers can take more than just a pixel stream– a good thing, since you’d be hard pressed to get that many pixels streaming from an ATtiny. These are character/graphic display drivers, which means you can get them to draw both characters and graphics on the screen if you speak the lingo.

It’s still not blazing fast; the documentation suggests “static or moderately dynamic UIs” as the suggested use case, and a clock is of the pre-programmed examples. From that, we can surmise that you can get 1 FPS or better with this code. You’re limited both by the simple micro-controller and the bandwidth of the I2C bus, but within those limits this seems like a very powerful technique.

This isn’t the first ATtiny graphics library to blow our minds, but if you really want an impressive graphics demo from the little micro that could, you really need to race the beam.

Thanks to [Thomas Scherer] for the tip!

The clock and the rebuilt calculator from which its VFD was donated.

An RPN Calculator And A Bonus VFD Clock From Casio Revival

January 5, 2026 by Tyler August 15 Comments

Have you heard the saying “the problem is the solution”? It seems to originate in the permaculture movement, but it can apply equally well to electronics. Take the problem [shiura] had: a Casio Mini CM-602 that had let out the magic smoke. The solution was a twofer: rebuild the Casio into a modern number cruncher with Reverse Polish Notation (RPN), and save the Vacuum Fluorescent Display (VFD) for a gorgeous WiFi clock.

[shiura]’s write-up includes a helpful guide for reverse engineering the pins on this sort of VFD, if you don’t happen to have the same model calculator (or VFD tube) they’re working with. If you’ve done this sort of thing, you know what to expect: power it up and kill power to the pins, one by one, to map out which segments or characters go out, thereby identifying the anodes and grid electrodes. The cathodes had already been ID’d from looking at the PCB. After that it’s just a matter of wiring the VFD to an ESP32 via a transistor array to get the voltages right, and voila! Clock. The code and case design files for this clock — including an editable .blend — are available via GitHub.

The calculator half of the project is an incredibly elegant hack that relies on the fact that the Casio’s CPU has the same pin pitch as modern micros: 2.54 mm, or 0.1″, so an RP2040 zero can sit in the footprint of the original CPU, scanning the keypads with its GPIO. Then an I2C display is separately wired up to replace the clockified VFD. Perhaps some driver circuitry for the VFD died, or [shiura] salvaged the display before deciding to save the calculator, because otherwise we see no reason why this brain transplant couldn’t be done while keeping the original display. Admittedly having two lines on the display instead of one make the “new” calculator a tad more usable. The code for that is also available on GitHub, and while the readme is in Japanese, machine translations have gotten pretty good and the code is quite readable on its own.

Longtime readers will likely be familiar with [shiura]’s work, with a number of finely crafted clocks having been featured from the Japanese maker, along with vintage pocket computer repairs. Bringing both together makes this twin hack particularly on-brand.

Continue reading “An RPN Calculator And A Bonus VFD Clock From Casio Revival” →

Interconnected circuits for controlling the clock

Tick, Tock, Train Station Clock

December 31, 2025 by John Elliot V 9 Comments

We’ve seen a few H-bridge circuits around these parts before, and here’s another application. This time we have an Old Train Station Clock which has been refurbished after being picked up for cheap at the flea market. These are big analog clocks which used to be common at railway stations around the world.

This build uses an ESP32 C3-mini microcontroller (PDF) in combination with an A4988 Microstepping Motor Driver (PDF). The logic is handled with MicroPython code. The A4988 provides two H-bridge circuits, one for each of two stepper motors, only one of which is used in this build.

The controller for this clock needs to send an alternating positive then negative DC pulse every minute to register that a minute has passed so the clock can update its hour hand and minute hand as appropriate. The ESP32 and the A4988 H-bridge cooperate to make that happen. The wifi on the ESP32 C3-mini is put to good use by facilitating the fetching of the current time from the internet. On an hourly basis the clock gets the current time with a HTTP call to a time server API, for whatever is suitable for your time zone.

Thanks to [PiotrTopa] for writing in to let us know about his project. If you’re interested in learning more about H-bridge applications be sure to check out Introduction To The H-bridge Motor Controller and A H-Bridge Motor Controller Tutorial Makes It Simple To Understand.

TULIP: The Ultimate Intelligent Peripheral For The HP-41 Handheld Calculator

December 30, 2025 by John Elliot V 8 Comments

[Andrew Menadue] wrote in to let us know about the TULIP-DevBoard and TULIP-Module being developed on GitHub.

TULIP is short for “The Ultimate Intelligent Peripheral” and it’s an everything expansion board for the HP-41 line of handheld calculators sold by HP from 1979 to 1990. These particular calculators support Reverse Polish notation which seems to be one of those things, like the Dvorak keyboard, where once you get used to it you can never go back.

Continue reading “TULIP: The Ultimate Intelligent Peripheral For The HP-41 Handheld Calculator” →

Xcc700: Self-Hosted C Compiler For The ESP32/Xtensa

December 30, 2025 by Maya Posch 21 Comments

With two cores at 240 MHz and about 8.5 MB of non-banked RAM if you’re using the right ESP32-S3 version, this MCU seems at least in terms of specifications to be quite the mini PC. Obviously this means that it should be capable of self-hosting its compiler, which is exactly what [Valentyn Danylchuk] did with the xcc700 C compiler project.

Targeting the Xtensa Lx7 ISA of the ESP32-S3, this is a minimal C compiler that outputs relocatable ELF binaries. These binaries can subsequently be run with for example the ESP-IDF-based elf_loader component. Obviously, this is best done on an ESP32 platform that has PSRAM, unless your binary fits within the few hundred kB that’s left after all the housekeeping and communication stacks are loaded.

The xcc700 compiler is currently very minimalistic, omitting more complex loop types as well as long and floating point types, for starters. There’s no optimization of the final code either, but considering that it’s 700 lines of code just for a PoC, there seems to be still plenty of room for improvement.