I'm sure a database could be community made.
You said that to do these saves, you would have to send the Retrode information such as "Memory Pak, SRAM, Flash, EEPROM, and memory size". If the Retrode firmware had some way to receive this information from the PC, someone could write a program (heck, I could do it, even in an odd language like PHP) to read the ROM, look it up in such a database, and automatically send the necessary information to the Retrode. It could even run as a Service or Daemon.
Some of this information is available. This site
has a list of games with the save type, save size, and game CRC for several consoles (specifically the GB based handhelds).
For the N64, this site
has a list of N64 games and the save method and size used by each game. And the N64 is known to use the following save types: "EEPROM (512 bytes), 4X EEPROM (2Kbytes), SRAM (32Kbytes), FlashRAM (128Kbytes), and the Controller Pak (256Kbytes)".
Any games that are missed can be researched and submitted by users or volunteers.
The same tool could be used for NES cartridge. As suggested in this thread
, Retrode could read the first PRG ROM bank and list it as a file in the Retrode drive interface. The hypothetical software does a CRC check on the 16KB PRG file, looks it up in the database, and if found, sends the necessary information to the Retrode for it to read the cartridge properly. Databases containing info on NES cartridges is available here
, the time consuming part would be creating the CRC/checksum/hash list to match to each game. Users would have to be presented with a list of known games to choose from and be given the option to submit the 16KB PRG CRC, and the option to choose their own memory controller and chip size for games not on any list.
I believe the biggest technical difficulty was limited storage in the Retrode for information like this, having it done through the PC would eliminate that problem.
What I would need to create such a hypothetical program is config options for "save type" (flash, eeprom, sram, etc.) and "save size". If those are available, creating the software to do everything else is at least possible.
And for implementing NES support, you would need to expand the "forceMapper" to cover the different memory mappers used in the NES, the "forceSize" would probably need to be like the GB/GBC (pages, since all NES chips should be a multiple of 16KB), and the firmware would have to make available to the PC the 16KB PRG file (for checksum purposes). On top of programming the firmware to support the different MMC's/mappers, but there are resources online (particularly those geared towards Kazzo and USB CopyNES, and the NESDev wiki) that should help with that.
Besides all that, there would need to be some way to let the Retrode know to reload the config file after it's been updated and reprocess the cartridge. Like writing a blank file named "reload" to the Retrode drive.
If you could provide those options (and if I had a Retrode with the necessary adapters) I don't think I would have any problem creating the software necessary to automatically give Retrode the necessary information to access these cartridges and saves.
/edit Wouldn't even need a Retrode, almost all of the program I could write blind, only part a Retrode would be needed for is to verify the checksums the hypothetical program creates are the same as those from other sources, and there's at least one user
who knows PHP, has a Retrode, and has expressed interest in exactly this.