[Chicken Knife]

Yeah, given that the first 96 posts in this thread are all about Dragon Warrior 1 and 2 (mostly about 2), it might be worth changing the thread title to reflect that .

How revoltingly...sensible of a suggestion. There we are.

PS: Don't be surprised when I change the subject further to Dragon Warrior 1, 2 & 3 

[abw]

How revoltingly...sensible of a suggestion. There we are.

I try to come up with one of those every now and then.

PS: Don't be surprised when I change the subject further to Dragon Warrior 1, 2 & 3 

I await the day!

[Chicken Knife]

@abw

Ok, the day has arrived that I'm seriously trying to get extraction and insertion rolling. I would have loved to have gotten further than step 1 on my own.

The first challenge I'm facing is the fact no one seems to have posted the start and end addresses of the dialogue pointers for DW3 like was done for the first two games. It's easy enough to see the actual storage of the dialogue based on loading the posted table file into a hex editor but I'm not having much success in my attempts to trace back to the block of pointers based on my formerly useful methods. I have a feeling you're going to tell me that debugging is the best way to determine them and... I need to get better at that. Also, I'd imagine this would have to be broken up into a part 1 and part 2 based on the previous extractions? I think that had to do with the final strings being a different length but I'm not 100 percent clear.

**EDIT I just want to clarify, I'm not waiting for you to find the pointer table for me. I'm going to continue to be poking and prodding.

[abw]

The first challenge I'm facing is the fact no one seems to have posted the start and end addresses of the dialogue pointers for DW3 like was done for the first two games. It's easy enough to see the actual storage of the dialogue based on loading the posted table file into a hex editor but I'm not having much success in my attempts to trace back to the block of pointers based on my formerly useful methods. I have a feeling you're going to tell me that debugging is the best way to determine them and... I need to get better at that. Also, I'd imagine this would have to be broken up into a part 1 and part 2 based on the previous extractions? I think that had to do with the final strings being a different length but I'm not 100 percent clear.

Debugging is always a way, but there's nothing wrong with trying an educated guess or two first. You already know from the first two games that they only store a pointer to the first string in a block of 16 strings, so maybe DW3 does the same. If you take the start of the text you can read easily at 0x40010, count ahead 16 strings to 0x40190, convert those to RAM addresses $8000 and $8180, and then search the ROM for 00808081, you should get a hit at 0x28080. Et voilà!

DW3's text is approximately twice the size of DW2's, and it's not compressed, so it sprawls over 6 banks and not every bank ends with a full 16 strings, so you'll need to split the extraction into several parts, but other than being a bit dull and repetitive, it shouldn't pose any problems.

Hmm, the Text section of the DW3 ROM map on the wiki does look woefully inadequate... let's see if we can pump it up a little .

[Chicken Knife]

Debugging is always a way, but there's nothing wrong with trying an educated guess or two first. You already know from the first two games that they only store a pointer to the first string in a block of 16 strings, so maybe DW3 does the same. If you take the start of the text you can read easily at 0x40010, count ahead 16 strings to 0x40190, convert those to RAM addresses $8000 and $8180, and then search the ROM for 00808081, you should get a hit at 0x28080. Et voilà!

DW3's text is approximately twice the size of DW2's, and it's not compressed, so it sprawls over 6 banks and not every bank ends with a full 16 strings, so you'll need to split the extraction into several parts, but other than being a bit dull and repetitive, it shouldn't pose any problems.

Hmm, the Text section of the DW3 ROM map on the wiki does look woefully inadequate... let's see if we can pump it up a little .

The problem with my attempts to search for the pointer was getting way too many hits. Combining two addresses being pointed to and then searching is one hell of a great idea. This is what I pay you for!

Doing some updates to the ROM information sounds like a good idea. I'll make sure to do that.

As far as counting the strings manually at the ends of rom banks and setting up separate sections for each, that sounds doable!

One more thing I'm foggy on though. I'd say that our script increased in size somewhere between 5-10 percent. Seeing the massive chunk of blank space after the existing text made this seem like not much of a problem. But how big of a problem would it be if the text creeps into another rom bank?

