Author Topic: hack works on all emulators but on no flashcards. any possible solution? (Read 6718 times)

MaverickZero · « **on:** February 08, 2018, 07:50:26 am »

i made a Final fantasy V hack for the gba, wich gives only new sprites to the characters, and since the game is compressed, i had to use tools like nlz gba and then repoint the new spritesheets since most of them were bigger than the old one.
the game is working perfectly on pc and android emulators, but once i or my friend tried it on our flashcard, it crashes everytime the game attempts to load the sprites, so in pause menu or in battle...
could this have something to do with where i placed the new sprites?
i hope this much work of respriting wasn't for nothing

mz · « **Reply #1 on:** February 08, 2018, 09:40:39 am »

Have you tried changing your new position to one that's correctly aligned?

I've never done anything similar to this, but I'd make sure that the new position is a multiple of 4 (or 2, maybe...)

Besides that, I have no idea.

weissvulf · « **Reply #2 on:** February 08, 2018, 03:31:18 pm »

What mz said is the most common issue I've seen that makes a game run on emulators but crash on real hardware. Specifically, the op-code 'load word' (which loads 4 bytes into a register) requires that the read location start at a multiple of 4 (0x0,0x4,0x8,0xC). Since that's a limitation of MIPS processors, it's usually not enforced by emulators running on different processors. A compressed graphic is likely to have data in a header needs to be 'aligned' like this.

MaverickZero · « **Reply #3 on:** February 08, 2018, 04:38:57 pm »

so in order to get it work, the new adress has to be a multiple of 4?
did i get that right?

but the code is reversed when i repoint so...
does the forelast number have to be a multiple of 4 then?
i'll just try both.
Thanks mz and weissvulf, you've both been great help

February 08, 2018, 05:19:43 pm - (Auto Merged - Double Posts are not allowed before 7 days.)

that doesn't seem to solve the problem

the new adress where it is pointed to is 0x858944 so...
anyone an idea what might help?

weissvulf · « **Reply #4 on:** February 08, 2018, 05:29:47 pm »

You might try narrowing down what is causing the problem by reversing all modifications except for 1 small sprite and seeing if the crash still happens. If it does, you at least know where to look for a solution. If the crash doesn't happen, add back your modifications 1 by 1 until the problem shows up. Narrowing down the issue is always a good place to start on a solution.

MaverickZero · « **Reply #5 on:** February 08, 2018, 05:35:52 pm »

the thing is, all i do is importing the new spritesheet and repoint because it is bigger than the old one, those are actually all steps...
but somehow it worked when doing it with nlz gba, but it imported the sheet wrongly, the characters legs were missing when spellcasting and they were partly screwed when they were dead.
but as i imported it correctly, the very same crash happened.
and i really don't even know what may the cause of this.
and if you meant that, i can say that i try sheet for sheet but it crashes already on the first one $:-\$

mz · « **Reply #6 on:** February 08, 2018, 07:31:12 pm »

Maybe you're overwriting important shit like code or a pointer table or other compressed stuff.

Maybe the older position was referenced in many places and that program only updates one.

In any case, just insert one sprite sheet until you figure out what's wrong. Not one by one or whatever, just one, stop wasting time or corrupting even more ROM by inserting unnecessary (at this point) stuff.

Also, try using a more accurate emulator like mGBA.

MaverickZero · « **Reply #7 on:** February 08, 2018, 08:33:26 pm »

ok you're right, i'll tr, it out and thanks for your advice

FAST6191 · « **Reply #8 on:** February 09, 2018, 04:38:33 am »

Do bear in mind there are usually two different versions of any given decompression function for the GBA, usually split between VRAM safe and WRAM. Alignment is the big one for this
http://problemkaputt.de/gbatek.htm#biosdecompressionfunctions has more if you want technical. http://members.iinet.net.au/~freeaxs/gbacomp/#BIOS%20Decompression%20Functions has more if you want slightly less technical.

I don't know what NLZ would have done offhand (I usually use GBAcrusher, which is on the second link above, and go manual for the GBA, and possibly on the DS as well but there are other choices for that one).

I would have thought most of the emulators would have minded but I guess not. But yeah try mgba or possibly no$gba (its debug version might throw an error message about it). If it works in an emulator though then it should be able to be made to work on hardware as most emulators, while maybe not being crazy crazy accurate, don't suffer the same pitfalls as some of the NES and SNES offerings; most of the inaccuracies in GBA ones being in the timings not being as tight, headers and such not needing to be there and I guess this sort of thing with alignment and initialisation.

Squall_FF8 · « **Reply #9 on:** February 09, 2018, 08:11:04 am »

Hey MaverickZero, I'm working primary on FF5 both SNES and GBA versions. While for SNES things are fairly known, GBA one is quite a blank zone. I've seen few individuals with some/extended knowledge, but no central place to keep their findings

I will be glad if we work together. My main project is my Viewer. All the GBA things implemented are mainly discovered be me (with 0 asm, just statistical searches based on SNES), so if you find something interesting I will be happy to share what I have found.

Funny but currently I'm searching for the master table that hold info on job sprites (tiles, palettes and maybe tile-map of the sprite) witch seems exactly what you are doing atm. Could you share location and format of that table? Also one or 2 examples with address of a sprite tiles/palette?

