Cyber Knight translation

[megatron-uk]

Is there any way of having Mednafen put a breakpoint at logical address? - as I'm having a bit of a pain tracking down where this text string is being loaded from and when the section of rom is being swapped in to be read from.

I'll probably call it enough for the weekend now - I've got to prepare for a job interview tomorrow.

[TheOldMan]

*(page):(address)   => ie, *02:ffef  will break on that exact address only.
(addr)                      => ie         0fff  will break on that address in any page, when mapped in.

The second one will generate a lot more breaks; you have to check the mpr registers to see if it's the page you want.  Try both and see which one you need - thought it's probably the first, at this stage.

[Bonknuts]

There's also external address breaking that isn't bank mode: so *15:8c44 can be done as *2ac44. And you can do a range as well *2ac44-*2acff. And you can have multiple range reads, but just make sure your 'long' address ranges come last in the window. So something like: 57ff 2066 7ff0-7fff *2ac44-2acff. Another pro tip; you can put more arguments/parameters than what will fit in the text window. Use the arrow keys to scroll back and forth, because it won't show the whole thing.

[burn_654]

When I've been working here and there on Momotarou Katsugeki the script worked much the same way - that control code to switch between hiragana and katakana, and a control code to put dakuten/handakuten on the previous character. What I ended up doing was similar - making a table for each - but there are tools that can make the extraction easier for you. I had good luck extracting snippets (ie, a hex range) with romjuice by putting that control code as my 'switch tables' identifier, hooking up my two tables and it spat out some nice txt dumps. Atlas can do this too (and probably the tool to use for complete dumps) but I found it a bit harder to use for simple tests, it seems intended for script dumps when you have a pointer system figured out. It was just my experience dumping a sentence or two with a table change mechanic worked well in romjuice.

This makes me want to resume my work as well - I'll be following this! For katsugeki I'm still cracking away at trying to figure out how to alter the tilemap for dialog boxes.

[megatron-uk]

Thanks for the read-break pointer syntax help! The mednafen docs could do with some extra examples!

But, we have a winner! The image below is with a read break on a single address - *1DEFE - immediately after the dialogue box is shown and before the text is printed, so the pointer must have been fetched just before this point.

[NightWolve]

Ah man, I wish we had that debugger (David and I) back when we worked on Ys IV! Looks pretty decent. I used a brute-force method to find a string pointer and I got lucky at about 3000 or so byte changes to the state file per reloading in the YAME emulator! Heh-heh. Did what I had to do, and it managed to work after enough patience!

Basically, I wrote a Perl script that opened the YAME state file at the start of RAM, and it would INC a byte, then pause till I'd hit return. I would ALT+TAB to YAME, press the quick key to load a state file (set to F5), load the menu, see if I changed the text in question, if not, ALT+TAB back to the Perl script now open in a CMD window, press enter, and so then it would DEC the byte that it just changed, move to the next one, INC it, pause, rinse and repeat for hundreds and hundreds and hundreds of times till you find the byte that you're looking for!!! So I found it after like 3 or 4 days.... If not, David would've had to hand trace some assembly for me, but it didn't come to that for this issue.

[megatron-uk]

That's hardcore, that is

[Bonknuts]

Ah man, I wish we had that debugger (David and I) back when we worked on Ys IV! Looks pretty decent. I used a brute-force method to find a string pointer and I got lucky at about 3000 or so byte changes to the state file per reloading in the YAME emulator! Heh-heh. Did what I had to do, and it managed to work after enough patience!

Basically, I wrote a Perl script that opened the YAME state file at the start of RAM, and it would INC a byte, then pause till I'd hit return. I would ALT+TAB to YAME, press the quick key to load a state file (set to F5), load the menu, see if I changed the text in question, if not, ALT+TAB back to the Perl script now open in a CMD window, press enter, and so then it would DEC the byte that it just changed, move to the next one, INC it, pause, rinse and repeat for hundreds and hundreds and hundreds of times till you find the byte that you're looking for!!! So I found it after like 3 or 4 days.... If not, David would've had to hand trace some assembly for me, but it didn't come to that for this issue.

 That's hardcore old skool!

[megatron-uk]

Ok, I now have two reproducible dialogue examples and have found where the string is located in logical memory for each of them.

The first is the message from MICA which activates if you stray too far on initial landing:

ROM position: 0x01DEFE
Logical position: 5EFE
Hex sequence: 4D 49 43 41 A2 BB B8 BE DD 5C B4 D8 B1 5C B6 D7 20 CA BD DE DA C3 B2 CF BD A3 08

