News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: Link's Awakening: Pointer issues with selection dot?  (Read 3891 times)

4lorn

• Jr. Member
• Posts: 82
Link's Awakening: Pointer issues with selection dot?
« on: September 17, 2011, 12:09:03 pm »
First of all, hi everyone First post here, hope this is the right place in the forum. Now, as to the topic at the hand...

The idea was to translate the non-DX version of Link's Awakening into Portuguese. I've decided to translate both text and change tilesets in order to reflect the change, though I had several objectives before I started out. One was to just learn a couple of tricks in regards to tile and hex editing, and that's going pretty well, I think. The second was to translate the game without using any ROM expansion tools - as in, simply working with the 16 character per line limit of the game. This last one is self-imposed since I was more interested in learning the basics before I went further, and it let me devise a translation that was on par with the english one - small and concise.

Now, the "Yes" and "No" kind of answers in the game are providing a challenge. I've become accostumed to tile editing, using TileSHOW or Photoshop to replace certain characters (like "ä" or "î" with more appropriate ones), as well as adding others by taking advantage of unused tiles in the game (LA has several of these white squares with gray crosses, totally unused in the game, where it's possible to place new characters and call their use through hex values).

Now, the problem with "Yes" and "No" is that "no" is three letters in portuguese, reading "Não". At first, since I couldn't circumvent this, I decided to take the letters, each 8x8 in a 24(8x3)x8 area, and group them in a 16(2x8) area. So, whereas "N", "ã" and "o" have their own characters, the answers would now be two tiles, one with "N" and the other with "ão" (but with the first pixel column of "ã" beginning in the "N" tile). I've implemented this and, barring the fact that the spacing is a lot smaller, the word style is still the same and it's pretty legible (plus, I can also translate replied like "No!" by using the same amount of tiles, simply having that exclamation point as the third, unmodified one.

If I go with this route, it's possible to do the same with any answer that is too long for the word limit, though I'm having second thoughts. I didn't want to deviate from that second objetive - keeping myself to the game's character limit - so I wondered how I could work with this. The main issue I've come across is the selection dot, that little circle LA uses to show players what answer they want to select. I figured that, if I could move that dot to the start of a line, it could be easier to take advantage of surplus space. But I'm unsure of how to do this. Is the position of the dot related to a pointer? I *have* tried reading several ASM and pointer documents. I forget the program I used, but it revealed a line where it appears (I chose the very first time you can be made a question, by the fisherman in Mabe Village) to call up something like "cp \$4f". What little I understood of this and through the use of utilities, it seems the game is calling up a comparison between values.

I'm thinking it may be possible to find out different values for its position if I search for other questions and answers in the game, see if there is any different value. I thought I had found a way, but then the dot was placed on top of the second answer, so I guess I didn't. I'm guessing it's somehow different depending on context.

So basically, I was wondering if someone could point me in the right direction with this. Is that dot position really tied to a pointer?

« Last Edit: September 17, 2011, 12:16:42 pm by 4lorn »

Auryn

• Hero Member
• Posts: 649
Re: Link's Awakening: Pointer issues with selection dot?
« Reply #1 on: September 17, 2011, 04:55:12 pm »
I am not so good at ASM either and you probably need some sort of ASM hacking to do so.
What i would try is a to find a "cheat code" for forcing one of the 2 answers (start search, let the button same place, search same value, move to the other answer, search different value ... maybe searching for a greater or smaller value depending if left or right answer) and mess around with that value.
Repeat the same with another answer selection to see if you get the same offset (all the same coordinates for each answer choice), the position of the dot is hardcoded. If each answer has it set of coordinates, the coordinates are probably calculated in some way.
Anyway the solution should be just above the "cheat" you found in the ASM.

justin3009

