When retro computing nostalgia meets modern wireless wizardry, you get a near-magical tap-to-load experience. It’ll turn your Commodore 64 into a console-like system, complete with physical game cards. Inspired by TapTo for MiSTer, this latest hack brings NFC magic to real hardware using the TeensyROM. It’s been out there for a while, but it might not have caught your attention as of yet. Developed by [Sensorium] and showcased by YouTuber [StatMat], this project is a tactile, techie love letter to the past.

At the heart of it is the TeensyROM cartridge, which – thanks to some clever firmware modding – now supports reading NFC tags. These are writable NTag215 cards storing the path to game files on the Teensy’s SD card. Tap a tag to the NFC reader, and the TeensyROM boots your game. No need to fumble with LOAD “*”,8,1. That’s not only cool, it’s convenient – especially for retro demo setups.

What truly sets this apart is the reintroduction of physical tokens. Each game lives on its own custom-designed card, styled after PC Engine HuCards or printed with holographic vinyl. It’s a tangible, collectible gimmick that echoes the golden days of floppies and cartridges – but with 2020s tech underneath. Watch it here.

If you grew up with a beige Atari ST on your desk and a faint feeling of being left out once Doom dropped in 1993, brace yourself — the ST strikes back. Thanks to [indyjonas]’s incredible hack, the world now has a working port of DOOM for the Atari STe, and yes — it runs. It’s called STDOOM, and even though it needs a bit of acceleration or emulation to perform, it’s still an astonishing feat of retro-software necromancy.

[indyjonas] did more than just recompile and run: he stripped out chunks of PC-centric code, bent GCC to his will (cheers to Thorsten Otto’s port), and shoehorned Doom into a machine never meant to handle it. That brings us a version that runs on a stock machine with 4MB RAM, in native ST graphics modes, including a dithered 16-colour mode that looks way cooler than it should. The emotional punch? This is a love letter to the 13-year-old Jonas who watched Doom from the sidelines while his ST chugged along faithfully. A lot of us were that kid.

Sound is still missing, and original 8MHz hardware won’t give you fluid gameplay just yet — but hey, it’s a start. Want to dive in deeper? Read [indyjonas]’ thread on X.

If you’ve ever squinted at a DE10-Nano wondering where the fun part begins, you’re not alone. This review of the Mr. MultiSystem 2 by [Lee] lifts the veil on a surprisingly noob-friendly FPGA console that finally gets the MiSTer experience out of the tinker cave and into the living room. Developed by Heber, the same UK wizards behind the original MultiSystem, this follow-up console dares to blend flexibility with simplicity. No stack required.

It comes in two varieties, to be precise: with, or without analog ports. The analog edition features a 10-layer PCB with both HDMI and native RGB out, Meanwell PSU support, internal USB headers, and even space for an OLED or NFC reader. The latter can be used to “load” physical cards cartridge-style, which is just ridiculously charming. Even the 3D-printed enclosure is open-source and customisable – drill it, print it, or just colour it neon green. And for once, you don’t need to be a soldering wizard to use the thing. The FPGA is integrated in the mainboard. No RAM modules, no USB hub spaghetti. Just add some ROMs (legally, of course), and you’re off.

Despite its plug-and-play aspirations, there are some quirks – for example, the usual display inconsistencies and that eternal jungle of controller mappings. But hey, if that’s the price for versatility, it’s one you’d gladly pay. And if you ever get stuck, the MiSTer crowd will eat your question and spit out 12 solutions. It remains 100% compatible with the MiSTer software, but allows some additional future features, should developers wish to support them.

Want to learn more? This could be your entrance to the MiSTer scene without having to first earn a master’s in embedded systems. Will this become an alternative to the Taki Udon announced Playstation inspired all-in-one FPGA console? Check the video here and let us know in the comments.

