Software wanted

[Thomas Jentzsch]

Has anyone ever written a software which automatically identifies duplicate ROMs which only differ at bankswitching hotspots and RAM areas?

 

When I look at my ROM collection, there must LOTS of those duplicates.

[Omegamatrix]

This is a huge issue when you look at how many alternate roms are out there. Thomas I have been speaking to you and Eckhard about this. I think this software will be very useful, and I thank you both for your responses to my PM's. So let me see if I got this all straight:

 

- Roms over 4k in size use bankswitching. To switch to a different bank you do a read from a "bankswitching hotspot". This bankswitching hotspot is located in the bank you want to jump to. Each hotspot is two bytes in size. In a standard 8k game you would have a hotspot in each bank to jump back and forth. That means 2 hotspots or 4 bytes total.

 

- The data located in these addresses is irrelevant, but is it completely random? From a purists point of view this is the major issue.

 

- Eckhard explained to me that the first implementation of the cartridge reader simply skipped reading the hotspots, and left $00 there. The -a option however reads the rom at the slower 2600 speed, and gives more reliable results for the values at the hotspots. Using the -a option the hotspot is now read and included in the binary. Eckhard said although you can never really be sure that the hotspot addresses are read correctly, the binaries read with the -a option are closer to the actual content of the game ROM chip then not using it. He recommend using the binaries read with the -a option if you wanted to be more true, but also said both binaries are functionally identical as the data located at the hotspot address is not used by any game. I will start using the -a option with all my bankswitching binaries.

 

 

 

Case in point. Here we were talking about Sir Lancelot, because the rom that can be downloaded from AA was (and still is) bad. That rom works fine in an emulator, but not on real hardware. Armin black flagged it long ago as a bad dump.

Sir_Lancelot__bad_dump_.bin

 

So I dumped my Sir Lancelot. The -a option method was unknown to me at the time. I created a new alternate rom as the hotspots were filled with $00.

Sir_Lancelot__no_A_option_.bin0FF8 $00

0FF9 $00

1FF8 $00

1FF9 $00

 

This was the alternate rom that was already out there. After redumping my Sir Lancelot last night using the -a option I matched it 100%.

Sir_Lancelot__with_A_option_.bin0FF8 $FF

0FF9 $FF

1FF8 $FF

1FF9 $FF

 

So now we got three Sir Lancelot bins. One should obviously never be used because it is a bad dump. With the other two they are functionally the same rom, but I'm going to choose the one that was dumped with the -a option. It might not be absolutely true, but is closer then not reading the hotspot at all.

 

 

1. There are some cart readers that read the de-soldered chip. Would one of those read the hotspots truly?

2. If a game is 2k which half of the 4k rom is actually read? What is the address range of it?

3. Why does a hotspot need two bytes? I know a 4 bit hex address takes two bytes, but since the information at the location is disregarded it must be something else.

4. Commavid did some type of extra ram within a 4k chip. I think 2k rom, 2k ram. Would it be using a bankswitching hotspot to go back and forth? Is this the only example of bankswitching below 4k? If so then we only have to worry about these few Commavid roms and everything else that is greater then 4k.

 

 

Thanks,

Omega

Edited February 22, 2008 by Omegamatrix

[Eckhard Stolberg]

1. There are some cart readers that read the de-soldered chip. Would one of those read the hotspots truly?

2. If a game is 2k which half of the 4k rom is actually read? What is the address range of it?

3. Why does a hotspot need two bytes? I know a 4 bit hex address takes two bytes, but since the information at the location is disregarded it must be something else.

4. Commavid did some type of extra ram within a 4k chip. I think 2k rom, 2k ram. Would it be using a bankswitching hotspot to go back and forth? Is this the only example of bankswitching below 4k? If so then we only have to worry about these few Commavid roms and everything else that is greater then 4k.

1. That depends on the ROM type. If you have a prototype or a game from a smaller company that used EPROM chips for the game code, then the bankswitching logic is done with extra chips. Therefore unsoldering the EPROM chip will allow you to read out the ROM image entirely without having to deal with hotspots. If you have a maked ROM chip, then the bankswitchinglogic is build into the ROM chip directly, so unsoldering the chip won't help in this case.

 

2. 2K games have their data accessable at both halves of the 4K cartridge address space of the VCS. Therefore it doesn't matter which half you read out, as they are identical.

 

3. Hotspots don't need two bytes. In Atari's bankswitching (there are more complicated bankswitching formats by other companies) you need one hotspot for each bank that you want to map into the cartridge address space. But the hotspots are located in this address space too. You need to read the entire cartridge address space in order to read out a certain bank. Therefore the data for the hotspots will be missing in all banks that you read out.

 

4. CommaVid games don't use bankswitching, as there are no ROM banks to switch. The ROM fits entirely into the cartridge address space of the VCS. Therefore it doesn' t need any bankswitching hotspots. But two CommaVid games have 1K of RAM. If you read out these games as 4K images, you would also read out the RAM. Reading the RAM might get you random results, which means that you might get many different binaries that are functional identical too.

 

 

Ciao, Eckhard Stolberg

[Omegamatrix]

2. 2K games have their data accessable at both halves of the 4K cartridge address space of the VCS. Therefore it doesn't matter which half you read out, as they are identical.

