Separate names with a comma.
Discussion in 'NDS - ROM Hacking and Translations' started by joesteve1914, Feb 17, 2013.
How would I convert an elf file to something like a narc where I could view its files?
Now there are instances of the ELF format cropping up in games and on the DS in particular, however I suspect it is probably not the case here for you.
That said ELF is an executable format and not a container format, this is not to say it can not contain files (I see it all wedged into binaries all the time) but should it have happened here you are not likely to find it useful to "convert" it to NARC or some other container format as the binary will have been built to handle it as such and you will never be able to rebuild it if you convert it.
Still http://blea.ch/wiki/index.php/Elf_linking might be a start, it assumes the ELF files you are dealing with are not too custom though.
I believe you were also told much the same on RHDN.
I was told on RHDN thatI needed to convert it to NANR. Would that work?
You usually don't need to change NANR files in a translation especially not to change the basic graphics/text.
I would spend more time looking at the file itself and less time hoping to find a tool online that do the job for you.
What would be the best format for me to convert it to?
Does objdump run on Windows? That is what they used on that page to see the different sections of the ELF.
and we all are supposed to know the answer to this question??
Why you not check that misterious site for a download link and try it out??
Well I haven't found it on there so I assumed it wasn't working because it was only on another OS, but I
Just found it on another website. If its not good to change it to NANR, why'd you tell me to study the format on RHDN?
Its part of devkitarm which you can find on the devkitpro website
From my long post in RHDN the only part you actually remember is "you study the NANR format"???
If you didn't notice, my post is divided in paragraphs and in that paragraphs i was talking about my work on AAI2 and the animations there that was changed by me without the help of any program.
And by the way, in another post i told you that those files probably contain all what you need for a "room" including text, graphics and music so why i would suggest you to study an animation format that you probably will not use?? Well, if you didn't get it, it was my way to tell you to stop look for a program that will magically open those olz/elf and start analize that file, open it in an hex editor and stare at it till you see between the numbers, see if you find something that look like pointers, if yes, start split those files in the subfiles, check the size of each subfile, what would be the biggest subfile?? what could be the smalles?? Try to find out if the "sequence" of the subfile is always the same for all olz/elf and so on.
Alternative to this??
Start learn ASM, trace the program and see what it does with those files, where do the game put them in the ram?? Etc....
Just give up like i told you already.
Does splitting the files into subfiles require you to know programming?
People are really trying to help you but you are not making it easy joesteve1914. You seem to have locked onto two games that would require either tools to be made, half decent skills or strict instructions to be followed which have been generated by someone with said half decent skills, your tenacity is admirable in a way as many of those aspiring to be ROM hackers would have given up long ago but what you are doing is somewhat akin to asking circular questions and that can get quite frustrating for those trying to help. Suffice it to say most of those trying to help will not have been sitting there with all the info needed, tools necessary and whatever else to allow your work to happen but for some reason are not giving it to you, most of the people trying to help though will know exactly what has to be done but even when you know how to do it all it is a long and tedious process done for many games before and these two games are not interesting enough to overcome that.
From the top then
The idea of executables
The results of programming, especially when it comes to leisure activities likes games, are made all the nicer by being able to expand upon what the system/programming language affords and programmers and systems designers alike collude to make this a possibility. Initially these extras were included in the code itself, later files were not in the code itself but still fairly well wedged within it and later filesystems are used to contain the files which can be referenced at will and changed an awful lot without touching the underlying code. On top of that you can have a filesystem/archive within anything else.
There are benefits and drawbacks to each line of logic and all are used in modern programming. The DS is the first Nintendo handheld to use a proper filesystem in commercial games though, which is nice as nearly anybody can explode a DS ROM into the files that make it up, and for various reasons (the big one being the DS cart/ROM is not visible in memory like earlier systems). This makes the vast majority of DS games hackable by those that are far more at home in a text editor or image editor and also helps those that make programs for the former immensely- our advice seems to be find one of those and hack that for there are loads of nice to hack games worthy of being hacked/translated that are not even being looked at right now. Programmers like this too as it means you do not get bugged to build games or have to make things to build games for those working in your art department every time they want to test a slightly tweaked colour for something.
To that end the vast vast majority of DS games will use the filesystem to store almost all their files and may even have archive formats within that for various reasons, the most prominent of the archive formats is NARC (the one Nintendo made as part of their development kit) though DS ROM hackers frequently find themselves up against custom archive formats, but enough of that for the moment.
Recall that the DS cart it not visible in memory like earlier systems, this means you need to store code to be run on the processor in the actual memory of the DS and that would be where the ARM9.bin, the ARM7.bin and overlays (though by definition they come and go all the time) sit.
Just because you can use filesystems does not mean you have to (and there are some possible benefits to not doing this) and the arm9.bin, arm7.bin and overlays can store more than just instructions to be run on the processor. In "good" programming this would probably mean just numbers and tables for the game to reference to work with the instructions, however you are not limited to this and these arm9.bin files can contain all sorts of data and often do. This can go right up to fairly complex file formats like those made by Nintendo for use with their developers kits.
The problem comes in that when things are included in the binary they are visible in memory and will tend to be referenced by their memory location meaning if you make the file bigger you will send everything after it out of line and that is crashing time for games. If you make it smaller and do not pad it back out you will also see the game crash. This is why you can not "convert" it to NARC and expect to get anything useful out of it unless you are planning to do anything more than rip the assets.
Also most tools designed to decode Nintendo and other known formats will expect the formats to start as they normally do, if you feed it a binary and it sees a few hundred kilobytes of data beforehand it is probably not going to know what to do ("smart" programs have little need to exist on the DS unlike earlier systems so most are not programmed as such beyond detecting compression methods). If it is in the binary you can extricate the file with a hex editor (select it and copy and paste into a new file), a file trimmer or something else and feed it to it if you prefer, all this takes no programming skill to do at all if you know where your file is (which if it is a SDK format you do as it will start with a known string and then probably have the length of the file immediately afterwards). Again though when you put it back it had better be the same size or smaller (if it is smaller you need to add say enough 00's or something to the end of the file to make it back up to the size it was before) or the game will crash.
Should you have made the file bigger it depends upon what you are doing as to how you work around it. Typically this requires fairly high end programming skills for normal files like this and a lot of luck (memory is rather limited on the DS)- when editing things that have to go into memory along with a lot of other stuff (which means any time you edit the binary) you really want to keep the file the same size or make it smaller.
There are programming techniques that the original developer could have used to make this process easier (just because it is in memory does not mean it has to be directly referenced as such all the time) but this is an extra step for the programmer to have taken and likely will not have happened for an actual file. Related to this if the file type is a complex SDK one you might get lucky- by design most SDK files will have pointers in them telling you where various sections are and you could abuse this by making it think the file is way off in the distance and the game will then calculate the new location which is still off in the distance but is now elsewhere in memory*, however most of this is a fixed length even if the thing has a pointer so the programmer might have just said skip it and go to good stuff. There is a further complication known as relative/generated pointers which is kind of like the example for the "if you are lucky" thing that is in the line below but I will avoid that for the time being.
*say my file says the good data is at 0200h which is not a memory location the game would read the 200h and add it to the location of the file in the binary (probably something like 2000000 to get 2000200 in memory)- if that number in the header reads 0020FFFF it will instead look at 220FFFF in the memory which might have nothing in at all in the base ROM but your edited one might have that location house your edited files.
When first encountering programming some people wonder how the console knows to start up and what to do when it does and later how it runs programs. This is a fairly simple affair and depending upon what your computer operates like it may end up taking several steps. As not all computers run a single program and are done it gets to be useful to have a method of storing executable code. Enter the format known as ELF, where I said about "programming techniques above" this is not one of them per se but it effects a similar thing to a filesystem on occasion and you can dump things from it (this would be the objdump program). ELF has a long history in embedded device programming, which this is, and though its abilities are not strictly necessary as this is a simple single program system many developers and developer tools will kind of use it anyway. Whether this is the case here I am unsure as I have not really looked at the game yet, it would not be surprising but it is not that common. Equally just because ELF affords a measure of packing still does not mean it was used here, indeed the programmer inclined to include a file like that of an SDK format file on a system like the DS probably would not have done it like that.
In other words Joesteve:
How long are you trying to translate those 2 games?? If my memory is not wrong it's about 8 months.
Here you will see what you get if you invest about 3 hours using your head and not hoping any program to make the work for you.
I know a translation is wrong, i know i messed the background of the text and i know i messed the palettes as well.
Just proving you that it's possible.
NB: don't even bother to ask how i have done it.
I never said I wanted a program to do it for me.
So why are you so desperate to convert those files into a format program X can handle??
Ballon Fight is much easier to translate than the other and you failed already.
I was checking it while i was at work and in less than 6 hours i found all the files to translate single player game (160 files by the way) and i am checking how i can make sure the translation will be seen on multiplayer as well. The game can be translated easy below 6 days and you are trying since 8 months.
I will tell you just this:
to translate Balloon fight you will need:
- an hex editor
- your head
- MS paint/Gimp/Photoshop or Co (optional)
So, try again with it and if you can not do it, just let it be and forget about both games.
Don't be sad if you can not, you have sure other qualities but you are not cut for romhacking.
Try read THIS, I hope you understand now.
Anyway to give you a little taste, HERE another little video to show you the progress since the last post (no more broken palettes and backgrounds.
Good work, I will post the log of xdelta:
[20:10:16] Original file "4089 - Irodzuki Tingle no Koi no Balloon Trip (JP)(Independent).nds" selected.
[20:10:24] Patch file "intro.xdelta" selected.
[20:10:26] Applying patch, please wait... (don't panic!)
[20:10:26] An error has occurred: xdelta3: not a VCDIFF input: XD3_INVALID_INPUT
Anyway, I believe you want to show me you translated the intro of Tingle Balloon Trip??
And then?? You changed 1 file after i made all the work for you and told you step by step how to do it ( http://www.romhacking.net/forum/index.php/topic,14822.20.html ).
Does it means you are a romhacker now??
If so then stop asking questions in the various forums and do the job on those 2 games!
Or just continue like you are doing now and nobody will ever care about your posts.
Is this enough proof that I am cut out for romhacking?
Wow! Sir romhacker!! That proves everything
As if the pokemon games are not documented enougth.
You want to show everybody you are a romhacker???
Why you not show us something YOU have discovered and not something based on somebody else work?? Let's see....something like the 2 japan only tingle games:
Stop asking any questions about Tingle games and pubblish the complete translation.
Then somebody maybe somebody will give you some credits but for now you are just showing the world exactly that you are not a romhacker.
You know what?? Forget about what i wrote; do as you wish.
I have better things to do as continue this useless conversation.
I'm done. These games are just not worth the frustration. I guess I didn't know what I was getting myself into nor had the skills to do it.
You're right, I'm not cut out to be a romhacker.