Also, to your comment of DW2 and DW3's text size being roughly equivalent, that's actually shocking to hear. DW3 not only has more towns but has a day / night cycle that would seem to almost double the text. The translating / writing process definitely *felt* like it took 3x as long.

[Choppasmith]

Speaking of translating and inserting, I'm ready to start inserting my changes and testing DQ2.

Abw, I downloaded abcde v4 and saw your setup and tables for all the various things (seriously WOW). Unless I missed something, when extracting, the atlas.txt didn't add the table changes (easy to add myself) or the JMP commands for jumping to various parts of the ROM (a little trickier). Was abcde SUPPOSED to add those? (I did sort of Frankenstein my whole atlas.txt adding the other parts from the new version (credits, menus, etc) to my original which was just the script plus item and monster names). I'm wondering if I missed something somewhere and should just rip from scratch, or if I just have to add those JMP commands. Thanks.

[abw]

Combining two addresses being pointed to and then searching is one hell of a great idea. This is what I pay you for!

*cha-ching* .

Doing some updates to the ROM information sounds like a good idea. I'll make sure to do that.

That was actually a (very) roundabout way of hinting that I had just fleshed out the text section a little bit. Definitely add anything I missed, though!

I'd say that our script increased in size somewhere between 5-10 percent. Seeing the massive chunk of blank space after the existing text made this seem like not much of a problem. But how big of a problem would it be if the text creeps into another rom bank?

Overflowing any of the ROM banks is a problem, but hopefully not one that will be difficult to overcome. The existing text is uncompressed, so if you're only over by 5-10%, adding a simple compression like DTE (which usually gets you 30-40% compression) should be more than enough. The existing text is also spread over multiple banks and there is a large chunk of free space in the final text bank, so probably there's a tiny data table somewhere that controls which bank gets loaded for each string, and you could modify that to shift the text around between banks or even extend it to use one (or more) of the existing empty banks.

Also, to your comment of DW2 and DW3's text size being roughly equivalent, that's actually shocking to hear. DW3 not only has more towns but has a day / night cycle that would seem to almost double the text. The translating / writing process definitely *felt* like it took 3x as long.

DW3 definitely has much more text than DW2. It depends exactly what you count and how, but 3x sounds about right. That "twice" was clearly a typo for "thrice" and not at all me just throwing out a number based on some vague recollection from a script size comparison I did months ago .

Abw, I downloaded abcde v4 and saw your setup and tables for all the various things (seriously WOW).

Heh, possibly my setup is overkill, but I like having the non-text data embedded in the script show up all nice and pretty in my script dumps; it saves me from having to go back to look up what the data is for every time I'm editing things, plus I can do all of its editing/inserting as part of the same process for editing/inserting the script.

Unless I missed something, when extracting, the atlas.txt didn't add the table changes (easy to add myself) or the JMP commands for jumping to various parts of the ROM (a little trickier). Was abcde SUPPOSED to add those?

Yeah, I've been of two minds about this. When you're not making any changes to the text engine, it would be nice to have more of the insert commands generated for you by the extract process, but when you are making engine changes, having insert commands based on the old engine is kind of annoying. Hmm, maybe I'll just add an option for that and let the end user decide what they want. For now, though, abcde does NOT add everything you'll want in your insert script, but usually it only takes a couple of minutes to add the missing parts yourself.

[Choppasmith]

So, I was running into some problems

First more of a program usage question abw, when trying to use abcde with all those tables I get

Code: [Select]

table 'C:\Users\mog11\Downloads\abcde_v0_0_4\menu_params.tbl' contains a control code table switch parameter to non-existant table 'heights' at C:\Users\mog11\Downloads\abcde_v0_0_4/abcde/Table/Table.pm line 82. at Atlas.txt line 0!

C:\Users\mog11\Downloads\abcde_v0_0_4>pause
Press any key to continue . . .

They're all in the same folder so I'm not sure what I'm missing here.

