Re: [stella] ROM image classifications

Subject: Re: [stella] ROM image classifications
From: Glenn Saunders <cybpunks2@xxxxxxxxxxxxx>
Date: Mon, 16 Dec 2002 22:16:22 -0800
At 02:40 PM 12/16/2002 -0500, you wrote:
In a controlled environment, this is totally the best way to go. The Internet
isn't a controlled environment, though, and I don't think this would provide
the kind of centralized control that Glenn and co. are looking for.

If we could go back in time, yes, but the reality is that 2600 ROM images have been floating around the internet for close to a decade, and introducing a new generation of ROM images on the internet with metadata wrapped around them is not going to change that, nor is it going to help for all the people who already have a full collection of ROMs on their hard drives.

I think going by checksum is the way to go, as is the case with Good2600. You shouldn't rely on filename. The only thing that is going to remain a constant from machine to machine is the game's contents itself. An MD5 hash becomes the game's serial number.

Then you build a CENTRALIZED database for all the games.

As you distribute emulators, yes, you distribute the most recent version of the database for the client. But the client itself should be able to update itself by synching to the central database.

You make the URL configurable so that even if AtariAge goes down or changes the URL of the update page, you just update the setting in the client. It can be future-proof.

If you look at something like Mame32, its database is similar to what I think 2600 emulators should be like, or the My Kazaa tab in Kazaa. The 2600 catalog is vast enough that you should be able to generate various "views" of the game list. View by category, view by ROM size, manufacturer, whatever. You can easily group all space invaders hacks together as children of Space Invaders. A heirarchical file format like XML is IDEAL for this. XML is basically a flat-file database system.

I think the reason this hasn't happened is because emulators are by and large still developed for a command line interface so the GUI section is an afterthought, and the loaders that get developed for DOS are inherently limited in what they can do.

Archives (includes files) at
Unsub & more at

Current Thread