tool to verify roms like NSRT will, but for NES/GB..

[tellyup]

I am starting to use the excellent NSRT tool which will verify a SNES ROM, even fix it. I would now like to expand into other Nintendo platforms such as GameBoy and NES but do not expect there to be a tool as developed as NSRT for them.

Can anybody confirm that there is a tool which will confirm a DMG GameBoy, CGB, GBP, GBA or NES ROM similar to what NSRT will.

Many thanks for this.

[Gil_Hamilton]

For most systems, the so-called Good tools are, sadly, the primary option.


There's also the TOSEC stuff, but I'm not sure how comprehensive that's gotten.

http://www.tosec.org/

[Clements]

No-intro dats are an option for simple verification only.

http://www.no-intro.org/

[tellyup]

I tried looking at Tosec but there doesn't seem to be anything to download, unless they're dats. I need a program. Being an OS X user I steer clear from ClrMamePro and ROMcenter as they're Win only.

However I am looking at uCON64 as a Mac option, the GUI version is not working for me (PPC) but the Terminal one is, however I find that if I compare results of a ROM read that the NSRT data is more complete than uCON64. I know NSRT is very good but uCON64 is missing simple things like Genre. Maybe I have not enabled an option?

Anyway, The data I am getting back from NES ROM's is quite limited, I expect that, here is what I have from "Gremlins 2"

393216 Bytes (3.0000 Mb)

Padded: Maybe, 8 Bytes (0.0001 Mb)
Interleaved/Swapped: No
Backup unit/emulator header: Yes, 16 Bytes
Internal size: 3.0000 Mb
Internal PRG size: 1.0000 Mb
Internal CHR size: 2.0000 Mb
Memory mapper (iNES): 4
Mirroring: Horizontal
Save RAM: No
512-byte trainer: No
VS-System: No
Checksum (CRC32): 0x2b20b022

Is that all that a NES ROM contains? How do I verify that the ROM is okay, complete, with GameBoy games it will report a bad dump but for NES the green writing does not come up.

Here's a dump from uCON64 for a SNES Game:

Super Nintendo Entertainment System/SNES/Super Famicom
TimeSlip
Vic Tokai Inc.
Europe, Oceania and Asia
1048576 Bytes (8.0000 Mb)

Padded: No
Interleaved/Swapped: No
Backup unit/emulator header: Yes, 512 Bytes
HiROM: No
Internal size: 8 Mb
ROM type: (0) ROM
ROM speed: 200 ns (SlowROM)
SRAM: No
Version: 1.0
Checksum: Ok, 0x78e3 (calculated) == 0x78e3 (internal)
Inverse checksum: Ok, 0x871c (calculated) == 0x871c (internal)
Checksum (CRC32): 0xadac8eff

I purposefully opened the same ROM with textedit and added a char randomly, scanned it again and it got flagged as a bad dump, it did not fix and so I know that works. But, if I feed it a hacked game e.g. [PD] it still shows as okay, how do I tell if the game has been tampered with?

[Deathlike2]

I moved this thread because it didn't seem ZSNES specific.

However I am looking at uCON64 as a Mac option, the GUI version is not working for me (PPC) but the Terminal one is, however I find that if I compare results of a ROM read that the NSRT data is more complete than uCON64. I know NSRT is very good but uCON64 is missing simple things like Genre. Maybe I have not enabled an option?

The Genre stuff isn't contained in the game data obviously.. it's just happens to be handy for some that want some reasonable management available. The other relevent information is worthy of being paid attention to anyways.

[grinvader]

But, if I feed it a hacked game e.g. [PD] it still shows as okay, how do I tell if the game has been tampered with?

PD games aren't 'hacked'. They're games or demos not released commercially. Coded up from scratch. It shows as ok if the coder cared to calculate the checksum and put it in the internal header.

You can use a cross check between various hashes to know if a game has been tampered with.

[tellyup]

*np moving the thread*

I didn't know that, I thought Genre was convenient! I didn't know that about the PD game, so its a hacker thats made it, in my eyes thats a fake and I wouldn't want it so how would I do a cross check please?