Also, for the asar usage, in your coding suggestions I see an added table file with inputting text with you noting "you can input these manually if you don't want to bother with a table $36,$18,$16,$0E,$FA ;" I thought I'd try this and just entered those bytes on a line and asar said it didn't understand the command. Is it db or something else? Also, just curious is the warnpc: address I see in some asm files is that a way to warn you if your code goes past a certain point?

Okay, so even worse news for me is that somehow or another my "base" rom (pre-script insert but had the new dictionary and item/monster name values changed) became corrupt somehow so I had to start over. I changed the dictionary and also from my notes changed the second script bank from 02 to 0C (bank 12) via x03FA92 and I'm getting garbled text (it also freezes once you get past the Prologue when starting a new game) I even cut out the extra stuff from the atlas.txt to focus just on the script, and I have no idea what happened.

This still looks correct, right?

// Define, load, and activate a TABLE
#VAR(Table, TABLE)
#ADDTBL("dw2_script_NEW.tbl", Table)
#ACTIVETBL(Table)

// add this near the top of the insert script:
#VAR(pointerNum, COUNTER) // create a COUNTER variable named pointerNum
#CREATECTR(pointerNum, 8, 0) // pointerNum is an 8-bit value initialized to 0
#AUTOCMD($17FE7, #WLB(pointerNum, $3FA90)) // update the code that controls which pointer starts the next bank

// Jump to start of script
#JMP($14010)
#HDR($C010)

// auto-commands for when DW2 does a mid-string bankswap and resets its read address:
#AUTOCMD($17FE7, #HDR($28010))
#AUTOCMD($17FE7, #JMP($30010, $3400F))

Really at a loss here.

[abw]

First more of a program usage question abw, when trying to use abcde with all those tables I get

Code: [Select]

table 'C:\Users\mog11\Downloads\abcde_v0_0_4\menu_params.tbl' contains a control code table switch parameter to non-existant table 'heights' at C:\Users\mog11\Downloads\abcde_v0_0_4/abcde/Table/Table.pm line 82. at Atlas.txt line 0!

They're all in the same folder so I'm not sure what I'm missing here.

What command were you running? The Atlas.bat script included in the examples folder does include all the required tables and works for me. It sounds like maybe you didn't include heights.tbl on the command line or inside your Atlas.txt file.

Also, for the asar usage, in your coding suggestions I see an added table file with inputting text with you noting "you can input these manually if you don't want to bother with a table $36,$18,$16,$0E,$FA ;" I thought I'd try this and just entered those bytes on a line and asar said it didn't understand the command. Is it db or something else? Also, just curious is the warnpc: address I see in some asm files is that a way to warn you if your code goes past a certain point?

Yup, the full line would be something like "db $36,$18,$16,$0E,$FA". I did say that I hadn't tested it . The xkas/Asar documentation describes what warnpc is supposed to do, though I vaguely recall having issues at some point with it not actually working. Might be worth giving it a test to confirm its behaviour.

Okay, so even worse news for me is that somehow or another my "base" rom (pre-script insert but had the new dictionary and item/monster name values changed) became corrupt somehow so I had to start over. I changed the dictionary and also from my notes changed the second script bank from 02 to 0C (bank 12) via x03FA92 and I'm getting garbled text (it also freezes once you get past the Prologue when starting a new game)

And this is why having a fully scripted insert process backed by source file version control is a Good Idea™ . For the crash, try modifying 0x3FA94 instead - 0x3FA92 is the +$02 in "BCC +$02", so changing that to "BCC +$0C" would probably have disastrous results.

[Choppasmith]

So 1. I was using the old bat file I was using for my initial script inserts. Didn't realize you had to add ALL the tables to the command line. Lesson learned.

2. After a good 3 HOURS of trial and error, I found that it was indeed my dictionary text causing problems. I still don't know what exactly but since I was using the DW2 menu table to edit it, there must've been a random wrong byte getting swapped in somehow. To avoid future problems I just made a separate dictionary table and all is well again.

3.

And this is why having a fully scripted insert process backed by source file version control is a Good Idea™ . For the crash, try modifying 0x3FA94 instead - 0x3FA92 is the +$02 in "BCC +$02", so changing that to "BCC +$0C" would probably have disastrous results.

