I had been pondering about doing more or less the same thing for 6502 (6510).
It was always the dilemma of whether to pull the CPU out of a C64 and replace it like this, do it as a bus mastering cartridge, or replace the RAM.
I have been leaning towards the cartridge plan to avoid the requirement of doing machine surgery. If you get the RP2350 to pretend to be the RAM then the video hardware could read directly out of it which makes all sorts of shenanigans possible (every line a BADLINE).
At some point it would look like just plugging A VIC-II and a SID into a board with the RP2350 though, The cartridge approach means you have to do transfers across into the computer's RAM, but you could also write to hardware registers every CPU cycle, which would enable some potentially new modes that would not be entirely dissimilar to every line a BADLINE.
Right now I'm mucking around with getting the RP2350 to output video constructed a scanline at a time, using as little CPU as possible. I got three layers of tiles and two layers of sprites each with different pixel formats working yesterday. Quite pleased with that. The CPU calculates a handful of values per scanline, but fetching tilemap data, then tile data, then conversion to pixel values, transparency and palette lookup are all DMA and PIO. Does 1,2,4, and 8 bits per pixel, each tile/sprite/imagebuffer layer with independent 24 bit palettes.
I think, for my use, just having the ability to write to DMA registers would have been a big advantage. It feels wasteful to have A DMA waiting on a FIFO just to write what it gets to DMA registers to do the transfer you actually wanted.
Looking at the Architecture diagram It seems like it could have allowed that and stayed on the same side of the AHB5 splitter.
Hot tip: Ignore the RP2350 design sheet and use a standard 1.2V LDO in to provide the internal vCore - you save having to use that weird inductor and can clock it at a 300Mhz much more reliably at 1.2V.
What was the reasoning behind that? Were there specific features of that inductor that led them to choose it, or did they choose it and then found some of their design relied on atypical generic inductor behaviour.
The problem with going off design sheet is you don't know what might change. There's usually a good chance that you are not depending on the difference, but it's the not knowing that gets to you.
They are suggesting bypassing the RP2350's internal switching regulator (which only needs an external coil and some caps) and replacing it with an external linear regulator (which is actually supported by the datasheet)
Switching regulators have much lower power draw (which is important when running off batteries) and generate less heat, which sometimes leads to a more compact footprint (though I'm not sure the RP2350's core uses enough power for that benefit to kick in)
The power/heat savings don't really matter for this usecase, and linear regulators have the advantage of producing more stable power, though you are hardwiring it to 1.2v (a small overvolt) rather than using the ability of the internal regulator to adjust its voltage on the fly (adjustable from 0.55c to 3.30v)
This is less of a “CPU replacement” and more of a bus-level participant.
Once you control the bus cycle-accurately, the CPU abstraction kind of disappears.
You’re effectively redefining the whole machine behavior from the outside.
I want to make something like this as a classic CPU ICE, with trace memory, disassembly, etc. (note that you need a crystal oscillator circuit for many CPUs- 6802, 8085, etc.)
It would be useful for debugging classic computers like Altair 8800, etc. What you do is get a boot trace (record the first 100,000 instructions) of a working machine and diff it with the one from your broken machine. This finds the problem in like 5 seconds.
I am a newbie to the 'homebrew' hw, have many years in plc systems in various environments with different requirements.
I love for reasons maybe unexplainable my Teensy2.. I want this one too. I feel this hobby is going to become very expensive. I have an old family Tandon and I'm getting ideas.
Oh wow. Enhancements for the Sharp MZ line! Wonderful. I spent a lot of time with those machines in the 1980s and own a few. Being able to emulate the Sharp MZ-80K's (https://blog.jgc.org/2009/08/in-which-i-switch-on-30-year-ol...) MZ80FD would be cool.
I used a Z80 (Zilog80) Computer Kit (Assembly Programming learning simulator) for college digital coursework. That was actually a good learning experience. Forget the name of the actual company but you could program it on the actual board, but making one mistake meant starting over, no backspace function :)
Just for hobbyists. It's very much over-engineered as a simple Z80 cpu drop-in replacement.
That's not to say I couldn't imagine that someone, somewhere, wakes up to an alert one day that some control board has failed, and it's _just_ the CPU, and the spare parts bin for out-of-production components got water in it and is ruined, and the company is losing millions per hour the system is down. I just don't think that'll be a common story. With full faith in humanity I like to imagine instead that the people responsible for such systems have planned for full control board replacements to be available for use comfortably before unavailability of the Z80 risks a significant outage due to component failure.
A LOT of them. Zilog only announced its discontinuation in 2024.
But that also means that there are A LOT of them out there, and they are cheap and generally extremely reliable parts. So if you rely on a device with a Z80 in it and you're worried about the CPU failing you can have hundreds of these things on the shelf for ~no money.
So I would say it's of limited utility for industrial applications for now simply because scarcity is not an issue for the real thing. This might change in the future so it's good that projects like this exist.
It's sad Z80 production was discontinued. There are some niche IC manufacturers that specialize in legacy parts (eg. Rochester Electronics comes to mind). It would have been nice if Zilog had passed on manufacture of the good 'ol Z80 to a manufacturer like this. Even if it's just small production batches every couple of months/years or so.
There'll be plenty of hobbyists and/or legacy industrial / niche applications for a looong time to come.
The TI-84+ graphing calculator is still popular and a current model and it is Z80 based. (Though I doubt you'll find a DIP40 socket in one for a swap.)
The TI-84+ uses a TI REF 84PLUSB (or variant) ASIC that has a Z80-compatible core in it, not a Zilog Z80, and, as you say, definitely not a DIP40 part.
Thank you! I had a job coding Z80 assembly "back in the day" and grew to love its instruction set so I'm not surprised there is legacy and value to keep stuffing wee Z80ish cores into modern devices.
The one thing that makes a modern computer faster than an 80s computer is cache. Without cache, your computer has to go to the memory bus to fetch every instruction and memory read or write, and your system will wait to get the bytes back before it takes any action. You end up at the performance level of an 80s computer.
So you replace the CPU with a faster one with built-in cache. CPU ends up with its own private copy of the RAM and ROM sitting in its cache. But that's not the end.
Computers have a memory map, memory bank switching, memory-mapped IO, and other things to consider. The CPU with its cache has to be kept in sync with the actual memory map of the system. Both the CPU and any memory mapping hardware need to be kept in sync with each other. Memory-mapped IO reads and writes need to go to the actual memory bus at native bus speed.
Then you're left with the issue of other devices that need to access the RAM. This requires cache flushing for writes, and cache invalidation for reads.
I had been pondering about doing more or less the same thing for 6502 (6510).
It was always the dilemma of whether to pull the CPU out of a C64 and replace it like this, do it as a bus mastering cartridge, or replace the RAM.
I have been leaning towards the cartridge plan to avoid the requirement of doing machine surgery. If you get the RP2350 to pretend to be the RAM then the video hardware could read directly out of it which makes all sorts of shenanigans possible (every line a BADLINE).
At some point it would look like just plugging A VIC-II and a SID into a board with the RP2350 though, The cartridge approach means you have to do transfers across into the computer's RAM, but you could also write to hardware registers every CPU cycle, which would enable some potentially new modes that would not be entirely dissimilar to every line a BADLINE.
Right now I'm mucking around with getting the RP2350 to output video constructed a scanline at a time, using as little CPU as possible. I got three layers of tiles and two layers of sprites each with different pixel formats working yesterday. Quite pleased with that. The CPU calculates a handful of values per scanline, but fetching tilemap data, then tile data, then conversion to pixel values, transparency and palette lookup are all DMA and PIO. Does 1,2,4, and 8 bits per pixel, each tile/sprite/imagebuffer layer with independent 24 bit palettes.
You have such ponderings in common with engineers@work:
https://eaw.app/pico6502/
"and palette lookup are all DMA and PIO"
PIO is a revelation.
It's great, but I think the critique from the other day was also pretty valid. and offered an alternative.
https://www.bunniestudios.com/blog/2026/bio-the-bao-i-o-copr...
I think, for my use, just having the ability to write to DMA registers would have been a big advantage. It feels wasteful to have A DMA waiting on a FIFO just to write what it gets to DMA registers to do the transfer you actually wanted.
Looking at the Architecture diagram It seems like it could have allowed that and stayed on the same side of the AHB5 splitter.
I do love the PIO. I want to show it to a computer engineer from the 80s.
Not all that different from the MCS-96 HSIO.
> I had been pondering about doing more or less the same thing for 6502 (6510).
https://microcorelabs.com/2025/12/15/worlds-fastest-commodor...
https://microcorelabs.com/2021/01/08/mcl65-worlds-fastest-ap...
Hot tip: Ignore the RP2350 design sheet and use a standard 1.2V LDO in to provide the internal vCore - you save having to use that weird inductor and can clock it at a 300Mhz much more reliably at 1.2V.
What was the reasoning behind that? Were there specific features of that inductor that led them to choose it, or did they choose it and then found some of their design relied on atypical generic inductor behaviour.
The problem with going off design sheet is you don't know what might change. There's usually a good chance that you are not depending on the difference, but it's the not knowing that gets to you.
They are suggesting bypassing the RP2350's internal switching regulator (which only needs an external coil and some caps) and replacing it with an external linear regulator (which is actually supported by the datasheet)
Switching regulators have much lower power draw (which is important when running off batteries) and generate less heat, which sometimes leads to a more compact footprint (though I'm not sure the RP2350's core uses enough power for that benefit to kick in)
The power/heat savings don't really matter for this usecase, and linear regulators have the advantage of producing more stable power, though you are hardwiring it to 1.2v (a small overvolt) rather than using the ability of the internal regulator to adjust its voltage on the fly (adjustable from 0.55c to 3.30v)
Exactly this. Also having the regulator off chip reduces the heat a teeny bit.
Sounds more like a cool tip than a hot tip to me in that case ;)
This is less of a “CPU replacement” and more of a bus-level participant.
Once you control the bus cycle-accurately, the CPU abstraction kind of disappears. You’re effectively redefining the whole machine behavior from the outside.
I want to make something like this as a classic CPU ICE, with trace memory, disassembly, etc. (note that you need a crystal oscillator circuit for many CPUs- 6802, 8085, etc.)
It would be useful for debugging classic computers like Altair 8800, etc. What you do is get a boot trace (record the first 100,000 instructions) of a working machine and diff it with the one from your broken machine. This finds the problem in like 5 seconds.
I am a newbie to the 'homebrew' hw, have many years in plc systems in various environments with different requirements.
I love for reasons maybe unexplainable my Teensy2.. I want this one too. I feel this hobby is going to become very expensive. I have an old family Tandon and I'm getting ideas.
Oh wow. Enhancements for the Sharp MZ line! Wonderful. I spent a lot of time with those machines in the 1980s and own a few. Being able to emulate the Sharp MZ-80K's (https://blog.jgc.org/2009/08/in-which-i-switch-on-30-year-ol...) MZ80FD would be cool.
This is basically an In-Circuit-Emulator (ICE).
This reminds me of the MicroCoreLabs MCLZ8 (2022):
https://microcorelabs.com/2022/05/11/mclz8-zilog-z80-emulato...
(Also drop-in emulators for the 6502, 6809, 68000 and 8088.)
This is a cool project!
I used a Z80 (Zilog80) Computer Kit (Assembly Programming learning simulator) for college digital coursework. That was actually a good learning experience. Forget the name of the actual company but you could program it on the actual board, but making one mistake meant starting over, no backspace function :)
So is this just for hobbyists or it has any, say, industrial applications? are there any machines still running on a Z80?
Just for hobbyists. It's very much over-engineered as a simple Z80 cpu drop-in replacement.
That's not to say I couldn't imagine that someone, somewhere, wakes up to an alert one day that some control board has failed, and it's _just_ the CPU, and the spare parts bin for out-of-production components got water in it and is ruined, and the company is losing millions per hour the system is down. I just don't think that'll be a common story. With full faith in humanity I like to imagine instead that the people responsible for such systems have planned for full control board replacements to be available for use comfortably before unavailability of the Z80 risks a significant outage due to component failure.
No, that's false. There are tons of microcontroller CPUs not found on computers or hobbyist ARM boards.
Approximately every old digital technology is still in use industrially.
> are there any machines still running on a Z80?
A LOT of them. Zilog only announced its discontinuation in 2024.
But that also means that there are A LOT of them out there, and they are cheap and generally extremely reliable parts. So if you rely on a device with a Z80 in it and you're worried about the CPU failing you can have hundreds of these things on the shelf for ~no money.
So I would say it's of limited utility for industrial applications for now simply because scarcity is not an issue for the real thing. This might change in the future so it's good that projects like this exist.
It's sad Z80 production was discontinued. There are some niche IC manufacturers that specialize in legacy parts (eg. Rochester Electronics comes to mind). It would have been nice if Zilog had passed on manufacture of the good 'ol Z80 to a manufacturer like this. Even if it's just small production batches every couple of months/years or so.
There'll be plenty of hobbyists and/or legacy industrial / niche applications for a looong time to come.
The TI-84+ graphing calculator is still popular and a current model and it is Z80 based. (Though I doubt you'll find a DIP40 socket in one for a swap.)
The TI-84+ uses a TI REF 84PLUSB (or variant) ASIC that has a Z80-compatible core in it, not a Zilog Z80, and, as you say, definitely not a DIP40 part.
See the ASIC here, in what looks to me like a QFP-144 package: https://guide-images.cdn.ifixit.com/igi/e25cVO2avPxiMoXl.hug...
The CE also uses an ASIC, but with an eZ80 core instead.
Thank you! I had a job coding Z80 assembly "back in the day" and grew to love its instruction set so I'm not surprised there is legacy and value to keep stuffing wee Z80ish cores into modern devices.
I also found this gem just now: http://datamath.org/Album_Graph.htm
Ported to an actual Tandy Radio Shack Model 3 Computer (based on the Z-80)?
how is "tranZPuter" not "transputer" (https://en.wikipedia.org/wiki/Transputer)
and elsewhere on the page, ZPU (FPGA-based microprocessor) sounds a lot like "ZipCPU" FPGA-based microprocessor https://zipcpu.com/
How do the personas work? Does the board direct the Z80 to an alternate ROM stored in the flash?
Zilog?
Yes.
[dead]
The one thing that makes a modern computer faster than an 80s computer is cache. Without cache, your computer has to go to the memory bus to fetch every instruction and memory read or write, and your system will wait to get the bytes back before it takes any action. You end up at the performance level of an 80s computer.
So you replace the CPU with a faster one with built-in cache. CPU ends up with its own private copy of the RAM and ROM sitting in its cache. But that's not the end.
Computers have a memory map, memory bank switching, memory-mapped IO, and other things to consider. The CPU with its cache has to be kept in sync with the actual memory map of the system. Both the CPU and any memory mapping hardware need to be kept in sync with each other. Memory-mapped IO reads and writes need to go to the actual memory bus at native bus speed.
Then you're left with the issue of other devices that need to access the RAM. This requires cache flushing for writes, and cache invalidation for reads.