Having trouble re-inserting dumped script using Atlas

[badnest]

Hey guys, I'm working on a translation project. I managed to figure out the table, modify the font, find the text pointers and use them to extract the script with cartographer. This is an SNES game that uses loROM. So far for this test run I'm working only with the first block of text.

They're 3 byte pointers, but the third byte only changes with each block, so since I'm only working with the first block I'm telling cartographer to ignore the third byte of each pointer.

Pointer table start: $FB60
Pointer table end (first block): $FBDC

The first pointer at $FB60 is $00F5. Inverting the bytes and subtracting $8000 gives us $7500. The text starts at $27500. So we also have to add $20000. $20000 - $8000 from before gives us $18000, so,

Base pointer: $18000.

With this I managed to get a perfect script dump of the first block, and it looks something like this:

Code Select Expand

//GAME NAME:        game

//BLOCK #000 NAME:        block

//POINTER #0 @ $FB60 - STRING #0 @ $27500

#W16($FB60)
text[BREAK]
text[END]
//
//POINTER #1 @ $FB63 - STRING #1 @ $2758E

#W16($FB63)
text[BREAK]
text[END]
//
//POINTER #2 @ $FB66 - STRING #2 @ $275F5

#W16($FB66)
text[BREAK]
text[END]


The part I can't get to work is the reinsertion part. My table for re-inserting is in UTF-8 and so is the script. I removed the /n and /r formatting codes from the table.

From what I gather there should be a #HDR command with the offset that has to be added to the pointer, which in this case is $18000, correct?

Them the #JMP command should point to the start of the game script and the maximum end of the script, is that correct?

The script for the first block starts at $27500 and we can use all the way to $27FFF, so #JMP($27500,$27FFF)?

So currently my script looks like this:

Code Select Expand

//GAME NAME:        game

//BLOCK #000 NAME:        block

#VAR(table, TABLE)
#ADDTBL("table-insert_utf8.tbl", table)
#ACTIVETBL(table)

#HDR($18000)
#JMP($27500,$27FFF)

//POINTER #0 @ $FB60 - STRING #0 @ $27500
#W16($FB60)

...
But it doesn't work. Atlas passes the parsing part and then crashes after a while leaving a blank debug log. I know I must be doing something wrong. I think I'm messing up the #JMP command because I'm not sure if that's where it's supposed to point to. I read the romhacking103 and although a great series, this specific part is very unclear to me.

So if a seasoned atlas user can help me out, it'll be of great help! Thanks in advance!

[yugisokubodai]

One principle: the text file used for insertion must be the same format (UTF-8 or Ansi/Shift-Jis....) as the table format.

[Vehek]

I slapped together an ASCII table to test your sample, and it seemed to work for me, so it's not clear why it failed, but regarding the other questions:

From what I gather there should be a #HDR command with the offset that has to be added to the pointer, which in this case is $18000, correct?

#HDR is for a copier header, a chunk of data not part of the original ROM. It subtracts the value from the address when calculating pointers. While I was surprised to see it work for this small sample, it's not how you should do it.
What you really want to do here is either use the #SMA command to pick a built-in address conversion method, or designate a pointer type and use the variant write commands that specify a pointer type. As it's basic LoROM, not something with a base address in the middle of a bank, #SMA("LOROM00") or #SMA("LOROM80") along with the generated #W16 commands should work fine.

Them the #JMP command should point to the start of the game script and the maximum end of the script, is that correct?

I've never used this variant. I've always used the one with just one address. Preventing text from overflowing into another section isn't mandatory for insertion purposes.

[abw]

First off, congratulations on your progress so far!

The structure of what you've posted here is okay, so whatever's causing the problem is most likely related to your specific table/script files; can you try posting/linking to a more complete example?

Atlas actually crashing is fairly rare, so I'd be interested in seeing exactly what's triggering that.

#HDR is for a copier header, a chunk of data not part of the original ROM. It subtracts the value from the address when calculating pointers. While I was surprised to see it work for this small sample, it's not how you should do it.
What you really want to do here is either use the #SMA command to pick a built-in address conversion method, or designate a pointer type and use the variant write commands that specify a pointer type. As it's basic LoROM, not something with a base address in the middle of a bank, #SMA("LOROM00") or #SMA("LOROM80") along with the generated #W16 commands should work fine.

For a contrary opinion: although this is maybe not its intended purpose, using #HDR as a way to tweak the ROM <-> RAM address conversion works just fine and dovetails nicely with Cartographer's output; setting up a custom pointer type and rewriting all the #W16 commands is probably more "correct", but is also more work for little/no benefit.

I've never used this variant. I've always used the one with just one address. Preventing text from overflowing into another section isn't mandatory for insertion purposes.

Setting an upper bound on the insertion range isn't mandatory, but it is nevertheless an extremely good idea.

[badnest]

#HDR is for a copier header, a chunk of data not part of the original ROM. It subtracts the value from the address when calculating pointers.
What you really want to do here is either use the #SMA command to pick a built-in address conversion method, or designate a pointer type and use the variant write commands that specify a pointer type. As it's basic LoROM, not something with a base address in the middle of a bank, #SMA("LOROM00") or #SMA("LOROM80") along with the generated #W16 commands should work fine.

Thanks for taking the time to help me out. I know that that's the command's intended use, but I just figured it'd be simpler to use it for offsetting rather than defining and implementing a custom pointer. I figured using #SMA("LOROM80") would deal with the subtracting $8000 part but I'd still need to tell atlas about the $20000 offsetting:

Yes, atlas subtracts the header size from the text address when writing the new pointer value. I thought atlas looked at the pointer then calculated where the text should be for inserting then recalculated all pointers or something which makes no sense, that's why I was so confused with the #JMP command. I now understand that atlas simply inserts the script on the address specified by the #JMP command, and calculates the 2 byte pointers and writes them, so the text being at $20000 or $30000 or whatever doesn't really matter for 16-bit pointers, right?

First off, congratulations on your progress so far!

The structure of what you've posted here is okay, so whatever's causing the problem is most likely related to your specific table/script files; can you try posting/linking to a more complete example?

Atlas actually crashing is fairly rare, so I'd be interested in seeing exactly what's triggering that.

Thanks. You hit the nail on the head there. After some thinking about what you said, I tracked down the problem to, believe it or not, CR/LF line terminators. You see, I'm on a Unix workstation, so my files don't have CR/LF line terminators. I had tried inserting the script on my WinXP dual-boot, but since all the files were just copied over it crashed anyway and made me believe the problem wasn't related to me not being on Windows.

Anyways, after using unix2dos to insert the terminators on my table file, everything works like magic. Looks like atlas can't deal with files lacking them. Thanks a lot everyone.

[abw]

Ha, yup, that does it - after switching a test table file to use Unix LF instead of Windows CR/LF, I'm able to reproduce the crash on my system too. Thanks for letting us know what the root cause of the issue was, and good luck with the rest of your translation project!

[MysticLord]

Atlas is open source, anyone feel like adding more informative error messages for this issue?

[abw]

Or just plain fixing the issue .

As an alternative if the issue becomes sufficiently annoying, abcde should also be able to handle this.