In my defense, having the same values right next to each other is sure easy to change the wrong one.

4. Now I can start messing around with those battle routines and I'm not having much luck so far. But so far with enemies I'm actually getting stuff like "(Hero name) appears!" for single enemies. Takign your suggestions from other posts, I did manage to combine a couple.

Code: [Select]

norom

org $1150C
base $94FC

LDA #$52
STA $A8 ; initialize per-group string ID to use in multi-group battles
LDA #$00
STA $A7 ; initialize total # of empty groups processed
process_group_string:
JSR $9EEE ; given an index (in A) into the array of structures at $0663, set $B5-$B6 to the address of the corresponding item inside that structure
LDY #$09
LDA ($B5),Y
STA $8F ; number of monsters in this group
BEQ done_display_string ; 0 monsters => no string to print
INC $A8 ; string ID to use for this group
LDY #$00
LDA ($B5),Y
STA $0161 ; current monster ID
LDX #$00
JSR $9CD6 ; write monster name in A (+ monster number within its group in X, if > 0) to $6119
LDA $60D8 ; total number of non-empty enemy groups in the current battle
CMP #$01
BEQ display_string ; if there's only 1 group, then use string ID #$0001 (change the text to be appropriate)
LDA $A8 ; otherwise use the per-group string ID (also change those texts to be appropriate)
display_string:
JSR $9CCA ; for A < #$60, display string ID specified by A; for A >= #$60, display string ID specified by A + #$A0
done_display_string:
INC $A7
LDA $A7
CMP #$04
BCC process_group_string
LDA $60D8 ; total number of non-empty enemy groups in the current battle
BNE next_section
LDA #$02 ; String ID #$0002: But it wasn't real.[end-FC]
JSR $9CCA ; for A < #$60, display string ID specified by A; for A >= #$60, display string ID specified by A + #$A0
LDA #$FD
STA $98 ; outcome of last fight?
JMP $9685
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP

next_section:

Code: [Select]

norom ; stop Asar from trying to apply SNES memory mapping to this NES code
org $00BF00 ; set the ROM file insertion point
base $8EF0 ; set the starting RAM address

LDA $0161 ; monster ID for the current group
CMP #$4E ; bosses have IDs >= #$4E (so does the "Enemies" monster, but that's not a monster ID you can encounter)
BCS no_change
SEC ; not strictly necessary since we got here by BCS and nothing has changed C
RTS
LDY $8F    ; number of monsters in group
DEY        ; count from 0 instead of 1
BEQ one     ; 0 => only one monster => handle "A" vs "An"
LDX #$00    ; read index
LDY #$00    ; write index
loop:
LDA some,X ; Monster Counts text
STA $60F1,Y ; start of text variable buffer
INY       
INX       
CMP #$FA    ; [end-FA]
BNE loop  ; if not end token, keep copying
done:
SEC        ; SEC to trigger read of [end-FA]-terminated string from $60F1, CLC to use A
RTS       
some:
db $36,$18,$16,$0E,$FA ;"Some" not using a table here
one:
; at this point we know Y = 0
LDA #$24 ; "A"
STA $60F1,Y ; start of text variable buffer
LDA $6119 ; first letter of monster name
CMP #$24 ; "A"
BEQ an
CMP #$28 ; "E"
BEQ an
CMP #$2C ; "I"
BEQ an
CMP #$32 ; "O"
BEQ an
CMP #$38 ; "U"
BNE no_change
an:
LDA #$17 ; "n"
INY
STA $60F1,Y ; start of text variable buffer
no_change:
LDA #$FA ; [end-FA]
STA $60F1,Y ; start of text variable buffer
BNE done
Also I meant to ask you if this "s" fix looked right to you

Code: [Select]

norom ; stop Asar from trying to apply SNES memory mapping to this NES code
org $01C7E8 ; set the ROM file insertion point
base $B7D8  ; set the starting RAM address

