-
Welcome to Smashboards, the world's largest Super Smash Brothers community! Over 250,000 Smash Bros. fans from around the world have come to discuss these great games in over 19 million posts!
You are currently viewing our boards as a visitor. Click here to sign up right now and start on your path in the Smash community!
How to port NTSC codes in PAL?
- Thread starter Michi
- Start date
I don't know for sure, you have to have the hex stuff for both regions and compare the differences between them and fix them accordingly. I am not 100% it's that, but it's not an easy task for use, otherwise we would have all the codes ported already.
It's very much not a hard task, but it requires an understanding of how Gecko OS codetypes work. There are very few people who have the knowledge, it seems, and they are often not inclined to port codes.
Essentially, it comes down to opening up a NTSC-U and PAL memory dump of the entire 80000000-81800000 region. Then, whenever the code refers to a specific location, you find that location in the NTSC-U memory. You search the PAL memory for a region of code very similar to that of the region around the location in NTSC-U, and then when you find the point you want you write that into the code instead.
There are a few possible hiccups. The first is that it is hard to find a matching region of code. Sometimes, the address you want is in a location which has other addresses written in it. So, because address locations are different in the two dumps, you won't get a match with a search. Generally, the solution to this is to search a reasonable distance away from the area you want in order to find a more 'generic' set of code to use as a search.
Similarly it's also possible you find multiple matching sets of code, where a similar approach (or making the search more specific) helps.
The biggest problem is usually finding where the code references different addresses. This is where an understanding of WiiRD-type codes and ASM codes comes in, generally you can get information from wiird.l0nk.org (not a competing site). Many simple codes refer to only one address. In fact, some of the more complicated ones also only refer to one. Although the specific addresses are different between regions, generally the relation between addresses remains the same. For example, if in the american version i store a piece of information 16 units past a specific address, it'll probably be in the same relative address in the european version. This is important when considering pointers (and pointer trees), which you may not know about.
The thing is that sometimes codes (especially ASM codes) refer to addresses without telling you about it. This is the biggest hiccup with Phantom Wings' file replacement codes; generally his technique is to write a set of assembly code to assorted locations on the memory, then write in a lot of other places telling them to read his instructions. Because of the way all of the offsets have been organized, it makes it a real burden to overcome.
There's one very rare bug which I've encountered with ASM codes, and that is that in very rare cases the American and European versions of the game use different registers to store data. This probably stems from a very subtle change in the way the code has been written (which probably doesn't change gameplay at all). The only time this has come up was when I ported spunit's frame speed modifier. When originally ported, every character would continually flicker until a specific register was changed. It was very bizarre.
Well, I imagine that won't help at all. But now you know.
Essentially, it comes down to opening up a NTSC-U and PAL memory dump of the entire 80000000-81800000 region. Then, whenever the code refers to a specific location, you find that location in the NTSC-U memory. You search the PAL memory for a region of code very similar to that of the region around the location in NTSC-U, and then when you find the point you want you write that into the code instead.
There are a few possible hiccups. The first is that it is hard to find a matching region of code. Sometimes, the address you want is in a location which has other addresses written in it. So, because address locations are different in the two dumps, you won't get a match with a search. Generally, the solution to this is to search a reasonable distance away from the area you want in order to find a more 'generic' set of code to use as a search.
Similarly it's also possible you find multiple matching sets of code, where a similar approach (or making the search more specific) helps.
The biggest problem is usually finding where the code references different addresses. This is where an understanding of WiiRD-type codes and ASM codes comes in, generally you can get information from wiird.l0nk.org (not a competing site). Many simple codes refer to only one address. In fact, some of the more complicated ones also only refer to one. Although the specific addresses are different between regions, generally the relation between addresses remains the same. For example, if in the american version i store a piece of information 16 units past a specific address, it'll probably be in the same relative address in the european version. This is important when considering pointers (and pointer trees), which you may not know about.
The thing is that sometimes codes (especially ASM codes) refer to addresses without telling you about it. This is the biggest hiccup with Phantom Wings' file replacement codes; generally his technique is to write a set of assembly code to assorted locations on the memory, then write in a lot of other places telling them to read his instructions. Because of the way all of the offsets have been organized, it makes it a real burden to overcome.
There's one very rare bug which I've encountered with ASM codes, and that is that in very rare cases the American and European versions of the game use different registers to store data. This probably stems from a very subtle change in the way the code has been written (which probably doesn't change gameplay at all). The only time this has come up was when I ported spunit's frame speed modifier. When originally ported, every character would continually flicker until a specific register was changed. It was very bizarre.
Well, I imagine that won't help at all. But now you know.