• Hero Member
• Posts: 1608
• Welp
Re: Link's Awakening: Pointer issues with selection dot?
« Reply #2 on: September 17, 2011, 09:46:15 pm »
There's most likely a hardcoded value of coordinates for those.  You can find them stored somewhere in memory, that's almost a guarantee.  So if you're able to figure that out, maybe you can trace it backwards and change it.  I've never done any sort of ASM besides SNES so I can't say what's the same or not, but it's just a guess.
'We have to find some way to incorporate the general civilians in the plot.'

'We'll kill off children in the Juuban district with an infection where they cough up blood and are found hanging themselves from cherry blossom trees.'

4lorn

• Jr. Member
• Posts: 82
Re: Link\'s Awakening: Pointer issues with selection dot?
« Reply #3 on: September 18, 2011, 10:09:57 am »
Thank you both I'll see what else I can dig up, then.

September 21, 2011, 04:31:29 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Well. I'm feeling pretty stupid. In a good way, because it means I have to dedicate much more time and effort.

Which is to say I still haven't gotten close to finding out the pointers. All I've found so far, or think I found, is that:

1) the same selection dot in monologues is also the same selection dot used for the areas in the wold map;

2) I *think* I have found some pointers, though mostly these are within monologues themselves. GBRead lets me check the ASM directly, meaning a whole monologue like: "How about some fishing, little buddy? I'll only charge you 10 Rupees..." has Reset to Offsets, Loads, and Jump Relatives. The Jump Relatives in this particular case, if I'm reading this correctly, point ("jump") to places in the same block of text. This monologue starts at 00053056, and in 0005305A, it reads "jr nz, \$530BD; Jump Relative (If Not Zero) To \$530BD". If that value is another offset, then it directs me to one of the fisherman's answers (in this case, if I answer "not now"). This happens in just about every single monologue, though I suppose it may be regarding paragraphs and text size? (not sure);

3) I've tried using VBA's memory viewer. Neat stuff - if I choose to update it automatically, I can see almost exactly what's happening in the code. There are at least three lines that rotate in real time along with Mabe's crane mini-game. This way I found out some values about the possible location of the selection dot (a couple of values blink on and off along with the dot), but that's probably as far as I went in finding something;

Wasn't it Jigglysaint the one who cracked the most out of Link's Awakening and the Oracle games? He found a lot of good things, but I can't seem to find anywhere if he ever got down to this kind of info. I suppose there may be something (very wrong) in the way I'm trying to find these pointers, probably.
« Last Edit: September 21, 2011, 04:34:19 pm by 4lorn »

Spikeman

• Hero Member
• Posts: 1063
• *unce unce unce*
Re: Link's Awakening: Pointer issues with selection dot?
« Reply #4 on: October 02, 2011, 06:38:33 am »
Hello, I decided to take a look in a debugger and see what I could find. I've never hacked a GB game before, but I was able to find what you were looking for.  Here's how:

First, load up the game in BGB. Go to the fishing minigame and talk to the guy.

The first thing you need to do is set a breakpoint for when the keypad is read. How do you do this? Press ESC to pull up BGB's debugger, then from the Debug menu, go to Access Breakpoints. Type in FF00 for the address, click the read checkbox, and click add. How did I know FF00 was the keypad? When my usual method (from GBA hacking) of setting a breakpoint on graphics didn't work, I decided to google around and found this tutorial: http://blog.pkh.me/p/1-scavenger-hunt.html. That page explains things in a lot more detail, and has some nice screenshots, but it's for a different game.

Using the method in the tutorial I just linked, I figured out that the keys that are held are stored in ffcb and the keys that were just pressed are stored in ffcc. I set read breakpoints on both, but only A and B were checked from ffcb, so to follow along, just set a read breakpoint on ffcc.

Set a breakpoint on ffcc, it breaks at ROM0:278A. Here's the code:
`ld a,(ff00+cc)  ;read the value from ffcc.bit 4,a         ;Checks if bit 4 is set (A button)jp nz 27ae      ;goto 27ae if A was pressedand a,03        ;check if left or right was pressedjr z,27a1       ;go to 27a1 if neither was pressed`

