CloneSpy CloneSpy resurrected!

[enthusi]

Nice findings!

I agree.

Is there a (weak) Atarivox group based on your code?

[Thomas Jentzsch]

Won't work. For a 33% threshold, you would need ~1350 identical bytes in a 4K ROM, but the I2C driver is just about 100 bytes.

[enthusi]

Yeah, for such things you'd need a direct search-mask taking into account all non-adress-bytes.

So it would be possible to compile a batari-basic list easily now?

Edited September 22, 2016 by enthusi

[Thomas Jentzsch]

Quite easily, yes. Take the two groups and that's it.

[alex_79]

Actually my point was exactly that. How much are BASIC programs alike because they use the BASIC routines.

Same here. It was obvious that games written in Basic would have part of the code in common, even if the authors programmed them from scratch, but it's interesting to see to what extent.

Moreover, as Thomas pointed out, an analysis of the program's output can still provide some indicators about the amount of original work put into the game.

(including example programs from the bB tutorials in the group of roms to test would probably help in that respect).

 

[Thomas Jentzsch]

Another finding.

 

Of course Tennis and Laser Gates are not related at all. But CloneSpy groups them together. Why? Because the 2nd 2K of "Tennis (1983) (CCE) (C-858) (4K)" is filled with 2K of Laser Gates. If you split the 4K file into 2K files, you find that the first 2K file runs Tennis on its own (see attachment).

 

So this ROM is probably an overdump. Or somewhere during production Laser Gates got involved too.

Tennis (1983) (CCE) (C-858) (4K).001.bin

[Thomas Jentzsch]

A related finding.

 

Here we have two variations of Asteroid Belt and the first prototype of Cabbage Patch Kids linked together. As of now I am not sure if this is a bug of CloneSpy, especially because it triggers only for two Asteroid Belt ROMs, where all of them are almost identical.

 

But there is more.

 

CloneSpy automatically orders the different prototype versions of Cabbage Patch Kids correctly. So when you find a prototype ROM without a date, you can identify its time relation to other prototype versions.

 

In this case, the version dated 06-XX-1984 seems to be slightly newer than 06-14-1984.

Edited September 22, 2016 by Thomas Jentzsch

[enthusi]

Very interessting though by now, you need to get used to the table-interpretation

[Thomas Jentzsch]

Do you have an idea how to present this better?

[+Propane13]

I'm enjoying the current presentation thus-far.

[alex_79]

Here we have two variations of Asteroid Belt and the first prototype of Cabbage Patch Kids linked together. As of now I am not sure if this is a bug of CloneSpy, especially because it triggers only for two Asteroid Belt ROMs, where all of them are almost identical.

Almost the entire first 4k bank of the 05-24-1984 proto is filled with the byte sequence "ff ff 01 01". I guess that confuses CloneSpy.

 

This is part of the hexdump of the rom. Asterisks indicate areas where the byte sequence repeats:

 

00000000  ad f9 ff ea ea ea ea ea  ea ea 4c 3c f0 ea ea ea  |..........L<....|
00000010  ea d8 a2 00 8a 95 00 9a  e8 d0 fa a9 06 85 89 a9  |................|
00000020  00 85 d2 a9 11 85 d3 a9  31 85 0a a9 b0 8d 96 02  |........1.......|
00000030  e6 81 d0 02 e6 82 20 5e  f0 4c 00 f0 ad 84 02 30  |...... ^.L.....0|
00000040  fb 85 02 a9 02 85 02 85  01 85 02 85 02 85 02 85  |................|
00000050  00 85 02 85 02 a9 00 85  02 85 00 4c 2b f0 a2 01  |...........L+...|
00000060  b5 d0 30 22 d0 1a b4 d2  b9 a2 f0 10 06 a9 ff 95  |..0"............|
00000070  d0 30 13 95 17 a9 0c 95  d0 bd a0 f0 95 15 f6 d2  |.0..............|
00000080  d6 d0 b5 d0 95 19 ca 10  d7 a5 d0 10 12 a5 d1 10  |................|
00000090  0e a9 22 85 d2 a9 43 85  d3 a9 00 85 d0 85 d1 60  |.."...C........`|
000000a0  04 0c 1a 11 1a 11 14 11  14 11 11 13 14 17 1a 1a  |................|
000000b0  1a 1a ff 11 0d 11 0d 11  0d 11 0d 12 0f 17 17 11  |................|
000000c0  17 11 11 ff 00 1b 1b 17  11 0f 11 17 00 1b 1b 17  |................|
000000d0  11 11 11 11 00 1a 1a 14  0f 0d 0f 14 00 1a 1a 14  |................|
000000e0  0f 0f 0f 0f ff 17 0f 18  0f 1b 0f 18 0f 17 0f 18  |................|
000000f0  0f 1b 0f 1f 0f 14 0d 15  0d 17 0d 15 0d 14 0d 15  |................|
00000100  0d 17 0d 18 0d ff 01 01  ff ff 01 01 ff ff 01 01  |................|
00000110  ff ff 01 01 ff ff 01 01  ff ff 01 01 ff ff 01 01  |................|
*
00000da0  ff ff 01 01 ff ff 4c 01  ff ff 01 01 ff ff 01 01  |......L.........|
00000db0  ff ff 01 01 ff ff 01 01  ff ff 01 01 ff ff 01 01  |................|
*
00000ff0  ff ff 01 01 ff ff 01 01  ff ff 01 01 0d f0 0d f0  |................|
00001000  ea ea ea 4c 10 f0 ea ad  f8 ff 4c 00 e0 ad f8 ff  |...L......L.....|
00001010  a9 ff 85 b1 85 b3 a9 14  85 b0 a9 4a 85 b2 a9 34  |...........J...4|
00001020  85 b5 a9 03 85 b6 a9 39  85 b7 a9 fe 85 a1 a9 ff  |.......9........|
00001030  85 a3 a9 14 85 a6 a9 09  85 a7 a9 13 85 a4 85 b9  |................|
[...]

