A Simple Commodore 64 Cart Dumper

c64

While [Rob] was digging around in his garage one day, he ran across an old Commodore 64 cartridge. With no ROM to be found online, he started wondering what was stored in this ancient device. Taking a peek at the bits stored in this cartridge would require dumping the entire thing to a modern computer, and armed with an Arduino, he created a simple cart dumper, capable of reading standard 8k cartridges without issue.

The expansion port for the C64 has a lot of pins corresponding to the control logic inside these old computers, but the only ones [Rob] were really interested in were the eight data lines and the sixteen address lines. With a little bit of code, [Rob] got an Arduino Mega to step through all the address pins and read the corresponding data at that location in memory. This data is then sent over USB to a C app that dumps everything in HEX and text.

While the ROM for just about every C64 game can be found online, [Rob] was unlucky enough to find one that wasn’t. It doesn’t really matter, though, as we don’t know if [Rob] has the 1541 disk drive that makes this cart useful. Still, it’s a good reminder of how useful an Arduino can be when used as an electronic swiss army knife.

23 thoughts on “A Simple Commodore 64 Cart Dumper

  1. Nifty indeed – but I am so lost about the editorializing in the last paragraph.

    Wouldn’t this be a tremendously _lucky_ find? If the ROM was already online, why would one care to dump it again in the first place? He’s now contributing to the archiving of old ROMs for the C64.

    Also why would he need the disk drive to make the cart useful? If he’s dumped the ROM, can’t he now use it in any C64 emulator?

      1. So the mystery cart is the actual one in the photograph? Call me a genius, but it seems to be an Epyx Fastload cartridge. Is this the first case of ROM-reading over a website?!

        No, I looked on the label. Since the C64 famously had crappy hardware driving it’s serial port, for some reason, maybe to do with VIC-20s, or maybe something else, it’s disk games took as long to load as ZX Spectrum games did from cassette tape.

        So people would write loader routines that would bit-bang the serial disk-drive port and do it properly and quickly. Some people incorporated them into carts. Called “fast-loaders”. They were really popular. Anyone with a disk drive will have had one.

        Why would anyone need an Arduino to know that? I’d also be really surprised if such a common cart hasn’t really been dumped before.

    1. Also… the picture is with the http://en.wikipedia.org/wiki/Epyx_Fast_Load so not rare or special (a quick google suggests dumps are available). How he could wonder what was on it is a mystery. unless that is not the real cartridge – which makes me wonder; what _was_ on the real cartridge? (didnt see it mentioned in the article either)

      Or perhaps I am missing something or don’t’ “get it”.

      1. The actual cartridge is “Graphics Utility” by Cockroach Software, the Epyx Fast Load was used first to ensure it was dumping correctly (as it was easy to compare to a downloadable ROM).
        Although it turns out my cart revision is slightly different to the one previously downloaded anyway, I did also use “Visible Solar System”, and it matched 100%

  2. Cool, as someone said awhile back here when everyone was ranting about Arduino…It allows you to focus on what you want to do. So while I laugh at the Arduino jokes and cringe at something like Java, it allows you to focus on cool applications that would be very hard and long from scratch. If you think about it, some of the basic protocols and standards like i2c, RS-232, C, i386, etc; they are still here, not going anywhere anytime soon, and there isn’t *that* many options that anyone is capable of making. Many of them are really pretty similar too as you delve into them.

    Seriously considering my Arduino for reading this damn controller board on a Tenney environmental chamber. It’s so old, yet had the glorious Z80 chip lol. Ended my day w/ the blue screen of death and I don’t know why at all…All I have to say is it sucks being an engineer when modern computers take away all the serial ports I frickin’ need and get replaced by some crap emulated “solution”.

    1. I too miss real serial ports on my PC.
      I also miss the parallel printer ports..so easy to connect to
      hardware! USB is flaky and fragile..works on my PC..sorta
      and then fails on many other peoples boxes. arrrgh :-(

      1. If for whatever reasons (drivers/OS/hardware etc) you can’t use USB serial on your PC, you can’t use Arduino either as that’s what it uses.

        I specifically bought a motherboard with serial and parallel port. Made myself a few USB to serial dongles with those fake PL2303 chips I got from China and most of them work fine with latest drivers under Win7 x64. I just need to modernize my collection of FPGA JTAG cable one of these days.

        1. It might be that your outdated serial gadget can’t use a USB adaptor, but only works with an actual serial port. In that case an Arduino would still work on that machine. There’s perhaps a few subtle differences, though I can’t think what would be such a big one.

    1. There was a serial header on my new motherboard too. I still need two serial ports. and while the USB adapters work fine for my purposes, needing one less adapter was a pleasant surprise.

      1. Doesn’t seem to have been in any of the software mentioned on the web. Sure it could have been done in-cart, plenty of other 8-bit machines used paging inside and outside the computer. Atari and Nintendo were massive users of paging. In Atari’s case it was usually just a simple logic chip or 2, flip-flopped by a certain combination of address lines. I’d imagine any C64 paging scheme would be equally simple.

        Then again, even if paging is used on the cartridge, that’s just to extend the address bus. The ROM chip itself should be normal. Should work fine if you just read the ROM chip directly.

  3. Nice hack. One improvement that would help is that the reader side could calculate a checksum (eg. CRC32) so one could find if the transfer was successfull or not. At least on my experiments, the first few bytes of a serial transfer are sometimes garbage.

Leave a Reply to Chris C.Cancel 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.