The Apple Macintosh Plus was one of the most long-lived Apple computers and saw three revisions of its 128 kB-sized ROMs during its life time, at least officially. There’s a fourth ROM, sized 256 kB, that merges the Western ROMs with Japanese fonts. This would save a user of a Western MacIntosh Plus precious start-up time & RAM when starting software using these fonts. Unfortunately, this mythical ROM existed mostly as a kind of myth, until [Pierre Dandumont] uncovered one (machine-translated, French original).

Since this particular ROM was rumored to exist somewhere in the Japanese market, [Pierre] went hunting for Japanese Macintosh Plus mainboards, hoping to find a board with this ROM. After finally getting lucky, the next task was to dump the two 128 kB EPROMs. An interesting sidenote here is that the MacIntosh Plus’ two ROM sockets use the typical programming voltage pin (Vpp) as an extra address line, enabling 256 kB of capacity across the two sockets.

This detail probably is why this special ROM wasn’t verified before, as people tried to dump them without using that extra address line, i.e. as a typical 27C512 64 kB EPROM instead of this proprietary pinout, which would have resulted in the same 64 kB dump as from a standard ROM. Thanks to [Doc TB]’s help and his UCA device it was possible to dump the whole image, with the images available for download.

Using this ROM image was the next interesting part, as [Pierre] initially didn’t have a system to test it with, and emulators assume the 128 kB ROM format. Fortunately these are all problems that can be solved, allowing the ROM images to be validated on real hardware as well as a modified MAME build. We were informed by [Pierre] that MAME releases will soon be getting support for this ROM as well.

Has anybody heard of the ATW800 transputer workstation? The one that used a modified Atari ST motherboard as a glorified I/O controller for a T-series transputer?  No, we hadn’t either, but transputer superfan [Axel Muhr] has created the ATW800/2, an Atari Transputer card, the way it was meant to be.

The transputer was a neat idea when it was conceived in the 1980s. It was designed specifically for parallel and scientific computing and featured an innovative architecture and dedicated high-speed serial chip-to-chip networking. However, the development of more modern buses and general-purpose CPUs quickly made it a footnote in history. During the same period, a neat transputer-based parallel processing computer was created, which leveraged the Atari ST purely for its I/O. This was the curious ATW800 transputer workstation. That flopped as well, but [Axel] was enough of a fan to take that concept and run with it. This time, rather than using the Atari as a dumb I/O controller, the card is explicitly designed for the Mega-ST expansion bus. A second variant of the ATW800/2 is designed for the Atari VME bus used by the STe and TT models—yes, VME on an Atari—it was a thing.

The card hosts an FPGA module, specifically the Tang 20k, that handles the graphics, giving the Atari access to higher resolutions, HDMI output, and GPU-like acceleration with the right code. The FPGA also contains a ‘synthetic’ transputer core, compatible with the Inmos T425, with 6Mb of RAM to play with. Additionally, the board contains an original Inmos C011 link adapter chip and a pair of size-1 TRAM slots to install two physical transputer cards. This allows a total of two transputers, each with its dedicated RAM, to be installed and networked with the synthetic transputer and the host system. The FPGA is configured to allow the host CPU and any of the transputers direct access to the video RAM, so with proper coding, the same display can mix 68K and parallel computing applications simultaneously. The original ATW800 couldn’t do that!

In addition to the transputer support and boosted graphics, the card also provides a ROM big enough to switch between multiple Atari TOS versions, USB loop-through ports to hook up to a lightning-ST board, and a MicroSD slot for extra local storage. What a project!

If you don’t know what the transputer is (or was), read our quick guide. Of course, forty-year-old silicon is rare and expensive nowadays, so if you fancy playing with some hardware, might we suggest using a Pi Pico instead?

Thanks to [krupkaj] for the tip!

If you want read-only memory today, you might be tempted to use flash memory or, if you want old-school, maybe an EPROM. But there was a time when that wasn’t feasible. [Igor Brichkov] shows us how to make a core rope memory using a set of ferrite cores and wire. This was famously used in early UNIVAC computers and the Apollo guidance computer. You can see how it works in the video below.

