Faxanadu Retranslation

[Ascended Mermaid]

I did figure out how to do bank switching at one point. Now here I am, trying to figure out the same trick twice. I know $008C is an 'active bank' and $0100 is the 'current bank' (according to the labels I'm reading). Even with all the guides at my disposal, I feel like a complete noob. Reading my old posts, I've always been a clueless noob, but that was back when I learned, and improved. Now I sit here, puzzled, studying the assembly, and while I 'know' my opcodes, I feel as though my attempts to use them are futile.

// Even though I 'was' smart and 'documented' my work, I didn't document well enough the *important* stuff -- like bank switching. It's kinda funny, really; I was accused of hacking facebook accounts, which I'll take as a compliment, since I can't even hack a Nintendo game.

// I've got it, surprisingly enough.

// So now that I've taken care of bank switching, I'm presented with a new problem. Tile $FF is all that is printed in the moved area, repeatedly. Since the moved data isn't printing the same way as it would if it stayed in the same area, I have clearly made a boo-boo. I'm not exactly sure what, just yet.

By the way, I'll just leave this here in case I need to remember bank switching in the future...

To switch PRG ROM banks, load the bank number into A and call this subroutine:

mmc1_load_prg_bank:
sta $E000
lsr a
sta $E000
lsr a
sta $E000
lsr a
sta $E000
lsr a
sta $E000
rts

I believe I have figured it out, and more -- I may have figured out how to paint the exact tiles loaded into PPU memory! Which means... I may finally fix the bloody name screen, once and for all.

// Done. Now I'm thinking that it looks kinda ugly without those empty boxes. >.o

// Wanna know what the funniest thing about all of this is? I didn't even need to move the data into the expanded ROM in the first place! I suppose I can empty the new bank and move the data back where it was. I've learned much through this experience, at least.

// $03C707:AE C2 03 is erroneous. This is the call made by the Battle Suit item -- you pick it up, and it checks how many weapons you are carrying, when it should be checking how much *armor* you are carrying. This bug was in the original game, so my SRAM patch is not at fault.

So to bring everyone up to speed on bugs and other misc. stuff:

1. The Pendant. Instead of increasing your attack power, it takes it away. Why? Because it thinks you already have it when you don't, and vice-versa; a BNE/BEQ error.

2. The Battle Suit, explained above.

3. In progress, the nurse's missing rosary and chest. Noting that there are a few alternate graphics, I assume that some are beta graphics (such as an alternate hat for the nurse), and that the changes to the nurse, though drawn, weren't programmed. I can't think of any intentional reason for the bottom half of the rosary tile to be excluded, considering that rosaries are everywhere in the Japanese version, and I can't imagine the bust size raising any issues.

4. In progress, the ladder bug; if you don't have a shield equipped, but you have the Studded Mail equipped, half of the main character's chest disappears while climbing a ladder.

5. In progress, text needs to be moved to the new bank, fonts need to be reduced, and the maximum dialogue space needs to be increased.

// 6. In progress, the 2xSai version of the Rev A / European font (for the name screen) needs to be smoothed out. I refuse to have jagged, gigantic letters in the final version.

// 7. In consideration, the Battle Helmet does nothing. Considering the final boss DOES cast magic, however, changing that would require rebalancing.

[Ascended Mermaid]

Finished:
- Pendant (Done before, but listed anyway)
- SRAM (Same)
- Name Screen
- Battle Suit
- Nurse
- 2xSai font
- Dialogue increase (Max lines and max letters per line doubled.)
- Ported old translation (For testing; proof of concept)
- Ladder bug

Skipping:
- Battle Helm (That would be a game-changer, as explained before.)
- Magic damage halved even without a shield (For the same reason as the Battle Helm.)

In progress:
- Update text pointers (Or we will never hear the end of how "this is not enough Golds.")
- Reduce fonts and print positions (8x8 instead of 16x16)

[Ascended Mermaid]

I was only half-right. I dumped the assembly by process of elimination, but that's all I have for personal documentation.

Luckily, SP labeled the US assembly, so I do have *some* resources. The difference in code varies, but it looks as though I'll need to reverse engineer a little before I can work it into something (personally) more usable. That would be nothing short of a miracle.

[Ascended Mermaid]

A miracle has happened and I found where the game loads the player character's sprite data. The ladder bug is no more. I'm on the last leg of this hack; all I need to do now is fix the dialogue code as follows:

- Print 8x8 tiles instead of 16x16, update/adjust tile addresses as needed.
- Implement the "break prompt" dialogue script from the US version. Otherwise it will *only* prompt after printing 64 characters, instead of breaking if the 'next letter' accumulator reads 'FC'. (The US break prompt; it will change to an unused 'FA' for the translation as 'FC' is used as the character's name.)

// Finished the following:
- Update the code so that it prints the correct dialogue.

Added to my to-do list:
- Iron out a bug with the smoker at the bar in Dartmoor. He prints garbage text.

// This is so weird. I've found out that not only did the Battle Helm check how many *weapons* you have and set the accumulator to the amount of armor you have, the Dragon Slayer checks how much *armor* you have and sets the accumulator to the number of weapons you have. So yeah, I've fixed the Dragon Slayer bug while I was at it.

[Ascended Mermaid]

ALL bugs ironed out! That was just a little annoying. I updated the address pointers and dedicated a whole bank to dialogue (That's 16384 characters long in decimal; 4000 bytes in hex.), and randomly (because sometimes it gets done faster like so) picked one of my A2 10 bytes (within bank 0F) to change to A2 0D -- which is LDX #$0D. The X accumulator really doesn't mean anything on its own, but opcodes follow that use the X accumulator to switch banks. 0D is the old dialogue bank which has all of the nifty pointers, and I consider myself extremely lucky that the game actually does handle the bank switch for the pointers separately from the bank switch for the dialogue, because they were originally the same bank.

So yes, now I just have to teach the game to print the tiny EU / Rev A font I've already pasted in, pretty much, and I'm kinda banking (heh) on the game's programming being as kind to me in that regard. Tiny font, and dialogue breakpoint prompt. ALMOST DONE!!!!

Well, that is, I'm almost done with a largely proof-of-concept hack. This by no means concludes the translation phase of the project.

// The dialogue breakpoint prompt is implemented. Now I just need to shrink the font!

// Errr... well not yet. Leaving myself a friendly reminder for when I come back to finish the job. Sure I have a working breakpoint, but it still needs to clear the dialogue box when it's done. I just need to find a place (without looping) to put JSR $F541.

// Alright, the text clears after an interrupt. NOW I can work on implementing the 8x8 font!

[Ascended Mermaid]

This happened to me before I fixed the transparent spacing.

There is
a mark
of "Jack
"
By the k
ey hole.

Now for an explanation: I increased the letter limit per line as well as the line limit, but I was still using transparent spacing at the time. Since the letters are so big, it wraps around once per line horizontally before going to the next line, and once vertically after the second line.

SPOILER: Click to show

(There is a mark) wrapped around and printed over itself, became (Taemarks)
(of "Jack") wrapped and became ("f "Jack)
(by the key hole.) wrapped and became (ey hole.),
which printed over (Taemarks) and became (eyehole.)

[Xalphenos]

I'm glad you're working on this again. Good Luck.

[SkyeWelse]

I'm also glad to see you've picked this up again. Can't wait to play through the final result.

-Thomas

[Ascended Mermaid]

Thanks, guys.

One thing I will have to mention: I'm taking this one step at a time. While the Retranslation project was always planned to be the foundation for the Restoration and Remix hacks, it is not a gameplay hack. It's the same old Faxanadu, but with bugfixes, a new save feature, and all of the original Japanese version features left intact. Here's the full scoop on what is and isn't to be expected from the Retranslation hack:

- The SRAM hack. The password screen is dummied out and replaced with a simple load feature. The reasons for this are that nothing is actually lost in removing it, and nobody really likes the password system -- it gives erroneous passwords and doesn't store information with any level of precision. The SRAM feature stores things that weren't originally intended to be stored (such as current exp and gold), but will load this information as though you've entered a password (resetting the exp and gold to levels specified by your rank). This ultimately sets the foundation for a new save system for the Remix hack.

- Bugfix hacks. The pendant, battle armor, dragon slayer, and missing/unused tiles (climbing in armor without a shield, and the nurse portrait)

- Translation hacks. That means altering the name screen for aesthetic purposes, expanding the bytes available for dialogue by switching rom banks, and implementing the alphabet in both large (16x16) and small (8x8) variations for aesthetic and practical purposes.

- No dummying out anything that was in the original Japanese version to begin with (except for the password screen, for reasons explained under SRAM)

- No restoring anything that was clearly dummied out of the original Japanese version.

- No gameplay altering hacks (except for bugfix hacks)

- An old translation patch (for those who wish to play with the original script and all of the aforementioned hacks)

- A retranslation patch (for those who wish to play with the new script and all of the aforementioned hacks)

As soon as I implement that blasted 8x8 font and complete another successful test run (which never takes long), the old translation patch will be ready for release!

[Ascended Mermaid]

I'll backup the current version, as well; all future hacks will be compatible with both the Japanese and English translations. I'm not sure how big the Japanese fan base is, but I feel no reason to exclude them.

[Ascended Mermaid]

It's going to take quite a bit longer. I don't know what exactly I did to mess up the name screen, but it's messed up pretty bad. :\

On the bright side, I've figured out how to decrease the print width. (I checked, this doesn't alter the name screen.) Now I just need to do the same for the height, and find the pointer for the font.

// I've fixed it. Simple, simple. I'm lucky to have documented the exact byte addresses I've altered for the dialogue.

[Xalphenos]

I'm curious are you keeping the large font and adding a smaller one or are you replacing the the large font with the small one? Is the font 1bpp? I've never messed around with nes roms but I have changed the size of fonts for other games. How did you change the width without changing the Height?

Anyway you seem to be making great progress on this. Hope you don't have trouble finding a translator when the time comes.

[Ascended Mermaid]

It's just one thing after another. I had to fix another dialogue byte address -- unless of course, you want the game to crash when you shop. I've implemented the 8x8 font, so I really don't have to fool around with pointers and such; I converted the dialogue using a new table instead.

Now I just have to reduce the print height in length, which will allow for more dialogue. Ultimately, the dialogue system will match its US and EU cousins. Yes, all this work just to produce an identical effect.

// Xal: I'm keeping the large and small fonts. The large one is used specifically for the name screen, while the small one is used for the dialogue. As for 1 bpp... 1 bit (or is that byte?) per pixel? I... I'll have to look that up in SP's thing at some point. It's either in his blog or his disassembly -- or maybe Vagla's document. I'm not sure how to explain this, but the fonts are funky; one color does the top and bottom, and the other two are specific to the top or bottom. As for changing the width without changing the height, I believe I've just duped the game into overwriting every other tile by writing a NOP over an ASL. I discovered that through sheer dumb luck, as I tend to do when I'm desperate.

I'm a total noob, but... somehow I still manage to pull through. :S I'm really desperate to take care of this height deal, as well, and it almost doesn't seem likely that I'll find a dumb luck solution to this. As it is I'm struggling to understand any part of the font printing process. I know how the game handles portraits and sprites, but fonts are... just weird, and I hope I'm not alone in thinking this.

// OH, pfft. Yeah, as I recall, it uses a few bytes, and tiles often appear off-center in TLP, so I have to shift them... I think it's called "bitwise" or so, but don't quote me on that. I just know barely enough to get by. XD

[Ascended Mermaid]

Have some pudding!



I hear there's some proof in there.

// I'm just going to take my time and study this "PPU_Buffer". After looking at the name table, I see how the tiles are written.

40 42
41 43
60 62
61 63

So one character is that 40, 41, 42, 43 junk. 40 is located at X 12, Y 38. Watching the PPU_Buffer, I'll probably see something that looks like:

"LDA (tile from ROM)
STA (tile to PPU)
INY
LDA (tile from ROM)
STA (tile to PPU)
DEY
INX"

...I'm hoping, anyway. If it's something easy like that, I'll know just what to do with what I've learned from the Name Table.

[Ascended Mermaid]

It turns out I've had it all along. I think I have an *idea* of how it works.

0F:F739:AD 16 02 LDA byte_216 = #$0C ; Load the byte from $0216 (Letter position) to the Accumulator
0F:F73C:EA NOP ; I NOP'd this one. It was ASL.
0F:F73D:0A ASL ; For every ASL, multiply Accumulator by 2
0F:F73E:0A ASL ; I could NOP this one, too, and use much less PPU.
0F:F73F:0A ASL ; "
0F:F740:0A ASL ; "
0F:F741:0A ASL ; "
0F:F742:26 E9 ROL byte_E9 = #$16 ; I guess this shifts the byte in $00E9 left one bit?
0F:F744:85 E8 STA byte_E8 = #$F0 ; This stores the Accumulator to RAM
0F:F746:AD 1A 02 LDA byte_21A = #$00 ; This loads... I guess a partial line position?
0F:F749:4A LSR ; This divides the Accumulator by 2
0F:F74A:4D 17 02 EOR byte_217 = #$01 ; Exclusive OR, Absolute byte. Checks if A is ^ $0217?
0F:F74D:29 01 AND #$01 ; Logical AND, Immediate byte. Checks if A & #$01 match?
0F:F74F:0A ASL ; Multiply whatever it got out of that by two. It lost me at EOR.
0F:F750:05 E9 ORA byte_E9 = #$16 ; Logical OR, Zero Page. Checks if A does NOT match the byte at E9, #$16?
0F:F752:69 14 ADC #$14 ; Add with Carry, Accumulator + Memory + the Carry bit.
0F:F754:85 E9 STA byte_E9 = #$16 ; Stores the Accumulator to RAM.

It loads the letter tile from $0216 into the Accumulator, and for every ASL, it multiplies the Accumulator by 2. If I NOP another ASL, it will look screwed up in-game, (because every tile is then shifted to 40, 41, 42, 43 -- which if you recall, are the top-left, bottom-left, top-right, and bottom-right tiles of a character, in that order) BUT it will use less PPU and appear correctly in the PPU viewer. I've been going through throes of insomnia lately, so I'm sure that isn't helping me right now. It's like a puzzle. A simple, yet intricate puzzle.

Alternatively, I could see if 40, 41, 42, 43, etc. appear in hex somewhere. It wouldn't be the first time I've found something that simple. It'd probably look like this:
"40 42 44 ... 4A 4C 4E 50 ... 5E
41 ... 4F 51 ... 5F", etc., all the way to 7F.

I'll probably get some sleep though first, if I can.

// Nope, I didn't see anything that looked like that. It could just be written differently from my theory. I wouldn't be surprised.

// Actually, maybe I can find the solution in the "Draw Window" script. I think I remember seeing something like that... it looked similar my previous example;
LDA #$00
BEQ $STA ; jump to STA 1
LDA $xxxx; loop start
STA $xxxx
INY
LDA $xxxx
STA $xxxx
DEY
INX
...
...
CMP #$7F
BNE $LOOP ; Branch (if A != #$7F) back to loop start.

// I believe that $0217 is the line position. The problem is, every #$01 increases the position by 2. I've been staring at that ASL right under AND #$01. If I can get it to print from 40-5E (evens), 41-5F (odds), 60-7E (evens), and 61-7F (odds again), I should be able to NOP another ASL and I'll be set.

Of course, it's not that simple. If I print 41-5F after 5E, it will still overwrite every even number from 42 on, I think. If I understand correctly, it doesn't actually alter the draw size, only the draw position. Instead, it would be best if I can get it to print from 40-4F straight, and then 50-5F, and so on, and instead of it reading the PPU in the dialogue window

lk hs  s
ieti, Ih
ol eale!
udb l st

(like this, I should be all set!)

// Of course, even if I get it to print that way in the PPU viewer, that's only half the job. I'd still have to modify it somehow to read from 40-4F and 50-5F (etc.) in the dialogue window.

[Ascended Mermaid]

0F:F739:AD 16 02 LDA byte_216 = #$0C ; Load the byte from $0216 (Letter position) to the Accumulator
0F:F73C:EA NOP ; I NOP'd this one. It was ASL.
0F:F73D:0A ASL ; For every ASL, multiply Accumulator by 2
0F:F73E:0A ASL ; For every ASL replaced by a NOP, I use half as much PPU.
0F:F73F:0A ASL ; If I didn't NOP any ASLs, it would print after 4 tiles.
0F:F740:0A ASL ; If I NOP 1 ASL, it would print after 2 tiles.
0F:F741:0A ASL ; If I NOP 2 ASLs, it would print every tile.
0F:F742:26 E9 ROL byte_E9 = #$16 ; I guess this shifts the byte in $00E9 left one bit?
0F:F744:85 E8 STA byte_E8 = #$F0 ; This stores the Accumulator to RAM
0F:F746:AD 1A 02 LDA byte_21A = #$00 ; This loads... I guess a partial line position?
0F:F749:4A LSR ; This divides the Accumulator by 2
0F:F74A:4D 17 02 EOR byte_217 = #$01 ; Exclusive OR, Absolute byte. Checks if A is ^ $0217? $0217 is the location of the Line Position byte.
0F:F74D:29 01 AND #$01 ; Logical AND, Immediate byte. Checks if A & #$01 match?
0F:F74F:0A ASL ; Multiply whatever it got out of that by two. It lost me at EOR.
0F:F750:05 E9 ORA byte_E9 = #$16 ; Logical OR, Zero Page. Checks if A does NOT match the byte at E9, #$16?
0F:F752:69 14 ADC #$14 ; Add with Carry, Accumulator + Memory + the Carry bit. In this case, I guess it adds #$14, plus however much the Carry bit is, plus 2 which makes the Accumulator #$16 at the time the debugger was snapped as seen in the following line.
0F:F754:85 E9 STA byte_E9 = #$16 ; Stores the Accumulator to RAM.

Hrm... I really need to think about this.

By the way, this line is preceded and followed by special opcode data. This data is as follows: 40, 41, 60, 61. In other words, it's the closest match I could find to the dialogue window table, being the labels of the first tiles on the left, from top to bottom. It doesn't change anything when altered, however.

// I feel so silly. So I NOP'd that pesky ASL under AND #$01. Everything appears correctly in the PPU viewer, but it's still scrambled in-game.

// It didn't increase the max number of lines, however. The game just stops writing at $5F and starts writing over from $40 again.

[Ascended Mermaid]

With that "partial line position" $021A, I can probably get it to write to line 3, but good luck getting it to write to line 4. Without that extra NOP, it writes on lines 1 and 3.

I guess I'll just see how the US/EU version is written. Maybe I'll learn something useful from SP's disassembly.

// DUH! That AND #$01... should be AND #$03! It's no wonder I was limited to two lines!

So okay, I have 4 lines. Maladjusted, given, but I have them.

[Ascended Mermaid]

I suppose I'll be spending my time replacing (the things that match, at least) the Japanese code with the US/EU codes. As a safeguard, I've backed up my last working build.

// Bah! There must be an easier way! >_> Maybe I should retry and keep track of which bytes I should associate with certain registers, instead of pretty much copying near verbatim (except for JSRs and JMPs, which I've been VERY careful of) the US/EU code.

// Great, it turns out I managed to screw something up, even in my backups. >_> I may have to rewind back to December 17th.

// That was quick and painless to recover from.

[Ascended Mermaid]

I've decided... I'm just going to add that ASL back in, and see if I can, with what knowledge I have, make the game write every other byte after every 'line break'.

// More trouble. I must've saved during a half-step or something. I was definitely in the middle of something. For the life of me, I can't figure out why it keeps going back half-width. >_>

[Xalphenos]

What is it you are trying to do right now? Still the 8x8 font? I would have to see it in action to tell for sure but it seems like you are attacking the routine that prints the ppu to screen textbuffer to the dialog window. It would be better to attack the routine that reads the font from the ROM. I can't tell for sure without seeing the code being run though.