C64 powered by ARM running 6502 emulator

A software core for the C64 it's possible. Unlike other implementations based on programmable logic (FPGA) and soft-cores, this is a 32-bit microcontroller running a 6510 emulator. So I call it software-core, no soft-core.For easy reconfigurability, a portable C programed microprocessor emulator is used resulting in a "High-Level Languaje In-Circuit Emulator".This is a spacetime emulator use, space because in-circuit, and time because real-time operation (software running synchronized to an extrernal clock).Watch the videos about a C64 with the 6510 microprocessor replaced with a 32-bit microcontroller: ARM Cortex M3 LPC1769. There are running games and IEC operation (via Uno2IEC).

As you can see, emulation it's not limited to 6510 processor only. Why not implement another CPU emulators for an heterogeneous multi-core C64. In this next post view 6510 and Z80 emulators on ARM for cartridgeless C64 CP/M: Dual Core C64

ARM:Thinking that at some point Arduino would limit performance I choose a more powerfull platform: an NXP LPC1769, ARM Cortex 3. The LPC also has 5V tolerant GPIO pins needed by MOS chips. First test was with a 32k x 8 SRAM (HM62256) and fake6502 running EhBasic.

The pins connection was direct and the emulator ran asynchronously, EhBasic code was, like on the Arduino, contained as a C constant array in the microcontroller flash program memory.

Comparing ROM Dump with ROM Read

C64:

Then I wanted to reproduce 6502 operation reading program from a ROM, that is an external stored program, external to the microcontroller. One first option was to write EhBasic to a 29FXXX DIP Flash but I prefered to use C64 ROMs, so I retired from a C64 a socketed 901225 Characters ROM chip, connected it like the SRAM to the microcontroller and readed it.

And then, one more step, what about connecting the microcontroller to the C64 replacing the original 6510 and test ROM, CIAs and SID with address decoding provided by the original PLA.

It seems trivial but presents several difficulties because in the C64 the 6510 microprocessor shares the buses with the VIC video chip, the system RAM is DRAM refreshed by the VIC chip and we need to emulate 6510’s I/O port.

6510’s I/O port is mapped at $0001 address and, in C64, bits 0,1 and 2 connected to LORAM, HIRAM and CHAREN signals. PLA use this signals for switching between ROM and RAM for $A000-$BFFF, $D000-$DFFF and $E000-$FFFF memory areas.

This operation was implemented with 3 GPIO pins and catchs at write function:

For first tests I removed the VIC chip from the board, but that left me without CPU Clock and without refresh for DRAM, so emulator must use microcontroller RAM. With catchs on memory write function I redirected RAM writes to screen area ($0400-$7fff) to microcontroller debug console and received the C64 startup message. Also pending address lines A14 and A15 were implemented with two aditional GPIOs: P4.28 and P4.29

ROM Read

Booting C64 ROM

VIC:As VIC provides CLK for CPU up to here the emulator runs asynchronously. In order to place the VIC on the board and share buses the emulator needs third state capability and synchronization to system clock.

In the C64 bus access is driven by VIC with it’s BA signal connected to 6510’s AEC pin. All microprocessor read and write operations take place when AEC=1 and must be enabled by the RDY signal too. When AEC=0 VIC uses the buses and microprocessor pins must go to third state.For more datails please see: http://www.zimmers.net/cbmpics/cbm/c64/vic-ii.txt

Interface:That operation was implemented using a custom interface adapter using discrete logic: 3 x 74HC245 Octal 3−State Noninverting Bus Transceivers for address and data bus and a 74HC00 for R/W. Two remaining 74HC00 gates were used to accommodate required delay between in and out 6510 clock signals.

Also read and write functions were rewritten in order to take into account AEC and RDY states.As 6510 only can access buses when AEC=HIGH all read and write operations are synchronized to that signal and not to Clk (Fi2).