Ted Fried's MicroCore Labs builds replacement CPUs for machines that stopped being made

A repository of boards, not a library

The repository is a collection of separate hardware projects rather than a single tool. The top level contains about thirty directories, each named for a board or a project, including MCL51/, MCL64/, MCL65/, MCL65+/, MCL68/, MCL6809/, MCL86/, MCL86+/, MCLZ8/, MCLR5/, XTMax/, EPROM_Emulator/, Wheelwriter/ and several more.

The description calls them FPGA CPU cores and emulators for the 8088, 8086, 8051, 6502, 68000, Z80 and RISC-V, and the README splits the contents into groups: boards, emulated processors, microsequencer-based processors, other processors and miscellaneous projects.

The primary language of the repository is listed as C++, and the C++ is in the emulation cores rather than in the board designs. The hardware projects are described as FPGA based or as running on a Teensy microcontroller board.

So the useful way to read this repository is as an index. It is one maintainer's working archive of retro computing hardware, and the README is the table of contents. There is a companion blog and a YouTube channel linked at the top of the README, both given as www.MicroCoreLabs.Wordpress.com and a channel link, and the README says the blog has some details on the projects and the channel has videos of the stuff in action. For a project set where the interesting part is what the board actually does on a real machine, that video record is arguably the more informative documentation.

The default branch is master and the last push was on 2026-08-28.

Drop-in replacements for processors that stopped being manufactured

The boards group is the part with the clearest purpose, and the descriptions are consistent about what these are.

The MCL6809 is a Motorola 6809E emulator which runs on a Teensy 4.1 and can be used as a drop-in replacement. The MCLZ8 is a Zilog Z80 emulator with the same shape, a Teensy 4.1 running as a drop-in replacement. The MCL86+ is an Intel 8088 emulator, again on a Teensy 4.1, drop-in.

The 6502 side has two entries with slightly different targets. The MCL65+ is a MOS 6502 emulator which runs on a Teensy 4.1 and can be used as a 6502 drop-in replacement. The MCL64 is a MOS 6510 emulator, also on a Teensy 4.1, described as a drop-in replacement in the Commodore 64.

The distinction between the 6502 and the 6510 is the point. The 6510 is the variant with the I/O port built in, which is what the Commodore 64 uses for the keyboard, the joystick ports and the VIC-II register access. A drop-in replacement for the 64 therefore has to be a 6510, not a 6502, and the repository keeps them as separate boards.

The MCL68+ is a Motorola 68000 emulator on a Teensy 4.1 as a drop-in replacement, and the MCLV20_Max is a NEC V20 drop-in replacement CPU which uses the MCL86+ board. The second one is a neat piece of reuse: the 8086 board carries a V20, which is an 8086 variant with 186 instructions, in a machine that expects something in that slot.

The MCL8080+ is the odd one out. It is an Intel 8080 emulator which runs on an ATtiny85 and has an SPI interface as the local bus, which is a very different physical approach to the same idea.

And there is one board that is not a processor at all. The MCL86jr is an IBM PCjr accelerator which boosts performance to IBM PC/AT speed.

Microsequencer cores and the older emulator code

Under emulated processors, the README lists three projects that are software rather than boards.

The MCL68 is a Motorola 68000 Emulator written in C. The RISCV is a Simple and compact RISC-V RS32I implementation written in C. The MCL65 is a MOS 6502 written in C.

These sit under a different heading from the boards for a reason. A board emulates a processor in an FPGA or on a microcontroller, and the emulation logic is part of the hardware design. These three are implementations you can compile and study, and the RISC-V one is explicitly described as simple and compact, which is the right adjective for an implementation that has to fit in a small footprint.

The microsequencer-based processors group is a distinct architecture. The MCL65 is a MOS 6502, the MCL51 is an Intel 8051, and the MCL86 is an Intel 8086/8088. A microsequencer design breaks a processor into a control unit that emits micro-operations and a datapath that executes them, which is how you fit a processor into an FPGA that has far less gate count than a general purpose CPU would use.

This is the architecture behind the newer boards, and it is why the three microsequencer designs line up with three of the drop-in boards: the 6502, the 8051 and the 8086 are the ones where a microcontroller or FPGA replacement makes sense for a surviving machine.

Under other processors there are two more. The MCLR5 is a Quad-Issue Superscalar RISCV, and a Lockstep Quad Modular Redundant System. The second is the interesting one for an aerospace or safety reader: lockstep redundancy means several identical cores execute the same instruction and compare results, so a single upset in one core is caught rather than silently propagating.

Peripherals for retro machines, which is where the variety is

The miscellaneous group is the most eclectic, and it covers the parts of a vintage computer that were not the processor.