I use uCON64 (Terminal) and NSRT (GUI)

I have come across "padded" for the game Battle of Olympus, I tried searching but I don't know what it means?..

"Padded: Maybe, 80 Bytes (0.0006 Mb)"

This is all very valuable help for me, thanks.

[Gil_Hamilton]

... I didn't know that about the PD game, so its a hacker thats made it, in my eyes thats a fake...

It's a programmer that made it, not a hacker.
But... when you say it's a fake game, you mean it's not a commercial release?
So basically, you're in it for the hardcore piracy.


And some of the "PD" ROM images are actually dumps of official products. The test cartridge being the best-known example.
Cowering seems to have confused "public domain" with "not sold in stores"

[tellyup]

Lol. Nothing that I do not already own and have had since the time of release. What I want to do is discern from those modified officially released carts and the those of the hardcore collector.

Most people are only going to have ever been exposed to the ones in the shop,s the ones they got fro Christmas - the ones they played. I am trying to put together the knowledge to make a video to show people how to make sure that the the ROMs they have are the ones they think they do.

So PD is a nice touch, but not for the foundation of a collection. Its more of a niche.

Would you be able to tell me how to cross-check the checksums/hashes, would this have anything to do with the "CRC32"?

Many thanks.

[I.S.T.]

CRC32 is a type of checksum/hash/whatnot.

[tellyup]

so what command do I type into nsft, I think that is where the GUI in 3.4 has its limitations, to compare/cross-check checksums please?

[Deathlike2]

Limitations? What the heck are you talking about? NSRT computes checksums of hacked ROMs as well. I don't understand the complaint.

If you want to properly compare, just select both ROMS (or as many) you want to compare, and NSRT's frontend will display them both.

[Gil_Hamilton]

Lol. Nothing that I do not already own and have had since the time of release. What I want to do is discern from those modified officially released carts and the those of the hardcore collector.

Most people are only going to have ever been exposed to the ones in the shop,s the ones they got fro Christmas - the ones they played. I am trying to put together the knowledge to make a video to show people how to make sure that the the ROMs they have are the ones they think they do.

So PD is a nice touch, but not for the foundation of a collection. Its more of a niche.

Okay, so PD was irrelevant in either case, regardless of if the PD images are "fake" or not.

[powerspike]

That padded file you're referring to is Battle of Olympus, The (U) [o1].nes. Just give it a toss since at the end of the file is a message from your happy neighborhood dumper; followed by 80 bytes of padding. Not all padding is bad mind you so it's not a good way to tell if it's bad or not.

[tellyup]

@Deathlike2: with all due respect I do not want my thread to be infected with provocative statements. I naturally assume that GUI frontends of original command line programs have restrictions, comparrissons being one of them. I did not see the option in and of the drop down menus as as that is the way GUI systems work I thought it was not implemented.

What I think you mean is that I can bring up two sets of information for me to interrogate, fine, but I don't know what to look for. I don't use MAME for ROMs I keep them as individual smc files for example in a folder. I believe the way MAME does it is to use a derivative ips format that just has the modified code in it but it relies on the original copy for the game itself. I am sure I came across hacked smc files themselves and played them.

Anyway, lets take the NES game below, with a SNES game some of the fields would say "OK" in them, that was reassuring, but the NES ones do not so what data will tell me here that this is a good copy?

41088 Bytes (0.3135 Mb)

Padded: Maybe, 119 Bytes (0.0009 Mb)
Interleaved/Swapped: No
Backup unit/emulator header: Yes, 16 Bytes
Internal size: 0.3125 Mb
Internal PRG size: 0.2500 Mb
Internal CHR size: 0.0625 Mb
Memory mapper (iNES): 64 (1088)
Mirroring: Horizontal
Save RAM: No
512-byte trainer: No
VS-System: No
Checksum (CRC32): 0x753cc0fc

[tellyup]

That padded file you're referring to is Battle of Olympus, The (U) [o1].nes. Just give it a toss since at the end of the file is a message from your happy neighborhood dumper; followed by 80 bytes of padding. Not all padding is bad mind you so it's not a good way to tell if it's bad or not.