While rope memory superficially resembles core memory, the principle of operation is different. In core memory, the core’s magnetization is what determines any given bit. For rope memory, the cores are more like a sensing element. A set wire tries to flip the polarity of all cores. An inhibit signal stops that from happening except on the cores you want to read. Finally, a sense wire weaves through the cores and detects a blip when a core changes polarity. The second video, below, is an old MIT video that explains how it works (about 20 minutes in).

Why not just use core memory? Density. These memories could store much more data than a core memory system in the same volume. Of course, you could write to core memory, too, but that’s not always a requirement.

We’ve seen a resurgence of core rope projects lately. Regular old core is fun, too.

We know [Happy Little Diodes] frequently works with logic analyzer projects. His recent wireless logic analyzer for the ZX Spectrum is one of the oddest ones we’ve seen in a while. The heart of the system is an RP2040, and there are two boards. One board interfaces with the computer, and another hosts the controller.

The logic analyzer core is powered by a common open-source analyzer from [Eldrgusman]. This is one of the nice things about open source tools. Most people probably don’t need a logic analyzer that plugs directly into a ZX Spectrum. But if you do, it is fairly simple to repurpose a more generic piece of code and rework the hardware, if necessary.

You used to pay top dollar to get logic analyzers that “knew” about common CPUs and could capture their bus cycles, show execution, and disassemble the running code. But using a technique like this, you could easily decode any processor, even one you’ve designed yourself. All you need to do is invest the time to build it, if no one else has done it yet.

[Happy Little Diodes] is a big fan of the [Eldrgusman] design. What we would have given for a logic analyzer like this forty years ago.

If the Otis King slide rule in [Chris Staecker’s] latest video looks a bit familiar, you might be getting up there in age, or you might remember seeing us talk about one in our collection. Actually, we have two floating around one of the Hackaday bunkers, and they are quite the conversation piece. You can watch the video below.

The device is often mistaken for a spyglass, but it is really a huge slide rule with the scale wrapped around in a rod-shaped form factor. The video says the scale is the same as a 30-inch scale, but we think it is closer to 66 inches.

Slide rules work using the idea that adding up logarithms is the same as multiplying. For example, for a base 10 logarithm, log(10)=1, log(100)=2, and log(1000)=3. So you can see that 1+2=3. If the scales are printed so that you can easily add and then look up the antilog, you can easily figure out that 10×100=1000.

The black center part acts like a cursor on a conventional slide rule. How does it work? Watch [Chris’] video and you’ll see. We know from experience that one of these in good shape isn’t cheap. Lucky that [Chris] gives us a 3D printed version so you can make your own.

Another way to reduce the scale is to go circular, and you can make one of those, too.

Remember Video Volley? No? We don’t either. It looks like it was a very early video game console that could play tennis, hockey, or handball. In this video, [James] tears one apart. If you are like us, we are guessing there will be little more than one of those General Instrument video game chips inside.

These don’t look like they were mass-produced. The case looks like something off the shelf from those days. The whole thing looks more like a nice homebrew project or a pretty good prototype. Not like something you’d buy in a store.

Even inside, the wiring looks decidedly hand-built. The cheap phenolic PCB contained a surprise. The box does have a dedicated “pong” chip. But it isn’t from General Instruments! It’s a National Semiconductor chip instead.

The controllers are little more than sliding potentiometers in a box with a switch. We wonder how many of these were made and what they sold for new. If you know anything, let us know in the comments.

We still see the occasional project around a General Instruments chip. If you really want a challenge for a homebrew pong, ditch the pong chip and all the other ICs, too. If you want to read more about the history of the pong chip, you’ll probably enjoy this blog post from [pong-story].

