"Good" sets suck!

[JCKnife]

For the love of God, will someone please invent a "Great Tools" naming scenario that only includes perfect, original roms? I am sick to death of (PD), Hack, b1, b2...it's senseless! Who wants these things?!?

[jcrouse]

Amen! Tell it brother.

Whats really needed is a better naming convention AND a utility, using some sort of DAT files, that integrates with FE's to allow easy sorting and creating of game lists.

John

[Acids]

For the love of God, will someone please invent a "Great Tools" naming scenario that only includes perfect, original roms? I am sick to death of (PD), Hack, b1, b2...it's senseless! Who wants these things?!?

I always thought the " ! " were the complete unmodified original roms. maybe im wrong?

[!] Verified Good Dump   yup i was right.

[APFelon]

It's more of a documentation process than anything else... It uses the TOSEC naming conventions, I believe... and TOSEC is designed to document all of the versions of games floating around the Internet.

(Totally made up) example:

Okay, let's say Fairlight released a version of Super Mario Uberl33t Brothers for the SNES in 1994. It gets downloaded, played, etc.

Crystal also has a Super Mario Uberl33t release. They both release the game with a cracktro (those lil demos in front of the game that advertises the cracking group)

Years go by, and user X sees that a SNES emulator is out, and people are hungry for games for it. He thinks, "Hey, I have the Fairlight release of Super Mario Uberl33t that I'd bet people want!" and uploads it to the newsgroups. In turn, it is downloaded and put up on HTTP sites and FTP sites.

User Y does the same thing, and again, it is distributed throughout the Internet. This time with the Crystal release.

User Z hates cracktros, so he redumps the ROM and sends it out.

User A sector edits the game so it says "Super Jimmy Uberl33t Brohams" and uploads it. Unfortunately, he corrupts the ROM in the process and it only works up to level 3.

Not to mention Schmentendo releases Japanese, Spanish, German, French, Portuguese, and Itallian language versions of the game. They all eventually find their way to the Intarweb.

Whammo. Ten different releases, each with different checksums, (one of which doesn't work), all floating around the 'net. Along comes TOSEC, grabs the checksum of each, and makes verification files.

(Un)fortunately, there are folks out there who like to distribute whole sets from every corner of Cyberspace. This means you get three good ROMs, one from Jimmy and a ton of foreign language dumps that, if you are solely an English speaker, are next to worthless.

However, if you snag a file called "SMUL", run it though a TOSEC compatible tool or Good Tools, it'll tell you what you have.

All Good Tools does is document what is out there. I have seen "pure" floods on Usenet on occasion.

Good luck!

APf

[Brad]

Whilst I agree that the "crap" versions should be left out, you can still sort the rubbish from the gold using the good tools set and GoodGUI. I extracted a goodset of all the emulator sets I have, sorted them intro (U) only with GoodGUI and then only moved the good ones to the rom folders. I then deleted all the rubbish. I think I reduced for example the SNES set like this:

GoodMerge SNES = 4.4gig DVD roughly.

Arcade Cab set = 773meg (950 games)

I applied this principle to something like 38 consoles LOL! I then archived the complete set including matching snaps to DVD for easy cab setup =)

Brad

[jcrouse]

That's very similar to what I do Brad. The problem is then grabbing a torrent (mamezipped) when a new set becomes available. Someday everything will be much easier.

John

[JB]

Aside from not all good dumps have [!] tags, there's naming problems, particularly with japanese games. I've seen one series carry 3 diffrent name formats within a single system database.

GoodNES also doesn't support header checking/fixing, last I checked. And unlike most systems, good headers are pretty much required for proper NES behavior.

[paigeoliver]

You know if SOMEONE came up with GOOD console emulators that worked like Mame and EXPECTED certain rom versions then all those crap versions would go away.

[jcrouse]

This seems like a real stretch. It would require that the rom anme be in the code. The problem is that when a new game arose the code would need updated. It would just require to much maintenance of the emu code. We can't get some of these people to update their emus twice a year let alone everytime a game name changes or a new game is found.

Just my 2 cents,
John

[Brad]

Not only that but consoles are generally static in design. Once it's emulated thats it and the rom only needs to have a valid structure for the machine type. Mame is entirely different in that it's emulating many, many hardware types instead of one, hence the recognising rom thing...well apart from NeoGeo and some others. but the structure is still the same.

To simplify, SNES = 2 or 3 processors??? Not sure
Mame = Hundreds and many using multiple processors. You then need a driver for each game or group along with separate emulation for each video and sound CPU.

Interestingly the latest incarnation of Bliss (Intellivision emulator) has an internal dbase and will not recognice and load a rom it deems is not valid. Not sure but I think UberNes is similiar?

Brad

[JCKnife]

Project 64 has an internal d-base too, and it's handy, but it will still load unrecognized roms (and the main point is, I still need to "clean" them out of my set!)

[JB]

You know if SOMEONE came up with GOOD console emulators that worked like Mame and EXPECTED certain rom versions then all those crap versions would go away.

If my console emulators told me what I could and couldn't play, or complained because I was using a translation patch, I'd be annoyed.

[JB]

To simplify, SNES = 2 or 3 processors??? Not sure

2.
65816(CPU) and SPC700(sound processor).

[Lilwolf]

I do.

I hate when I play a 'perfect' version when my local arcade had an older version where the snow bees don't warp and cheat. 

Whats perfect for one isn't always perfect for someone else.  'perfect' to me is what version I used to play.

[ericball]

There are, of course, the completist collectors who (for some reason) want one of everything, no matter how similar / non-working / incorrect it is.  I had a guy email me looking for an in-progress version of my 7800 homebrew which had gotten added to one of the lists.

Headers provide hints to the emulators about stuff which isn't code/data.  For example, the Atari 2600 has an 8K address space (4K reserved for cartridge ROM).  However, there are many cartridges which are more the 4K using various kinds of bankswitching (similar to NES mappers).  This is extra control logic inside the mask ROM (or via external logic) which reacts to certain address bus values.

Unfortunately, there are multiple bankswitching methods.  So if you have an 8K ROM, how does the emulator know which method to use?  Some emulators have an internal or external database based on either the filename or a hash value.  But then, what happens when someone discovers a new game or dump (or writes one)?  Then you have to update that database.  The alternative is to include a header.  The header can also include whether the games is NTSC or PAL, what kind of controllers it needs, and other kinds of meta-data.

[JB]

Headers provide hints to the emulators about stuff which isn't code/data.  For example, the Atari 2600 has an 8K address space (4K reserved for cartridge ROM).  However, there are many cartridges which are more the 4K using various kinds of bankswitching (similar to NES mappers).  This is extra control logic inside the mask ROM (or via external logic) which reacts to certain address bus values.

Unfortunately, there are multiple bankswitching methods.  So if you have an 8K ROM, how does the emulator know which method to use?  Some emulators have an internal or external database based on either the filename or a hash value.  But then, what happens when someone discovers a new game or dump (or writes one)?  Then you have to update that database.  The alternative is to include a header.  The header can also include whether the games is NTSC or PAL, what kind of controllers it needs, and other kinds of meta-data.

But how important the header is depends greatly on the specific system.

SNES emulators, for example, rely on analyzing the ROM image to figure out how it's set up, because the SNES header format is pretty much useless. It has no coprocessor information, and is limited to just 2 of the many possible ROM mappings. It also tends to just be wrong.

Most NES emulators rely on what the header says, because it's a comprehensive format that has a lot of important stuff in it.
Unfortunately, the most common images of some games have bad headers, and are perpetuated because the ROM image is the same.