[Chicken Knife]

@abw

Since I already did that while making my own table file earlier, try looking at 0x14014 - 0x14021; based on the pointer values, it looks like DQ2 uses 64 strings per pointer (but the individual strings are 1 byte per character and so short that it's still faster than reading through 16 English strings), and based on me tracking down a couple of random strings, the Japanese strings are not stored in the same order as the English strings.

My Japanese script extraction was successful. The only problem is that most of it came out in massive blocks of kana text. However, there were a ton of separated lines in the middle of the extract file and I'm going to guess that once nejimakipiyo takes a look at them they will turn out to be the battle and miscellaneous text that we need. Therefore we can probably ignore the lack of proper spacing for now but I will have to root out that issue when we do a real translation straight from the script dump. Thank you for the tips on getting the kana to show up properly in WindHex32. I didn't bother with that for now but I will probably need to use that in the future.

If you spend some time going through a trace log, you can track a string back to its source and then keep going further back to find the pointer to that string.

Figuring out this trace log process is probably the next thing I really need to learn in order to be effective in my role. I imagine this will not only help me with finding pointers and such but will also enable me to do more of the things I want with manipulating palette and tile assignments. Rather than ask you to type up a massive tutorial, let me try to read the documentation for FCEUX again and see what I can glean. There doesn't seem to be a lot out there to guide me through this process. A video or two exists on youtube but they are extremely introductory to the point of being little value. Once I spend some time reading, I'm sure I'll be returning to you with a list of questions on foggy concepts.

@nejimakipiyo

We really did do a hell of a job, mostly due to your research. The upcoming DQ3 item and monster names sound phenomenal and I'd say they are far more accurate and informed than any English translations we've seen. Can't wait to unleash them onto the world!

@everyone

Look out for an update to DQ1 Delocalized that I submitted last night. It includes a correction of a single typo found by my dedicated playtester. More significantly we also reconfigured several of the monster names. We've looked at all the wizard type enemies between DQ 1, 2 and 3 as a whole and tried to figure out which names were best for each monster from a translation standpoint. We also thought about making sure item and class names match up to the respective monster name when the Japanese word is shared between the two (ie Wizard's Wand will now be Sorcerer's Staff because it shares the same word with the tier 2 DQ1 wizard-type.) One caveat: while Horii opted to infrequently introduce a new monster with the same name as one of his prior monsters, we've opted to choose variant translations that capture the same meaning and provide each monster with a unique name.

The new progression in DQ1 is Wizard, Sorcerer and Grand Wizard. DQ2's will be Magus, Shaman and Warlock. DQ3's will be Magician, Evil Mage and Archmage.

Also, I think we have come up with a great translation of the Japanese enemy named Meda (Druin/Lunatick). The Japanese name is the word for Eyeball with the end of the word chopped off. We present our translation: "Eyeba." The GBC name Eyeber came close but ours comes closer still. It also has the alien kind of sound we were looking for. This is an example of the benefit that nejimakipiyo is bringing to this project--I was going to leave it "Meda" simply not knowing what to do with it.

I've linked to the new patch and updated release notes on the first post of this thread.   

[Chicken Knife]

@abw

We came across a text problem in DQ1 that is inherent to all versions of the game and I wanted to ask your advice on a potential fix.

Here is the problem: when you try to open a treasure chest containing an herb and you already have the max 6 herbs, the text produced indicates that the chest is empty. It's the exact same text that would produce if you tried to open an actually empty chest like the one where you obtain the Stone of Sunlight. However, if you are attempting to collect a non stackable inventory item like Torch but your inventory is full, the game will ask you if you want to throw something else out.

Our issue here is the false report that a chest containing herbs is empty. In fact, the text that should be produced is already in the game: the same message the item dealer tells you when you attempt to buy a 7th herb--something along the lines of having too many.

I haven't ever made an attempt at redirecting PRG instructions to a different line of text. I obviously can't just change the line of text because that would mess up the actual empty chests. Would this be something we could do?

[abw]

This appears to be a pretty easy fix, actually. Want to give it a try it on your own? I'll give you some hints, choose for yourself how many to read:

Spoiler:

Start with what you know - the text "Unfortunately, it is empty." gets displayed on screen when you open a treasure chest that contains an herb while you're already carrying the maximum number of herbs.

Spoiler:

You also know that string is in the block of strings starting at RAM $AA2E, and the pointer to that block is at RAM $801C.

Spoiler:

The game has to somehow decide to display that string before it can display it.

Spoiler:

The Trace Logger tells all!

Spoiler:

Setting a read breakpoint on $801C and then opening an herb chest with 6 in your inventory causes the debugger to snap here:

Code: [Select]

                $FCF1:A5 31     LDA $0031 = #$0E                             A:00 X:9F Y:02 S:EF P:nvUBdIZc
                $FCF3:0A        ASL                                          A:0E X:9F Y:02 S:EF P:nvUBdIzc
                $FCF4:AA        TAX                                          A:1C X:9F Y:02 S:EF P:nvUBdIzc
                $FCF5:BD 00 80  LDA $8000,X @ $801C = #$2E                   A:1C X:1C Y:02 S:EF P:nvUBdIzc


Spoiler:

Searching backwards in the trace log for $0031 shows that the pointer table index is derived from $0037:

Code: [Select]

        $FCD5:A5 37     LDA $0037 = #$DA                             A:4C X:00 Y:02 S:F7 P:nvUBdIZc
        $FCD7:28        PLP                                          A:DA X:00 Y:02 S:F7 P:NvUBdIzc
       $FCD8:20 30 00  JSR $0030                                    A:DA X:00 Y:02 S:F8 P:nvUBdIZC
         $0030:4C 1D B5  JMP $B51D                                    A:DA X:00 Y:02 S:F6 P:nvUBdIZC
         $B51D:20 32 B5  JSR $B532                                    A:DA X:00 Y:02 S:F6 P:nvUBdIZC
           $B532:85 1A     STA $001A = #$00                             A:DA X:00 Y:02 S:F4 P:nvUBdIZC
           $B534:29 F0     AND #$F0                                     A:DA X:00 Y:02 S:F4 P:nvUBdIZC
           $B536:4A        LSR                                          A:D0 X:00 Y:02 S:F4 P:NvUBdIzC
           $B537:4A        LSR                                          A:68 X:00 Y:02 S:F4 P:nvUBdIzc
           $B538:4A        LSR                                          A:34 X:00 Y:02 S:F4 P:nvUBdIzc
           $B539:4A        LSR                                          A:1A X:00 Y:02 S:F4 P:nvUBdIzc
           $B53A:85 1B     STA $001B = #$00                             A:0D X:00 Y:02 S:F4 P:nvUBdIzc
           $B53C:8A        TXA                                          A:0D X:00 Y:02 S:F4 P:nvUBdIzc
           $B53D:0A        ASL                                          A:00 X:00 Y:02 S:F4 P:nvUBdIZc
           $B53E:0A        ASL                                          A:00 X:00 Y:02 S:F4 P:nvUBdIZc
           $B53F:0A        ASL                                          A:00 X:00 Y:02 S:F4 P:nvUBdIZc
           $B540:0A        ASL                                          A:00 X:00 Y:02 S:F4 P:nvUBdIZc
           $B541:65 1B     ADC $001B = #$0D                             A:00 X:00 Y:02 S:F4 P:nvUBdIZc
           $B543:18        CLC                                          A:0D X:00 Y:02 S:F4 P:nvUBdIzc
           $B544:69 01     ADC #$01                                     A:0D X:00 Y:02 S:F4 P:nvUBdIzc
           $B546:85 31     STA $0031 = #$1D                             A:0E X:00 Y:02 S:F4 P:nvUBdIzc


Spoiler:

Searching further backwards in the trace log shows where $0037 get set:

Code: [Select]

        $FD3F:85 37     STA $0037 = #$00                             A:DA X:00 Y:02 S:F7 P:nVUBdIzC


Spoiler:

And a little further back is where A gets set:

Code: [Select]

    $C7E4:A5 3C     LDA $003C = #$DA                             A:00 X:00 Y:02 S:FB P:nvUBdIZC


Spoiler:

And if you keep going, you'll find out where $003C's value comes from:

Code: [Select]

  $E233:A9 DA     LDA #$DA                                     A:FA X:00 Y:02 S:FD P:nvUBdIZC
  $E235:4C 42 D2  JMP $D242                                    A:DA X:00 Y:02 S:FD P:NvUBdIzC
  $D242:20 BD C7  JSR $C7BD                                    A:DA X:00 Y:02 S:FD P:NvUBdIzC
    $C7BD:85 3C     STA $003C = #$0E                             A:DA X:00 Y:02 S:FB P:NvUBdIzC


Spoiler:

So, if you change 0xE244 to the index of the string you want to use, you'll get different text when you open that herb chest; if you don't want to use any of the existing strings, you can probably cannibalize one of the 3 empty strings ($96, $C2, $DD) to use for your new string.

Spoiler:

Bonus: if you check the rest of the code around this area, you'll notice that $E230 also gets executed when you open a chest containing a Magic Key but already have 6 keys, so whatever string you use for herb chests will also get used for key chests; on the other hand, there are no key chests in the game that you can open while holding 6 keys, so that's really only relevant if you're going to combine the script update with e.g. a map hack.

[AdamDravian]

I've been following this project for a while and really like what you're doing. I feel the exact same way about Dragon Quest's localization (well, almost--I prefer Loto to Roto, heh.).

I've played the first three games in the series, but I've been holding off on playing DQIV until you give that your treatment. Thanks a lot for doing this.

[Chicken Knife]

@abw,

Thanks for the help. I like your approach with the spoilers as to not give me the answer right away. This seems like a nice and small first task with FCEUX's debugging tools. Here's the problem. For your fifth hint, I went into FCEUX's hex editor RAM section, went to $801C and set a read breakpoint. I noticed something was amiss however because the whole section of data starting at $8000 in the RAM goes through a changing cycle every few seconds which makes me think it has something to do with the game's overall timing. When I placed the read breakpoint for $801C regardless, it gave me this data

>03:FF78:A5 02     LDA $0002 = #$01
 03:FF7A:D0 FC     BNE $FF78
 03:FF7C:60        RTS ------------

There must be something I'm fundamentally not understanding here..

@AdamDravian, thank you for the support! Just so you know, the version of 3 I have here is extremely preliminary with only some updates to item/monster/spell namings and graphics. We are working now on the actual retranslation and you can expect a huge update in the next couple months hopefully with all the text revised plus further updates to items/names/monsters/etc.

@Everyone

Nejimakipiyo and I have been working very hard recently on a major update to the first two games and all future releases where we are moving away from the pure Japanese spell names. Earlier on in the project, I was convinced that the Japanese names had no meaning whatsoever and that simply reproducing them in this hack would be the most authentic approach. Nejimakipiyo had noticed months ago that a minority of the names had components of words that conveyed meaning but it didn't seem like enough of them to rethink the approach to our project. Now after weeks of continuous research, especially through use of Japanese wiki sites, we have determined that a large majority of the Japanese spell names actually do have meaning or create sound or visual impressions to a Japanese native speaker. After thinking this through and listening to the feedback of a majority of people who have been turned off by our use of meaningless Japanese spell names, we have decided to create a new English system. This new system strives to utilize basewords that carry meaning but to use the same kinds of suffixes (or occaisionally prefixes) that are used in the Japanese names themselves. This is kind of like the contemporary Final Fantasy system but with variation of the suffixes between the spell families.

Two examples:

New Name     Japanese name   Original English

Blaze              Mera                 Blaze
Blazami          Merami             Blazemore
Blazoma         Merazoma         Blazemost

Flare             Gira                   Hurt/Firebal
Flarama         Begirama           Firebane
Flaragon        Begiragon           Firevolt

For Mera family, Blaze was a fine translation and we are happy to keep some connection to the original US namings when they are accurate.
For the Gira family, none of the prior English versions have conveyed the actual meaning of the Japanese base word Giragira which is a reaction to bright light. Flare seems ideal because it refers to a flash of light and also corresponds well to the burning effect of the spell.

[AdamDravian]

Nejimakipiyo and I have been working very hard recently on a major update to the first two games and all future releases where we are moving away from the pure Japanese spell names. Earlier on in the project, I was convinced that the Japanese names had no meaning whatsoever and that simply reproducing them in this hack would be the most authentic approach. Nejimakipiyo had noticed months ago that a minority of the names had components of words that conveyed meaning but it didn't seem like enough of them to rethink the approach to our project. Now after weeks of continuous research, especially through use of Japanese wiki sites, we have determined that a large majority of the Japanese spell names actually do have meaning or create sound or visual impressions to a Japanese native speaker. After thinking this through and listening to the feedback of a majority of people who have been turned off by our use of meaningless Japanese spell names, we have decided to create a new English system. This new system strives to utilize basewords that carry meaning but to use the same kinds of suffixes (or occaisionally prefixes) that are used in the Japanese names themselves. This is kind of like the contemporary Final Fantasy system but with variation of the suffixes between the spell families.

Two examples:

New Name     Japanese name   Original English

Blaze              Mera                 Blaze
Blazami          Merami             Blazemore
Blazoma         Merazoma         Blazemost

Flare             Gira                   Hurt/Firebal
Flarama         Begirama           Firebane
Flaragon        Begiragon           Firevolt

For Mera family, Blaze was a fine translation and we are happy to keep some connection to the original US namings when they are accurate.
For the Gira family, none of the prior English versions have conveyed the actual meaning of the Japanese base word Giragira which is a reaction to bright light. Flare seems ideal because it refers to a flash of light and also corresponds well to the burning effect of the spell.

Nice. I really like this approach. I'm curious to know what you're going to do with Hoimi, since that's a really iconic word in Japan and it already sounds a bit like Heal.

[nejimakipiyo]

Hello @AdamDravian!

Hoimi was a difficult one. Because the word "Hoimi" itself has no meaning and was just chosen for the sound and impression it conveys, I really wanted to preserve it as well. After all, this would be a reflection of Horii's intentions. And I do think it has a pleasant sound!

However, we decided that it'd be necessary to translate the other "nonsense" spell names, such as Ru-ra, Remi-ra, and Riremito, because they are simply not accessible to English-speaking players who have no familiarity with the Japanese names. I was streaming my playthrough of DQ1 Delocalized and the biggest negative reaction from viewers was about the Japanese nonsense words. The sad part is that in translating the other no-meaning words, preserving Hoimi would have been jarring and incredibly inconsistent.

The plus side is that we did keep the suffixes for the Hoimi family of spells as close as we could.

The new set of healing spells are as follows:

New Name     Japanese name   Original English

Heal          Hoimi          Heal
Helimi        Behoimi        HealMore
Heloma        Behoma         HealAll
Helomara      Behomara       HealUs
Helomazun     Behomazun      HealUsAll

[abw]

Thanks for the help. I like your approach with the spoilers as to not give me the answer right away.

Yeah, I figured that would be a nice balance between "too much help" and "not enough help". I'm trying to get better at this .

I noticed something was amiss however because the whole section of data starting at $8000 in the RAM goes through a changing cycle every few seconds which makes me think it has something to do with the game's overall timing.

That's bank swapping at work - as the game makes different ROM banks visible in the RAM bank at $8000-$BFFF, the RAM section of the Hex Editor will update to show the new bank instead of the old bank. You'll also see other sections of RAM (e.g. $5000-$6FFF) changing rapidly as the game goes about its business; that's all perfectly normal.

When I placed the read breakpoint for $801C regardless, it gave me this data

>03:FF78:A5 02     LDA $0002 = #$01
 03:FF7A:D0 FC     BNE $FF78
 03:FF7C:60        RTS ------------

There must be something I'm fundamentally not understanding here..

Ah, I see what's going on here. Whenever you open the Debugger window, FCEUX puts the currently executing line into view (but doesn't actually pause emulation), which in Dragon Warrior's case is very likely to be the "wait for VBlank" busy loop at $FF78-$FF7A, and when you add a breakpoint from the Hex Editor while the Debugger is closed, FCEUX opens the Debugger for you, so that's what you'll almost always see. If you keep playing the game until your breakpoint is reached, FCEUX will pause emulation and switch focus away from the game window to the Debugger window, at which point you should see something closer to what I posted.

