Any interest in flashcart rumble hack for Legend of Zelda: A Link to the Past (GBA)

[Phrankles]

I recently created a hack which enabled rumble for flashcarts in Pokemon Pinball R&S, so I have the knowledge to hook pretty much any function to rumble at this point, so long as I know the address of the function to hook. My next idea is to try hacking rumble into a game that didn't already support it, and I just so happen to have read a blog recently that included the function addresses of both Link getting hit and dishing out damage. With this it should be relatively trivial to add rumble under those two conditions, but I am personally not all that interested in this game on GBA. Does anyone care about this? I may mess with it anyway, but public interest will definitely help with motivation.

 

[FAST6191]

As a general rule you will tend to find someone say "do it" when it comes to this sort of thing, and frankly more hacks is more better. You will possibly also get the Zelda fanboys wanting it because why not (though if potential download count matters to you then maybe).

The better questions to ask at these sorts of points are choices between various games; even if it just which you handle first.

Anyway why ALTTP and not Minish Cap? Finding activators is usually not hard thing; find something that is in RAM dealing with that (in this case your health and any enemy health, both of which should be fairly standard cheats* https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial ) and then basically a "my first tracing session" afterwards to get a nice hook for it. https://www.romhacking.net/documents/361/ is old and I would suggest adapting it for no$gba now it is nice and free for the debug version but yeah.


*Zelda games using hearts makes life harder than simple number bar, or possibly bar without numbers. This is as the final number tends to reflect you being able to have half or quarter hearts filled depending upon the game and damage type.
Similarly you might want to take a step back or two from the enemy damage as multiple enemies will tend to have independent health stats, not to mention rumble when you hit a rock (possibly even one of those hidden rocks/walls being different) or an enemy that blocks things might also be an idea.

 

[Phrankles]

As a general rule you will tend to find someone say "do it" when it comes to this sort of thing, and frankly more hacks is more better. You will possibly also get the Zelda fanboys wanting it because why not (though if potential download count matters to you then maybe).

The better questions to ask at these sorts of points are choices between various games; even if it just which you handle first.

Anyway why ALTTP and not Minish Cap? Finding activators is usually not hard thing; find something that is in RAM dealing with that (in this case your health and any enemy health, both of which should be fairly standard cheats* https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial ) and then basically a "my first tracing session" afterwards to get a nice hook for it. https://www.romhacking.net/documents/361/ is old and I would suggest adapting it for no$gba now it is nice and free for the debug version but yeah.


*Zelda games using hearts makes life harder than simple number bar, or possibly bar without numbers. This is as the final number tends to reflect you being able to have half or quarter hearts filled depending upon the game and damage type.
Similarly you might want to take a step back or two from the enemy damage as multiple enemies will tend to have independent health stats, not to mention rumble when you hit a rock (possibly even one of those hidden rocks/walls being different) or an enemy that blocks things might also be an idea.

Thanks for the reply! The reason I did ALTTP was because I already know the function addresses. I am still new to the concept of hooking functions, so my strategy for finding an arbitrary function to hook was to literally watch the memory viewer of mGBA in real time while triggering what I was looking for. This took like 20 hours and I never want to do that again. It did not occur to me that someone has probably already done memory maps for a lot of these games. I guess my question is: Which well documented games would people like to see rumble enabled and for what functions.

 

[FAST6191]

Well documented GBA games if you are thinking as seen on the likes of https://datacrystal.romhacking.net/ or various complete disassemblies are a bit thin on the ground.

Again though most things are available on debugging emulator for minimal effort. Doing what is effectively some kind of human driven equivalent of http://fceux.com/web/help/CodeDataLogger.html (though as of a version or two back no$gba should have something like that as well) would be a nightmare in comparison. There are times where you get to go over code with the proverbial fine tooth comb to find things, this should not be one of them.

Basic idea.
You have three main types of operations a CPU does to memory (or itself in some regards) in the general concepts of computing (and computer security a bit further down the line).
Read
Write
Execute

Consequently there are three main classes of breakpoint, or watchpoint/log point.
Break on Read (BPR)
Break on Write (BPW)
Break on Execute (BPE but also some other things depending upon the emulator/debugger/system)
Better debuggers will give a few more options like if between these ranges then tell me, or abilities to do maths/boolean maths on the results.
Their job is to halt emulation, say this thing just did the thing you told me to watch for, here are all the register states and last 10 or so instructions executed. Log/watch stuff will log stuff to a text file or other output for your later perusal.
Quite useful (especially if you have the fceux style function logger) when doing something odd/rare or just wanting to eliminate -- want to find jump in say Mario then you would get somewhere, start running, idling... basically everything but jump such that it has seen everything else. Jumping will then be the last new thing executed in that scenario and you have your answer.

