The old cartridges for the Commodore 64 use EEPROMs to store their data, and the newer Flash carts use either a Flash chip or an SD card to put a whole bunch of games in a small plastic brick. [Stian] and [Runar] thought that wasn’t good enough – they wanted to program cartridges in real time, the ability to reboot the C64 without ever touching it, and a device for coding and testing. What they came up with is the latest advance in Commodore cartridge technology.
The device presents 8k of memory to the C64, but it doesn’t do this with Flash or an EEPROM. Instead, [Stian] and [Runar] are using a dual-port static RAM, specifically one from the IDT7005 series. This chip has two data busses, two address busses, and /CE, /OE, and R/W lines for either side of the chip, allowing other digital circuits to be connected to one small section of the C64’s memory.
Also in the cart is an ATmega16 running V-USB to handle the PC communications. It takes about 1 to 1.5 seconds to transfer an entire 8k over to the cartridge, but this chip can read and write the RAM along with the C64 simultaneously.
If you want a box that will give you the ability to put ever game in existence on a single cartridge, this isn’t the one. However, if you want to write some C64 games and do some live debugging, this is the one for you. The Eagle files are available, and there’s a video demo below.
Very nicely done! My friends and I used to call these things “Rom-ulators” (or “Romulans”). They are excellent fast-turaround tools and yours is especially well realized. Great looking PCB. Thanks for sharing this! Coop, aa1ww
Still wondering why no one staggers certain cart contacts like with USB..
You mean having some of the PCB contacts be longer than others? The reason that’s done on USB and other things like SATA is because they’re designed for hot plugging. Those contacts are longer to make sure they contact first. Generally the longest will be ground and power, to dissipate ESD and power up the device before the data pins are connected.
These cartridges aren’t meant to be hotplugged, so there’s no need to waste time manually resizing the contacts.
Based on my experiencing a FLASH programmer with V-USB, I can tell you that there are a few things that could improve the data transfer speed.
– Ditch that HID as it is using Interrupt transfer which limits transfer rates as you are only allowed 8 bytes packet every (10ms per USB specs). I got 20kB/s transfer rate (which is the theorical limits) using Vendor Class Bulk Transfer BTW. It is worth that extra minute installing the .info driver.
– I used port D as 8-bit port (ditching Rx/Tx) which save the crazy bit shifting I/O. (similar to the USB2LPT project). Hate the half-ass way Atmel assign the ports. They should have Tx/Rx and Xtal signals in one of the incomplete 8-bit ports.
– I ran V-USB at 20MHz (overclock). I need to issue those long FLASH programming sequences which consume a lot of clock cycles.