[Thomas Jentzsch]

Almost the entire first 4k bank of the 05-24-1984 proto is filled with the byte sequence "ff ff 01 01". I guess that confuses CloneSpy.

Yes, this plus a small tweak I had added to identify shifted addresses. I made a little fix now, this eliminates the problem. Unfortunately now all values will slightly differ. Especially for less related ROMs, the relations will decrease a bit.

 

Attached is how it looks now. Note that the order of the prototype versions is even better now.

clonespy v2.2.zip

[Mr SQL]

Actually my point was exactly that. How much are BASIC programs alike because they use the BASIC routines.

 

I follow you, but imo it's not a good indicator of originality to include the language RUNTIME in the analysis because the authors code could still be original; I suspect it would be possible to run this tool or a similar one against the high level source if you had the BASIC listings.

 

Same here. It was obvious that games written in Basic would have part of the code in common, even if the authors programmed them from scratch, but it's interesting to see to what extent.

Moreover, as Thomas pointed out, an analysis of the program's output can still provide some indicators about the amount of original work put into the game.

(including example programs from the bB tutorials in the group of roms to test would probably help in that respect).

 

 

 

If you analyze the 2K bB programs they will all look mostly the same because they are comprised of mostly RUNTIME code; the larger BASIC programs will start to look different only in proportion to the compiled BASIC code outweighing the RUNTIME code.

 

The same analysis on c++ programs would show they are nearly 100% identical with practically no original code.

[Thomas Jentzsch]

Nevermind, fixed

Edited September 23, 2016 by Thomas Jentzsch

[Thomas Jentzsch]

Added new, bug fixed version to the first post. The ZIP now also includes results for 505 homebrews until 2012 (a never collection is missing ) too.

 

For the original games results, I removed three multi game HES ROMs.

[Thomas Jentzsch]

I had some fun and calculated a "relation rating" (R-R) for all homebrews. High values (100 is the average) show a lower relation to other games in the same group, which might indicate a higher quality compared to lower rated games of the same group.

 

I think it works quite nicely for BB games.

clones.zip

[Thomas Jentzsch]

Update, now with more (210) BB games.

 

Top 3 with highest R-R:

1. 796 Princess Rescue
2. 644 Zippy the Porcupine
3. 641 Super Mario Bros. 2600

 

clones.zip

[Mr SQL]

Update, now with more (210) BB games.

 

Top 3 with highest R-R:

1. 796 Princess Rescue
2. 644 Zippy the Porcupine
3. 641 Super Mario Bros. 2600

 

 

Which confirms the tool is pretty much useless for analyzing BASIC games - the largest footprint games appear to be more original simply because there is more compiled BASIC code in ratio to the common RUNTIME code.

 

You have to discard the RUNTIME to perform a non-weighted analysis.

 

[+Gemintronic]

I had some fun and calculated a "relation rating" (R-R) for all homebrews. High values (100 is the average) show a lower relation to other games in the same group, which might indicate a higher quality compared to lower rated games of the same group.

 

I think it works quite nicely for BB games.

 

What does "higher quality" mean here? Is it code diversity?

[Thomas Jentzsch]

What does "higher quality" mean here?

More content means more graphics and sound, more game play, more variations etc.

 

Of course more content is just an indicator. Even games with a lot of content can suck and lower content games can be a lot of fun (I am a fan of Deimos Lander). But if you look at the list, on average games with more content seem to have a higher quality. Some ROMs with a very low rating are not even games, just some basic test code. Others have only very, very basic game play, minimal graphics and little to none sound.

[alex_79]

Do you have an updated CSV convert utility that calculates the relation-rating?

[Thomas Jentzsch]

Sure.

 

The calculation is pretty simply and naive. It just adds and subtracts the percentages for all other related games and then divides by the number of related games. Maybe someone can come up with something more sophisticated?

Clones2CSV.zip

Edited September 26, 2016 by Thomas Jentzsch

[Thomas Jentzsch]

Quick update:

 

Looks like Microsoft has disabled 8.3 file name generation by default. CloneSpy still relies on those short names, so you have to enable it.

 

In Regedit navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation. The value must be 0 (or 2 and allowed for the volume you are trying). After setting the new value, you have to reboot AND you have to copy (not move) the files into the test folder again.