News:

11 March 2016 - Forum Rules

Main Menu

Changing rom size of snes rom

Started by poponon, May 09, 2014, 11:08:20 AM

Previous topic - Next topic

poponon

Hi, first post here.

Recently I was trying to get dynamic-design's latest chaos seed translation patched rom running on actual hardware via flashcart. I'm using the tototek super flash cart, but when i try to load the rom to the cart I recieve an error.

Although i'm not home right now, the error seems to have to do with the rom size . It comes up as a 64bit rom when loading to the cart, and errors out halfway through loading to the cart with an error along the lines of "there is no more data left". So, I'm assuming the rom size in the header is incorrect.

I've tried looking for a method to change the header rom size via ucon64 and snestool but I'm coming up short.

Does anyone know a method of altering the header rom size?

Any help is very appreciated

KingMike

First Google result for "snes cart header"
ROM $7FD7 (if LoROM) or $FFD7 (if HiROM, both values unheadered), value 0C = 4MB.

If the patch doesn't pad the game to a full 4MB, then you should do that (either use a hex editor and 0, FF or whatever to the end of the ROM up to 0x3FFFFF, or just download WindHex. There's an option in there somewhere to pad the ROM.
"My watch says 30 chickens" Google, 2018

poponon

Quote from: KingMike on May 09, 2014, 11:43:29 AM
First Google result for "snes cart header"
ROM $7FD7 (if LoROM) or $FFD7 (if HiROM, both values unheadered), value 0C = 4MB.

If the patch doesn't pad the game to a full 4MB, then you should do that (either use a hex editor and 0, FF or whatever to the end of the ROM up to 0x3FFFFF, or just download WindHex. There's an option in there somewhere to pad the ROM.

So from my understanding you don't believe the problem is an incorrect rom size in the header but rather this padding issue?

puzzledude

The header rom size is usually insignificant with SNES emulation. It is ignored completely in some cases. Much more important is the actual size of the rom. But real hardware is much more problematic.

So if you (for instance) have 2MB of actual data, you first need the hex editor to expand the rom to exactly 4MB, filing the rest with blank FF bytes. Once this is done, you simply need to modify the byte at 0x7FD7. Which is 0A for 1MB Lorom. 0B for 2MB and 0C for 4MB. Now your rom is 4MB.

Of course the upper hex address is accurate only, if the file does not contain the 200 "lead-in" or copier header (containing mostly 00 bytes) at the front of the file, which should be removed completely.

Note: The rom size is not necessarily your problem.

Gideon Zhi

Quote from: puzzledude on May 09, 2014, 01:39:22 PM
So if you (for instance) have 2MB of actual data, you first need the hex editor to expand the rom to exactly 4MB, filing the rest with blank FF bytes. Once this is done, you simply need to modify the byte at 0x7FD7. Which is 0A for 1MB Lorom. 0B for 2MB and 0C for 4MB. Now your rom is 4MB.

The rom size value in the cartridge header is completely ignored by actual cartridges and SNES hardware, and is in fact inaccurate in a few commercial titles. (I can't name any off the top of my head, but I know who to ask to find out...) If it's being polled by a flashcart, then that's a flaw in the flashcart's read logic and isn't a problem with the translation patch.

puzzledude

Quote from: Gideon Zhi on May 09, 2014, 01:41:42 PM
The rom size value in the cartridge header is completely ignored by actual cartridges and SNES hardware, and is in fact inaccurate in a few commercial titles.
Good to know. So the definition of the romsize in the internal header is actually insignificant and does not relate to the problem in any way.

Gideon Zhi

Quote from: puzzledude on May 09, 2014, 01:49:36 PM
Good to know. So the definition of the romsize in the internal header is actually insignificant and does not relate to the problem in any way.

Ah, but I didn't say that. It's insignificant where official hardware is concerned. (A lot of the internal header information is insignificant, the exceptions being actual programmatic things like the reset vector.) I've never used one of Tototek's cartridges though, and it's very possible that your cartridge may (improperly) poll internal header information for ROM image size.

poponon

 thanks for all the input everyone. I'm going to try and play around with the rom a bit more when I get a chance and I'll bring back some more details.

Also, wow! a reply from gideon zhi.  Just want to take the chance to let you know how much I appreciate and enjoy so many of your projects! Thanks for giving everyone the opportunity to play some amazing games that would otherwise have gone unnoticed. I recently finished playing your Ys V translation on actual hardware - it was an amazing game and the translation was phenomenal.

Revenant

Quote from: Gideon Zhi on May 09, 2014, 01:41:42 PM
The rom size value in the cartridge header is completely ignored by actual cartridges and SNES hardware, and is in fact inaccurate in a few commercial titles. (I can't name any off the top of my head, but I know who to ask to find out...) If it's being polled by a flashcart, then that's a flaw in the flashcart's read logic and isn't a problem with the translation patch.

Super Noah's Ark 3D is one, if that counts (and most other unlicensed/bootleg carts I've seen don't bother with valid size info in the header either).