; data -> code
; if $8F-$90 == #$0001, print "s" + [end-FA] to $60F1 and SEC, else print [end-FA] and CLC
; indirect control flow target
; from $02:$BE37 via $8006
    LDA $90
    BNE s ; if $90 > 0, add "s"
    LDY $8F
    DEY
  BEQ end ; if $90 == 0 and $8F - 1 == 0 (i.e. $8F == 1), do not add "s"

s:
    LDA #$1C ; "s"

fix:
STA $60F1
    LDA #$FA ; [end-FA]
STA $60F2
    SEC
    RTS

end:
  LDA #$FA ; [end-FA]
    BNE fixAs I recall it's those last 2 bytes that needed fixing and you suggested a quick branch as an easy fix that would fit into the existing space. I just wanted to make sure I have this right.

But moving priorities a bit.

I was looking at your Latin translation so I could apply your border names code. I extracted the Latin script with Cartographer and strangely noticed that with mine, the original, the pointer and strings count up normally from 0 while yours jumps straight to 30 after 0 and seems to combine a bunch of those strings together. Did you maybe shift some pointers around or is it just Cartographer being weird?

[abw]

So 1. I was using the old bat file I was using for my initial script inserts. Didn't realize you had to add ALL the tables to the command line. Lesson learned.

You have to tell abcde where your table files are somehow; you can do that on the command line or inside the command files, but it's not going to go around opening random files and trying to use them as tables. A table's ID and file name can be completely different, so guessing at the file name based on the ID doesn't really work (and in v0.0.5 I re-added a pre-release idea where you can have multiple tables inside the same file, so it really doesn't work there).

2. After a good 3 HOURS of trial and error, I found that it was indeed my dictionary text causing problems. I still don't know what exactly but since I was using the DW2 menu table to edit it, there must've been a random wrong byte getting swapped in somehow. To avoid future problems I just made a separate dictionary table and all is well again.

The menus definitely use a different table - it's very similar to the table used for most other things, but not quite the same. Spaces in particular can be $81 in the menus, but putting a $81 in the dictionary might result in weirdness happening.

3. In my defense, having the same values right next to each other is sure easy to change the wrong one.

Yup, there are plenty of pitfalls in this business - I'm just saying that having a scripted insert process is one way of avoiding some of them .

4. Also I meant to ask you if this "s" fix looked right to you

Yeah, I think that was the smallest modification that would fix the F2 control code. For the 0xBF00 code, you can shuffle things around a little bit to save a couple of bytes:

Code: [Select]

norom ; stop Asar from trying to apply SNES memory mapping to this NES code
org $00BF00 ; set the ROM file insertion point
base $8EF0 ; set the starting RAM address

LDY $8F ; number of monsters in group
DEY ; count from 0 instead of 1
BEQ one ; 0 => only one monster => handle unique monsters and "A" vs "An"
LDX #$00 ; read index
LDY #$00 ; write index
loop:
LDA some,X ; Monster Counts text
STA $60F1,Y ; start of text variable buffer
INY
INX
CMP #$FA ; [end-FA]
BNE loop ; if not end token, keep copying
done:
SEC ; SEC to trigger read of [end-FA]-terminated string from $60F1, CLC to use A
RTS
some:
db $36,$18,$16,$0E,$FA ;"Some" not using a table here
one:
; at this point we know Y = 0
LDA $0161 ; monster ID for the current group
CMP #$4E ; bosses have IDs >= #$4E (so does the "Enemies" monster, but that's not a monster ID you can encounter)
BCS no_change
LDA #$24 ; "A"
STA $60F1,Y ; start of text variable buffer
LDA $6119 ; first letter of monster name
CMP #$24 ; "A"
BEQ an
CMP #$28 ; "E"
BEQ an
CMP #$2C ; "I"
BEQ an
CMP #$32 ; "O"
BEQ an
CMP #$38 ; "U"
BNE no_change
an:
LDA #$17 ; "n"
INY
STA $60F1,Y ; start of text variable buffer
no_change:
LDA #$FA ; [end-FA]
STA $60F1,Y ; start of text variable buffer
BNE done


