An interesting conundrum.

[Muzer]

Hello again!

Thanks to Matthias's genius, I now have most Atari 2600 games working flawlessly once more. However, they are a little slow now - it seems to be about one second per kilobyte (varying slightly depending on which bankswitching method is used), with most Atari games being from 2kB to 16kB. This isn't too much of an issue though, in my opinion. Basically the problem was that for some electronics reasons I don't understand, changing every bit at once on the address buses of Atari games was causing a power drain causing the processor to freeze. This affected some people's units worse than others due to natural differences in the tolerances of the components. The fix is to only write to the port bit-by-bit.

However, I've run across another interesting issue that isn't any fault of the Retrode hardware or software that is interesting.

Atari 2600 game ROMs have no headers, and there is also no header in the file. However, Atari 2600 games sometimes have RAM on the cartridge and sometimes don't.

So, emulators decide whether or not to emulate RAM based on the checksum of the game (among a few other things as far as I can tell).

However, the checksum of the game includes the RAM. RAM is not always going to be the same.

You can see where this is going.

Games dumped by the Retrode, through no fault of the Retrode or its firmware, have a different RAM each time. So, the emulators don't always detect it as having RAM and you must specify manually that it does. This only works normally because the emulators have checksums of most/all of the ROMs on the internet; even for those there doesn't seem to be a convention for what to fill the RAM with (some have it as 0s but others have again random bytes). But obviously stuff from a Retrode isn't going to be the same as stuff from the internet, so the checksums won't match.


I suppose the only real way around this would be to moan at emulator authors to not include the RAM in the checksums. However, this would still have problems for previously undumped games (which are more common than you think; most games where the PAL versions are different have no PAL dumps online).

Thoughts?

[emuDrache]

sounds like that will be a royal pain to sort out properly ....

[ríomhaire]

I don't know that much about emulations, but will telling the emulator to emulate RAM affect games that don't need any RAM or will it just waste some computer resources while doing nothing? If won't affect the game you could just recommend that the emulator makers put in an option to force RAM emulation always.

[Muzer]

It will affect the other games, because the RAM's addresses overlap where ROM would be on other games, so make those parts of ROM inaccessible.

[HowlingBlue]

So, the RAM is always mixed in as part of the ROM file, and there is no real way to tell if it is RAM or not without knowing in advance? That is annoying.

I have a couple of questions, out of curiosity.

1. How are the emulator makers getting a consistent checksum? Are they just not including or zeroing out the RAM area of the dumped ROM?

2. Is the location of the RAM area consistent among all cartridges or even certain developers?

3. Can the Retrode manipulate the cartridge RAM?
     3a. Could this damage the ROM, if the cartridge has no RAM?

* Incoming dumb theory from someone who has no concept of how the Retrode's dumping process works *

The first thought I have, although it would make the slow dumping process even slower and would need #3 to be true, is to do a two-pass dump. Get a dump, then try to manipulate possible RAM areas, then dump again. If the ROM turns out to be different, then you know you have RAM and where it is. Zero out the RAM (or whatever need be done to meet the checksum criteria) and there is the true dump.

* End dumb theory *

At worst, one could write a utility to tidy up the RAM areas of A2600 ROMs. Even if each game is different, you would just need profiles for each different game.

[Muzer]

So, the RAM is always mixed in as part of the ROM file, and there is no real way to tell if it is RAM or not without knowing in advance? That is annoying.

Yep!

I have a couple of questions, out of curiosity.

1. How are the emulator makers getting a consistent checksum? Are they just not including or zeroing out the RAM area of the dumped ROM?

There is only one ROM dump on the internet for most A2600 games, and obviously the RAM that happened to be present at the time when it was dumped will stay like that in the ROM, which is how the checksums are consistent.

2. Is the location of the RAM area consistent among all cartridges or even certain developers?

There are a relatively small number of possible configurations - if you know (or can guess/work out through trial and error) the configuration you know exactly where the RAM is.

3. Can the Retrode manipulate the cartridge RAM?
     3a. Could this damage the ROM, if the cartridge has no RAM?

Almost certainly it can, and it won't damage the ROM at all as far as I know.

* Incoming dumb theory from someone who has no concept of how the Retrode's dumping process works *

The first thought I have, although it would make the slow dumping process even slower and would need #3 to be true, is to do a two-pass dump. Get a dump, then try to manipulate possible RAM areas, then dump again. If the ROM turns out to be different, then you know you have RAM and where it is. Zero out the RAM (or whatever need be done to meet the checksum criteria) and there is the true dump.

* End dumb theory *

That's a good theory, if it weren't for #1. Most of the ROM dumps in the wild are filled with random garbage data in the RAM section that happened to be there when the ROM was dumped, and this random garbage data is included in the checksum. Of course, talking to emulator authors would be a very viable option; they could add additional checksums for games based on zeroed-out RAM, then this suggestion would work fine

At worst, one could write a utility to tidy up the RAM areas of A2600 ROMs. Even if each game is different, you would just need profiles for each different game.

This is also possible, but it does make the Retrode a bit more of a pain to use (plug in cartridge, plug in Retrode, copy rom to HDD, run through utility, run in emulator).