Remember when @Arch was making FireShell, and he tried repointing the Event Pointer table, but only the indices that were meant to be events could be used for events? Or rather, that they are even automatically loaded for the chapter? Change this routine to read off of some table so we can make an arbitrary number of events.
1 Like
I checked some of your code and have a few questions - bear in mind that I’m pretty new to all this stuff. For the sake of an example, I’m using the give all items (with wipe) as reference.
First of all, the directives are all unknown to me. What assembler do you use?
What registers are commonly available for use? I see you pushed r1-r5 and r14 to the stack, but why did you pop the original value of r14 into r0?
Values starting with a hashtag are immediate data, correct? Values surrounded with brackets… Refer to on-board memory?
What is the function of strh, ldr and ldrb?
Last, is there documentation of FE-relevant offsets and freely usable areas of memory available?
It might be a while before I’m able to get something useful done, but I’m looking forward to learning more so please be patient with me 
devkitPro ARM. Icecube does his stuff directly in a disassembler so idk. But devkitARM is standard for most of us.
To bx to. You can’t bx to r14. A common pattern is
push {r14}
@code
pop {r0} @or r1 if r0 is a return value
bx r0
This is seen in the in game code as well.
If you’re familiar with c++:
mov r0, #0x1 is r0 = 1
ldr r0, [r1] is r0 = *r1
store halfword (strh r0, [r1] → short* r0 = 0xSOMETHING; *r0 = r1), load word (ldr r0, [r1] → int* r1 = 0xSOMETHING; int r0 = *r1) load byte. Too lazy to type out an example again.
Browse around. FEU has searching for most things. We have a few things strictly documented, but most is scattered in the appropriate hacks… or search this forum. Search is great here, unlike SF.
my assembler is whatever build of gas comes with devkitARM
also
bx lr is perfectly valid in thumb
actually a good pattern (you won’t see this in the ROM for reasons I don’t know) is that you can do
push {lr}
...
pop {pc}
and it accomplishes the same thing as the other pattern except two ops shorter
(lr and pc are aliases for r14 and r15, if you couldn’t tell. also sp is an alias for r13)
Oh, right, oops I was thinking of “you can’t push {pc} or pop {lr}”
So apparently the code for enemy ranges was sitting unused in the FE7 rom this whole time:
Routine seems to begin at 0x801C65C, called it with ASMC just to test it out.
Problems: Can’t get dismiss it with B, screws up minimug palettes, and squares are opaque. But it’s a start.
7 Likes
I fucking knew it!!! All these years people thought I was crazy… Well, they probably still do but who cares?
Ryrumeli got it to work in FE8 once upon a time, so it makes sense that the leftover code would be in FE7, too.
2 Likes
That’s surprising, I couldn’t find the routine in the FE8 rom.
Okay, enemy ranges are now working perfectly! All I need now is to bind it to Select, or at least get the menu option to show up.
EDIT:
And now I have it working in FE8 too!
7 Likes
That feature contains many cool beans. I approve.
Totally going to use this in EN. Great stuff!
1 Like
Binding it to Select turned out to be simple (for FE7, at least). If anyone wants to try it out, just write 05 F0 F8 F8 2A E0 to $1C3E0. FE8 doesn’t seem to use the Select button so I had to improvise a bit. The FE8 patch is working but not ready for release.
The problem is that calling the routine with select instead of the menu does something to screw up the minimugs. Notice that in the two screenshots I had before, info windows like terrain and unit data are disabled while enemy range is active.
Now we get this:
1 Like
Can you write a brief description of how the binding works? This is something I’ve not known about how to do.
Sure, it’s simple enough. I started with a break on read on the IO pointer (0x08B857F8 for FE7, 0x0858791c for FE8).
Right below the break you can see what it’s checking for (AND 0x1 checks for A button, AND 0x4 checks for Select, AND 0xF checks for A+B+Start+Select). From there you can do whatever you want after the branch.
For FE8 it was harder because there is no check for the Select button. So I changed the Start check to Start OR Select, and checked which one it was later.
…Wait, what? Why are those ROM pointers instead of being in the IO block (0x04xxxxxx)?
Because in order to check the IO block, the routine must first
ldr r0 =#0x8b85748
ldr r0, [r0]
to get the RAM address where key inputs are stored (0200:0000 region). As for why it checks there instead of directly from the 0400 region, I don’t know but probably because there’s a difference between key press, key hold, and key release.
the key pointers are copied from 0400:xxxx to 0200:xxxx every mainloop cycle for a reason i couldn’t figure out
1 Like
It might be because of some quirk of how the IO hardware actually works
or maybe it’s just to make debugging easier idk
As for the extra level of pointing via the ROM, probably because it was written in C and the compiler didn’t optimize something very well.
This may be too ambitious but I think it would speed up things a lot faster if someone expanded the data to include all characters and classes from the GBA games into one FE7 or FE8 rom. I simply stopped work on my game because I screwed all the hex up. Had all my characters, faces, items, classes ready from the GBA games I just couldn’t expand my rom right. I’td be awesome if people good at adding that data with hex editor could collaborate into one super rom with all those characters and stuff so we all can all start our hack using it as our base rom. Of course if you need more than all the GBA content you could always expand it again but I’m sure some of us hate adding Marth, Roy, even a custom Ike into our every hack we make and expanding the character data wrong.
Point is several of us could all work on inserting tons of classes and characters on one rom and making it available to all as a “starter pack” rom so to speak. If we want Moulder, Roy, Eliwood, Gerik, Bartre, and Myrrh in the same game we download the super rom bc theyre all already in it. With all the expanding already done we can spend more time on other aspects of the game because expanding is nothing but busy work (personally I get headaches when we start talking hex and free space ranges. Of course it may cause issues if it got too big
3 Likes
Yes. Yes we do. Let’s stop doing it.
6 Likes