I was looking at your Latin translation so I could apply your border names code. I extracted the Latin script with Cartographer and strangely noticed that with mine, the original, the pointer and strings count up normally from 0 while yours jumps straight to 30 after 0 and seems to combine a bunch of those strings together. Did you maybe shift some pointers around or is it just Cartographer being weird?

I think I mentioned it earlier, but I did reorder the menus to make them easier for me to work with (e.g. storing similar menus side by side), so what you're seeing sounds right.

[Chicken Knife]

@abw,

After much dragging of feet with DQ3, I finally got down to figuring out the start and end addresses of the pointers related to each of the six rom banks, along with segregating the final pointer for each bank and counting the number of strings for it.

Something unexpected came up where there is some text data appearing at the end of the bank $15 text that doesn't have an EF end token following it. It starts at 0x05616F and ends at 0x056197. I'm thinking this has a different end token, EE? Should I count that text as an additional string in my cartographer file?

As I go through the initial text in bank $10--which has a ton of in game command related text, those end tokens would seem to be EE as well. I suppose I would just need my table file to tell abcde that both EE and EF are end tokens, right?

Now the main thing I need to do before extracting is to make sure my table file is optimal. I'm also a little foggy on the concept of the base pointer. Would I use a base pointer of $10 for all the segments of the DQ3 script or would I need to make any adjustments to that?

[abw]

Something unexpected came up where there is some text data appearing at the end of the bank $15 text that doesn't have an EF end token following it. It starts at 0x05616F and ends at 0x056197. I'm thinking this has a different end token, EE? Should I count that text as an additional string in my cartographer file?

As I go through the initial text in bank $10--which has a ton of in game command related text, those end tokens would seem to be EE as well. I suppose I would just need my table file to tell abcde that both EE and EF are end tokens, right?

It looks like I have all of EE, EF, FE, and FF listed as end tokens; FE and FF get used outside of the main script (spell/monster/item names etc.). For the main script, it's the same basic idea as in DW2 - EF is a full string end token and EE is a sub-string end token for when the game needs to chop up a longer string into smaller sections, generally to supply different values for variable control codes that get used multiple times in the full string. So yes, mark them all as end tokens!

I'm also a little foggy on the concept of the base pointer. Would I use a base pointer of $10 for all the segments of the DQ3 script or would I need to make any adjustments to that?

BASE POINTER is just how much you need to add to the pointer value (a RAM address) in order to get to the string in the ROM file (including any header). So if your pointer at 0x28080 has a value of $8000 and the corresponding string starts at 0x40010, you need a BASE POINTER value of 0x40010 - $8000 = 0x38010. Later on, when your pointer at 0x280B4 also has a value of $8000 but the corresponding string starts at 0x44010 instead, you need to update the BASE POINTER value to 0x44010 - $8000 = 0x3C010. Typically, updating the BASE POINTER value goes hand-in-hand with extracting data from a new ROM bank, but games are free to do whatever kind of craziness their programmers came up with, so that's not a hard and fast rule.

[Chicken Knife]

 

