I have been working, along with two others, on a translation patch for the NTSC-J Wii game Zero 4, also known as Fatal Frame 4. At this point, most of the technological hurdles in creating a fully translated game have been overcome, a large chunk of the game is translated, and everything is proceeding smoothly.
Now, while the modified ISO can easily be run on backup loaders, this isn't very useful. I would like to create a patching application which could be run from the newly developed bannerbomb application, for use on a virgin legal Wii.
The idea would be to apply the game patch through some sort of homebrew application. Hopefully, it could be region free at the same time, but this isn't essential. At that point, a completely legal and freely usable translation patch would have been created. Nice.
Is this possible? I do not have extensive experience with homebrew programming, and thus I am looking for highly experienced opinions. If any clarifications are needed on any of these matters, simply post and I will do my best.
I appreciate any replies, and thank you in advance.
The progress thread for the translation can be found: here. (http://www.cameraslens.com/forum/index.php?topic=7248.0) Please, no homebrew or loader discussions on the BCL forums, post those here.
I'll reply with what little knowledge I have.
In SSBB, Phantom Wings was capable of finding a method using a prudent ASM insert or two to trick the game into checking an SD card for a file before checking the disk. The primary use for this is changing textures - but in your scenario, it might be usable to change the files which contain the text you're putting stuff into.
If you were able to find a way to make this method work in the game you're hacking, then you'd be able to boot your translated copy through Gecko OS. Of course, to my understanding, Comex' System Menu Exploit currently only works with downgrading and installing applications, but if it does get its usage increased, then it may be possible.
Hope you find this useful.
That is incredibly useful and just what I wanted to hear.
The bannerbomb is supposed to be able to run any elf or dol file. Your post might be a way to run this patch, and a superior way than my currently considered method (which is to package a copy of the ENTIRE game into the patch, and write a specific SDHD Loader to load that if and only if it detects the game in the disk drive. Not terribly practical).
The goal is to get it to run completely legally, or as close to as possible after all.
I've received no response from this fellow. Do you know where I could find documentation on his hack?
Or... Instead of using Phantom Wings ASM hack, you could use the new Gecko OS Patch File (.gpf).
I would like to help you with this, but I don't know how to use it, it's very new and only very few people know how to use it.
If you want "instructions" about this:
---------------------------------------------------------------------------------------------------------------------------------
In order to make a GPF (Gecko Patch File) you will need to use a hex editor. The file should be given named with the game ID and gpf extension and put in a patch folder, that is on the root of your SD card. Here's the patch file format as described by Nuke:
"[1 byte] - Number of patches (hex)
[4 bytes] - Patch Destination (hex)
[4 bytes] - Patch Size (hex)
[Patch X] - Patch data size of Patch Size
example
02 - Number of Patches
91000000 - Destination Address
00000002 - Patch Size (this example 2 bytes)
AABB - The Patch (size of Patch size)
91000004 - next
00000002 - next
CCDD -
The format will be just a hex blob like this
029100000000000002AABB9100000200000002CCDD
and saved to folder 'patch' on the SD card, with the GameID being the filename with .gpf extension, so for red steel jap, the file name would be REDJ41.gpf placed in folder 'patch'."
---------------------------------------------------------------------------------------------------------------------------------
I take no credits for this, these instructions are in the Gecko OS 1.9 package.
I don't know if it's me or these instructions are almost useless...
Anyway, I'll help you if I find out how to use these patches, good luck.
No, this is even better than the ASM hack. I'm assuming that this patches the data as found on the iso. With this the case, I can write up a script to make this patch by comparing a modified iso against a regular iso, and exporting all the changes as text. It's essentially a ppf file. Assuming that it works, the only improvement I could possibly think of would be automating the settings and actions of GeckoOS so that the end user need not worry about them, and can merely hit Go.
Thanks a ton! I'll start experimenting.
Patches are a one-time overwrite to a game's ram in a certain location. They do not modify the files on the disk, and if data is ever loaded into the location where you've put a patch, the patch is lost until the game is reloaded.
Phantom Wings has taken a break from Wii RAM Hacking - perhaps I should have noted that. I'm hardly as talented but I may be able to give you some help understanding it some time.
Ah, so it's not what I hoped for. RAM hacking and translation patches don't seem like the ideal match, from what I can tell. Theoretically I could create the codes, perhaps, but the code file would be well over a gigabyte of addresses and value changes, which may or may not work. Not to mention writing the codes would take ages.
I'm still not certain I can do this. If you happen to have information on Phantom Wings way to read data from the SD, link me to it or post it here.
If you're brainstorming and happen to think of a bold and dangerous plan which just might work, post it up here and I'll give it a shot.
Quote from: Tempus on May 15, 2009, 04:22:26 PM
Ah, so it's not what I hoped for. RAM hacking and translation patches don't seem like the ideal match, from what I can tell. Theoretically I could create the codes, perhaps, but the code file would be well over a gigabyte of addresses and value changes, which may or may not work.
Gpf files can have unlimited lines I beleve... so that would be your best shot.
The problem is that they're written to the RAM only once at the beginning, correct? And then subsequently overwritten by any following reads from the game disc? Since I'll be wanting to translate every piece of text in the game, theoretically this means that if I load one area, leave, and load it again, the translation would disappear, correct?
Perhaps I'm not understanding the process correctly, though. I'm familiar with hex, but not so much with memory management. I'm still not certain as to the advantages of a gpf patch (which writes only once, and can then be overwritten) versus an Ocarina hack (which continuously modifies values and thus could be potentially be set to replace certain data types with my replacements, through use of a read from SD and extensive checksums). I appreciate any replies.
I think to some extent .gpf files are less useful than originally conceived, because of newer updates to the Gecko program rendering them somewhat unnecessary. But I'll cite an example where I would want to use a patch over a code.
Say, in Mario Kart Wii, I want to change how fast each Kart moves/accelerates to a specific value. One way to do it would be to construct a series of If... cases that identify which Kart is being used, then follow a pointer tree and modify the appropriate value. Similarly, I could use an ASM code to intercept when these values would normally be read, and instead set up Ifs (If Kart is X, take Speed = A instead of its normal value). However, the issue with these codes is that they're cumbersome and long to write, and if I want to change a specific value it can be sort of hard to do at a glance for an inexperienced user.
Instead, I'd set up a table somewhere in unused memory space. The table would be simple: just a three-columned array of Kart || Speed || Acceleration. I'd put an intercept on the location of when the Kart Speed should be read, and instead tell it to scan the list, find the appropriate Kart and pluck out the appropriate value instead of whatever it would do normally. I could use a series of search algorithms to reduce the strain on the system if desired (for example, the Karts will use IDs and if they are sequentially separated, I can use a series of multiplications to get to the correct location in the table instead of searching one by one. But that somewhat irrelevant).
Now, I could write this table using a RAM write to an unused data area (most games have a few pockets of unused space), and then write the ASM code to refer to it. But once the table is written into memory, it does not need to change over time - it is a set of constants. So provided my memory space is truly unused, a single write (and thus a .gpf patch) is all that is necessary. If I am constricted by my line limitation, then it is important that I use these .gpfs rather than use up valuable line space writing things like this.
The fact that we can change where the codelist starts and ends somewhat reduces the need for this, notably. If there is a large pocket of unused memory then I can just write my codes in the first portion and my data tables in the second portion using RAM writes. If you have many small segments of unused space, though, the .gpfs may be needed. If really desperate, you can write ASM codes as .gpfs, too.
I still maintain that a method similar to Phantom Wings' would be the most appropriate for your issue if you did not want to use ISO hacking. But you would have to personally decrypt how the codes work, and try and transfer the result. He originally required a very complex method involving several codes totaling a hundred or so lines, but found an elegant solution which used only about twenty. Perhaps the potential for a similar code exists in your game - it may be the case that the codes which load data from the disk are written very similarly.
Thanks, that was really clear. I'll look around to see if I can find his codes - if you have a link handy that'd be great too of course. Looks like it'll require a complicated bit of assembly - I'll have to learn more or recruit someone better than myself to make certain it will work. And a gecko. Need one of those too I suppose.
Quote from: Almas on May 12, 2009, 11:46:10 AMIn SSBB, Phantom Wings was capable of finding a method using a prudent ASM insert or two to trick the game into checking an SD card for a file before checking the disk. The primary use for this is changing textures - but in your scenario, it might be usable to change the files which contain the text you're putting stuff into.
If you were able to find a way to make this method work in the game you're hacking, then you'd be able to boot your translated copy through Gecko OS. Of course, to my understanding, Comex' System Menu Exploit currently only works with downgrading and installing applications, but if it does get its usage increased, then it may be possible.
Unfortunately it probably won't be so simple in this case; the reason Phantom Wings was able to make a code for SD file loading is because SSBB already has functions for reading from a SD card, most games however do not. That doesn't mean it is impossible though, but it will probably require that SD card reading functions be inserted into RAM somehow and that is not an easy task.
Quote from: Tempus on May 16, 2009, 03:54:52 PMThe problem is that they're written to the RAM only once at the beginning, correct? And then subsequently overwritten by any following reads from the game disc? Since I'll be wanting to translate every piece of text in the game, theoretically this means that if I load one area, leave, and load it again, the translation would disappear, correct?
Perhaps I'm not understanding the process correctly, though. I'm familiar with hex, but not so much with memory management. I'm still not certain as to the advantages of a gpf patch (which writes only once, and can then be overwritten) versus an Ocarina hack (which continuously modifies values and thus could be potentially be set to replace certain data types with my replacements, through use of a read from SD and extensive checksums). I appreciate any replies.
It really works in almost the reverse of how you think it does; it isn't necessarily a problem if the data from a GPF (Gecko Patch File) is overwritten after being put in memory because you can setup an ASM insert to transfer the data to memory dynamically allocated for it before that happens. On the other hand codes have to be put into contiguous memory that will never be overwritten - and you can't easily change the location of the code list after the game has started. A good example of this is the GPF that I developed for Super Mario Galaxy (see the end of the first post in this topic (http://wiird.l0nk.org/forum/index.php/topic,39.0.html)).
As for what method to use to patch a game with your translation, it will really depend on how big the translated files are. Text patching would be easy and probably won't be a problem; a GPF will easily work for that. The graphics are the real problem, so depending on how big those are you might be able to use a GPF or perhaps you will need a SD loader. Currently creating a SD loader might be quite difficult, however I was considering doing some work on that anyway because I need it for other purposes (so I might eventually make a generic SD loader that is usable for all or most games/channels).
Quote from: matt123337 on May 16, 2009, 12:37:53 PM
Quote from: Tempus on May 15, 2009, 04:22:26 PM
Ah, so it's not what I hoped for. RAM hacking and translation patches don't seem like the ideal match, from what I can tell. Theoretically I could create the codes, perhaps, but the code file would be well over a gigabyte of addresses and value changes, which may or may not work.
Gpf files can have unlimited lines I beleve... so that would be your best shot.
I think they just add alot, 8191 if I remember correctly from a screenshot
Very good info, brkirch, and thanks for responding. Unfortunately, it doesn't look terribly promising then, but at least it's doable (which is better than what I've gotten from other areas!). Unfortunately, there is no way this game's text files could be kept as code - the unique raw scripts total 585, 612 bytes - about 5.8 mbs of text. Not only that, but the text is actually kept within a larger structure, as all the game data is kept within RSL files, which are themselves containers for a multi-level nested structure of other files. On top of all that, each script contains a formatting header (4 to 5 times as long as the script itself) and a dynamically pre-generated font image complete with unique character encoding generation, making the whole script likely to be 100 mbs+, even providing we could decode the RAM data and match it to the way the game loads the RSL files and overwrite only the text. If not, a gig, easy.
I know the game contains a method for saving and creating albums - I believe that this writes to the hard drive, though. I'm checking it now, just bear with me for a minute.... Yep, seems to be hard drive. Any more information on how to create this SD loader? Seeing as such a thing would be mostly independent from the actual game code, could it be written in C, compiled, and then the assembly code inserted and modified to work? The community response to an open (but moderated) translation page has been astounding, and provided we finish the batch text insertion program on time it looks like we'll be ready to go to alpha in two to three weeks. The patch here is really the final technological hurdle to break, and I'd like to get working on it if this method is truly possible.
Well, I also thought about it.. it's doable and a GPF could perform the job.. however, in most cases I guess an SD loader would be a more feasable way, even if it's initialized using a GPF.. you need to consider that a GPF only patches memory once.. so you need to find a memory area which is not overwritten by the game which is going to contain all your text!And then tell the game to use this text instead of different text. Although i hate to admit it.. doing this by doing a disc hack and using Backup loaders or Modchips is most likely much easier.. it will however break the disc signature. This would however also allow "easy image translation".
Still, like brkirch said.. it is possible.. just it's a long road to go!
Thank you for all your help so far.
After reading some assembly tutorials the last few days, I am afraid to say that this is probably beyond me. It would probably take me well over six months just to learn enough to be able to do this, and then another three or more to actually do it. I can tell I am out of my league here.
That said, I don't want to abandon all hope yet. Can I attempt to recruit helpers from this forum, and work with them to create this? If so, where can I ask? Is there an IRC channel as well? Thanks again for all your replies.
Quote from: REDSOXROX on May 18, 2009, 01:22:53 AM
Quote from: matt123337 on May 16, 2009, 12:37:53 PM
Quote from: Tempus on May 15, 2009, 04:22:26 PM
Ah, so it's not what I hoped for. RAM hacking and translation patches don't seem like the ideal match, from what I can tell. Theoretically I could create the codes, perhaps, but the code file would be well over a gigabyte of addresses and value changes, which may or may not work.
Gpf files can have unlimited lines I beleve... so that would be your best shot.
I think they just add alot, 8191 if I remember correctly from a screenshot
no. thats a game config option.
Quote from: matt123337 on May 23, 2009, 02:53:15 PM
Quote from: REDSOXROX on May 18, 2009, 01:22:53 AM
Quote from: matt123337 on May 16, 2009, 12:37:53 PM
Quote from: Tempus on May 15, 2009, 04:22:26 PM
Ah, so it's not what I hoped for. RAM hacking and translation patches don't seem like the ideal match, from what I can tell. Theoretically I could create the codes, perhaps, but the code file would be well over a gigabyte of addresses and value changes, which may or may not work.
Gpf files can have unlimited lines I beleve... so that would be your best shot.
I think they just add alot, 8191 if I remember correctly from a screenshot
no. thats a game config option.
Oh
So GPF's could add as many lines as you have room on SD for :confused:
Room in SD and in memory.
Luckily for Brawl hackers, there is a region of memory approximately 0x20000 in size that (as far as anyone can tell) is completely unused. After that there's another region of very similar size which occasionally has dump data placed in it but is otherwise clean. Each line of code takes up 0x8 space, so that one region of memory can hold approximately 16192 lines of code (it's slightly different because a few lines of code are needed to initialize and end the code list).
Of course, having that many available is impractical. Ugh I'm getting off topic.
This is the kind of thing I'd love to help with Tempus, but I'm kinda swamped with both real-life stuff and things I have to do for a project I'm working on.
Okay, well, I am tired of waiting for my gecko to arrive, so I think I will start recruiting now. I will be amking another thread since it seems like the code will be very portable (hopefully), and I'd like a clean, fresh, and specific intro post.
Okay: I've added the post here. (http://wiird.l0nk.org/forum/index.php/topic,3453.0.html) I hope that some of you who have been helpful can correct my mistakes and point me in the right direction as I work on this! I have no experience in assembly, only Scheme, php, tcl, applescript and perl. Needless to say I am familiar with hex, though. Hopefully some of this experience will come in handy!
This is maybe not the right thread to ask about gpf patches in, but I hope someone responds.
I've actually temporarily abandoned the translation via SD loader into memory as the assembly is too difficult for me and I was unable to procure an interested coder to help. Instead, I've moved on to an executable which interrupts the DVD calls to the IOS and passes them through a script to read resources from SD instead when available. I'll let you know when I've finished this, but it may be another month or two as I'm fitting it in along with the other parts of my project. This is of course providing it works and I don't need to look for yet another method. I technically got it working on a single file, but it's not exactly complete.