Back to: Nintendo - Game Boy Advance
 Famicom Mini Size |
|
Category: ROM data Closed (accepted) by: root. |
|
ATMB »
2004-02-14 19:27:43
Famicom Mini 01 Super Mario Bros. (J) Size: 32 Mbits Intro: None (it doesn't work in emulators yet, but on carts run fine) CRC32: 5848884C Famicom Mini Vol 03 Ice Climbers (J) Size: 32 Mbits Intro: None CRC32: 5646F9D1 Famicom Mini Vol 07 Xevious (J) Size: 32 Mbits Intro: None CRC32: 65A67D75 |
|
Bent »
2004-02-15 00:18:43
These files appear to be overdumped. Examining vol 1 & 3 with a hex editor will give show you it's a 8mbit file repeated 4 times. Vol 7 is this same 8mbit file, but instead of being repeated it is padded with 24mbit of 00 (instead of FF, which is what the file padding actually is, which leads me to believe it is overdumped) |
|
coolhj »
2004-02-15 05:06:41
yes, I checked. I cut the file (vol 1&3) average into 4 part,then each part has the same crc. In fact,the size of each of these 3 mini game is only 2 mbit,and all of them work on hareware perfectly. |
|
coolhj »
2004-02-15 08:38:00
Famicom Mini 01 Super Mario Bros. (J) Size: 2 Mbits Intro: None CRC32: 8DB32FC6 Famicom Mini Vol 03 Ice Climbers (J) Size: 2 Mbits Intro: None CRC32: 2DC0A5E7 Famicom Mini Vol 07 Xevious (J) Size: 2 Mbits Intro: None CRC32: 6BE31177 With gbata you can fix it easily. |
|
Bent »
2004-02-15 11:24:41
I think though that the proper size should be 8mbit, if we are going off of the cart size, since each file is padded out to this length anyway, it's probably the smallest size production cart I'd guess. If we are going off of what a proper redump will tell us, I would assume these 8mbit files would be right: Famicom Mini 01 Super Mario Bros. (J) Size: 8 Mbits Intro: None CRC32: CD2604DD Famicom Mini Vol 03 Ice Climbers (J) Size: 8 Mbits Intro: None CRC32: D0AEF472 Famicom Mini Vol 07 Xevious (J) Size: 8 Mbits Intro: None CRC32: F54EEB0E If these are decided to be more proper at 2mbit, so be it, but I think based on the file structure a redump would reveal an 8mbit file. |
|
coolhj »
2004-02-15 12:04:03
Maybe you are right, 8 mbits is better based on the structure, I think so! |
|
ATMB »
2004-02-15 13:09:11
Are you sure that most little cart size is 8 MBit? If you're sure, than gotta truncate 'em all (Pok?mon :P ) to 8, otherwise they need to be 32... let me know! bye! |
|
coolhj »
2004-02-15 13:29:09
I can just tell you that the original release of 3 mini game contains lots of crappy useless data,if you don't cut the size down to 8mbit , when you flash it into a flash cart,it will consume more capacity.8mbit version can be trimmed to 1.5 Mbit,the 32mbit version can only be trimmed to 25.5 mbit. |
|
volospin »
2004-02-16 05:22:38
with gbata, it shows that it can trim up to 1mbit... haven't try on hardware. |
|
coolhj »
2004-02-16 09:46:28
Works fine , I'v tested. "1mbit" is just a approximate value , the "bytes" is the true size. |
|
volospin »
2004-02-16 09:59:17
that's around 153,040bytes for ice climber and 161,120bytes for xevious working with PogoShell and SRAMPatch + Trim by GBATA |
|
Bent »
2004-02-16 10:49:29
It's not a question of how small it can be trimmed, or else we'd trim down every game that had any padding at the end. It's a question of file structure and what the file should look like. For those who don't get quite what I'm saying, assume the file that was released looks like this: 12345678123456781234567812345678 Each number is a megabit. Notice how the file has one part (12345678) that repeats itself 4 times. 1 & 2 hold game data, while 3-8 is FF padding. Now the game COULD be trimmed down to just parts 1 & 2, but I believe the proper size is 8mbit, because of this file structure. Games are padded all the time to reach the proper cart size, and that seems to be what was done here. One of the files (can't remeber which one without checking) has a slightly different structure. It looks something like this" 12345678999999999999999999999999 1-8 is the same as the other two files, 2mbits of code and 6 of FF padding. But part 9 is in this case 00 padding. Files do not come with two types of padding, it is either one or the other, and based on the other two files, this one should be 8mbit as well. Is my illustration making it any clearer? My guess is that two different groups dumped these three games (which if I remember right actually is the case). The reason that the files were overdumped probably is from the linker used. I'm assuming that 32mbit is the smallest game size that these linkers handle. One linker just repeated the file 4 times to make it fit into 32mbit, the other one just filled the file out with 00's. Whatever happens, it won't offend me, but based on the file structure, and the experience I have with dumping games (I have a gameboy linker that won't properly dump 2mbit games, it makes them 4mbit with the data repeated twice), I think the 8mbit file is the proper size. |
|
coolhj »
2004-02-16 12:17:41
8mbit is ok, that's all. |
|
ATMB »
2004-02-17 00:56:46
OK. 8 Mbit for me is good too. Let's see the last Famicom_Mini_Vol_2_Donkey_Kong_JPN_GBA-RS, 8 Mbit. :) byte! |
|
Bent »
2004-02-17 01:05:17
There is even mention of the previous ones being overdumped in that .nfo. |