The Thinkpad line of laptops, originally from IBM, and then from Lenovo, have long been the choice of many in our community. They offer a level of robustness and reliability missing in many cheaper machines. You may not be surprised to find that this article is being written on one. With such a following, it’s not surprising that a significant effort has gone into upgrading older models. For example, we have [Franck Deng]’s new motherboard for the Thinkpad X200 and X201. These models from the end of the 2000s shipped as far as we can remember with Core 2 Duo processors, so we can imagine they would be starting to feel their age.

It’s fair to say the new board isn’t a cheap option, but it does come with a new Core Ultra 7 CPU, DDR5 memory, M.2 interfaces for SSDs alongside the original 2.5″ device, and USB-C with Thunderbolt support. There are a range of screen upgrade options. For an even more hefty price, you can buy a completely rebuilt laptop featuring the new board. We’re impressed with the work, but we have to wonder how it would stack up against a newer Thinkpad for the price.

If you’re curious to see more of the same, this isn’t the first such upgrade we’ve seen.

Thanks [Max] for the tip.

In the world of (expensive) lab test equipment the GPIB (general purpose interface bus) connection is hard to avoid if you want any kind of automation, but nobody likes wrangling with the bulky cables and compatibility issues when they can just use Ethernet instead. Here [Chris]’s Ethernet-GPIB adapter provides an easy solution, with both Power over Ethernet (PoE) and USB-C power options. Although commercial adapters already exist, these are rather pricey at ~$500.

Features of this adapter include a BOM total of <$50, with power provided either via PoE (802.3af) or USB-C (5V-only). The MCU is an ATmega4809 with the Ethernet side using a Wiznet W5500 SPI Ethernet controller. There is also a serial interface (provided by a CH340X USB-UART adapter), with the firmware based on the AR488 project.

The adapter supports both the VXI-11.2 and Prologix protocols, though not at the same time (due to ROM size limitations). All design documents are available via the GitHub repository, with the author also selling assembled adapters and providing support primarily via the EEVBlog forums.

Recently [Colin Leroy-Mira] found himself slipping into a bit of a rabbit hole while investigating why only under Apple II MAME emulation there was a lot of flickering when using the (emulated) Apple II MouseCard. This issue could not be reproduced on real (PAL or NTSC) hardware. The answer all comes down to how the card synchronizes with the system’s vertical blanking (VBL) while drawing to the screen.

The Apple II MouseCard is one of the many peripheral cards produced for the system, originally bundled with a version of MacPaint for the Apple II. While not a super popular card at the time, it nevertheless got used by other software despite this Apple system still being based around a command line interface.

According to the card’s documentation the interrupt call (IRQ) can be set to 50 or 60 Hz to match the local standard. Confusingly, certain knowledgeable people told him that the card could not be synced to the VBL as it had no knowledge of this. As covered in the article and associated MAME issue ticket, it turns out that the card is very much synced with the VBL exactly as described in The Friendly Manual, with the card’s firmware being run by the system’s CPU, which informs the card of synchronization events.

The 1970s saw a veritable goldrush to corner the home computer market, with Tandy’s Z80-powered TRS-80 probably one of the most (in)famous entries. Designed from the ground up to be as cheap as possible, the original (Model I) TRS-80 cut all corners management could get away with. The story of the TRS-80 Model I is the subject of a recent video by the [Little Car] YouTube channel.

Having the TRS-80 sold as an assembled computer was not a given, as kits were rather common back then, especially since Tandy’s Radio Shack stores had their roots in selling radio kits and the like, not computer systems. Ultimately the system was built around the lower-end 1.78 MHz Z80 MPU with the rudimentary Level I BASIC (later updated to Level II), though with a memory layout that made running the likes of CP/M impossible. The Model II would be sold later as a dedicated business machine, with the Model III being the actual upgrade to the Model I. You could also absolutely access online services like those of Compuserve on your TRS-80.

