How to easily remove a cartridge from my C64 Cartridge Dumper with a pencil

Easier to do than to write 🙂

C64 Cartridge Dumper: removing a cartridge with a pencil by Luigi Di Fraia
C64 Cartridge Dumper: removing a cartridge with a pencil
C64 Cartridge Dumper: removing a cartridge with a pencil by Luigi Di Fraia
C64 Cartridge Dumper: removing a cartridge with a pencil

About Luigi Di Fraia

I am a Senior DevOps Engineer so I get to work with the latest technologies and open-source software. However, in my private time I enjoy retro-computing.
This entry was posted in Retrocomputing, Technical and tagged , , , . Bookmark the permalink.

2 Responses to How to easily remove a cartridge from my C64 Cartridge Dumper with a pencil

  1. e5frog says:

    … or make a 2cm longer PCB at the connector, so you can pull it loose. Perhaps with a pair of holes to attach a wire as a handle… if you’re making more of them.

    Have you accounted for various types of bank switching? There are various ways to activate the latch and then set it with any bits on the data-bus and/or address bus. Perhaps you’ll open up and examine an unknown cart the PCB before dumping?
    Why else would you dump it, if it’s not unknown. Most of them are already available as .crt files.
    You’d basically want the data of the entire rom/eprom/flash so you need to make sure you reach everything the the game uses.

    Nice little thing though.

    • Have you accounted for various types of bank switching? There are various ways to activate the latch and then set it with any bits on the data-bus and/or address bus.

      That’s the design goal here. If you haven’t noticed, the project supports Action Replay 4.x+ and Ocean Type 1 as “exotic” formats. Although these do not provide a huge variety of formats, they are the ones I was able to acquire cartridges for on eBay… at a reasonable price.

      The idea behind this project is to make sure that bank selection logic has been documented comprehensively for as many formats as possible. There are way too many holes in the existing documentation (formerly “CRT.txt” by Peter Schepers), and too many missing schematics. Using VICE’s code as reference is not quite the same as reverse engineering the hardware itself: again there are too many grey areas within the source code and its comments. As example, comments in VICE’s “ocean.c” source file assert that “Chase H.Q. II” is type A, where, in fact, I seem to understand it is type B. The opening comment in VICE’s “expert.c” source file states: “FIXME: the following description is atleast inaccurate, if not plain wrong”.
      All documentation I came across is peppered with this sort of inaccuracies: testing titles already available in CRT format using my hardware gives us the ability to address these inaccuracies.

      That said, dumping titles already available in CRT format and matching up the checksum of their binary part is quite useful to understand whether there exist different batch runs of a title and whether there has been an error in the dumping process in the past.
      Once that’s done, this hardware becomes a framework for experimenting with unknown bank selection logic. In my opinion our work with a format finishes when we have a schematic of the bank selection logic and we match it up with what the original software is doing to select banks. As a stretch goal, if we can dump EPROMS (and EEPROMS) directly and compare with the dumps that leverage bank selection logic, matching binary results, we have really preserved everything there is to preserve for a cartridge/format.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s