[Pikachumanson]

Why is a LDA($insert value here), y or x, also known as the A1 or B1 statement needed? Couldn't I just use something else if those statements happen to not be available in the games text routine? Like another type of LDA statement?

Forgive me, if this sounds like a stupid statement but I have been trying to locate a said A1/B1 statement that would work in my routine with no success, so I'd just like a breakdown as to why it's or an alternative solution some of you have used to overcome this problem.

I am working on Kawa no Nushi Tsuri for the Famicom and here is the area in the text routine I am referencing. That last line is the one I am using to perform my jump.

Code: [Select]

01E569:AD BA 07  LDA $07BA = #$00   ;index into window buffer
  01E56C:AA        TAX                ;X = index to dakuten line of current printed character?
  01E56D:18        CLC
  01E56E:69 12     ADC #$12
  01E570:A8        TAY           ;Y = X+0x12, because each line is 18 characters wide, so the main character will be 18 bytes after the corresponding dakuten
  01E571:20 FB DB  JSR $DBFB
  01E574:A5 91     LDA $0091 = #$23
  01E576:8D 06 20  STA $2006 = #$E8
  01E579:A5 92     LDA $0092 = #$27
  01E57B:8D 06 20  STA $2006 = #$E8
  01E57E:BD 50 06  LDA $0650,X @ $065F = #$FE  ;here it's reading the dakuten line
  01E581:8D 07 20  STA $2007 = #$98        ;and here's it writing one tile to VRAM
  01E584:B9 50 06  LDA $0650,Y @ $06B0 = #$34  ;here its reading the main text line. And the next will write that tile
[\code]



The text is loaded in the ram at 650 to 6DF and I been pouring through the searching for B1/A1 statements or the ram numbers in the range I am looking for. Can any of you tell me what I should be on the lookout for when I do that?

[KingMike]

Once again, you should trace for the code that stores the text INTO $0650-06DF.
While I'm not sure of the exact formatting, it is clearly some sort of mirror of the text window.

I think the code is at CPU address $F12B. I think I'll leave it a learning experience how I found it (quickly).

Because LDA (nn),Y (B1 xx) (most often used) and LDA (nn,x) are the only instructions that can read from a non-fixed address (ignoring the ,x and ,y instructions as those aren't useful for your purpose).

[Trax]

My guess is that the game builds a PPU Macro in the 650-6DF range, and the data is fed to the PPU in some other routine...

[KingMike]

It's not a macro, address is simply 18 bytes for each row of tiles, as the window has room for 18 characters wide (though the rows themselves are out of order).

[Pikachumanson]

Would it be a major thing to put them order?

[Trax]

I disassembled a few bytes of the code, in Banks 5 and 7, and I don't see anything really complicated here. For example, the first dialog of the game is located at 0x1715A. All lines end with FF. The length and offset of the entire dialog are hard-coded like this:

Code: [Select]

1710A: A9 11 LDA #$11 ; A = 11
1710C: 8D 5C07 STA $075C ; Lines in dialog
1710F: A9 B1 LDA #$B1 ; A = B1
17111: 85 13 STA $13
17113: A9 5A LDA #$5A ; A = 5A
17115: 85 12 STA $12

Addresses $12 and $13 contain the location of the lines of text. Data is processed in order, by incrementing the address every character. The dialog ends when a specific number of lines have been processed, stored into RAM at $075C. In this case, it is arbitrarily set to 11, which is the length of the first dialog...

As for the line skipping, I can see a more complicated issue, because there is the initial drawing of the tiles, but the text also scrolls down. So there are a few more looping variables that must be tweaked accordingly...