Thanks, most of that went over my head. The reason I got the files mixed up (your quite right it could have been BoO) was because I rename them to a few chars to make it easier when using the command line.

Right, so what is padding anyway? I don't get it.

What do you mean "give it a toss"?? I bet its slang, but I need replies t the letter because people keep talking in HEX etc...

So how did you, step-by-step, tell what the game was called. And from the dumped data what part would you use to verify its authenticity. The only slight thing I understand is that the CRC32 is a better checking system than something else. There must be something in that CRC32 number that gives it away but using the mcd line version of uCON64 I remember it was the couple of lines above that one which had the green OK signs.

I really have tried looking online to see what all this means, but I just don't understand. For example what is HiROM and LoROM all about?

Many thanks.

[gllt]

Right, so what is padding anyway? I don't get it.

I believe it's data filled with generally either F's or 0's, hexadecimally speaking.

[Deathlike2]

@Deathlike2: with all due respect I do not want my thread to be infected with provocative statements. I naturally assume that GUI frontends of original command line programs have restrictions, comparrissons being one of them. I did not see the option in and of the drop down menus as as that is the way GUI systems work I thought it was not implemented.

The provocation came primarily from misspelling the app's name wrong.

so what command do I type into nsft, I think that is where the GUI in 3.4 has its limitations, to compare/cross-check checksums please?

Secondly, it helps to try everything out on the program before coming to said conclusion, not that it was obvious, but an attempt is better than nothing.

What I think you mean is that I can bring up two sets of information for me to interrogate, fine, but I don't know what to look for. I don't use MAME for ROMs I keep them as individual smc files for example in a folder. I believe the way MAME does it is to use a derivative ips format that just has the modified code in it but it relies on the original copy for the game itself. I am sure I came across hacked smc files themselves and played them.

IIRC, MAME Romsets are just multiple "versions" of the same game in a file. No IPS type of files are involved.

Anyway, lets take the NES game below, with a SNES game some of the fields would say "OK" in them, that was reassuring, but the NES ones do not so what data will tell me here that this is a good copy?

1) If it's not found in the NSRT database, it's not a good copy.

2) If NSRT suggests you to fix the ROM (or they are overdumps and it suggests you trim it), and it can't fix them (you need to right click the ROM for those options to appear), then generally it's a bad dump.

Usually the obvious hint for a bad ROM is what the Checksum says.. it can only be "Good" or "Bad".

[powerspike]

What do you mean "give it a toss"?? I bet its slang, but I need replies t the letter because people keep talking in HEX etc...

There's really no slang involved. When I said give a toss I meant to throw it away, delete the file etc and find a good dump of the game. If you open the rom up in a hex editor then go to the end of the file you'll see the tag of the person who dumped it plus the 00 padding.

Get a hex editor and look at the file yourself:

http://mh-nexus.de/en/

[tellyup]

@Deathlike2: thanks for the info.

The thing about NSRT is that its very high level and clear, I can be sure that the SNES ROMs will be okay if its green and says okay. If anything needs to be changed the menu options will help. But I think I ran through a hacked version of a game and it gave it the all clear, so I'm still a little unsure how to tell genuine from hacked apart.


Inspecting GB ROMs using uCON64 cmd line will show data like SNES will, i.e. green writing! e.g.:


Game Boy/(Super GB)/GB Pocket/Color GB/(GB Advance)
SIMPSONS3
Acclaim Japan
Japan
131072 Bytes (1.0000 Mb)

Padded: No
Interleaved/Swapped: No
Backup unit/emulator header: No
Internal size: 1.0000 Mb
ROM type: ROM + MBC1
Save RAM: No
Version: 1.0
Game Boy type: Standard (4 colors)
Start address: 0x0150
Logo data: Ok
Checksum: Ok, 0x2273 (calculated) == 0x2273 (internal)
Header checksum: Ok, 0x85 (calculated) == 0x85 (internal)
Checksum (CRC32): 0x7aa4e0bb