If the two halves weren't identical, one bit in one halve was different, then it would probably have been a cart that suffered from bit rot and then dumped, correct? I've seen this before.

 

 

This is another rom that is troubling me. I don't know how it was dumped or by who. My guess is it's the same cartridge dumped two different ways, and then the roms were spit after. That means 1 true rom suddenly becomes 4 variations.

 

Wizard__1980___Atari__Chris_Crawford___Prototype___4K___a_.bin

Wizard__1980___Atari__Chris_Crawford___Prototype___4K_.bin

Wizard__1980___Atari__Chris_Crawford___Prototype___a_.bin

Wizard__1980___Atari__Chris_Crawford___Prototype_.bin

 

First the 4k roms:

file 1: Wizard (1980) (Atari, Chris Crawford) (Prototype) (4K) [a].bin
file 2: Wizard (1980) (Atari, Chris Crawford) (Prototype) (4K).bin
07FE	00	13
0FFE	00	13

 

And then the 2k roms:

file 1: Wizard (1980) (Atari, Chris Crawford) (Prototype) [a].bin
file 2: Wizard (1980) (Atari, Chris Crawford) (Prototype).bin
07FE	13	00

 

What's going on here? Is this a dumper putting in zeros instead of reading line 07FE and 0FFE?

[Eckhard Stolberg]

If the two halves weren't identical, one bit in one halve was different, then it would probably have been a cart that suffered from bit rot and then dumped, correct? I've seen this before.

It could be bit rot. Or it could be a problem with the cart reader. Is the bit always different, even if you read the game several times with the alternative reading method?

 

First the 4k roms:

file 1: Wizard (1980) (Atari, Chris Crawford) (Prototype) (4K) [a].bin
file 2: Wizard (1980) (Atari, Chris Crawford) (Prototype) (4K).bin
07FE	00	13
0FFE	00	13

 

And then the 2k roms:

file 1: Wizard (1980) (Atari, Chris Crawford) (Prototype) [a].bin
file 2: Wizard (1980) (Atari, Chris Crawford) (Prototype).bin
07FE	13	00

 

What's going on here? Is this a dumper putting in zeros instead of reading line 07FE and 0FFE?

The normal version of the 4K ROM is identical to the [a] version of the 2K ROM, and the [a] version of the 4K ROM is identical to the normal version of the 2K ROM. Therefore the two 4K ROMs are unnnessessary. The different byte in the two 2K ROMs is the low byte of the BRK vector. When the VCS executes a BRK instructions it reads the address where it's going to continue execution from the last two bytes in the ROM address space. So it might be possible, that these two binaries were indeed read from two different version of the prototype. Or maybe someone patched the binary to fix it.

 

 

Ciao, Eckhard Stolberg

[Thomas Jentzsch]

So it might be possible, that these two binaries were indeed read from two different version of the prototype. Or maybe someone patched the binary to fix it.

It could also be a serial number.

 

Anyway, since the break vector is unused, all four ROMs are functional 100% identical. There is no reason to keep more than one 2K ROM.

[Omegamatrix]

If the two halves weren't identical, one bit in one halve was different, then it would probably have been a cart that suffered from bit rot and then dumped, correct? I've seen this before.

It could be bit rot. Or it could be a problem with the cart reader. Is the bit always different, even if you read the game several times with the alternative reading method?

 

It wasn't anything I dumped. Rom gave me a few roms to check and that is what I noticed. They were 2k roms overdumped as 4k again. I decided to split them up into 2k roms and compare them all together. Three of the halves match, but one was different by one byte. If it was a legitimate change then it should show up in both 2k halves, but it didn't. I'll post the examples below.

 

Indy_500__overdump_.binIndy_500__overdump__a_.bin

file 1: Indy 500 (overdump).bin
file 2: Indy 500 (overdump)[a].bin
04E6	D6	56

Only the one half had $56 in it. All the other halves including the 2k Indy 500 rom out there have $D6 value at address $04E6. Since one half of that 4k overdump did have $D6 I think the difference in this half is bit rot. I have another example with slot machine, but it is basically the same deal (one byte difference in one half).

 

 

 

So it might be possible, that these two binaries were indeed read from two different version of the prototype. Or maybe someone patched the binary to fix it.

It could also be a serial number.

 

Anyway, since the break vector is unused, all four ROMs are functional 100% identical. There is no reason to keep more than one 2K ROM.

This is what I was confusing with interupt vectors, and bankswitching hotspots when I pm'd you. I was suspious of this rom when I saw difference was right at the end of it as I had read about these vectors in thread a while back. I think you are right about the serial number. A marked rom explains a great deal. What else could it be? This makes it hard to choose one when both are functionally the same. Was this a CGE release by any chance? If they did mark them all then I would just go with the $00 rom.

[Thomas Jentzsch]

Only the one half had $56 in it. All the other halves including the 2k Indy 500 rom out there have $D6 value at address $04E6. Since one half of that 4k overdump did have $D6 I think the difference in this half is bit rot. I have another example with slot machine, but it is basically the same deal (one byte difference in one half).

I think you are right. A brief look at the disassembly shows, that $D6 makes sense, $56 doesn't. And the difference between $D6 and $56 is only one single bit, so it most likely is bit rot.