One thing to watch out for is that the breakpoints you add from the Hex Editor window contain a condition that specifies which ROM bank the RAM address must correspond to; if you add the breakpoint while the right ROM bank is in RAM, this is great since it avoids the breakpoint triggering when the RAM address corresponds to a ROM bank you're not interested in, but if you add the breakpoint while the wrong ROM bank is in RAM, you'll get a breakpoint for the wrong ROM bank. If that happens, just edit the breakpoint condition to specify the right ROM bank (T==#02 for the bank with the dialogue pointers) or remove the condition completely and let it fire regardless of which ROM bank is currently loaded. In this particular case removing the condition should be fine since you aren't likely to get any false positives from the other ROM banks.

spell names

+1 for this - it is very nice to have some idea of what your spell is going to do without having to consult the game manual / patch readme every time you want to use magic .

[einlanzer]

I appreciate these types of hacks when they're done well, but just a quick word of warning from someone with a lot of experience in this area that a lot of romhackers and JP enthusiasts often fail to understand:

Literal translations are typically inferior to translations that take a bit of localization liberty. Even technically superior translations (like many of SE's updated ports of older games) end up being inferior in practice because of feeling stilted to western audiences.

CT is a prime example of this - there was a very detailed analysis of the original Woolsey script compared to the new DS one that eventually revealed a consensus that, despite its many technical errors, the Woolsey script was better overall because it took liberties to adapt the script to a western audience instead of fussing over accuracy, leading to greater & more believable emotional expression within dialogue and, therefore, higher contextual immersion and character relatability.

[Chicken Knife]

@Einlanzer,

Your feelings about fan translations in general sound very close to my own. I don't want to start naming names and losing friends here, but I agree that many fan translations have done more harm than good. There are times where someone has an incredible gift like Ryuusi in his retranslation of Breath of Fire II. His version provides far greater emotional resonance, clarity of plot, and even heaps of laughter. Those of us doing the writing for this project are probably not on Ryuusi's level but we try very hard to make sure the language we convey is warm, relatable and lacks any awkwardnes in being overly literal. We've taken liberties when there is no way a literal translation can avoid that awkwardness and I am particularly sensitive to that.

The thing I'm not clear on from your post is whether you are admonishing us in general or whether you have played some of the hack and are speaking directly about our work. If you are, don't hold back with any specific feedback. I care more about the result we are trying to achieve than protecting our egos. If you haven't played any of it then please give it a try and offer your reaction afterwards. I honestly haven't had any critical feedback from players who are at my level of sensitivity for these things and would love to receive it. So far reactions have been very positive. You may object to my inclusion of certain Japanese curio like the line in Melkido / Cantlin about a woman offering to trade her copy of Portopia for your copy of Dragon Quest. Those are debatable matters, and a lot of people love to have a flavor for Horii's original work. This project doesn't aspire to be the end all be all Dragon Quest translation; just one with a different approach and hopefully of high quality. As someone who has played these games a hundred times I've always had a sense of Horii's own style shining through in a muddled way; I wanted to make it shine through much more clearly--with great sensitivity to the differences in language.

[mariosmentor]

I appreciate these types of hacks when they're done well, but just a quick word of warning from someone with a lot of experience in this area that a lot of romhackers and JP enthusiasts often fail to understand:

Literal translations are typically inferior to translations that take a bit of localization liberty. Even technically superior translations (like many of SE's updated ports of older games) end up being inferior in practice because of feeling stilted to western audiences.

CT is a prime example of this - there was a very detailed analysis of the original Woolsey script compared to the new DS one that eventually revealed a consensus that, despite its many technical errors, the Woolsey script was better overall because it took liberties to adapt the script to a western audience instead of fussing over accuracy, leading to greater & more believable emotional expression within dialogue and, therefore, higher contextual immersion and character relatability.

Your argument, I'm afraid, is outright weak. Just because a foreign culture sees various subjects differently doesn't give localization teams the right to completely do away with the creator's original intention.

Take a look at Mega Man 7 on the SNES, for example. After the final battle with Dr. Wily, Mega Man threatens to kill the mad scientist. Wily reminds him that the Asimovian laws integrated into his code forbid this, and in the Japanese version, Mega Man becomes silent, proving that Wily is RIGHT. Mega Man is truly powerless to stop him once and for all, explaining why he never tried to kill the man before, and why he never will. The English version changes this scene, having Mega Man proclaim that he is more than a robot, and tries to kill him anyway, only to be stopped by Bass. This is in direct contradiction to the series lore. Even X, one of the first robots to truly express human emotion and conscious thought, rather than predetermined routines dictated by code, was still, by the end of the day, a robot. Nothing more, nothing less. Going against pre-established lore and character development for the sake of making a story sound better for an audience the creator never had in mind to begin with CAN ONLY WORSEN THE EXPERIENCE IN THE LONG RUN. And if you think my argument about the creator's intent is ultimately baseless, here's a quote from J.R.R. Tolkien regarding a translation of his novels that, like Chrono Trigger, took liberties for the sake of storytelling:

"In principle I object as strongly as is possible to the 'translation' of the nomenclature at all (even by a competent person). I wonder why a translator should think himself called on or entitled to do any such thing. That this is an 'imaginary' world does not give him any right to remodel it according to his fancy, even if he could in a few months create a new coherent structure which it took me years to work out. [...] May I say at once that I will not tolerate any similar tinkering with the personal nomenclature. Nor with the name/word Hobbit."

[Arjak]

Your argument, I'm afraid, is outright weak. Just because a foreign culture sees various subjects differently doesn't give localization teams the right to completely do away with the creator's original intention.

Take a look at Mega Man 7 on the SNES, for example. After the final battle with Dr. Wily, Mega Man threatens to kill the mad scientist. Wily reminds him that the Asimovian laws integrated into his code forbid this, and in the Japanese version, Mega Man becomes silent, proving that Wily is RIGHT. Mega Man is truly powerless to stop him once and for all, explaining why he never tried to kill the man before, and why he never will. The English version changes this scene, having Mega Man proclaim that he is more than a robot, and tries to kill him anyway, only to be stopped by Bass. This is in direct contradiction to the series lore. Even X, one of the first robots to truly express human emotion and conscious thought, rather than predetermined routines dictated by code, was still, by the end of the day, a robot. Nothing more, nothing less. Going against pre-established lore and character development for the sake of making a story sound better for an audience the creator never had in mind to begin with CAN ONLY WORSEN THE EXPERIENCE IN THE LONG RUN. And if you think my argument about the creator's intent is ultimately baseless, here's a quote from J.R.R. Tolkien regarding a translation of his novels that, like Chrono Trigger, took liberties for the sake of storytelling:

"In principle I object as strongly as is possible to the 'translation' of the nomenclature at all (even by a competent person). I wonder why a translator should think himself called on or entitled to do any such thing. That this is an 'imaginary' world does not give him any right to remodel it according to his fancy, even if he could in a few months create a new coherent structure which it took me years to work out. [...] May I say at once that I will not tolerate any similar tinkering with the personal nomenclature. Nor with the name/word Hobbit."

That seems to me to be a different issue altogether. There's a huge difference between rephrasing something to get the same point across better in a different language, and completely changing the intent of a story to "make it better." Mega Man 7 is the latter.

I agree with you that changing the dialogue in the ending to that game was a huge mistake, clearly made to try to spice things up in a way that doesn't fit with the world and scenario, and is a huge middle finger to the original creators. It shows zero respect to the source material.

However, translation is more art than science. Every language has nuances that are easily lost when translating literally to another. A translator's job is to get the same information from one language to come across the same way in another. That's not easy. Because of the differences in how each language works, sometimes a little tinkering is required to get the same effect, and as long as the translator and editor don't interject their own intent, and hijack the story, I think that a little tinkering is fine.

It's the difference between translating, "Konichiwa, Senpai! Genki desu ka?" as "Hello, elder classmate! Are you well today?" or "Hey, man! How're you doing?"

[nejimakipiyo]

As the one doing most of the actual translating, and because I've been translating Japanese content to English for about a decade, I'd like to chime in here.

Everybody who commented with regard to translating has very valid points and I don't think anyone is "wrong" or "right" per se. Translating is a delicate balance and there's no way to get all ideas from one language to another every time. With the exception of single-word utterances, something will be lost in translation. That's a guarantee. As translators we learn to live with that, and strive to reflect the source material accurately while still making the content accessible to the audience. So we'll take liberties where liberties need to be taken, but we have no intentions of hijacking the storyline to suit our own agenda.

If anyone has actually played this hack, or is willing to give it a run to test our language use, I'd also be more than happy to hear feedback!

[Chicken Knife]

@abw,

I took your suggestion and went into the same room as a treasure chest that contained an herb prior to setting a read breakpoint. (I'm visiting the chest in Garai/Garinham past the locked door.) My problem is that no matter what areas I visit, the RAM data viewable in the hex editor starting at $8000 is all uniformly updating to different values every couple seconds no matter whether anything is going on in the game or not. Any read break point I set at the $801C address triggers immediately--not when I open the chest, and provides a trace log result different than the one you indicated.

[abw]

Hmm, maybe it's time to back up a step and verify some assumptions. Which ROM are you using? That $801C breakpoint fires only when I want it to when I use one of the unaltered English ROMs (PRG0 or PRG1), but if you're looking at a hacked ROM, that could be a different story, and I haven't checked the original Japanese ROM. The basic methodology should still work, but you might need to try setting a breakpoint on the string itself rather than its pointer. The breakpoint should look like this in the Debugger window:

$801C:ECR---

Having a breakpoint is nice, but it's not actually necessary for this - you can just let the Trace Logger run and examine its output after the text gets displayed, you'll just have a larger file to deal with than if you halted the trace when the breakpoint fired. You can also reduce the size of the log by getting as close to triggering the behaviour you're interested in as possible (e.g. standing on the chest with the COMMAND menu open and the cursor on TAKE), then pausing the emulator, start the log, hold down the "A" button on the controller (or whatever you have that mapped to on whatever input device you're using), and then use the \ (backslash) key to advance emulation by one frame at a time until you've triggered the behaviour (i.e. the "Unfortunately, it is empty." text starts getting printed), and then stop the log.

[Chicken Knife]

@abw

I sent you a private message that should help you observe exactly what I'm dealing with.

[abw]

Thanks - I'm replying here in case it ends up being helpful for others too!

If your Hero's still marching in place and the music's still playing, you haven't hit a breakpoint yet . To see the difference, add a $A832:ECR--- breakpoint (i.e. a read breakpoint on the pointer to the list of spell names) and then try casting a spell. Adding the breakpoint itself doesn't affect anything (other than FCEUX pausing emulation while you're in the process of adding the breakpoint), you can still walk around and open the COMMAND menu just fine, and the Hex Editor will keep on displaying whatever it feels like displaying in whatever colours it wants, but as soon as you try to open the SPELL menu, gameplay grinds to a screeching halt and focus shifts to the Debugger window, which in this case ought to display something like this:

Code: [Select]

>01:A825:BD 30 A8  LDA $A830,X @ $A832 = #$56
 01:A828:85 A1     STA $00A1 = #$7A
 01:A82A:BD 31 A8  LDA $A831,X @ $A833 = #$BE
 01:A82D:85 A2     STA $00A2 = #$A4
 01:A82F:60        RTS -----------------------------------------


[Chicken Knife]

abw,

When I've placed the read breakpoint at the referenced address, prior to opening the chest the game immediately pauses and switches over to the debugger screen that shows the log of instructions. It's firing off immediately because code in the game is causing that address to change its data every couple seconds. My hero is definitely not marching in place and no music is playing.

I feel like there is going to be a really silly reason for this huge discrepancy in what we are experiencing. 

[abw]

Yeah, I don't know what to say here . The video you PM'd me definitely had marching in place, music, and no breakpoints firing. The Hex Editor was covering most of the Debugger window, so I couldn't see exactly what you had there, but the Hex Editor was still flashing updates as bankswaps happened, so that's another indication the game was still running.

I did a quick search for FCEUX debugger videos and came across https://www.youtube.com/watch?v=jfnqxxwlIyo; the section from 7:30 to 7:40 shows what a breakpoint hit looks like.

[Chicken Knife]

@abw

Ok. I watched that section of the video. I've watched this video a couple times already in addition to the one playing around with Dr. Mario. It doesn't look like anything I haven't been doing.

The video link I sent previously wasn't the whole process; I was only highlighting the fact that the block of text starting $8000 was getting updates on a timed basis.

I did a new video below where I walk you through the whole process. HOPEFULLY we can finally clarify what I'm doing wrong. Sorry this has been such a massive back and forth ordeal. Maybe I'll jump to doing a video like this right away next time. And I may want to figure out how to capture video directly from the screen instead of holding my phone up to the screen at some point. See video below.

https://www.dropbox.com/s/3q84cw4kaopwbqy/IMG_2933.MOV?dl=0