I need to know what the three successive bottom checks mean (Logo data, Checksum, Header checksum), also when it says "Game Boy type: Standard (4 colors)" I think that will tell me what type of GB ROM it is i.e. DMG/CGB/GBA but I have tried feeding in these different ROMs from different GB generations and not gotten any difference on occasion:

Megaman & Bass [GBA] didn't even have the 'Game Boy type' field, instead it had: "Device type: 0x00" which I think is the substitution there but its still didn't say what generation the ROM was?

a CGB game came up with "Game Boy type: Standard (4 colors)"

a GB game came up with "Game Boy type: Standard (4 colors)"

So what part of the information dump will tell me the type of game it is, what generation e.g. Colour GB or DMG Gameboy...?


Following on from the advice from powerspike suggesting I get a HEX editor to observe the Battle of Olympus ROM, can I do any of that HEX checking in uCON64, I notice when I get uCON64 to spit out the info of the ROM about five lines of HEX accompanies it? Anyway,I got a Mac version of HEX edit and found the following at the bottom of the BoO ROM:

"Battle of Olumpus - Released by MindRape & EFX!"


But searching other ROMS I have I did not see any info at the top or bottom, his advice was to toss this one. So the other ROMs that I have which are empty are good ones I take it? the padding was just 00000... its just a waste of space, what's the point of it? Isn't there a safe trim option, but using that might not guarantee the game is okay right?

I looked at the dump I pasted for Battle of Olympus (But I had it as Gremlins 2 by mistake) and I can only see two bits of information that could possibly indicate the type of game - the 'Checksum (CRC32): 0x753cc0fc' or 'Memory mapper (iNES): 64 (1088)', you see I'm walking about blind here. I tried searching for "0x753cc0fc" inside a HEX editor with BoO open, but the how would I know to look in that particular game?! Therefore it must be that dump data can be linked to the game via the dat file or something? And how do I do that, what uCON64 command allows for that please?


Okay so now I'm going to take that NES dump and line by line write what I think I know it is and what I don't:

"41088 Bytes (0.3135 Mb)"
--the size of the game on disc

"Padded: Maybe, 119 Bytes (0.0009 Mb)"
--sometimes it says "no", I take it no padding means its a perfect dump?, although powerspike said it can bee okay if there is some. In the instance of Battle of Olympus it was a bad dump, so if I see the above "Maybe, xxBytes" then I should HEX inspect it or just safe trim it, can padding be trimmed?

"Interleaved/Swapped: No"
--I read "Interleaving" is not bad, or maybe that was to have the file "Interleaved", its not going to cause a problem if it is. But I don't know what it actually is for.

"Backup unit/emulator header: Yes, 16 Bytes"
--all I know is that "16 Bytes" is all it can be, and something like is made up of a multiple of 4's, so if its a 10 then that is bad. But surely if its anything but 16 it would be corrupt right? Or I just toss it for a good one because it can't be fixed? And I don't know what it means.

"Internal size: 0.3125 Mb"
--no idea

"Internal PRG size: 0.2500 Mb"
--no idea

"Internal CHR size: 0.0625 Mb"
--no idea

"Memory mapper (iNES): 64 (1088)
--no idea, is iNES some kind of data bank/dat file?

"Mirroring: Horizontal"
--no idea

"Save RAM: No"
--no idea

"512-byte trainer: No"
--no idea

"VS-System: No"
--no idea, but that could be some kind of add-on compatibility?

"Checksum (CRC32): 0x753cc0fc"
--not much of an idea but that CRC checking is better than another way or doing it, I forget that way


I be this does not make things clearer your end.

[powerspike]

Just use goodNES. It's really not that bad if you ask me. Sorry, but I think you're doing more work then you need to be doing.

[tellyup]

I get a lot of that. Well I don't give up and they don't make a version for the Mac. What are Mac users supposed to do. That is why I am making a video.

So, can you please help me with any of the above questions?

Thanks.

[Gil_Hamilton]

MAME ROM sets include a full set of the "base version" ROM images, and the images of any ROMs that differ from the base version for variants.

MAME also takes a different approach than most console emulators by storing the individual ROM chip images as separate files instead of a single monolithic image.