The Wheelwriter is an FPGA based Printer Option for the IBM Wheelwriter 5, and the Wheelwriter2 is an Arduino Leonardo based Printer Option for the same machine. The IBM Wheelwriter 5 was an electric typewriter with a microprocessor and a display, and it is exactly the kind of machine where the electronics are lost but the mechanical part still works.

The Brother Typewriter project uses an Arduino Leonardo to convert Serial RX to a Brother Word Processor, which is the same class of problem: keeping a physical machine usable by replacing the electronics.

The EPROM Emulator is a small PCB which uses a Teensy 4.0 to emulate up to a 64KB 27C512 EPROM. That is a directly useful project for anyone restoring a machine whose original ROMs are unreadable or lost, because the emulator replaces the physical ROM without changing anything else.

Two of the peripheral projects are for the NABU Personal Computer. The MCL_TRS_NABU emulates a TRS-80 Model 1 using the MCLZ8 which runs inside of a NABU, and the Turbo NABU uses the MCLZ8 to run simple C code on the Teensy to control the motherboard resources of the NABU Computer.

The rest are display and adapter work. The MDA Video project uses an Arty Z7-20 SoC FPGA board to display BMP images to an MDA display. The IBMPC_68000 uses the MCL86+ board to emulate a Motorola 68000 which runs inside of an IBM PC as if they selected this processor in 1981. The MCL65_Apple1 converts an Apple II into an Apple 1 by emulating the BIOS PROMs, system memory and performing some I/O conversion. And the XTMax is an 8-bit ISA card containing a Teensy 4.1 which can emulate RAM, ROM and peripherals.

The MCL64_Tester is a different kind of project entirely: an extensive, menu-based set of tests for the Commodore 64 motherboard.

Where this collection is the wrong tool

Three cases, and they follow from what the repository actually is.

If you want to run old software faster, nothing here helps. The MCL86jr boosts a PCjr to PC/AT speed and the rest are emulations at their original behaviour, not speedups. The reason to build an FPGA 6502 is that you need a 6502 that still exists, in a machine whose original chip does not.

If you are looking for a software project, some of these are. The MCL68, the RISCV RS32I and the MCL65 are C implementations of processors and can be read, built and studied on their own. But they are not packaged, not documented as libraries, and they are written to be compact enough for hardware rather than to be pleasant to link against.

If you want a working replacement quickly, the barrier is skill and parts, not software. These are board designs: you need an FPGA toolchain for the FPGA designs and a Teensy or ATtiny toolchain for the microcontroller ones, plus the ability to bring a board up. The README is an index of what exists, not a build guide, so the per-project documentation is what you would need next, and for several of these projects that means the blog and the videos rather than text.

There is also a licensing point to settle early. The repository records no named licence, so the terms for reuse, modification and redistribution are not stated in the files you can see here, and that is worth resolving before you base a restoration on one of the designs.

One more practical caution. Several of the boards are described as drop-in replacements for a specific machine, and the emulated processor has to match what the machine's firmware expects, including the variants with different integrated peripherals. Getting the wrong variant means a board that appears to work and does not, and the README is where you check which one you need.

Maintenance, documentation and the shape of the archive

The repository is not archived and the last push was on 2026-08-28, so work is landing on it. There are no GitHub releases, which is consistent with a hardware archive: there is no single artefact to version, because each project produces a board and its own bitstream or firmware.

The top-level entries also tell you something about how the work is organised. Alongside the project directories there is a README.md, and the .gitmodules-style pattern is absent, so the projects are held directly in the repository rather than as submodules.

What documentation exists is thin by the standards of a software project, and that is a fair characterisation rather than a criticism. The README is a table of contents with one line per board or core, and the detail is in the linked blog and the video channel. For hardware that has to be built and brought up, seeing the board running in a real Commodore 64 or PCjr tells you more than a paragraph of specification would.

The contact route is also in the README, which says for questions email the author at www.MicroCoreLabs.com. For a one-maintainer hardware archive, the practical expectation is that support comes from the author directly or from the videos, and that the design files in each project directory are the authoritative version of the board.

The pattern to take away is that this repository is a catalogue of answers to a specific and unusual problem: what do you do when a machine's processor is forty years gone and the machine is otherwise fine. The answers are real boards, built for specific targets, and the value of the collection is that someone has already done the work for the 6502, the Z80, the 8088, the 6809 and the 68000.

Editorial conclusion

Adopt one of these designs if you are restoring a specific machine whose original processor is unobtainable and you have the skill to build and program the board, since each project is a self-contained hardware design rather than a shared library. Do not adopt it as a way to run old software faster, because the point is authenticity and continuity, not performance. Verify first which board fits your machine, since the README describes several as drop-in replacements for specific targets, and confirm the board-level details in the project directory before ordering parts, because the repository documentation is a single index rather than per-project manuals.

Frequently asked questions

Official sources

1. Issues
2. MicroCoreLabs/Projects on GitHub
3. README