P.S. Have you been a member of slick?

MaverickZero · « **Reply #10 on:** February 09, 2018, 01:08:35 pm »

WOW

!
Fast6191 you were right as always!
No$gba gave an error message
it said:CPU - Bad operation
Bad SWI Number.
i really don't know what that means, i have no hacking experience at all.
i thought graphic hacking would be easier...
do you or anyone know what that means or how to solve that problem?

Quote from: Squall_FF8 on February 09, 2018, 08:11:04 am

Hey MaverickZero, I'm working primary on FF5 both SNES and GBA versions. While for SNES things are fairly known, GBA one is quite a blank zone. I've seen few individuals with some/extended knowledge, but no central place to keep their findings

I will be glad if we work together. My main project is my Viewer. All the GBA things implemented are mainly discovered be me (with 0 asm, just statistical searches based on SNES), so if you find something interesting I will be happy to share what I have found.

Funny but currently I'm searching for the master table that hold info on job sprites (tiles, palettes and maybe tile-map of the sprite) witch seems exactly what you are doing atm. Could you share location and format of that table? Also one or 2 examples with address of a sprite tiles/palette?

P.S. Have you been a member of slick?

first off, i hack the european version, so if you still want everything i found, i would be glad to share it with all ff fans

.
please tell me if you are making a viewer of the us version or if you want the european data so i can send you everything in your thread, since you linked it already here.
i would be glad to work with you together as well

p.s. a member of slick?
i don't really understand what you mean

Squall_FF8 · « **Reply #11 on:** February 09, 2018, 02:07:20 pm »

European or not it doesn't matter. In general FF5 keeps internals the same (starting with SNES) so the difference is only in the file offset. Sharing the info in the Viewer thread will be the best!

Currently the Viewer supports us version. I had plans to make it more flexible and support any GBA version, but so far it seems no much interest in GBA so I didn't implement it (it will require significance internal change). Regardless if you search info on something that I had implemented, we will easily find where it is the European.

P.S. Sorry slick is short for http://slickproductions.org/forum/ - the best place for FF5 info! Unfortunately the site is down for a month so I'm afraid it will never be on again

FAST6191 · « **Reply #12 on:** February 09, 2018, 02:16:15 pm »

SWI = software interrupt, aka the technical term for what most people refer to as the BIOS calls.

I am not sure what caused it -- had you edited the assembly it would be one thing but just pointers and dumping graphics in a blank section.

I am back to the recompression used was not a VRAM safe one.

MaverickZero · « **Reply #13 on:** February 09, 2018, 05:25:27 pm »

seems like you'll need some programming skill to do that, or did i get the tutorial maybe wrong?
is there any vram safe compression tool, without the need of asm or c coding?

FAST6191 · « **Reply #14 on:** February 09, 2018, 07:15:36 pm »

Yeah the gbacrusher tool has it as an option, as do many of the more complete compression tools for the GBA and DS.

For the most part you have the graphics sorted, the pointers tweaked and the stuff done. Just sounds like you need to overwrite it with the newly VRAM safe compressed version of the graphics.

weissvulf · « **Reply #15 on:** February 09, 2018, 08:18:59 pm »

Cross referencing the Headspin's link with the No$GBA, it looks like the different formats are decompressed though distinct BIOS routines. If the compression method is not formatted properly for the BIOS routine that it is sent through, it makes perfect sense to me that it would produce a SWI error. Like FAST6191 says, the different decompression 'paths' seem to have different alignment requirements. Neat info!

For example, it says of the SWI 10 routine:

Quote

r0 Source Address (no alignment required)
r1 Destination Address (must be 32bit-word aligned)

For SWI 16, it says:

Quote

r0 Source address (must be aligned by 4)

MaverickZero · « **Reply #16 on:** February 10, 2018, 07:45:51 am »

wow, FAST6191 you are like zero in megaman x3...
every time i am doomed, you come through the roof and safe my butt.
in other words, it worked

thank you! you saved FFV once again for me

Squall_FF8 · « **Reply #17 on:** February 10, 2018, 09:03:34 am »

Quote from: MaverickZero on February 10, 2018, 07:45:51 am

in other words, it worked

Congratulation! What exactly was the problem?

BTW FF5 uses 2 table to store reference to compressed jobs tiles... Did you change both tables?

MaverickZero · « **Reply #18 on:** February 10, 2018, 09:24:23 am »

yeah, gba graphics editor automatically repoints it to both, it was like FAST6191 said, ffv used vram safe compression instead of wram.

Squall_FF8 · « **Reply #19 on:** February 10, 2018, 09:54:50 am »

Very interesting. Probably I should start studying ARM instructions

Is there something that you need help with or you need info on internals of FF5?

BTW Do you have any clue on tile-maps that compose the character jobs? After decompression it seems we get a pile of ties and without map we cant construct the right image ... Fortunately the first 12 tiles make 2 frames of 2x3 but after that things get complicated.
It seems all frames are made by 57 tile. SNES uses only 49 tiles to make 12 frames. I'm not sure does GBA uses same 12 frames ...