Okay so now I'm going to take that NES dump and line by line write what I think I know it is and what I don't:

"41088 Bytes (0.3135 Mb)"
--the size of the game on disc

Size of the file, actually. There's a slight difference between how big the file is and how much space it takes on the disk. But that's me being nitpicky.

"Interleaved/Swapped: No"
--I read "Interleaving" is not bad, or maybe that was to have the file "Interleaved", its not going to cause a problem if it is. But I don't know what it actually is for.

It's something some copiers do to make life hard on people.
Non-interleaved is generally better, but don't sweat it.
It's the same game data either way, and you should be able to de/re-interleave the ROM images at will.

"Backup unit/emulator header: Yes, 16 Bytes"
--all I know is that "16 Bytes" is all it can be, and something like is made up of a multiple of 4's, so if its a 10 then that is bad. But surely if its anything but 16 it would be corrupt right? Or I just toss it for a good one because it can't be fixed? And I don't know what it means.

Copier/emulator headers aren't actually part of the dump. They're added to give copiers or emulators some information about how the cartridge was originally configured.

Different systems have different header rules(or even multiple sets of rules). In fact, the NES often had 512-byte copier headers. Hard to fit meaningful data into 16 bytes.

And headers can be stripped/added without altering the ROM image. They're of no real concern.

"Internal size: 0.3125 Mb"
--no idea

If I had to guess, it's the size of the ROM image after all the extra stuff is stripped off.

"Internal PRG size: 0.2500 Mb"
--no idea

"Internal CHR size: 0.0625 Mb"
--no idea

Ah, now we get into the FUN stuff! It's reporting technical details of the actual NES game.

The NES has not one, but TWO cartridge busses.
One, the PRoGram bus, is for the ROMs that contain actual game code.
The other, the CHaRacter bus, is for the ROMs containing graphics data.

So you're seeing the size of the CHR ROM image and the PRG ROM image when they're broken out of the monolithic ROM image.

"Memory mapper (iNES): 64 (1088)
--no idea, is iNES some kind of data bank/dat file?

iNES is the de facto standard for NES emulation headers, named after the emulator it first appeared in.
The mapper number is supposed to tell you what kind of "mapper" chip was used in the cartridge.


Since the NES had a very small amount of space for ROM, developers found they needed bank-switching hardware to enable the use of larger ROMs needed for more complex games. By the time the system came to America, bank-switching was a common feature in game carts.

Unfortunately for the emulation community, there's roughly nine billion, three thousand, two hundred and forty-one different bank-switching chips.
And many of them were discovered after the last official upadte to the iNES standard.

Let's just say it gets messy.

"Mirroring: Horizontal"
--no idea

This has to do with how the NES stores graphics data.

"As you may have noticed, PPU supports 4 Name Tables with corresponding Attribute Tables. Nevertheless, there is only enough internal VRAM for 2 Name Tables. Other 2 tables are going to be mirrors of the first 2.

Which pages are mirrored depends on the cartiridge circuitry. Each cartridge has control of the PPU address bits A10 and A11. It may set them in one of four possible ways..."

If I recall, however, several mappers can toggle mirroring during gameplay, so it's a bit of a useless header datum.

"Save RAM: No"
--no idea

Does the cart have save RAM in it. This one's easy.

"512-byte trainer: No"
--no idea

If you don't know what a trainer is, consider yourself lucky.
In this case, it seems to be referring to dumps from a specific NES copier family, that had cheat codes embedded in the game.

"VS-System: No"
--no idea, but that could be some kind of add-on compatibility?

It's telling you that the game isn't for the Nintendo VS System, which was a NES-based arcade machine.
Unlike the (NES side of the) PlayChoice-10, there's some differences between home and VS hardware, so flagging a game as for the VS System instead of the NES is important.

[tellyup]

That was a very authoritative answer there, thanks very much for joining the conversation. Well that goes a long way to explaining all of that. How do you ken so much about this then?

[odditude]

because some of us have been "here" for years or over a decade, as opposed to just days or months. after a while, you start to pick up information.