Is there a real reason why most huge ass games fill all the space with junk (a bunch of $FF bytes in a genesis ROM, for example). I also read somewhere here that xbox 360 and ps games are almost the same, only difference is PS games have a lot of padding for the blue ray disks (and also changing text strings to load the right buttons that vary from each console). Is it really necessary to fill the emptiness in the games, to match the cartridge/disk size? Also, why when adding new art to a sonic game, sometimes the new DAC samples I add become noisy, but after resizing the padding file, its all better?
For ROM chips, yes, it is vital that the ROMs are padded, it's due to how the chips work. You can't have half a chip filled, something has to be there. In modern games, padding is almost always done to push the game data to the outside edge of a disc, to cut down loading times and saving wear on the laser motor.
To provide some more insight on this point, it might help to explain why they're padded with 0xFF instead of 00 or random values. Remember that each byte is made of 8 bits which can be 0 or 1. Thus FF is 11111111. A 1 is typically represented by the presence of voltage, and 0 represents a lack thereof. I don't know the specifics for a Gen/MD cart, but for the sake of this example I assume the system applies 5V to the cart. On an empty chip, every single address has a connection to that 5V source. When they 'burn' the ROM data onto the chip, they're burning away a physical connection between the voltage source and the desired address on the chip. Without that connection, you no longer have voltage present when trying to read data for that address. In short, a blank chip starts with everything returning 1's and you burn away what you don't want to be 1 in order to write data to the chip. This is a very simplified example, but I think it makes sense. NOR based flashcarts work very similar to this. If you've ever used an older GBA or MD flashcart, this is why it needs to be 'erased' before you can write a new rom to it. Everything get's set to FF before the desired bits get turned back off.
In case of ROMs, you got FF in unused parts because in erased state, the memory has its cells in High state (1). When being programmed the ones are programmed to zero. It does not matter if you burn the ROM/Flash/whatever partially, only erase operations degrade memory. If some software requires padding in a ROM its doing something wrong... it should either pad the file itself or not do it at all (my software only writes the data, and does no padding and I've yet to find something that's unhappy with it).
This is what I thought as well. Maybe the padding at the end of a rom file is specifically because of this, not because the original binary burned to the EPROM was really a 512 or 1024kb file exactly padded with 0xFF, maybe it was whatever size it needed to be and the rest ended up as 0xFF due to the burning :specialed:
in case of X360 and PS3 games being so big while actual game may take much less is because the stuff on the discs is encrypted... when you dump you dump all the stuff on the disc as there's no way of knowing where the stuff is or not etc. At least so I understood it when a friend talked about it.
This is both the worst and best answer ever. Good job. What's always confused me is why so many people seem to want "clean" dumps with the padding still intact and not trimmed. I understand the desire for a dump that hasn't been tampered with in any obvious way (pirate intros, etc), but padding properly removed serves no purpose but to save space.
I can think of two reasons: 1) there's nothing stopping programmers from using $FF as legitimate null data that the program has to read (this happens in Chaotix; the first few $FF bytes are actually used by the object system); 2) the padding bytes probably creates the false security of knowing it was dumped from an EEPROM dumper (padding is easy to fake too you know!).
Padding takes up almost no space at all when the file is compressed. I don't see how it's a problem either way.