After this is what happens if left or right was pressed (note both left and right do the same thing: toggle the dot location). So set a breakpoint here (ROM0:2795) by double clicking the line in the debugger and remove or disable the access breakpoints. Note that the game will run normally until you press left or right, then it will break - this means we are in the right spot. The code at 2795:
`ld hl,c177ld a,(hl)       ;loads the value from c177inc a           ;add one to itand a,01        ;trick to keep a to either 0 or 1ld (hl),a       ;store new value in c177`

Hopefully it's fairly obvious that this toggles the value at c177, so c177 is probably the dot position. Now we need to find how this connects to the X-position of the dot sprite. So, set a read breakpoint on c177. The game breaks at RO17:7D6F:
`ld a,(c177)      ;get the value at c177and a,01         ;trick to check if a=1jr z,7d77        ;goto 7d77 if a=0 (left dot position)inc e            ;e=1 if this is trigged, 0 if notld hl,7d50       ;jumps here if was zeroadd hl,de        ;this will be 7d50 if dot is on left, 7d51 if on rightld a,(hl)        ;gets X value!`

Nice, exactly what we were looking for. 7d50 and 7d51 are the positions you need to change! Note, that these are in bank 17. I'm not really familiar with GB architecture, but if you search the ROM for 30 58 1E 00 (the sequence you see in the debugger), you'll find it at 0x5FD50.

Note: In retrospect you probably would have had luck just search the ROM for 30 58, the two X positions which can be found easily in the OAM viewer. However, there was no way to know that the game stored them this way - debugging will always lead to the right answer.

You should be able to use this same method (or just search for the pair of X coordinates in the ROM and try changing them) to find the values for other menus. Hope this helps.
« Last Edit: October 03, 2011, 05:19:14 pm by Spikeman »
Open Source Hacking Projects: Guru Logic Champ, Telefang 2, (Want more? Check out my GitHub!)

4lorn

• Jr. Member
• Posts: 82
Re: Link\'s Awakening: Pointer issues with selection dot?
« Reply #5 on: October 03, 2011, 04:01:03 pm »
Oh my stars and garters! I am going to be all over this later tonight (still splicing through my attempt at translating Zero Mission right now). Thanks a bunch, Spikeman, I'll drop by as soon as I have news on this

October 03, 2011, 05:59:08 pm - (Auto Merged - Double Posts are not allowed before 7 days.)

Success! Not without some quick caveats, though. I'm getting some different readings in BGB. The values are close but not the exact ones you've mentioned, as in, 7B7C instead of 7d77 for instance. But this isn't criticism! I'm of the mind that the values may be different because either a) the ROM I have been hacking away at may not be a "perfect" version (if memory serves, it's a 1.2 version of the game), or b) altering the ROM's tilesets may have changed some values already.

Nonetheless, a quick search for 30 58 1E 00 *did* indeed reveal one single entry. Some quick tampering reveals that 30 corresponds to the dot's position on the left, while 58 tags its position towards the right. I also know one of the other values toggles at what line it appears (as in, whether the dot appears on the second line of the monologue, or in the first).

Next, I'm gonna have to try out how much this influences the available spacing in the monologue. Theoretically, since the selection dot can be moved, this should mean I do get to mess around with the extra spaces I move it (ie., 3 more characters if I move it 3 spaces).

I could kiss you right now!
« Last Edit: October 03, 2011, 05:59:08 pm by 4lorn »

Spikeman

• Hero Member
• Posts: 1063
• *unce unce unce*
Re: Link's Awakening: Pointer issues with selection dot?
« Reply #6 on: October 04, 2011, 12:56:15 am »
Quote
I'm getting some different readings in BGB. The values are close but not the exact ones you've mentioned, as in, 7B7C instead of 7d77 for instance. But this isn't criticism! I'm of the mind that the values may be different because either a) the ROM I have been hacking away at may not be a "perfect" version (if memory serves, it's a 1.2 version of the game), or b) altering the ROM's tilesets may have changed some values already.

I forgot to mention this, but I was using the Link's Awakening DX ROM since it's the one I had. If you're using the original version the addresses are probably different. But, hopefully you should still be able to use the same method to find values! Were you able to follow along the debugging process? I know I wasn't very specific on how I found that ffcb and ffcc are important, but after that I think it should be pretty clear.

Quote
Nonetheless, a quick search for 30 58 1E 00 *did* indeed reveal one single entry. Some quick tampering reveals that 30 corresponds to the dot's position on the left, while 58 tags its position towards the right. I also know one of the other values toggles at what line it appears (as in, whether the dot appears on the second line of the monologue, or in the first).

Do you understand that the reason that 30 controls the left position and 58 controls the right postion is because of this code?
`ld a,(c177)      ;get the value at c177and a,01         ;trick to check if a=1jr z,7d77        ;goto 7d77 if a=0 (left dot position)inc e            ;e=1 if this is trigged, 0 if notld hl,7d50       ;jumps here if was zeroadd hl,de        ;this will be 7d50 if dot is on left, 7d51 if on rightld a,(hl)        ;gets X value!`

Notice that (c177) is the dot's position - 0 = left, and 1 = right. (We know this from earlier code.)The variable 'e' is initially  zero, but if you notice the line "inc e", sometimes it increment (add 1) to e. What makes this important is that "and a, 01" then "jr z" combination. 'jr z' jumps to a certain line if the result of the last instruction was zero. So if a (the dot's position) is 0, then the AND instruction will return 'z' and skip over the "inc e" line, but if its not, it will return 'nz' (not zero) and add one to e.

