ROM Hack Golden Sun TLA editor & GBA audio data ripping tool

[cawwe123]

but some of hack roms can resolve that?..if you have a hack of golden sun..i should try what is the differences..
how long the progress of the golden sun hack?no beta?

 

[granville]

The problems Golden Sun has in that phone emulator is a bug in the emulator, not the rom. Hacking the rom would likely do no good.

 

[FAST6191]

Actually there may be a way although agree it is fairly complex and without testing to know then it may not even work.

The GBA has video memory, there are background and there are sprites. Each has a priority and there are a bunch of things that can be done ( http://www.coranac.com/tonc/text/video.htm , http://www.cs.rit.edu/~tjh8300/CowBite/Cow...ware%20Overview and http://nocash.emubase.de/gbatek.htm#gbalcdvideocontroller ). It is fairly complex and so emulation can occasionally get it wrong (ever had to set background priorities on a SNES emulator, same idea) and sometimes completely overlooks it.

Video is defined by various memory sections (see gbatek above) which are naturally writeable by the GBA (and especially an emulator), you can tweak these with a memory editor or a cheat (which you can hardpatch into the rom with GBAATM http://www.gbatemp.net/index.php?showtopic=99334 if your emulator lacks the ability).

The characters are most likely sprites, the text is most likely a background and the actual "background" is almost certainly a background). Mess with the priorities and display.

 

[Atrius]

There you go, I still need to do a lot of back end work before I can actually turn the text viewer into an editor, but at least I've got the compression algorithm now. I tested it on a few lines from the game, and I think my algorithm actually shaved a couple bits off of some of them. Of course I'll also make Item/Enemy/e.t.c. names/descriptions/e.t.c editable from their own menus too to make things easier.

 

[mrfatso]

hoo hoo nice one

haha, maybe one of these days, i be able to have excalipoor

 

[granville]

Errr, wasn't Excalipoor from Final Fantasy 5? There was a REAL Excalibur in the Lost Age.

 

[mrfatso]

ya i know that but if i have the power, i wish to rename all default weapon as excalipoor or some other weak sounding weapon

 

[Atrius]

How about an update on what I've been working on so you all know the editor isn't dead yet.


The way some of GS TLA's data is arranged is very peculiar, yet very helpful at the same time. At the end of the ROM file there is a large array containing various types of data ranging from graphics, to the games code itself. The new feature of the editor will allow you to browse through all of this data.

It's still in very early stages of development, so it will likely be improved before version 0.3 is released.

Viewing a palette for a map

A tileset, eventually you'll be able to load palettes with them so they aren't just black & white.

A menu graphic

A graphic for one of the Pierrot classes attacks. Despite not knowing what this was the data browser managed to identify at as being compressed, and decompressed it for us, how nice of it. Using the image viewing mode we can see the actual graphic.

Using the Hex option (which will eventually be a full fledged hex editor) on the data browser we see some unidentified data here. To a trained eye this looks a lot like map data, and that makes sense considering what it's surrounded by. The interesting thing though, is that the editor couldn't identify it as map data which means it isn't actually used in the game at all. Mmm... I do believe the unidentified data below it looks a lot like palette, and tileset data that isn't used at all either. Looks like despite having a map viewer, we still haven't seen all of the maps hidden away in TLA's data.



Also you may notice a value on the top bar of the editor, "1159.57Kb" or something around there. You may have also noticed that this was present in v0.2, but always read "0Kb" Well, now that the automatic repointing system (which assists in the editing of compressed data, ensuring it doesn't accidentally overwrite other data in the game) is finished and working, it keeps track of the amount of empty space in the ROM it has to work with. Golden Sun TLA in fact has 1159.57Kb of detectable empty space to work with, in contrast the original Golden Sun only has 67.36Kb.



Also, this isn't something in the editor yet, but I've been working on the compression algorithms so I could compress things into the format some of the games data is in, and managed to use them to create a new cutscene.

All text editing for this was done in the editor.

 

[Velveteer]

Haha, that cutscene's brilliant. It looks like the program's really coming along. Hopefully we'll be able to see some proper GS ROM hacks one day.

 

[FAST6191]

@Atrius very nice work as usual and you say 64 odd K: the GBA can/does address the entire 32 meg space but even if you wanted to keep it under 16 megs for the sake of things like the 3 in 1 to expand the rom you just need to point an address to it and make sure something is there.

All versions of the original golden sun were 64Mbit as well so I would argue you in fact have an entire 8 megabytes (the entire game again for those following along at home) and whatever you can scrounge from within the rom itself.

 

[Atrius]

It's just counting the space that's available in the ROM at it's current size, of course you'll be able to expand the ROM to a full 32MB. It would make sense to have it count that extra possible space as well though, wouldn't it?

 

[Atrius]

Time for another update on a cool new feature of the editor. The more I work on the Data Browser feature the more I come to love it, It is without a doubt my favorite feature of the editor so far.

What is it doing here you ask? Quite amazingly, it's scanned through a section of the games code and automatically detected pointers to data. This means no more tedious searching for all of the data that hasn't been located yet, now just go through the lists and figure out what's what! Anyone whose performed low-level hacking should be able to appreciate exactly what this means, at this rate the editor will practically do all of my hard work for me! If only I could get it to generate compression algorithms... It was even nice enough to match what's already been identified with a provided list, and label it.

Not only that, but while searching for all those pointers it keeps a tally of code functions it scans through. This means that it can track where the data is accessed from in the game's code, I'm sure our more seasoned hackers can think of plenty of uses for that kind of information.

Using these new features, I've easily located Djinn, Summon, and several other bits of miscellaneous data so far.

 

[Sterling]

Hot damn Atrus!

Thanks for programming this bit of fine engineering!

 

[FAST6191]

I have been known to use pointers for simple things but that is taking it to a level I did not think I would see. Nice work as always Atrius.

 

[Shinryuji]

This looks absolutely amasing, Atrius! What you are making is truly impressive, but one question, do we need the .NETFramework to run this? If not, then brilliant! If so, then damn... (Is a mac user

)