Romhacker knowledge needed

Strictly for discussing ZSNES development and for submitting code. You can also join us on IRC at irc.libera.chat in #zsnes.
Please, no requests here.

Moderator: ZSNES Mods

Post Reply
grinvader
ZSNES Shake Shake Prinny
Posts: 5632
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Romhacker knowledge needed

Post by grinvader »

Dual-posted on the NSRT forums for maximum coverage.

While trimming dumps of all superfluous data using advanced methods, Nach and I realised that a good deal of ROMs have garbage-like data stacked on their end to round it up.
By 'garbage' I mean chunks of 32768 bytes made of subblocks of 256 bytes filled with the same value (think 256 times 0xFF, then 256 times 0x00, and so on until 32768 bytes are filled). Heuristics show any value from 0x00 to 0xFF can show up in such garbage.

When you mirror the new ROM up to its proper size (power of 2), spots that should be taken by garbage are filled with real romdata (instead of garbage, since it's not available anymore). That's the only difference - spots that hold real data on the old mirror will have the exact same data in the new.
Forgot to mention: the trimmed ROM has of course a correct checksum.

The problem is: is it possible for a game to rely on the garbage data (in any way) ? I know the theoretical answer is yes, but have you ever met a ROM sadistic enough to rely on it ?
If you have, then please point out which, as having a real test case would greatly help improve our trimming methods.
皆黙って俺について来い!!

Code: Select all

<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
creaothceann
Seen it all
Posts: 2302
Joined: Mon Jan 03, 2005 5:04 pm
Location: Germany
Contact:

Post by creaothceann »

As I understand it, the cartridge's address decoder converts these addresses to valid ones pointing to actual ROM cells, so that the SNES (and the game) never sees the garbage.
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
byuu

Post by byuu »

I may not be following ...

If you're meaning the games have padded, repetitious data at the ends that you want to delete off the ROMs to make them smaller ... then no, please don't do that. That's insane, compression will eliminate the repetitions just fine.

Let's take a 3mb ROM, broke into 512kb chunks, legend: D = data, P = padding.
D0 D1 D2 D3 D4 P0
Mirror that to 4mb as you should be doing, and you get:
D0 D1 D2 D3 D4 P0 D4 P0

You're advocating cutting out P0 so that you have:
D0 D1 D2 D3 D4 D4 D4 D4 ?

I really can't understand why you'd bother. That won't match what the real hardware would have seen, regardless if the game reads the data or not. To answer your question, it's very unlikely the games are validating this "padded" data. It's possible they are specialized lookup tables to speed up some common operation, but unlikely. You can probably delete it ... but if it was on the original ROM, then why the hell would you?

Now, if you have a 4MB ROM with:
D0 D1 D2 D3 D4 D5 D4 D5
And you want to delete the last 1MB, go for it. Mirroring it back up to 4MB will restore the data, and it's almost guaranteed that the second ROM chip was really a 1MB chip with the highest address pin not connected anyway. In other words, it's likely an overdump, and even if it isn't, it doesn't matter. Our power of two algorithms will take care of it.
Nightcrawler
Romhacking God
Posts: 922
Joined: Wed Jul 28, 2004 11:27 pm
Contact:

Post by Nightcrawler »

Who are you to define what 'garbage' data is? It's a terrible idea to get rid of any information from a ROM dump. Fill bytes or patterns can most certainly be used in the ROM for whatever reason. Specific case examples don't even matter. Bottom line is any data from the ROM that can be seen by the SNES is not garbage, can be used, and should not be deleted.

If you can prove that said data was not in the original cartridge, or that data cannot be seen by the hardware, that's another story. However, even if it can't be seen by the hardware, I'm generally opposed to removing it anyway. due to the potential of removing data mistakenly where it shouldn't have been. I wouldn't use a ROM set that has had data pulled like that.
[url=http://transcorp.romhacking.net]TransCorp[/url] - Home of the Dual Orb 2, Cho Mahou Tairyku Wozz, and Emerald Dragon SFC/SNES translations.
[url=http://www.romhacking.net]ROMhacking.net[/url] - The central hub of the ROM hacking community.
tvtoon
Rookie
Posts: 18
Joined: Sun Dec 26, 2004 8:15 pm
Location: Brasil

Post by tvtoon »

Nightcrawler wrote:Who are you to define what 'garbage' data is? It's a terrible idea to get rid of any information from a ROM dump. Fill bytes or patterns can most certainly be used in the ROM for whatever reason. Specific case examples don't even matter. Bottom line is any data from the ROM that can be seen by the SNES is not garbage, can be used, and should not be deleted.

If you can prove that said data was not in the original cartridge, or that data cannot be seen by the hardware, that's another story. However, even if it can't be seen by the hardware, I'm generally opposed to removing it anyway. due to the potential of removing data mistakenly where it shouldn't have been. I wouldn't use a ROM set that has had data pulled like that.
We can have curiosity, can't we? :P

For the uninteresting part here (however hard to prove that is), I would use anything that means complete game data for any emulation related interests and advise against the opposite...
There is no sense in burning junk binary data or just pins data in CDs or DVDs, when all you need is the right plan, so I DO recommend the complete check of these instances.

Maybe it looks like stupid for SNES era, but nowadays it is ridicule seeing systems with File Systems (NDS) being dumped entirely as "ROMs"!
[url=http://s131.photobucket.com/albums/p308/tvtoon/Avatares/th_tvlogo.png]GO LOGO, GO![/url]
<Renze> "IRC, where men are men, women are men, and 14 year old girls are FBI agents"
Post Reply