Microcontrollers Now Substitute For CPUs

Microcontrollers are getting faster and faster, as is most of the rest of the computing world. Just like you can play Nintendo console games on the newest Nintendo handhelds, it seems that modern microcontrollers can replace CPUs on personal computers from the 80s. At least, that’s what [Dave] has shown with his latest project: an Atmel microcontroller that directly attaches to the CPU slot on a Commodore PET.

Essentially, the project started out as a test rig of sorts for the Commodore. [Dave] wanted to see if some of the hardware on the Commodore was still functional and behaving properly. From there, it somewhat snowballed. The address bus was easy enough to investigate, but adding only a few more pins on the microcontroller he was already using would be enough to access the databus too. A character table was soon added, a test algorithm, and more useful insights. It’s a masterful manipulation of this older hardware with modern technology and is definitely worth a look.

There’s a lot more going on in the retrocomputing world than meets the eye. One might think these old computers were all in landfills by now, but there is a devoted fanbase that does everything from building new hard drives for old computers or investigating their true audio-visual potential.

Thanks to [Mike w] for the tip!

26 thoughts on “Microcontrollers Now Substitute For CPUs

    1. It starts straight away as it is just running code from the microcontroller. It’s not a 6502 emulator, it’s a tool to test 6502 systems. I may look at adding a non real time 6502 emulation mode to it, but it’s really just to test systems that aren’t running well enough to test themselves.

      1. It loops endlessly like any Arduino does but it surely takes a brief bit to initialize. I guess since it it’s purpose is more troubleshooting, that doesn’t really matter? I imagine it does not “sync up” with the rest of the board, I guess is what I am getting at.

        1. Within a few seconds of switching on the PET, the screen is drawn and the ROM and RAM tests begin. On power up it holds reset to the PET for a second to ensure it is initialised. Then it setups up the CRTC (on newer PETs) and starts testing things. In terms of syncing up, the 6502 has clock input and clock outputs. So this board is fed by the system 1MHz clock, and it drives the 1MHz phi2 signal to the rest of the board as the ROM and RAM on earlier systems was synchronous and so I need to toggle the address, clock and r/w lines at the right time to read and write to the onboard devices. This happens slower than 1MHz, now as it takes several instruction cycles of the micro to initiate a read or write.

        1. Quite possibly, but that wasn’t my goal, see my original blog posts. Whoever posted this onto Hackaday may have misinterpreted my aims as the title seems to imply a CPU replacement 6502 emulator rather than the diagnostics tool I have created.

    1. A logic analyser would need the CPU to be running, which means it needs some RAM to work with and some code from ROM. This are often failure points, and if so, leave the CPU not doing anything useful or stuck in a look. Here the microcontroller has it’s own ROM and RAM which is working and it is running it’s my test code which tests the ROM and RAM on the host board to see what has failed. There are some examples of this in the original article, and this later one: http://blog.tynemouthsoftware.co.uk/2016/07/pet-diagnostics.html

  1. This is great stuff, with tools like this some serious diagnostics can be performed on systems that don’t rely on the system to be fully functional. Perhaps not on this system, but imagine that even if the screen or video generators don’t work diagnostics data could be outputted over the serial port of the micro-controller to a terminal, indicating what does work and what doesn’t. So it would be easier to find to real problem. Really useful stuff!

    1. Thank you. Yes, this version relies on the video generation system working, which on older PETs was pretty much a separate system anyway – hence the screen of random characters you get on those rather than blank screens. The next version does indeed have a USB port to the system can be monitored over a serial terminal.

  2. As you probably know Fluke made the 9000 series of CPU emulators for most common 8/16 bit CPUs. Unfortunately they were insanely expensive when new and even today the CPU modules cost hundreds of dollars when they appear on ebay. Not only are they popular for troubleshooting home computers but also for arcade game boards that used the 6502/Z80/6809/etc.

    If you want hundreds of people banging on your door shaking money in your face just turn your 6502 board into a script capable test system for arcade boards. IMHO it would revolutionize arcade board troubleshooting.

  3. If QEMU can emulate almost anything, and it can run on a PiZero, why couldn’t it be modified to emulate any sub set of the components on these old machines, including just the CPU?

    1. QEMU is not twiddling I/O and control pins. It must be easier to modify any of the open source 65C02 emulators than tear into QEMU. OTOH maybe an interface module to QEMU could do it, but you need precise timing for a lot of Pet and Apple II things to work, like video.

      1. Yes, you’d need to hack the QEMU code to drive the GPIO lines on the Pi correctly, for any CPU or subsystem you were emulating, so a real-time kernel in the Pi would also be desirable.

          1. True, for a general purpose “old gear” emulator you may need to put a mixed analogue/digital FPGA between the Pi and the bus or socket you were interfacing with. Then you have a beast that can do it all, but one that has headed in a very different direction to your build.

  4. Take a look to my ARM-powered C64 and Dual Core C64

    As I commented in this forum:

    I think that the future for 8bit Turbo-CPUs and REUs is based on microprocessors, being more accesible, cheaper and more practical than ASIC or FPGA based ones.
    This project was created as a proof of concept: software-based emulators can work in real-time and in-circuit. This new and unthinked use of a software emulator allows a reconfigurable system. A very easy to reconfigure system, as easy as write C code for instruction set modifications or new functiones implementations.
    Now we know that a RasPi powering our 8bit systems only requeries a bit of glue-logic and C code.

  5. Replacing the CPU with a faster one and then using an emulator to run the original code is decades old. However you would normally bridge the two buses using hardware, because doing it in software is inefficient.

    Software emulations are very restricted though, so I don’t believe they represent the future. Instead FPGA will just keep getting cheaper.

    The problem with CPU’s is they are inherently sequential while an FPGA is essentially a parallel CPU as each instruction is continuously being executed.

    For example, an FPGA hooked up to a C64 can have a turbo CPU and a display copper that can change one register per cycle. It would be very difficult to do it with a CPU and you’ll lose a lot of benefits of using a CPU.

    1. Absolutely, but that isn’t what I was trying to do with my project, it’s not attempting to run the original code but rather some diagnostics software. The title chosen by the person who linked to my blog is perhaps misleading as to the aim of the project.

    2. Hi smf
      On C64 and other old-system scenes TurboCPUs and REUS “for the masses” are highly desired. FPGA based are great, like the Turbo Chameleon 64, but normally not for everyone. And looking at what they offer you see that can be done with a decent microcontroller (obviously with less development time and user upgradeable).
      I’m interested in this topic, so please tell me about that “decades old” emulators replacing CPUs.

      1. Why are they not normally for everyone? I prefer the 1541ultimate over the chameleon, http://www.1541ultimate.net/content/index.php

        An off the shelf soft cpu core dropped into an fpga isn’t going to take much longer to hook up to a c64 than putting a micro controller in there. Obviously it requires different skills, but I’d argue that it was more user upgradable as you can make the FPGA do a lot more. Emulating a second SID chip on a CPU for example would introduce latency, so they would be out of sync.

        The phase 5 PPC boards for the Amiga was the one that came to mind. They had both a PPC and a 680×0 on them, but they couldn’t run at the same time and switching between them was expensive. So running a 68000 emulator on the PPC was more efficient. Several people were developing products that didn’t even have a 680×0, but I don’t think anything reached production.

        The advantage with the PPC boards was that the CPU sat on the address bus, so there was no software overhead with memory access. Using a Raspberry Pi with the bus hooked up via GPIO is a bit more convoluted.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.