A Moogle  🏳️‍🌈 💻 🎮 🎶 🇸🇪

Let's air the most basic flaw with this method first: You're making dumps that are ostensibly a single merged file, representing not just the contents of potentially more than one individual ROM chip, but the data post-processed by any potential on-cart memory mappers.

Fact is, not all games had the entire contents of the cartridge on one single IC. In fact, I would wager my next paycheck that a fair few do not. They're split across multiple chips.

Worse still, different cartridges had different ways of mapping the contents of these ICs onto a given console's bus. Doing a straight-up read of addresses 0 to N can't and won't give you the full contents of the cartridge in any one of numerous rare edge cases.

What this tells me, more than anything, is that you folks are only interested in backing up the more popular games, the more common games, the ones that are largely in little jeopardy of being lost to bit-rot in the first place.

It's important to keep in mind that this is one tool out of a growing toolbox. Every tool can have its use case. We're not afraid to dump ROMs. I would actually say it's the opposite: we're more worried about those in jeopardy of being lost to bit-rot, which is why we prioritize.

We've been focusing largely on our at-risk media. We embarked on a pilot project of dumping 100 floppy disks with a Kryoflux, which quickly expanded to dumping over 1700. These aren't retail floppy disks either, these are strictly from our archives.

I really hate to so consistently be That Guy (believe me, I do), but isn't the Kryoflux ostensibly a closed-source solution that relies on closed-source tools and proprietary formats, where there are equivalent tools that are far more open?

A project like this can take a few years to get off the ground. Tools available in 2015 or 2016 were different than the tools that were available when the project started in 2018. You have to weigh when to do things with the tools that are available, both hw and the manpower.