This is kind of a over-complicated way of doing things, but this basically sets e=1 if a=1 or e=0 if a=0. Now note the instruction "add hl,de" - 'de' is just 'd' and 'e' squished together, so since d is zero, its just 0e (00 if e=0 or 01 if e=1). So the result is simple, hl is 7d50 if a=0 (dot is on the left) or 7d50+01 if a=1 (dot is on the left).

Now if you realize that the address 7d50 is the same as the address in the ROM you found by searching, does it make sense that the first value (7d50 = 30) corresponds to the dot's left position, and the second value (7d51 = 58) corresponds to the dot's right position?

Also, a quick note. If you look in the VRAM viewer (in one of BGB's menus) and look at the dot sprite, you'll notice that it's x-position shows up as 30 and switches to 58 when you move it to the right. You can probably exploit this to find the value for other menus. (Just look in the VRAM, write down 30 and 58 as the two values, then search for 30 58.)

Sorry if I come off as pushing the ASM on you - I just think it's an important skill for any ROM hacker to have. Especially in this case, since this is an easy situation that you can apply to similar things you might need to find in the game.

(Mod edit: if using the pre tag, please watch out for stretched-out lines.)
(Spikeman edit: Sorry, looks like that was just a typo in my [/pre] tag.)
« Last Edit: October 09, 2011, 01:05:59 am by Spikeman »
Open Source Hacking Projects: Guru Logic Champ, Telefang 2, (Want more? Check out my GitHub!)

4lorn

• Jr. Member
• Posts: 82
Re: Link's Awakening: Pointer issues with selection dot?
« Reply #7 on: October 04, 2011, 03:38:17 pm »
Thank you once again for the indepth explanation, Spikeman

Truth be told, as per Auryn's suggestion up there, I was searcing for these values in a similar way. I was using Visual Boy Advance's debugging, and in retrospect, I could have found this earlier but the problem was my method (in short, too many of the wrong calculations throwing me off course).

Thanks to you, and these explanations, I really do realize more about ROM hacking now. I wasn't giving up, but was feeling miffed that the answer kept eluding me. Now I know I was on the right track, at least.

I promise to read up on even more ASM now!

EDIT: editing because I forgot to add this, and because I want to show how it's working:

I've tried the values/positions 17 and 48 for now. It gives me a much bigger space to work with. In the original game, the answers were all "pushed" towards the right, but by moving the dots left, I can now do more answers than "Yes" and "No".