The second is a message from the guards in the first town, move to them and they will activate a sequence where they check whether you are allowed to pass them. After that, this phrase will trigger when you then talk to each guard alternately:

ROM position: 0x01423E
Logical position: 423E
Hex Sequence: C0 C0 DE B2 CF 20 B7 DD D1 C1 AD B3 C3 DE B1 D8 CF BD 08

Now, I can see the text actually mapped in via the logical location that I have the read breakpoints set to (and the hex code matches that I scan in the rom). But I can't work back from that to figure out where the pointer to the string is loaded from.

[TheOldMan]

I assume the read breakpoints are at the actual text addresses.

When you hit the break, write down the pc (program counter) and which page is at that address.
Then set a breakpoint there, and remove the one on the text. If you start again, and go for the same message, you shoud break at the -code- where the address is accessed. From there, it's a matter of looking at the disassembly of the code in mednafen, and seeing what is being done before the text is printed. Most probably, the text is being loaded indirectly (ie, lda  [ax], x) from some address in the zero page. Examine that address, and your text pointer table should be there.

Also keep in mind mednafen has a memory viewer, so you can set it to the zero page and look at the stack to see what routines have been called to get where you are.

Hope that helps.

[megatron-uk]

Ok, so taking the guards example; the read breakpoint for the actual text string halts on the following instruction:

Code: [Select]

CD54: LDA ($30), Y (@ $423E = $C0 ; B1 30)
It appears that 0x00014000 is mapped in at $4000 at that point as the text is visible at $423E.
I clear the read breakpoint on *0001423E and set it for CD54. Stepping through it calls the same line with different offsets, the first one it breaks on is:

Code: [Select]

CD54: LDA ($30), Y (@ $400B = $00 ; B1 30)
After that it does

Code: [Select]

CD55: BEQ $CD9F ;F0 47
CD56: CMP #$20  ;C9 20

CD9F: INY ;C8
CDA0: JSR $C287;20 87 C2

C287: TYA ;98
C288: CLC ;18
C289: ADD $30 (@ $2030 = $0B) ;65 30
C28B: STA $30 ;85 30
C28D: BCC $2C91 ;90 02

C291: RTS ;60

CDA3: DEC $34 (@ $2034 = $12) ;C6 34
CDA5: BNE $CD51 ;D0 AA

CD51: LDY #$FF ;A0 FF
CD53: INY ;C8
CD54: LDA ($30),Y (@400C = $1A) ;B1 30
This continues for hundreds and hundreds of cycles, incrementing the address used by the LDA @ PC CD54 by one each time - so many that I just had to hold 'r' until it popped up the dialogue box.

Edit: Looking back at both traces, in each case it seems the operand to load the text string address is sourced from $5E (as both $5E and $5F are being set earlier).

[NightWolve]

That's hardcore old skool!

Yeah, a "brute-force linear search," so max search time equals 1-n, thus worst case scenario with 256 KB RAM, the byte that you're looking for is the last one, so I would've had to press "Enter", "Alt+Tab", "F5", etc. each about 262,144 (x3-4) times!!! Heh-heh. No cheating either, you couldn't say INCrement/DECrement 10 bytes at a time in the state file to increase your search range and then test in-game, because you would likely damage computer instructions at the same time and crash it, so it was gonna have to be one byte at a time if you were gonna do it!

Anyway, there goes a "protip" for ya megatron, that is, if for some reason you had no hope of finding something any other way!  I wanted to find some way to usefully contribute to your thread, so this was the best that I could do!

[megatron-uk]

Anyway, there's a "protip" for ya megatron, that is, if for some reason you had no hope of finding something any way else!

Thanks for that one

[TheOldMan]

It looks like $30 and $31 hold a pointer to the current character to print. The code posted appears to be part of the character-convert code (ie, the stuff that interprets the control characters.)
Note that bne $cd51 - that's probably the jump to re-start the loop with another character.
If you set a break there, you should be able to step and see one character at a time appear.

You say it sets $5e and $5f to the string address earlier. Set a break on that, and see what appears on screen when it breaks. If you see new strings each time, then whatever is being put into $5e and $5f may be your string pointer table.
In any case, you now know where the logic is to interpret the strings. From that you should be able to deduce all the control codes, and what information they use.

[megatron-uk]

Thanks again for the info - I'll take a look at that and see if I can find where $5e/$5f are getting set.