When you say VCS, I think of an Atari 2600 Do you mean something like github?
Ah, sorry - VCS = Version Control System. git is currently the most popular VCS, and github is the most popular place for hosting/sharing git repositories.
But you can use a non-game-specific tool without typing your whole script in a hex editor. That's what abw meant. Like using something like Pointer Tables to do your script, rather than directly typing into Windhex 32 EX.
And yes, anything CAN be done in a hex editor, but not necessarily SHOULD be done.
Yup. It's not like game-specific editors are evil or anything (some of them are pretty awesome), but if you always rely on them exclusively and never understand what's going on behind the scenes, that leaves you in a bad position for working on any game where somebody else hasn't already written a game-specific editor that does exactly what you want to do.
So to find these pointers, you just work backwards with a debugger: you set a breakpoint for the line of dialogue, see where it got that address from. If you're lucky, you'll immediately find the pointer; otherwise you just keep following the trail.
Here's how I found those pointers using FCEUX, in excruciating step-by-step detail. There are other ways of accomplishing the same goal, but despite the wall of text below, this process got me the answers I was after in only a couple of minutes, so it worked out pretty well.
1) Start with what you know: sometimes the game prints item names to the screen; for this example I'll use the ITEM command to trigger displaying item names.
2) Get to some place where item names are displayed; the ITEM command is available pretty much everywhere, so this part is easy.
3) Display the item name on screen; I have a Torch as the only item in my inventory, so that's what shows up.
4) Open the Name Table Viewer (from the Debug menu).
5) Put your mouse over the "T" in "Torch". The Properties section tells you the Tile ID (37 - in Dragon Warrior's case, this matches up with 37=T in your table file), the X/Y co-ordinates (34 / 27), and the PPU Address (2762) of that "T". We're interested in the PPU Address, so make a note of that.
6) Back in the game, get ready to display the item name again - close the ITEM menu, re-open the COMMAND menu, and position your cursor over the ITEM command, but don't press A yet.
7) Pause the emulator (use the Pause key on your keyboard or the NES -> Emulation Speed -> Pause menu item).
8) Open the Debugger (also from the Debug menu).
9) Create a new breakpoint using the "Add" button. We want to break when PPU Address 2762 is written to, so enter 2762 in the first "Address" box, check the "Write" checkbox, and select the "PPU Mem" Memory radio button, then press "OK". You should get a breakpoint labelled "$2762:EP-W--". Breakpoints are enabled by default (the "E" in the label) and you can toggle them on/off by double-clicking them. Make sure the breakpoint is enabled.
10) Open the Trace Logger (also from the Debug menu).
11) Select the "Log to File" option and "Browse" for a file to save the trace log under; I made a new "torch.log" file.
12) Press the "Start Logging" button to start logging CPU instructions.
13) Back in the game, unpause the emulator and activate the ITEM command. You'll want to be quick about this - the NES is slow by modern standards, but it still runs at over 1 million cycles per second, so letting a full trace log run for very long is going to generate a large file. I managed to keep mine down to about 4 MB containing nearly 40,000 lines of code. The emulator will stop executing code when it reaches the breakpoint we set up earlier.
14) In the Trace Logger, press the "Stop Logging" button.
15) Open the trace log file from disk in your favourite text editor.
16) At the very bottom of the file, you should see a line like
$FE48:E8 INX A:37 X:14 Y:0A S:E8 P:nvUbdIzc
. This is the instruction that was logged immediately before the emulator reached our breakpoint. You can see that A contains 37, which is the Tile ID for "T". Our job is to find out where in the ROM that 37 came from, and then find out where the code that loaded that 37 is, so we'll start working backwards.
17) Where did A get its value of 37 from? The previous line in the trace log is
$FE45:BD 00 03 LDA $0300,X @ $0314 = #$37 A:5F X:14 Y:0A S:E8 P:nvUbdIzc
which shows that the value of A came from $0314. $0314 corresponds to system RAM, not ROM, so we'll backtrack to find out where $0314 got its value from.
18) Searching backwards in the trace file for "$0314" takes us to
$ACA1:B9 36 64 LDA $6436,Y @ $6444 = #$37 A:5F X:14 Y:0E S:E9 P:nvUbdIzc
$ACA4:9D 00 03 STA $0300,X @ $0314 = #$5F A:37 X:14 Y:0E S:E9 P:nvUbdIzc
which shows us that $0314 got its 37 from $6444. $6444 corresponds to cartridge RAM, not ROM, so we'll backtrack to find out where $6444 got its value from.
19) Searching backwards in the trace log for "$6444" takes us to
$A562:BD 35 64 LDA $6435,X @ $6444 = #$37 A:18 X:0F Y:05 S:EC P:NVUbdIzc
which we don't care about since LDA is a read command, not a write command. Going further backwards takes us to
$A555:AD DD 64 LDA $64DD = #$37 A:0E X:0E Y:05 S:EC P:nvUbdIzc
$A558:9D 36 64 STA $6436,X @ $6444 = #$5F A:37 X:0E Y:05 S:EC P:nvUbdIzc
which shows us that $6444 got its 37 from $64DD. $64DD corresponds to cartridge RAM, not ROM, so we'll backtrack to find out where $64DD got its value from.
20) Searching backwards in the trace log for "$64DD" takes us to
$A62E:BD C9 64 LDA $64C9,X @ $64D2 = #$37 A:FF X:09 Y:05 S:EE P:nvUbdIzC
$A631:8D DD 64 STA $64DD = #$5F A:37 X:09 Y:05 S:EE P:nvUbdIzC
which shows us that $64DD got its 37 from $64D2. $64D2 still corresponds to cartridge RAM, not ROM, so we'll keep backtracking to find out where $64D2 got its value from.
21) Searching backwards in the trace log for "$64D2" takes us to
$A85E:65 A1 ADC $00A1 = #$B7 A:76 X:00 Y:76 S:EC P:nVUbdIzc
$A860:85 A1 STA $00A1 = #$B7 A:2D X:00 Y:76 S:EC P:nvUbdIzC
$A862:90 02 BCC $A866 A:2D X:00 Y:76 S:EC P:nvUbdIzC
$A864:E6 A2 INC $00A2 = #$BA A:2D X:00 Y:76 S:EC P:nvUbdIzC
$A866:A0 00 LDY #$00 A:2D X:00 Y:76 S:EC P:NvUbdIzC
$A868:AE E2 64 LDX $64E2 = #$09 A:2D X:00 Y:00 S:EC P:nvUbdIZC
$A86B:B1 A1 LDA ($A1),Y @ $BB2D = #$37 A:2D X:09 Y:00 S:EC P:nvUbdIzC
$A86D:C9 FF CMP #$FF A:37 X:09 Y:00 S:EC P:nvUbdIzC
$A86F:F0 07 BEQ $A878 A:37 X:09 Y:00 S:EC P:nvUbdIzc
$A871:9D C9 64 STA $64C9,X @ $64D2 = #$5F A:37 X:09 Y:00 S:EC P:nvUbdIzc
which shows us that $64D2 got its 37 from $BB2D. $BB2D corresponds to ROM, so we've found the start of "Torch". Hurray! Alas, FCEUX's trace log doesn't indicate which ROM banks were visible in RAM at that point, but with a little extra digging (left as an exercise for the reader) we can figure out that RAM $BB2D is ROM 0x7B3D.
So, we're halfway there. Now, how about that ($A1)? We can see that the old value of $A1-$A2 was $BAB7 (which happens to be 0x7AC7, i.e. the start of both "Bamboo" and the entire item list), but how did $A1-$A2 get to be $BAB7? Let's backtrack some more.
22) Searching backwards in the trace log for "$00A1" takes us to
$A823:0A ASL A:02 X:04 Y:02 S:E9 P:nVUbdIzc
$A824:AA TAX A:04 X:04 Y:02 S:E9 P:nVUbdIzc
$A825:BD 30 A8 LDA $A830,X @ $A834 = #$B7 A:04 X:04 Y:02 S:E9 P:nVUbdIzc
$A828:85 A1 STA $00A1 = #$FF A:B7 X:04 Y:02 S:E9 P:NVUbdIzc
$A82A:BD 31 A8 LDA $A831,X @ $A835 = #$BA A:B7 X:04 Y:02 S:E9 P:NVUbdIzc
$A82D:85 A2 STA $00A2 = #$A3 A:BA X:04 Y:02 S:E9 P:NVUbdIzc
which makes it look like $A1-$A2 is the third pointer (pointers are 2 bytes long, so the first pointer is X=00, the second is X=02, and we're the third at X=04) in a pointer table starting at $A830 (0x6840). A little further investigation (another exercise for the reader) shows that the $A830-$A831 pointer goes to other places (a pointer table for menu stuff), but $A832 - $A841 are pointers into our lists at $BAB7 - $BE9E (0x7AC7 - 0x7EAE).
And there you have it!