I've been working on a retranslation of SaGa 3: Jikuu no Hasha for GB for a while now, but haven't gone far beyond the initial stages of creating a table file, making translation notes and doing minor touch-ups on a few of the in-game graphics. Before I can get everything prepared, there are several problems I've considered about the ROM so far, as well as my general lack of knowledge in a few of these areas:

 - ASM work is going to be necessary to restructure hard-coded instances of subject-object-verb sentence order appearing in battle dialogues to the English subject-verb-object order. If possible, I would also like to increase the default text speed. It's terribly slow, and there's no in-game option for adjusting it.

 - The character limit needs to be increased quite a bit in some places. This may also require ASM work, but I'm not sure. The main problem is the character naming screen and the menu screen. The longest character name is 9 characters long, so that would probably be the new limit.

 - It would be a luxury to have a variable-width font worked in, but that might be asking for too much. I would count myself lucky just to have the essential work accounted for, but this could help compensate for the long character names, and possibly give me a more reasonable character limit to work with.

 - The title screen appears to be compressed, but I can't be certain. I've never been able to locate it within the ROM through any standard means. I have touched-up all other graphics requiring translation, though.

 - Diacritics don't appear as normal tiles in the ROM. Instead, they're imposed on top of regular kana in a dedicated line above the current line of dialogue. Diacritics appear to be borrowed from the period and comma characters in the font. Because of this, I can't put together an accurate table file, much less contemplate how editing such a complex script would work.

I've been trying to find ASM documentation pertaining to GameBoy, but no luck so far. Anything I've come across is game-specific, and not very detailed. Tasks such as expanding character limits and editing compressed data area also beyond my expertise. I may have to recruit a lot of help in order to get this project going, so I'm considering a "help wanted" ad sometime in the near future. In the meantime, I figure it doesn't hurt to ask for some insight. If anyone can lend me some advice, point me in the right direction, or offer to contribute their expertise toward the project, then I would appreciate any help I can get.

I took a look: Here's the GFX-Compression and some other stuff I looked at

ASM-Calls:

rst $18 - Multi Function call
Takes one byte X after the rst $18 command for input:
It has two modes depending on bit 3 of the read byte X

Mode 0

X bit layout:

7-4 --> More significant index
3 --> 0
2-0 --> Less significant index

Less significant index * 0x02 + (more significant index *0x10) + 0:3994
Another structure there:

[low][rombank index + high modulation]

rombank index + high modulation bit layout:

7-6 index in table 0:3990 (layout: [rom bank 1][rom bank 2] etc...)
5-0 high byte of pointer - 0x40

Routine calls function at RB:high,low
---------
Mode 1

X- bit layout

7-4 --> rom bank RB
3 --> 1
2-0 --> Index

Index to Pointer table 0:3A50 (format: [low][high]). Routine calls function at RB:high,low. Various purposes.
--------------------------------------------------------------------
rst $20 - load rom bank in register a
--------------------------------------------------------------------
rst $28 - restore previous rombank (writes new rombank to a)
--------------------------------------------------------------------
0:3F02 Decompression call; a = rom bank, hl = start of compressed data, de = end of compressed data +1

--------------------------------------------------------------------
--------------------------------------------------------------------
Decompression routine: It's a simple routine for converting 1bpp to 2bpp, however, can be used to compress any other data, too.

Layout of data:

[Buffer size] [[Fill-in byte][bitcode bytes]â€]…

Depending on the buffer size, the number bitcode bytes differs and depending on those the number of data bytes differs. Buffer sizes only from 0x00 to 0x03 (other sizes will break the routine!). Actual buffer sizes computed like : 0x04*0x02^(byte+1)

The bitcodes get shiftet bitwise left. For every '1' a data byte is written to the buffer, for every '0' the fill-in byte is written to the buffer. Since there are only 4 buffer sizes, namely 0x08 bytes, 0x10 bytes, 0x20 bytes and 0x40 bytes, there are either 1, 2, 3 or 4 bitcode bytes. Depending on the bitcodes the amount of data bytes varies!

Small example (taken from the title gfx):

[01] - buffer size is 0x04*0x02^(0x01+1) = 0x10 bytes
[FF] - Fill-in byte for first pass
[55][55] - bitcode bytes (every other byte fill-in/data)
(01010101)(01010101) - bits of [55][55]
[00][00][00][00][00][00][00][00] - data bytes (8 since bitcodes account for 8 data bytes and 8 fill-in bytes)

Actual decompressed data:

FF00FF00FF00FF00FF00FF00FF00FF00

The routine is (as stated above) supplied with both stating and ending points. There is no control code that stops decompression. As I said above, this is mostly a 1bpp --> 2bpp conversion method, since it can perfectly be used to "blank" one layer of the 2bpp data with either '0' or '1' and then just add the 1bpp byte.

This is really simple and a recompressor won't take much effort ^_^

Oh yeah, and the title gfx starts at 3:5C00 and ends at 3:612D (or rather 3:612C, that's the last byte of the actual data!)

A vwf might not be feasible, since it relies heavily on the character data being in ram. This is, however, not impossible to accomplish.
Changing naming lengths is probably too much, since you would have to tinker with the save game to allow for more stored data for the name. It is accomplishable nevertheless.
The restructuring of the battle dialogue might be very easy, but is certainly doable

Oh yeah, good z80 reference: http://www.geocities.com/SiliconValley/Peaks/3938/z80code.htm

Take out all the shadow registers and some flags and you basically have the z80gb

cYa,

Tauwasser

...do you even know what ASM is? Understanding how the hardware works is a prerequisite for doing most of what you want to do. Knowing the assembly language for the processor is only a small percentage of what you've gotta know to pull things off. The processor chips don't exist in a vacuum; they have to interact with all of the other hardware if you want to get anything accomplished.

I'm quite busy myself, so nope, sorry...Won't commit to that task

cYa,

Tauwasser

I can vouch for this.