I know this question comes up a lot, but rather than talk about how awesome it would be to have a plugin for this (though I won't lie - it would be quite awesome), I'd like to have a discussion about why it's so difficult to create one. Specifically: what are the challenges involved in dumping NES carts, and are there any practical solutions for overcoming or working around them?
As I understand it, based on rather limited research, here are the fundamental challenges of dumping NES carts:
- Each cart has (at least?) two types of ROM chips: PRG+CHR
- Each cart may use one of many different, incompatible types of memory mappers
- There is no programmatic way from the ROM(s) themselves to determine which memory mappers, etc. are included or should be used (ie., no built-in header)
Is that at least somewhat accurate? I'm sure I'm missing and/or oversimplifying some details, so please correct me where appropriate.
As for possible solutions... I know that there are a lot of people working on documenting NES ROMs. One of the most thorough and complete databases that I've found is the quite aptly named NES Cart Database
. The even publish an XML document
to make the data available for programmatic use (this will be referred to as 'database' below).
So, is there any reason Retrode, or an appropriate NES Retrode plugin, couldn't leverage this data to workaround the limitations of the NES carts themselves? For example, I'm thinking of something like this:
- A copy of the database is either baked into the firmware or exposed separately on the device (similar to RETRODE.CFG) for easier updates
- When reading a NES cart, a checksum is performed of the PRG and CHR ROMs
- The checksums are compared against the database to determine which game is being read
- Using the information obtained from the database, the ROM can be dumped in one of two different ways:
- Separate ROMs for the PRG and CHR, plus an extra XML file (or whatever) to define the data
- A combined data file w/ an appropriate header to define the data (such as iNES or UNIF format)
I think 4a would be better/cleaner, but 4b would be acceptable as well. In either case, the result would be a successful dump of the NES cart through a Retrode, as joy and happiness abound.
Again, I'm sure I'm missing some details or (grossly) oversimplifying the technical challenges, but conceptually, is something like this feasible? If not, why not, and are there any other feasible (if not easy) solutions available? I'd like to better understand the problems/challenges involved.