Anyway you set one of those on something you found with a cheat (or downloaded from a cheat database ( https://web.archive.org/web/20191123185756/https://doc.kodewerx.org/hacking_gba.html for how to decode cheats), get something to read/write/execute it in anger and you have your hooking point, or at least something you might want to follow back up the last 10 or so executed instructions to get a nice hooking point for (debatable for a rumble command you are basically jumping to and back from, if doing something more fundamental to the game's existing logic then you might want to go back -- changed controls, changed damage calculation, maybe adding the different effect based on hidden wall or not, speed, changed audio cue... probably all happen differently to the simple health value or further on from the button press if you start from that instead).

About the only thing I would add is other than cheat values and button presses if it changed a sprite on screen as a part/consequence of what you are really looking for then you want the OAM as that is what controls sprites and is good to hook, if it loads something from the ROM and you can find it in the ROM (many methods here but we will leave that aspect of ROM hacking for now) then breakpoints (obviously read and execute only) work for that too.

 

[Phrankles]

Holy wow. While I was familiar with BPE, I thought this was the only type of breakpoint available. I had no clue you could break on read/write to arbitrary address. That is definitely a game changer. Would have cut down my search to about an hour to find the rumble register instead of 20 to find the register then backtrace what wrote to it manually. I now see what you mean by using cheats to find the function since the BPW can easily be used to find what writes to the address of the cheat.

 

[FAST6191]

Yeah even if I hadn't known about such things I don't think I would have had the patience to try to catch something and narrow down the possibilities for that long.
Now you know, and know you have the patience where necessary, you can even possibly start branching out into more conditional versions, or possibly some kind of activate/disable option.

Also again it is for vba-sdl-h rather than anything fun like no$gba debug or https://wrongbaud.github.io/posts/ghidra-debugger/ but the old guide to it can give some idea of what is out there, what people like to do with them and then what you might be able to handle with it
http://web.archive.org/web/20130215155212/http://labmaster.bios.net.nz/vba-sdl-h/
and http://www.coranac.com/tonc/text/asm.htm in case you are still going instruction by instruction back to reference manuals.

fceux is the gold standard for debugging consoles/debugging anything that isn't PC (fceux is lovely but compared to some of the things IDA, and to a lesser extent the PC aspects of ghidra mentioned above and radare2 to round out the list of the big three, on PC can do... not even close) so not all emulators will match that, indeed the GBA stuff is probably closest in general worlds. If you do find yourself pondering another system and its normal debug options are lacking you might want to wander through the tool assisted speedrunning world as a good debugger there is... kind of the whole point actually.

 

[Issac]

Rumble support for Zelda games? Heck yeah! I think that would be very much appreciated by fans

Especially appreciated if you manage to flesh it out a bit, with fun patterns depending on what happens on the screen:
low-rumbling heartbeat if you have the low-health warning beeps, intense rumbling maybe with an interesting pattern when activating a big spell and so on.

 

[hippy dave]

low-rumbling heartbeat if you have the low-health warning beeps

Ooh, bonus points for disabling the damn beeps

 

[Zense]

My few thoughts are that if this is going to be for a handheld system, then maybe battery consumption is something to consider. In the example of rumble every time you get hit or hit something, or for as long as you have low health, then maybe make those a choice? Still I'm not sure how much battery life the rumble motors effectively drain.

A more simplified version would be to add it to certain events or things that don't usually happen often. For Zelda I can imagine whenever some large obstacle is moving or a castle emerges from the ground or a large gate opens. I do also think having rumble for bomb explosions could be a nice effect.

Those are my two cents, and you can take them or leave them as you prefer.

 

[FAST6191]

Ooh, bonus points for disabling the damn beeps

If it is a beep and not a sine wave (GBA stuff is still with a foot in the old school methods) then you might be able to overwrite it with sappy or something.

Alternatively all the tracing stuff up above with health values and whatnot from cheats. Chances are somewhere in that will be a "if health less than* then beep" type setup you can just NOP out (usually cmp, compare, and bne, branch if not equal, commands, with the results of the branch fiddling with the very specific areas of GBA audio handlers so you don't even need to check them all). You might not even have to lose health to find it if it checks every frame (not the best programming method but wasting an interrupt on that might also be a dubious act).

*again half hearts/quarter hearts mean you get to double or quadruple what the hearts value is, and as it presumably does not want your 3 heart new player to be beeping all the time it might do a subtraction/division from max health. This is all academic though if you are NOPing out a branch so it does not do something.

 

[Phrankles]

Alright, I have decided. My next project is gonna be adding rumble to Minish Cap, which is much more interesting to me as I have never played this game, and . This is possible thanks entirely to @FAST6191 , who in only a few comments has done more to improve my hacking skills than I did on my own in tens of hours. Plan of attack is to the hook the sound function and trigger various rumble patterns depending on the sound being played.

 

[Phrankles]

My few thoughts are that if this is going to be for a handheld system, then maybe battery consumption is something to consider. In the example of rumble every time you get hit or hit something, or for as long as you have low health, then maybe make those a choice? Still I'm not sure how much battery life the rumble motors effectively drain.

A more simplified version would be to add it to certain events or things that don't usually happen often. For Zelda I can imagine whenever some large obstacle is moving or a castle emerges from the ground or a large gate opens. I do also think having rumble for bomb explosions could be a nice effect.

Those are my two cents, and you can take them or leave them as you prefer.

The battery drain is definitely significant, to the point that it causes voltage drops on cheap batteries in my SP (the battery light becomes a green/red flasher on every rumble lol). Until now I did not have the knowledge to relatively easily add menu functions, and I really did not want to continue reverse engineering PP:R&S to find out how. With the knowledge this thread has given I now see path to adding menu options like this.

 

[djedditt]

I would recommend getting a rumble flash cartridge from insideGadgets as well for testing compatibility. Their cartridges and flasher are quite popular and was the first to add a rumble motor. If the implementation of rumble code is done correctly, it should work on all rumble cartridges (given save type is compatible, or the game can be patched to SRAM for example).

https://shop.insidegadgets.com/product/gba-32mb-256kbit-fram-save-flash-cart

Some people noticed that your Pokemon Pinball: Ruby & Sapphire rumble patch doesn't work properly on insideGadgets' rumble cartridge. I haven't looked into EZ-Flash's code much but it was suggested that they partially use custom commands for the ODE cartridge. That shouldn't be necessary and it would indeed break compatibility with other flash carts, as well as emulators that allow controllers to rumble when the rumble motor is addressed.

I wrote a very rudimentary example in C of how to drive the rumble motor in a way that is compatible with all rumble cartridges, the essence of which I also use for my own rumble patches out there already. It might be useful to you:

https://github.com/djedditt/gba-rumble-example

 

[Jayro]

I'm interested, if it's compatible with the single-game flash carts offered at https://shop.insidegadgets.com/

 

[FAST6191]

The battery drain is definitely significant, to the point that it causes voltage drops on cheap batteries in my SP (the battery light becomes a green/red flasher on every rumble lol). Until now I did not have the knowledge to relatively easily add menu functions, and I really did not want to continue reverse engineering PP:R&S to find out how. With the knowledge this thread has given I now see path to adding menu options like this.

Menu options I would usually work up to from cheat style approaches, then intro/trainer style, and finally to editing menu items, though leaping directly to menus is not necessarily jumping in at the deep end (maybe even less if you did some options menu cheat activator style things by saying pressing this off and on turns it on, the menu option below it deactivates it).

Anyway said approaches.
Cheat cart style.
Here every frame will be a check on the buttons/their debounced section (easy enough to add to vblank routines).
If it sees the combo it wants then in cheats it will do the cheat but here you would probably do a memory store of a value in some free bit of memory.
The rumble commands work as normal but before they fire they would check that area of memory to see if they are working or not. If you saw the discussion on GB player games and adding things that had rumble for that on a cart then Nintendo did the same thing.
Nothing will appear on screen unless you do further stuff similar to what follows but it will be a selectable option without needing to have multiple versions of a ROM on someone's cart.

Intro style. The classic "how to find the binary" thing from GBA assembly hacking* means you know where the first few instructions it runs after power on (or selection from a flash cart). Add your own jump in a suitable location and you can have a selection menu if you wanted (make it a standalone program if you want) and from there the same idea with the flags and checking.

Menu stuff works much the same as the earlier breakpoint stuff, however you go for new functions and work back to a more general thing, expand that and add an option. Different schools of thought on menu fiddling though the main three are find some area of memory it changes (can be useful for other things -- text speed changes can be how cheats make super fast or slow text) and do normal tracing, follow the button press on up through the system, or do the new execution thing as mentioned in the fceux link (and I guess the vba-sdl-h link, and no$gba changelog also included such things in a recent update from what I saw).

If this was on the DS (or anything that loads code into RAM, which is to say anything on a floppy disc, CD/optical media or basically with a filesystem like the DS, though strictly speaking it is not a feature of filesystems just a coincidence) then you might have been able to alter the binary in memory and have some other fun there.
The GBA does occasionally copy code to RAM to run super fast routines but subverting those for your rumble patches is a dubious plan.

*I have a nice worked with pictures option in the guide in my signature but short version is the first byte of the ROM is a jump, usually to the end of the header. Somewhere after that (usually it is a bit of IO) will be a jump to a new part of memory also in the ROM region (08??????). This new part of memory is the binary and depending upon what goes you will want to jump before this and back to it afterwards. Main exception being if the game decides to wipe memory before it gets going, which would wipe out any memory twiddling you did in your intro/trainer/menu.

 

[Baggins]

Awsome. SOmeone should do the Metroid games too.

 

[artiehead]

Awsome. SOmeone should do the Metroid games.

I found this thread because I was thinking last night in bed how cool it would be to have rumble on old games, specifically Metroid Zero Mission which I just started playing. Awesome someone is already working on something similar!