While it was appreciated that the TRS-80 (lovingly called the ‘Trash-80’ by some) had a real keyboard instead of a cheap membrane keyboard, the rest of the Model I hardware had plenty of issues, and new FCC regulations meant that the Model III was required as the Model I produced enough EMI to drown out nearby radios. Despite this, the Model I put Tandy on the map of home computers, opened the world of computing to many children and adults, with subsequent Tandy TRS-80 computers being released until 1991 with the Model 4.

The iMac G3 is an absolute icon of industrial design, as (or perhaps more) era-defining than the Mac Classic before it. In the modern day, if your old iMac even boots, well, you can’t do much with it. [Rick Norcross] got a hold of a dead (hopefully irreparable) specimen, and stuffed a modern PC inside of it.

From the outside, it’s suprizingly hard to tell. Of course the CRT had to go, replaced with a 15″ ELO panel that fits well after being de-bezeled. (If its resolution is only 1024 x 768, well, it’s also only 15″, and that pixel density matches the case.) An M-ATX motherboard squeezes right in, above a modular PSU. Cooling comes from a 140 mm case fan placed under the original handle. Of course you can’t have an old Mac without a startup chime, and [Rick] obliges by including an Adafruit FX board wired to the internal speakers, set to chime on power-up while the PC components are booting.

These sorts of mods have proven controversial in the past– certainly there’s good reason to want to preserve aging hardware–but perhaps with this generation of iMac it won’t raise the same ire as when someone guts a Mac Classic. We’ve seen the same treatment given to a G4 iMac, but somehow the lamp doesn’t quite have the same place in our hearts as the redoubtable jellybean.

It might seem strange to people like us, but normal people hate wires. Really hate wires. A lot. So it makes sense that with so many wireless technologies, there should be a way to do USB over wireless. There is, but it really hasn’t caught on outside of a few small pockets. [Cameron Kaiser] wants to share why he thinks the technology never went anywhere.

Wireless USB makes sense. We have high-speed wireless networking. Bluetooth doesn’t handle that kind of speed, but forms a workable wireless network. In the background, of course, would be competing standards.

Texas Instruments and Intel wanted to use multiband orthogonal frequency-division multiplexing (MB-OFDM) to carry data using a large number of subcarriers. Motorola (later Freescale), HP, and others were backing the competing direct sequence ultra-wideband or DS-UWB. Attempts to come up with a common system degenerated.

This led to two systems W-USB (later CF-USB) and CW-USB. CF-USB looked just like regular USB to the computer and software. It was essentially a hub that had wireless connections. CW-USB, on the other hand, had cool special features, but required changes at the driver and operating system level.

Check out the post to see a bewildering array of orphaned and incompatible products that just never caught on. As [Cameron] points out, WiFi and Bluetooth have improved to the point that these devices are now largely obsolete.

Of course, you can transport USB over WiFi, and maybe that’s the best answer, today. That is, if you really hate wires.

Delay line memory is a technology from yesteryear, but it’s not been entirely forgotten. [P-Lab] has developed a demo board for delay-line memory, which shows how it worked in a very obvious way with lots of visual aids.

If you’re unfamiliar with the technology, it’s a form of memory that was used in classic computers like the Univac-I and the Olivetti Programma 101. It’s a sequential-access technology, where data is stored as pulses in some kind of medium, and read out in order. Different forms of the technology exist, such as using acoustic pulses in mercury or torsional waves passing through coiled nickel wire.

In this case, [P-Lab] built a solid state delay line using TTL ICs, capable of storing a full 64 bits of information and running at speeds of up to 150 kHz. It also features a write-queuing system to ensure bits are written at the exact correct time — the sequential-access nature of the technology means random writes and reads aren’t actually possible. The really cool thing is that [P-Lab] paired the memory with lots of LEDs to show how it works. There are lights to indicate the operation of the clock, and the read and write cycles, as well as individual LEDs indicating the status of each individual bit as they roll around the delay line. Combined with the hexadecimal readouts, it makes it easy to get to grips with this old-school way of doing things.

We’ve seen previous work from[P-Lab] in this regard using old-school core rope memory, too.

