I just uploaded a short demo which replaces the 6502 emulation of the MCL65+ with the ability to run compiled C code. I adapted a printf, scanf, and a few functions to allow access to the video memory and the keyboard which makes it easy to run regular C code on a vintage computer via the 6502's bus interface.

https://microcorelabs.wordpress.com/2021/09/29/ultimate-apple-ii-accelerator-the-mcl65-fast/

-Ted

Very interesting idea! (I think there's a missing link to the github repo?)

Would there be a way to emulate some kind of peripheral to the 6502 view of the machine, so the 6502 can load ARM code into ARM memory and then cause it to run? (That might start to look a little like the Native ARM flavour of the PiTubeDirect's range of second processors for Acorn machines.)

Not to take anything away from what you've done, and have plans to do, but here is another idea: create, in ARM code, a smart peripheral for the 6502. Most obvious example is an FPU of some sort, where the 6502 needs to write and read a register file, and write to an operation register. Probably no need for a status register, as the 6502 only executes again when the FPU has done its thing.

Another kind of smart peripheral would be a (graphical) VDU accelerator: the 6502 writes to a control port and the ARM side renders into the Apple screen memory.

Yes, specialized instructions or even emulated hardware can easily be added to the MCL65+ 6502 emulation. The ARM processor on the Teensy supports 64 bit floating point math, so using a few unused 6502 opcodes for this would be easy!

The sky is the limit on VDU options as well. The MCL65-Fast implements printf as character writes to the bottom of the screen and scrolls everything upwards like a serial terminal, but something more graphical could also be developed.

But on a less whimsical note: It could also be used to test every 6502 accessible component on a motherboard. The Teensy has a meg of memory, a JTAG UART access, and can be coded in C, so tests can easily be written and results displayed to the user. The code could try to test each component and report success or failure, and could then send a fixed pattern onto the 6502 bus for the user to probe, maybe with a simple voltmeter, to see if the signal is the expected high or low. It could even sense and report if the CLK is toggling! Most or all other diagnostic tests out there depend on the CPU and/or video being functional to report results. This tester would not need anything other than power to report some results.

These vintage 6502 machines are just getting older... Might be useful if there was something that could be plugged into the 6502 socket which could diagnose and isolate broken ICs.

That's another interesting possibility! In the land of Acorn, we do have one or two test ROMs which try to exercise the machine (without relying on potentially defective RAM) but putting all of the test machinery into the CPU socket would allow for a much less constrained and more functional test.

Yes, you could drop in an MCL65+ into your Atom and experiment with using on-board RAM and ROMs as well as various levels of acceleration.

https://github.com/MicroCoreLabs/Projects/tree/master/MCL65%2B

Here is a link to the PCB files to build the board. It cost me $25 USD for ten boards including shipping from PCBWay. All of the parts are inexpensive and through-hole.

Here is an example of such a tester that uses the MCL64 hardware to replace the 6510 and run simple C code to test the components on a Commodore 64 motherboard. The MCL65+ (6502 version of the board) is basically the same hardware just with a slightly different pinout and could implement similar tests.

https://microcorelabs.wordpress.com/2021/11/22/commodore-64-tester-using-mcl64/

Very nice! Thanks for the transcript

Nice idea! You are using the USB CDC serial port, right? So no extra hardware is needed, neat.

In response to the recent wave of writeups on the 65F02, I have received a couple of questions whether the board could also be used as an in-circuit tester. Your Teensy platform seems much better suited than the 65F02: It has a USB port on board, and a microcontroller should lend itself better to programming test case suites than an FPGA. (Which would require plenty of awkward state machines.)

The typical use case for such a tester would be to test a variety of host systems, e.g. old arcade games and pinball machines, with different peripherals mapped to various memory locations. So one would need a more modular/flexible software.

You could think about a longer list of routines to test all kinds of peripherals (and RAM+ROM areas), which then gets configured by a host-specific text file loaded from the SD card. That file would define which units are actually installed in the machine, and where they are in memory. The SD card could also contain copies of the expected ROM images for a quick in-machine test of correct ROM content.

Just a thought, if you need a project for those long winter nights...

There are a few options for your 65F02 if you wanted to make it a tester:

You could use a modified version of my MCL65 which is a microsequencer based 6502 FPGA core with the entire 6502, including the ALU and the bus interface, implemented in microcode running on a seven instruction microsequencer. It wouldn't take much effort to instead run testing code. No FPGA state machines...
https://microcorelabs.wordpress.com/2017/10/07/mcl65-running-apple-ii-programs/

An easier option could be to instantiate a MicroBlaze CPU core which runs the testing code while the bus interface is a small AXI peripheral. Then you could write the tests in C.

But I agree with you that it's hard to beat the flexibility of a microcontroller which has a built-in USB UART, loads of RAM/ROM, speed, and the Arduino IDE.