A new CRC database.

[Greg Zumwalt]

Well, I have been swamped with hords of CRC data; much to my suprise

 

Over 500 new CRC's have been added!

A couple of unknown protos have been named.

 

A big thanks to A.W. for submitting several hundred himself.

 

That puts the BIN count at 2958.

 

I had someone inquire of me, how does a BIN get onto the CRC list?

 

Simple, if it is an Atari 2600 BIN, made available to the public via what ever means and made available to me' or

if the BIN exists in a private collection and someone else submits the appropriate data.

 

I was also asked, why?

Obvious reasons aside, I was often asked by others, or found myself, with a bin that had no real identfying name.

It didn't look familiar.

Often, it wouldn't work... but it was there.

These were usually protos, demos, test files, etc.

Yet, they were being gotten, and questioned.

Further, nothing came close to identifying them, including Cowerings Tools.

Thus, the list.

 

That's the short of it.

Enjoy.

 

PS I have added a tool to produce the CRC lists and compare them yourself.

 

Use :

CRC.EXE directory*.bin > crc.txt

crc.zip

crctest.zip

[Thomas Jentzsch]

I'm 100% sure there is quite are large percentage of duplicates in your collection. Often only a single totally unimportant byte (mostly at the very end of the dump) differs, just because the dumping process was slightly different.

 

You should try to eliminate those duplicates. Maybe you can even write a simple program for that to automize the process.

[Greg Zumwalt]

I'm 100% sure there is quite are large percentage of duplicates in your collection.  

 

As for duplicates... not in the strict sence.

Although to a large degree that is true.

 

However, the point of the list, from my perspective, is that know where else that I know of, keeps track of all the variations. I'm not concerned so much about someones hack that they opted to scrap and no one ever sees. I am more so interested in those files that made it to the WWW and someone did download and now wants to know what they have.

 

This could be very important to those who burn bins.

One byte more or less could be all the differance in a working cart or a door stop, and the CRC can help.

As stated in a prior post, this list is usually requested by developers, and not usually the general public.

But lately, I've been receiving more and more requests to identify a bin found in the wild, that I though I'd make the process a little easier.

 

e.g. Someone downloads a bin00xxx file off of the BigList.

No clue to the name or the game. A proto. Maybe just a test file. But how can one be certain?

Check the CRC and look at the list.

Find the name next to the CRC and go, oh, that's what it is.

 

Or, someone downloads hangman.bin ... well, thanks to the hangman editor, dozens of hangman variations were made.

By examing the CRC and comparing it to my list, one can hopefully identify the exact version, maybe who made it even.

 

And, if the CRC isn't in the list, it and relevent data can be submitted.

 

For those who simply want a cut and dry, hard to the core only sort of tool that just identifies "authentic" 2600 bin dumps, use the 2600 Good Tools... all be it dated and flawed still. Shame really

 

Of course, after enough requests, I took the time to make the crc tool I use available so that people can generate their own lists.

[Greg Zumwalt]

You should try to eliminate those duplicates. Maybe you can even write a simple program for that to automize the process.

 

Prior to the generating of the list, several tools are used to test file names, zipped files named to bins, and crc comparisons, so that all true duplicates can be removed.

 

For the purpose of testing how closely related bins may be, I highly reccomend CloneSpy.

 

HA HA HA... preaching to the choir their now, eh

[Doran]

Thomas wrote:

Maybe you can even write a simple program for that to automize the process.

 

You should know that's not as easy as it sounds.

 

Overdumps are easy to spot, but things like random data read from superchip RAM write areas are a lot more difficult. The problem is on par with autodetecting the banking scheme used in an image.

 

I'm pretty sure we've discussed this on the stella biglist before.