[Thanks to Giuseppe for the tip!]

“If there’s one thing the Commodore 64 is missing, it’s a large language model,” is a phrase nobody has uttered on this Earth. Yet, you could run one, if you so desired, thanks to [ytm] and the Llama2.c64 project!

[ytm] did the hard work of porting the Llama 2 model to the most popular computer ever made. Of course, as you might expect, the ancient 8-bit machine doesn’t really have the stones to run an LLM on its own. You will need one rather significant upgrade, in the form of 2 MB additional RAM via a C64 REU.

Now, don’t get ahead of things—this is no wide-ranging ChatGPT clone. It’s not going to do your homework, counsel you on your failed marriage, or solve the geopolitical crisis in your local region. Instead, you’re getting the 260 K tinystories model, which is a tad more limited. In [ytm]’s words… “Imagine prompting a 3-year-old child with the beginning of a story — they will continue it to the best of their vocabulary and abilities.”

It might not be supremely capable, but there’s something fun about seeing such a model talking back on an old-school C64 display. If you’ve been hacking away at your own C64 projects, don’t hesitate to let us know. We certainly can’t get enough of them!

Thanks to [ytm] for the tip!

On a Commodore 64, the computer is normally connected to a monitor with one composite video cable and to an audio device with a second, identical (although uniquely colored) cable. The signals passed through these cables are analog, each generated by a dedicated chip on the computer. Many C64 users may have accidentally swapped these cables when first setting up their machines, but [Matthias] wondered if this could be done purposefully — generating video with the audio hardware and vice versa.

Getting an audio signal from the video hardware on the Commodore is simple enough. The chips here operate at well over the needed frequency for even the best audio equipment, so it’s a relatively straightforward matter of generating an appropriate output wave. The audio hardware, on the other hand, is much less performative by comparison. The only component here capable of generating a fast enough signal to be understood by display hardware of the time is actually the volume register, although due to a filter on the chip the output is always going to be a bit blurred. But this setup is good enough to generate large text and some other features as well.

There are a few other constraints here as well, namely that loading the demos that [Matthias] has written takes so long that the audio can’t be paused while this happens and has to be bit-banged the entire time. It’s an in-depth project that shows mastery of the retro hardware, and for some other C64 demos take a look at this one which is written in just 256 bytes.

Thanks to [Jan] for the tip!

In the early days of computing, and well into the era where home computers were common but not particularly powerful, programming these machines was a delicate balance of managing hardware with getting the most out of the software. Memory had to be monitored closely, clock cycles taken into account, and even video outputs had to be careful not to overwhelm the processor. This can seem foreign in the modern world where double-digit gigabytes of memory is not only common, it’s expected, but if you want to hone your programming skills there’s no better way to do it than with the limitations imposed by something like a retro computer or a Raspberry Pi Pico.

This project is called Kaleidoscopio, built by [Linus Åkesson] aka [lft] and goes deep into the hardware of the Pi Pico in order to squeeze as much out of the small, inexpensive platform as possible. The demo is written with 17,000 lines of assembly using the RISC-V instruction set. The microcontroller has two cores on it, with one core acting as the computer’s chipset and the other acts as the CPU, rendering the effects. The platform has no dedicated audio or video components, so everything here is done in software using this setup to act as a PC from the 80s might. In this case, [lft] is taking inspiration from the Amiga platform, his favorite of that era.

The only hardware involved in this project apart from the Pi Pico itself are a few resistors, an audio jack, and a VGA port, further demonstrating that the software is the workhorse in this build. It’s impressive not only for wringing out as much as possible from the platform but for using the arguably weaker RISC-V cores instead of the ARM cores, as the Pi Pico includes both. [lft] goes into every detail on the project’s page as well, for those who are still captivated by the era of computer programming where every bit mattered. For more computing demos like this, take a look at this one which is based on [lft]’s retrocomputer of choice, the Amiga.