ROM Hack Arm9 files.

[raiderscrusade]

As you may be aware, when GTA:CW was released it needed an arm9 file to autosave and fix errors.

Recently, I have downloaded both NRL and AFL Mascot games, and neither of these autosave.

Would an arm9 file be needed to make these Roms autosave?

If so, how would I create an arm9.bin file for the specific Roms?

 

[Vague Rant]

Highly unlikely that this is the problem. What's your flash card?

 

[Crass]

Lol. Google Max Crass Method FTW.

 

[kobykaan]

Firstly what flash card are you using?

Second its usually the ARM 7 that's swapped for save game issues ... GTA had protection to be bypassed also afaik

 

[raiderscrusade]

Flashcart: M3 Simply with the latest YSMenu. Tried on v1.14 but same error.

I have also arm7 patched this and it still continues to have this error. The donor rom I used as Mario Kart if that makes a difference.

 

[FAST6191]

Some clarification appears to be necessary:

ARM9: In commercial games this is the main code of the game. Whether for lack of knowledge about patch distribution methods or some perceived ease of use sort of thing (it gets a bit complex when the DS is involved but not overly so and for reason I mention at the end) some patches are distributed as a complete ARM9 binary which is probably to get a headbutt from the copyright fairy: derived works at best and actual piracy at worst.

ARM7: In commercial games the ARM7 is given over to donkey work (I do not want to say coprocessor but it is not far off). Saving is part of this donkey work though and in commercial games whether by agreement or laziness (we favour the agreement idea) Nintendo effectively provides the ARM7 for all games. This means they are all largely compatible with one another even if they are not byte for byte identical (yes that is an amazingly rare thing to happen in computing).
Swapping out an arm7 binary with one in an older game often provides the API set (not sure if that term is strictly correct) and allows otherwise unsupported games to be patched before proper updates come.
In homebrew the ARM7 can and frequently is used for anything and everything (some programs even reverse the role and use the ARM9 for number crunching and the ARM7 for everything else).

Overylays: As there is no writable memory aside from save sections on actual DS cards an old computing method is used. In theory you can have ARM7 overlays but in practice the ARM7 is common to many games and it is a very simple bit of code so it lacks them.
Nobody really uses overlays in homebrew as we have DLDI which works far more nicely if you work it properly.
As for what they are the DS has a sharply limited amount of memory and by setting some aside you can add features in by "overlaying" them onto this set aside memory. This means features you are not going to use all the time can be called into play at will and dismissed later on and not have to sit there wasting memory.

All three have been documented on many occasions to have things in them that interfere with flash carts be it by happy coincidence, developers intention or a new save type/similar.

They have all been known to be compressed, a mishmash of ARM and THUMB as well as to be comprised of things other than machine code.

 

[kobykaan]

Some clarification appears to be necessary:

ARM9: In commercial games this is the main code of the game. Whether for lack of knowledge about patch distribution methods or some perceived ease of use sort of thing (it gets a bit complex when the DS is involved but not overly so and for reason I mention at the end) some patches are distributed as a complete ARM9 binary which is probably to get a headbutt from the copyright fairy: derived works at best and actual piracy at worst.

ARM7: In commercial games the ARM7 is given over to donkey work (I do not want to say coprocessor but it is not far off). Saving is part of this donkey work though and in commercial games whether by agreement or laziness (we favour the agreement idea) Nintendo effectively provides the ARM7 for all games. This means they are all largely compatible with one another even if they are not byte for byte identical (yes that is an amazingly rare thing to happen in computing).
Swapping out an arm7 binary with one in an older game often provides the API set (not sure if that term is strictly correct) and allows otherwise unsupported games to be patched before proper updates come.
In homebrew the ARM7 can and frequently is used for anything and everything (some programs even reverse the role and use the ARM9 for number crunching and the ARM7 for everything else).

Overylays: As there is no writable memory aside from save sections on actual DS cards an old computing method is used. In theory you can have ARM7 overlays but in practice the ARM7 is common to many games and it is a very simple bit of code so it lacks them.
Nobody really uses overlays in homebrew as we have DLDI which works far more nicely if you work it properly.
As for what they are the DS has a sharply limited amount of memory and by setting some aside you can add features in by "overlaying" them onto this set aside memory. This means features you are not going to use all the time can be called into play at will and dismissed later on and not have to sit there wasting memory.

All three have been documented on many occasions to have things in them that interfere with flash carts be it by happy coincidence, developers intention or a new save type/similar.

They have all been known to be compressed, a mishmash of ARM and THUMB as well as to be comprised of things other than machine code.

that's exactly what I was going to say next! .... erm honest

lol!

thanks FAST6191 for your never ceasing technical input

 

[raiderscrusade]

So, basically, from the above 2 posts, your saying that it would most likely be an arm7 issue, not an arm9 issue?

I knew the arm9 was a file specifically associated with a game, but maybe this file was edited by the creators so it didn't autosave?

I might try arm7 patch with a different Rom.