C64 cartridge emulation with ATmega

More a side-note than an answer: There is the impressive Kung Fu Flash project which is doing exactly this and much more using a STM32F4 controller running at 168 MHz. It is all open source, so it should yield all the necessary information if someone is going to try something similar using a different controller.

This is intended to supplement the other answers here; you should also read them if you've not done so already.

Address Mapping

There are basically two possible situations when it comes to address mapping and interaction with the cartridge.

If you assert G̅A̅M̅E̅ and do not assert E̅X̅R̅O̅M̅, there's only one address mapping configuration possible because bits 0-2 of the processor's PIO output ($0001) are ignored by the PLA. This gives you:

• RAM at $0000-$0FFF; this can never be disabled in any mode.
• I/O at $D000-$DFFF. The C64 internal I/O devices respond to requests in $D000-$DDFF, but $DE00-$DFFF are free for your use. The I̅O̅1 and I̅O̅2 lines will be asserted for accesses to the lower and upper half of these areas, but you don't really need these because you already know that there are no C64 devices there.
• Everything else "unmapped" as far as internal devices go. For accesses to locations $8000-$9FFF and $E000-$FFFF the R̅O̅M̅L̅ and R̅O̅M̅H̅ signals will be asserted, but in this mode you don't need them since you know that no C64 internal devices will ever be using this range anyway.

In this mode you can never get access to the C64 KERNAL, BASIC or character set ROMs. Writes will go through to C64 RAM, but you can never read from it.¹

In all other states that can be set by the cartridge (i.e., any where G̅A̅M̅E̅ is not asserted), the memory mapping is affected by the low three bits of $0001 as read by the PLA. The cartridge can't read these directly, since these are lines between the processor and PLA only, the only knowledge the cartridge hardware can have of what parts of the memory map won't be responded to by internal devices (causing great trouble if the cartrdige also tries to respond to a read) are the I̅O̅1, I̅O̅2, R̅O̅M̅L̅ and R̅O̅M̅H̅ lines. If you're using only software entirely under your control and understood by you, it can set the memory map appropriately to let the cart use other areas, but if any other software might change this map without disabling appropriate cartridge hardware, you are likely to see problems.

BA

I've checked the schematics, and from my limited knowledge it looks to me that the BA signal is an output from the VIC. But it would be good if someone with more knowledge than me would confirm this.

---

¹_{Actually, there are some special tricks that might let you get access to some of this ROM and RAM, but that's a subject for [other questions]rc 12372.}

This is basically a duplicate for NES cartridge ROM emulation with Arduino or Pi?. The fact that the C64 is a bit slower doesn't change it in any way, so you might want take a look at the answers - as well as Martin Rosenaus's fitting answer.

To pull something like this off, you need a MCU about 15-25 times faster than an ATmega (using assembly, make that 50 times for C). With some external hardware this might be lowered, but not by much.

Now, if you're serious about the idea, you should take a look at Cypress' PSoC5 family. They not only offer a rather fast ARM core, but an incredible versatile programmable I/O section with several units that can be made into status machines, handling most signaling and data transfer on their own. Not to mention that building such a parallel system is much more fun in itself :))

As a personal project I had the idea to create a custom cartridge for my Commodore 64 and use an ATmega 1284p microcontroller to emulate eproms and/or custom chips.

I doubt that this will work!

The reason is simply the time needed by the microcontroller to react on a signal change:

As far as I know, you have about 0.25µs to react on some edge on the C64 bus. (Some diagrams I found in the internet even mention much shorter times!)

Even if your microcontroller is running with 48 MHz, you can do 12 machine instructions in this time. Even if you use hand-optimized assembler code, this is not very much.

You'll have about 5 instructions to check if the C64 bus lines are in the correct state and in the case of a read from the module, you need at least 2 instructions to drive the data bus.

About 5 instructions are remaining for doing something. This might even not be sufficient to read a byte from the ROM!

(And if the CPU is too slow for hand-optimized assembler code, there is of course no chance to use code written in C or C++!)

Using 20 MHz clock frequency (ATmega 1284p) you would have only 5 machine instructions. Even when using hand-optimized assembler code, this is not even sufficient to check which address is accessed by the C64!

Initial assumption you are making about the signals /GAME, /EXROM, R/W, and the clock are reasonable. There are some nuances with the other signals that you might need to consider.

The C64 has the ability to map the 4K of addess space at D000-DFFF as either system RAM or I/O. The only way your cartridge can know which one is mapped is using the /IO1 and /IO2 lines. If those lines are inactive, then its system RAM being accessed.

/ROML and /ROMH are, in fact, necessary to simplify cartridge design. A legacy cartridge could be just ROM chip(s) with no address decoding logic. So, it would rely on these signals to let the C64 do the decoding needed for Chip Select (CS). Of course, your cartridge controlling /GAME and /EXROM outputs causes changes in how these two inputs appear. It may be a simpler and more reliable approach to use these signals as they were intended.

/DMA and BA need to be used in tandem, but only if you intend to actually implement a DMA capability. This is true DMA, whereby your cartridge can be the bus master and can modify the C64's system RAM directly, bypassing the 6510 CPU. This could allow very capable, fast I/O, but seems out-of-scope for what you are trying to accomplish.