jp 1.0 index 219 setup notes/questions

Line 565 in doc: 0x3FDBEC (JP 1.0 address "Menu Type Open"): if this is 7 or 14, then OoT save menu can open while debug menu is open
Line 566 in doc: 0x3FDBEE (JP 1.0 address "Debug Menu Open") want this address to be either 1 or 2 to open debug menu



Length Array starts at 0x1CAEC8
Message Array starts at 0x1CAE00

Soar Cursor Index (JP 1.0 Address 0x3FDC40)


Want Soar Cursor Index = 219 for this setup


Length Offset = 219*2 = 438

So we should read the Length from the 2 bytes that start at 438 bytes after 0x1CAEC8.
So we should read the Length from the 2 bytes starting at 0x1CB07E.

For me, the Length value is 0x008E which is 142 in decimal, this is the length in characters and
each JP character is 2 bytes, so the length of the Message will be 284 bytes.



Message Offset = 219*18 = 3942

So we should read the Message from the 284 bytes that start 3942 bytes after 0x1CAE00
So we should start reading the Message from 0x1CBD66



---------

"Buffer A" is 200 bytes and starts at 0x3FCFE0 (this is a bit before Current Message Content II (aka "Buffer B") and Buffer A should have the same values as Buffer B when a textbox comes up)

Buffer A starts at 0x3FCFE0 and Buffer B starts at 0x3FD51C, so Buffer B starts 1340 bytes after the start of Buffer A

---------

Text Instruction Counter is stored at the 2 bytes starting at 0x3FD5E4 and Buffer B starts at 0x3FD51C, so it starts 200 bytes after the start of Buffer B.

The first 2 bytes of Buffer B are already filled in from the JP equivalent of "Soar to ", so the value of Text Instruction Counter will be obtained from bytes 199 and 200 (if I define "byte 1" to be at 0x1CBD66 which is the start of where we read the Message from based on the Message Offset above), so starting 198 bytes after 0x1CBD66.

198 bytes after 0x1CBD66 is 0x1CBE2C



So the value of Text Instruction Counter will become the value that the address 0x1CBE2C has. For me (i.e. based on what Bizhawk RAM Watch says for my current savestate, which has successfully been used to bring up the Debug Menu using this setup), this will give Text Instruction Counter a value of 0x036A which is 874 in decimal. (This DOES happen, so this is correct!)


On JP, the main text processing function is now copying starting from (Start of Buffer A) + 2 + 2*(Text Instruction Counter), so on JP 1.0, it starts reading from 0x3FCFE2 + 2*(Text Instruction Counter) because Buffer A starts at 0x3FCFE0

0x3FCFE2 + 2*(Text Instruction Counter) = 0x3FCFE2 + 2*874 = 0x3FCFE2 + 1748 = 0x3FD6B6

The first 2 bytes starting at Buffer B were already filled, then the next 284 bytes were filled, so a total of 2 + 284 = 286 bytes are filled. So the text processing function starts writing at 286 bytes after the start of Buffer B, which is 286 bytes after 0x3FD51C which is 0x3FD63A

So the text processing function starts reading from 0x3FD6B6 and starts writing to 0x3FD63A and will proceed to do this character-by-character (I think? i.e. 2 bytes at a time on JP) until a terminating character is found.


Buffer B starts at 0x3FD51C and Menu Type Open (2 bytes long) starts at 0x3FDBEC and Debug Menu Open (2 bytes long) starts at 0x3FDBEE, so Menu Type Open is 1744 bytes after the start of Buffer B and Debug Menu Open is 1746 bytes after the start of Buffer B


If 1750 bytes after the start of Buffer A (i.e. 0x3FD6B6) gets written to 286 bytes after the start of Buffer B, then the 2 bytes starting at 3208 bytes after the start of Buffer A get written to the 2 bytes starting 1744 bytes after the start of Buffer B (Menu Type Open) and the 2 bytes starting at 3210 bytes after the start of Buffer A get written to the 2 bytes starting 1746 bytes after the start of Buffer B (Debug Menu Open).

Buffer A starts at 0x3FCFE0
Buffer B starts at 0x3FD51C

So 3208 bytes after start of Buffer A is 0x3FDC68
And 3210 bytes after the start of Buffer A is 0x3FDC6A

So the 2 bytes starting at 0x3FDC68 get written to the 2 bytes starting at 0x3FDBEC (Menu Type Open)
and the 2 bytes starting at 0x3FDC6A get written to the 2 bytes starting at 0x3FDBEE (Debug Menu Open)



For me, the 2 bytes starting at 0x3FDC68 originally have value 0x0000
For me, the 2 bytes starting at 0x3FDC6A originally have value 0x0008

Observation 1: 0x3FDC38 is the address for Item Screen Slot, but 0x3FDC68 (which is 48 bytes after the address for Item Screen Slot) appears to have the same values/behavior as the Item Screen Slot address. Why? I'm not sure.