Just got the main script fully dumped--All 11 sections of it. (11 and not 12 because bank $11's final pointer conveniently addressed 16 strings.

I then went through a rather pleasurable exercise of tweaking my table file's opcode representation to present the grammar in as natural a style as possible for writing purposes. As I think about this, I should probably get the spell / item / monster lists included now as part of the extraction as to make their insertion easier down the road. I'll start working on that promptly, and will also continue to scour the document for any unidentified opcodes. It seems like it's easiest to fix them now in the dump stage of the process.

Once I get those items done, I suppose I'll be adding in the mostly finished script line by line. Since the compression you mentioned before is totally new territory for me, should I be doing anything differently with my formatting or simply prepare the insertion script the same way as I did for DQ1 and 2? After that I will be reaching out to you for help with adding code for the compression. Also, this is not a concern right now, but I believe I'll be setting up a separate boundary for each $4000 rom bank in the atlas file, correct?
September 24, 2019, 08:05:48 am - (Auto Merged - Double Posts are not allowed before 7 days.)Ok, another thing. The game seems to have an opcode for his/her: $B0. Since there is a ton of misgendering in the original script when you pick a female hero (getting called son, boy, etc) we went for a more gender neutral approach (child, etc). I haven't yet ventured into the realm of creating new opcodes but I assume the idea of making one like son/daughter or he/she would pose quite a challenge. But again, it's not something I'm too worried about since we are relatively happy with our current gender neutral language.
September 24, 2019, 09:35:37 pm - (Auto Merged - Double Posts are not allowed before 7 days.)**UPDATE

It would appear that $B6 is an opcode for son/daughter. It's amazing that these things exist in the game but the game doesn't use them 9/10 of the time 

[abw]

Just got the main script fully dumped--All 11 sections of it. (11 and not 12 because bank $11's final pointer conveniently addressed 16 strings.

Congratulations!

Since the compression you mentioned before is totally new territory for me, should I be doing anything differently with my formatting or simply prepare the insertion script the same way as I did for DQ1 and 2? After that I will be reaching out to you for help with adding code for the compression. Also, this is not a concern right now, but I believe I'll be setting up a separate boundary for each $4000 rom bank in the atlas file, correct?

No, the insert script formatting is pretty much the same either way. Bank boundaries will take a little extra work, but not too much; basically I just set up per-bank insertion ranges and then update the ROM -> RAM address calculation offset, so something like:

#JMP($40010, $43FE7)
#HDR($38010)
// bank $10 script here

#JMP($44010, $47FE7)
#HDR($3C010)
// bank $11 script here

// etc.

As for fitting your larger script in, try to cram as much as you can into each bank and then see if the rest will fit in all the extra space in bank $15. If it does, then great; it looks like the code for controlling which bank to load for a given string starts at 0x03AE9F, so updating a couple of numbers there should be enough to make things work. If not, then you get to decide whether you want to add compression or whether you want to use up some of the other giant empty areas of space.

I haven't yet ventured into the realm of creating new opcodes but I assume the idea of making one like son/daughter or he/she would pose quite a challenge. But again, it's not something I'm too worried about since we are relatively happy with our current gender neutral language.

You mean like the B6=[son/daughter] or B2=[he/she] control codes that already exist? If you're happy with a gender-neutral script, that's fine, but the original game does come equipped with several control codes that display different text based on the hero's gender, so you have the option of using gender-specific language too.

For control codes, here's what I had (I think the A* ones were not used in the main script, but you can confirm that):

B0=[his/her]
B1=[himself/herself]
B2=[he/she]
B3=[him/her]
B4=[man/lady]
B5=[he's/she's]
B6=[son/daughter]
B7=[(s)-B7]
B8=[check if orb placed]

A0=[y/ies]
A1=[an/en]
A2=[ol/lls?]
A3=[i/ls?]
A4=[(es)-A4]
A5=[(s)-A5]
A6=[a/e]
A7=[no plural]

C0=[(s)-C0]
EB=[line]\n
ED=[sacrificial merchant's name]
/EE=[end-EE]\n\n
/EF=[end-EF]\n\n
F0=[class]
F2=[letter]
F3=[spell]
F4=[item]
F5=[name]
F7=[number]
F8=[number]
F9=[hero]
FD=[wait]
/FE=[end-FE]\n\n
/FF=[end-FF]\n\n

[Chicken Knife]

Just like what has frequently happend, I figured out that son/daughter is an opcode right before you told me. In fact I had cracked every single one on your list except for the A sequence which, yes, wasn't in the script. FYI you may have a problem with assigning both $F7 and $F8 the same designation: [number]. I used [value] for $F8.

I seem to recall you saying that you weren't exactly planning to do anything with DQ3. I'm very amused that you seem to have done all this charting out ahead of me simply for fun. 

I've decided to just leave the spell/monster/item lists for the insertion, which is what I did last time for DQ2 according to my notes. That means it's time to start porting in the script. This will be lengthy but shouldn't be much of a headache. After that I'll start playing around with the bank loading code you pointed out. We'll almost certainly be discussing that further but I'll give it a crack.

[abw]

Just like what has frequently happend, I figured out that son/daughter is an opcode right before you told me. In fact I had cracked every single one on your list except for the A sequence which, yes, wasn't in the script.

See? You don't need me for this stuff at all anymore .

FYI you may have a problem with assigning both $F7 and $F8 the same designation: [number]. I used [value] for $F8.

Hmm, yup, good catch. I guess that must have been the point where I got sidetracked, since I had the other duplicate texts separated. Based on its usage in the script, F7 must be used for cardinal numbers (One, Two, Three, ...) and F8 for digits (1, 2, 3, ...).

I seem to recall you saying that you weren't exactly planning to do anything with DQ3. I'm very amused that you seem to have done all this charting out ahead of me simply for fun. 

Don't you know by now that you can't believe everything you read on the internet? Translating just 1 and 2 feels wrong - either finish the Erdrick trilogy or the NES quadrilogy! But I got distracted by other things and didn't get much further than an initial script dump + replay (for refreshing my memory, checking some control codes I wasn't sure about, and generating a decent CDL file to use for disassembling).

I've decided to just leave the spell/monster/item lists for the insertion, which is what I did last time for DQ2 according to my notes. That means it's time to start porting in the script. This will be lengthy but shouldn't be much of a headache. After that I'll start playing around with the bank loading code you pointed out. We'll almost certainly be discussing that further but I'll give it a crack.

Sounds like a plan to me!

[tvtoon]

So I finally translated the biggest RAM mapping work I have done for these games, the DQ3 GBC version. I have been stocking this here for more than half a decade, always forget to post this massive stuff but when I saw this topic, flashes happened! I was going to do the NES and SNES versions too, but time is short plus it shares many traits with them.

The work is now available at Data Crystal, enjoy! Off: it is about time to update those templates!

[Grimoire LD]

Spectacular! I was shocked at how little information there was on this legendary game and that about satisfied my curiosity for the most part (for most matters outside of battle). Great work!

[Chicken Knife]

So I finally translated the biggest RAM mapping work I have done for these games, the DQ3 GBC version. I have been stocking this here for more than half a decade, always forget to post this massive stuff but when I saw this topic, flashes happened! I was going to do the NES and SNES versions too, but time is short plus it shares many traits with them.

The work is now available at Data Crystal, enjoy! Off: it is about time to update those templates!

Great work! We may find some value in this for the NES projects and it certainly looks like a nice win for Dragon Quest hacking community in general.

@abw

nejimakipiyo and I are quite far along in getting the Atlas file ready for DQ3 but we ran into a roadblock with miscellaneous text. We are having a difficult time verifying it against the Japanese. In some cases, it is dependent on rare items; in other cases my partner would have to do another playthrough; in yet other cases we have no idea what the pieces of text connect to in the game. Therefore we decided that we would need to do an extraction of the DQ3 Japanese rom's text.

We spent tonight building a kana table file and then were going to try to locate the beginning of the script along with relevant pointers. The first problem we hit was that I can't get Windhex32 to display the kana. I spent a fair amount of time investigating forums and some people seem to indicate that Windhex32EX is the version I need but that doesn't seem to be available anywhere. Anyway, I moved on to an idea I caught from a forum to use romaji instead of kana in the table file. It gets a little dicey with hiragana vs katakana vs small hiragana all translating to the same combinations of letters but we worked out a .tbl that seemed sensible. Once I loaded that, I didn't see any great swaths of text that I was expecting. The text seems to be limited to a couple short segments, and with nejimakipiyo looking over them, they appeared to be related to items. Now I'm getting DQ2 flashbacks of the compressed script, something that wouldn't surprise me considering the infamous storage issues they had with Japanese DQ3 resulting in a cut title screen and fanfare.

So to boil that all down to a couple questions: 1, any thoughts about my kana viewing issues in a hexeditor? 2, do you think my suspicions of compression are correct? And 3, if compression, could the solution be relatively simple like the bit based table file we created for DQ2? Going down this kana extraction path has created some real headaches but I think it's pretty important. I wouldn't feel great about knowing that several English lines were left alone and never vetted. I'm not exactly the "good enough is good enough" type, fortunately and unfortunately.

abw, thank you as always...