I don't think so...what is the matter with Cartographer??

This is gonna take some explaining.

All right, first note that there are two files named "Cartographer" in the folder: "Cartographer.exe" and "Cartographer.bat." The first is the program; the second is a batch file for automating the dump process. If you double-click on Cartographer.bat, you'll get a command prompt window with an error message - the same one you got when you tried running it from the command prompt.

Cartographer is already set up with a bunch of sample files for dumping FF1's script. Right-click on Cartographer.bat and select "edit." You'll see something like this:


That is, when you try to run Cartographer from the command prompt, you're actually running the batch file, which contains this command: it will try to dump the script from "FF1.nes" using the directions supplied in "ff1_commands.txt" to a set of files (indicated by the "-m(ultiple)" flag at the end; "-s(ingle)" means it will dump everything to a single file) prefixed with "ff1_script." As you can see, the folder already has "ff1_commands.txt," which demonstrates two different ways of dumping the script. You can also check out the two FF1 script dumps it produces. For fun, try removing or renaming the supplied script dumps, put a FF1 ROM in the folder with the filename "FF1.nes," and run Cartographer - it should reproduce the script files perfectly.

So. If you want to use Cartographer, you'll need to edit the batch file to look for your ROM and command file, as well as dump to the appropriate filename. You'll also need to create a command file and supply the tables Cartographer requires for a proper dump. Once everything's in place, you'll be able to double-click Cartographer.bat and dump the script - you won't ever have to fiddle with an actual command prompt.

The command file is plain text. You can double-click it and it'll open in Notepad, like any other text file.

Let's take a moment to dissect the sucker.


The readme explains each command in more detail, but since you're having a little trouble grasping the basics here, lemme explain what you're looking at here.

Each block defined in a command file determines what gets dumped and how. If you look closely, you'll see these two blocks are actually the same block. That is, both will dump the same text, but using two slightly different methods.

"RAW" (dumped to ff1_script_000.txt, also a plain text file) is just the script, helpfully commented out. This might be your only option for more complicated scripts, but it's less than ideal, since it means you'll have to do all the formatting needed to insert it using Atlas manually. It starts dumping at the given start address and keeps going until it reaches the end address.

"POINTER_RELATIVE" (dumped to ff1_script_001.txt) is more Atlas-friendly. Instead of pointing Cartographer to the script, you point it to the pointer table, and it uses that to figure out where the strings are. As a result, the script dump will include the pointer writes Atlas needs to insert the script: you still need to add the header information so Atlas knows which table to insert with and whatnot, but the hardest part (the pointers) has been taken care of already.

Note that the two blocks take slightly different tables. And by "slightly," I mean that "ff1_raw.tbl" and "ff1_ptr.tbl" (also plain text files) differ by only a single line. The "/" before the "00" token in ff1_ptr.tbl is important: it denotes that this byte indicates the end of a string, and without it, Cartographer will simply dump the entire rest of the ROM over and over again until it's read through the entire pointer table. So be warned.

I don't know what makes you think tables have checksums, but the aforementioned sample tables will tell you what yours should look like. If you're completely lost, a table is a file indicating which byte values correspond to which characters. Again, in Cartographer's case, your table has to have an end tag defined if you're going to use the Atlas-friendly POINTER_RELATIVE mode, or Bad Things will happen (really, your computer will slow to a crawl for a short while and you'll have a huge whopping text file on your hard drive filled with redundant data).

It explains it well enough for people with experience with this kinda of thing, but not so well for beginners like me. All I've ever done before was messing around with the graphics in pokemon games, so text extraction and translation is very new to me. I went back to read it and now most of it makes sense, but not everything. You should include a beginners guide answering the questions I had just starting out, and an advanced guide for users who might only have the occasional tech problem.

I understand almost everything Ryusui, but I am a bit confused about the "/" thing for the .tbl files. I'm looking at the command file you show, but I don't see an "/" in there. Am I supposed to edit that in the batch file? Or is "/" in the script files?
I already edited the batch file to look for the rom and dump the script to a .txt file with the rom name. I've edited the command file to dump tables and script from the rom, and now just need to find the pointers. Hopefully I won't have anymore problems with cartographer as I now know what I am doing to an extent.

EDIT
while reading the read me I noticed string length. How do I determine string length? Or do the pointers do that for me?


edit again
I'm having no luck getting TAG2b to run. After I get it to start and I start typing in hex data it crashes. Also finding pointers to start the text dump from is a pain. I know how to hex edit, but using Hex workshop to find pointers is harder then I thought. Any tips for that?

*sigh* When did I say the end tag would be in the command file? I said it would be in one of the table files, the one that the pointer relative block needs to dump properly.


Like I said: this is what defining the end tag in the table is for. If you've set up your table properly, Cartographer will recognize the end tag as indicating the end of a string, stop dumping, and move on to the next pointer. Otherwise...Bad Stuff. ^_^;


What's TAG2b? Never heard of it. As for hex editors, I recommend WindHex.

The "caveman" method for finding pointers is simply to search for the address in the ROM. This will probably be tedious. You'll also need to convert the file address to the ROM address. Lunar Address is the tool to use for this if you're working on a SNES game. For GBA, just add $08000000 to the file address (i.e. $BEEF = $0800BEEF).

Well, you don't really need a tool to make a table. Me, I make mine by hand. It's tedious, but it doesn't take long.

They're ordinary text files, anyway. If you're making a Japanese table, of course, you'll need to save it as UTF-8 instead of ASCII (you'll have this option in the Save File dialogue; if you screw up, Save As and save it over the old version with the new encoding).

And when I say "file address," I mean "the position you find a given string in your hex editor." (I use WindHex myself, BTW.) The pointer for that string will point to the same location, but game consoles use their own addressing schemes, since cartridges are (usually) treated as read-only memory (hence, "ROMs"). A SNES ROM, for example, is divided into banks of 8000h-10000h bytes, depending on the addressing scheme used (LoROM or HiROM). If you're not sure which one a game uses, open it up in an emulator - it should tell you. You don't need to know exactly how to convert a file address to a SNES address, but you do need to know whether it's LoROM or HiROM if you're going to use Lunar Address to do the math for you.