Calculating Dungeon-Only Script Addresses (Interaction with ID 20xx)

[Lin]

Thanks to Jigglysaint for an example script, I was able to crack down the reading on it and backtrace some stuff, and debug more stuff to create this. Very simple, and I don't see why I didn't see it earlier. Anyway, here is the formula to get the addresses of the scripts for the things like the bracelet. This will be built into the script editor.

PointerLocation = 20C2C + (dungeon * 2)
Calculate the pointer there using bank 8 (20000)
PointerLocation = CalculatedLocation + (index * 2) //index = second ID byte
FinalLocation = (Calculated pointer at PointerLocation) with bank 0C (30000)

~Lin

[Jigglysaint]

What makes me wonder is why the programmers didn't just have one entire list of events for all the dungeons like how 21xx works?

That reminds me, there are things this game does that is quite forign to what I've seen in Z80.  For example, if the game wants to read the second ID byte in an interaction, it goes 1E 44, and if it wants to read the first byte, it's 1E 42 or somthing like that.  Those two values must be a ram address, but it doesn't seem to make sense.  Then of course we have a thing that turns a value into a pointer, 1A DF 2A 66 6F, which I don't know what goes on there.  I think there must be some special memory routines that are set up for quick access.  Being able to know what does what(and different values do affect certain things) will allow for greater understanding of the game engine.

Edit:  Actually double checked.  1E 42 is the second ID byte, and 1E 44 is the current piece of code excecuting.  Also it's at D540, so I think this means that 1E is wired to get data from that section, making it somewhat of an additional direct page addressing.  More experiments needed, but my guess is that poking around in that section of ram will reveal a bunch of oft used memory locations needed for everything from events to weapons.

[Lin]

Yes, actually the ID does get (maybe temporarily) cached into the RAM. When loading an interaction, what the game does is loops through each Dx40 address incrementing x one time until it hits an address with the value of 00 or E0, in which case it stops. It then sets the value to 01 to indicate there's something there, and loads the first value into Dx41 and the second into Dx42, and uses the values there from then on. The current RAM address's upper byte (Dx) is stored somewhere in FFxx, perhaps FFF8 or something, and taken out whenever needed.

This was all recalled by memory, so something might be a tad wrong. And yeah, I wonder things like that too. The game does a lot of weird things, like jumps to addresses relative to the assembly address depending on a certain value.