Observation 2: 0x3FDC6A is the Soar Cursor Index shifted by 31 (decimal) in the positive direction. Why? I'm not sure.

After the pause menu stuff, the 2 bytes starting at 0x3FDC68 have value 0x0000 (because item cursor is on ocarina) and the 2 bytes starting at 0x3FDC6A change to 0x00FA once the Soar Map comes up

While the Text Instruction Counter is originally 0x036A, as expected, it changes several times before the Debug Menu opens (and ultimately 0x3FDC68 and 0x3FDC6A, which are the addresses I would expect to write to the Menu Type Open and Debug Menu Open address (and they indeed do that if you don't do the pause menu stuff for the setup), end up not writing their exact values onto Menu Type Open and Debug Menu Open). I'm not really sure what is going on to make Text Instruction Counter change so many times.





-----------------------------------------------------------------------------------------------------


NOTE: 0224 is the JP equivalent of the control code D4 (I did not know this and that is why I was so confused at the start of this conversation lol)




ImbuedToday at 6:19 PM
Can someone explain the pause menu/control stick portion of the jp 1.0 219 index setup? I noticed the two addresses that would've written to Menu Type Open and Debug Menu Open without the pause menu/control stick portion of the setup are related to the Item Screen Index and Soar Cursor Index values, but not sure how all of the logic works. Regardless of whether or not I do the pause menu/control stick portion of the setup, the Text Instruction Counter changes several times and I'm not sure why (I would have expected Text Instruction Counter to just remain the same value; not sure why anything would overwrite it). Here are some notes I made for myself that show most of my logic https://pastebin.com/Mbj4Js4x
Pastebin
jp 1.0 index 219 setup notes/questions - Pastebin.com


faschToday at 6:23 PM
the instruction counter will update whenever it catches a "control code"
which are special codes that don't print the character they are, but rather specific things
So if you go to my setup you'll notice the bytes that overwrite the pause/editor combo
come an additional 12 bytes after what you calculated

ImbuedToday at 6:24 PM
so once a control code is seen, I assume that'll then change where the text processing function starts reading characters from next?
since it changes the text instruction counter

faschToday at 6:24 PM
yea, its just used to keep its place
so in my setup video I set lens to c-down which sets 3FDC74 to 000E0001
3FDC74 - 3FDC68 = C
thats where the 1F comes into play
001F is a special character
that reads the next character as the number of spaces to print
001F 00xx specifically
So the memory is set up so that there are 3 of these
001F 0000 means to print 0 spaces
since 001F000 = 4 bytes in total
and i do 3 of those
thats the 12 bytes required to push the manipulated pause/editor further up to a better address
2 of the 1Fs come from the control stick, the other comes from hovering over spring water in the mask inventory and hovering over ocarina slot
and the other important action of my setup is hovering over song of soaring to set the selected song to 09 which acts as a terminator, but also being aware that the selected slot on the quest status screen sets another terminator so you just need to move away without hovering over another song
because that quest status slot would prematurely terminate printing

ImbuedToday at 6:42 PM
so I guess before addressing some of those details, something I'm wondering right now is: once the soar location message has been written into Buffer B, the main text processing function starts writing 286 bytes after the start of Buffer B (reading starting from 1750 bytes after the start of Buffer A). So it has like 1400 or 1500 ish bytes to read before writing anything to Menu Type Open or Debug Menu Open and in those 1400-1500 bytes, wouldn't there be a good chance that a control code is hit which would change the Text Instruction Counter which would then offset where the text processing function is reading from (potentially by a lot)? If we actually do reach at least one control code in those 1400-1500 bytes, then I imagine what bytes are read from to write to Menu Type Open and Debug Menu open likely wouldn't be so close to the ones I expected to write to them (unsure if you do something to check if any control codes exist in those 1400-1500 bytes)

faschToday at 6:43 PM
Ok so any time the instruction counter updates
thats the intended functionality
If you take a look at the buffer A on a normal instance
you'll see it it starts reading from the start
and then when it reaches that 0224 for the location name
it'll update the instruction counter to point to the character following that 0224
so that way it knows when its done printing the location name, it can go back to buffer A and print whatever is next

ImbuedToday at 6:45 PM
which 0224?

faschToday at 6:46 PM
it should be the second character

ImbuedToday at 6:48 PM
like the soar location name happens to have 0224 as its second character?
(I didnt check it)

faschToday at 6:49 PM
So buffer A is before processing and putting any variables
since the location is a variable
they just put it as 1 character in the preprocessed message

ImbuedToday at 6:51 PM
not sure what you mean by "So buffer A is before processing and putting any variables"

faschToday at 6:52 PM
So the string that is put into buffer A would look like this "Soar to %?"
the function copies everything from buffer A to buffer B

ImbuedToday at 6:52 PM
yup

faschToday at 6:52 PM
but when it encounters special characters
like in the case of "%" here
it'll do special printing
after its done with special printing
it'll return back to buffer A based on the instruction counter, because there is still more to print
which is the "?"

ImbuedToday at 6:53 PM
Yes I agree with that

faschToday at 6:54 PM
so thats why it updates the instruction counter

ImbuedToday at 7:01 PM
So normally would it be like "Soar to (D4)?" is copied into Buffer A, then "Soar to " (9 bytes) is written from Buffer A into the first 9 bytes of Buffer B and then the D4 control code is read which causes the soar location message to be copied into Buffer B and then would the Text Instruction Counter update to be 10 to start reading 10 bytes after the start of Buffer A so that it reads the "?" (which I picture to be 1 byte after the byte of Buffer A that has the D4 control code)?

faschToday at 7:01 PM
yeah

ImbuedToday at 7:02 PM
ah ok so really when the Text Instruction Counter was changing in the setup, it was changing in a way so that it would return to the byte directly after the control code it just read?

faschToday at 7:03 PM
exactly

ImbuedToday at 7:03 PM
and therefore nothing crazy could happen

faschToday at 7:03 PM
yep

ImbuedToday at 7:03 PM
ok that makes sense

faschToday at 7:03 PM
the only time something crazy would happen is by printing over it

ImbuedToday at 7:03 PM
that is good to know

faschToday at 7:03 PM
As for the 2nd part of the question regarding accidental control codes
Yes there could be some, but it wasn't really an issue because most of the addresses are constant and just don't line up
and its japanese
so theres a significantly smaller portion of control codes to character ratio

ImbuedToday at 7:11 PM
I'm not really familiar with most control codes, so not sure what potentially problematic things running into them could do (I imagine running into a D4 could cause the Soar Location Message to be copied into Buffer B again which would maybe cause some issues since the difference between where in Buffer A the function reads from and writes to in Buffer B would increase; for example suppose where the text processing function is reading from is exactly 2000 bytes away from where it writes to, but then a D4 is hit and the soar location message is 100 bytes long, then once it finishes writing that into Buffer B, the difference between them would be 2100 (or 1900 depending on which one is first in memory I guess))
though I imagine most wouldn't be problematic as I imagine most likely wouldn't write something extra into buffer B

faschToday at 7:12 PM
yeah it just reprints the location again
lets say it was 'Snowhead' as the location
and you had "Soar to (D4)(D4)?"
it would do
"Soar to SnowheadSnowhead?"

ImbuedToday at 7:14 PM
Yeah makes sense

faschToday at 7:14 PM
so its a nice way to print a lot of characters with very few bytes to manipulate
so my setup follows the reverse of that, I wanted less characters printed

ImbuedToday at 7:16 PM
What I'm getting at is if there's some random D4 in the 1400-1500 bytes I was talking about earlier, then it would end up changing what bytes in memory are read from to write over Menu Type Open and Debug Menu Open, so in the jp 1.0 219 index setup there definitely was not a D4 anywhere in those 1400-1500 bytes or else we'd have had a difference of more than 12 with our addresses that write to menu/debug

faschToday at 7:16 PM
yeah

ImbuedToday at 7:17 PM
ok so rereading what you said earlier is making more sense now
you basically used a 001F control code to write 0 spaces to advance 4 bytes further into where we're reading from, but without advancing where we're writing to and you did that 3 times and that is why where you read from was 12 bytes ahead of me

faschToday at 7:19 PM
yep

ImbuedToday at 7:20 PM
so that part makes a lot more sense now. However, I'm unsure why you need the 09 terminator. Is this to stop overwriting stuff because there is stuff nearby (after the Menu Type Open and Debug Menu Open adresses) that if you overwrite it you'll get a crash?

faschToday at 7:21 PM
yeah
not necessarily nearby
but still prevents a lot from being overwritten

ImbuedToday at 7:22 PM
yeah makes sense
so is there a list of terminators/control codes? I've seen this before (but haven't really read most of it) which has info on some control codes to my understanding https://wiki.cloudmodding.com/mm/Text_Format#Text_Format
Text Format

faschToday at 7:24 PM
thats what i use

ImbuedToday at 7:24 PM
ctfl + f "terminator" gives me nothing though

faschToday at 7:24 PM
oh
theres a message from exodus with the japanese ones
and mrcheeze with the US ones
0009, 000B, 0103, 0104, 0110, 0111, 0112, 0230, 0240, 0500 are the terminators for JP 1.0
the terminators are characters 10,12,15,19,1A,1B,1C,1D,BF,E0 on US

ImbuedToday at 7:28 PM
cool thanks for all the info (didn't see a message with JP 1.1 ones when I searched past discord messages, but saw JP 1.0 and English like you linked)

faschToday at 7:28 PM
i'm 99% certain they would be the same on J 1.1
as on J
1.0