Cyber Knight translation

[megatron-uk]

The text at the main title screen seems to be generated with the same/similar display routine as the dialogue in the rest of the game.

The text, as standard, looks like this:

Code: [Select]

0D 06 43 59 42 45 52 29 4B 4E 49 47 48 54 00
... which displays "CYBER KNIGHT", centrered in the dialogue box.

The first two bytes appear to be control codes and this particular sequence controls how much whitespace is prepended to the text before display.

By changing 0D 06 to 0D 01 and the 0D 15 it moves the text towards the left (1 space instead of 6) or towards the right (15 spaces instead of 6, which is too much, in this case).

[megatron-uk]

Nothing as low level as this!

It's not so bad. PCE arch' is fairly straight forward/clean compared to some other systems. Mednafen is a pretty powerful debugger, once you get the hang of it.

Oh, I don't know about that I think Unix with it's flat memory model has spoiled me! The whole bank and memory region register thing baffles me! I just trust the assembler to do it's job 

I'll certainly take up your offer when the time comes and I wouldn't be surprised if I post a few more questions relating to the translation process here or on RHDN when I get a little further.

[Bonknuts]

Nothing as low level as this!

It's not so bad. PCE arch' is fairly straight forward/clean compared to some other systems. Mednafen is a pretty powerful debugger, once you get the hang of it.

Oh, I don't know about that I think Unix with it's flat memory model has spoiled me! The whole bank and memory region register thing baffles me! I just trust the assembler to do it's job 

 Well, the video/sound arch is. The CPU is accumulator based, so it's gonna be a little bit convoluted in that respect. Though IMO not any more so than x86 banked mode. Actually, less so - but that's probably because I've cut my teeth on 65x. Yeah, flat memory models are nice. But the banking on the 6280 isn't so bad. Better than both the snes and the nes. I usually keep important stuff near, and everything else is far jump/jsr (with a macro, just looks like a regular function call). But that doesn't apply to hacking. You have to learn how the game treats each 8k bank. Sometimes the games use a very clean/organized approach and it's easy to hook into that - other times it's more hack-ish in approach. All depends on how the developer structured their code.

[megatron-uk]

I think I've just worked out that all the single-char Japanese characters run on from the ASCII numbering sequentially in Cyber Knight.

For example, look back at the first font image - all the ascii chars are in sequence, and they are represented by standard ascii hex codes in the game rom. Fine so far (but a nice easy way to start!).

Now, look at the font tiles that come at the end of lowercase 'z', a gun, a sword, a right chevron and a red block, followed by the single Japanese characters. If you number these with the ASCII sequence immediately following that of z=0x7a, then you get the gun=0x7b, sword=0x7c and so on. The Japanese characters also continue that sequence sequentially, so 0x81=small_o_symbol, 0x82=left_upper_right_angle and so on.

I haven't gone all the way through the first page of fonts yet, but from those I've tested so far (the main title screen is the easiest way of doing this - simply replace the ASCII codes for CYBER KNIGHT with them and it works 100% so far (ie you get "CYBER <gun><sword><chevron><block>"). If everything is sequential it will make it a lot easier to construct the mapping table.

The image shows the result of changing the ASCII sequence for "CYBER KNIGHT" to the hex codes:

Code: [Select]

0D 06 7B 7C 7D 7E 81 82 83 84 85 86 87 88 00Which begins after the end of lower-case 'z', and shows that the numbering of the font tiles is contiguous with the ASCII sequence at that point - what a stroke of luck!

EDIT: I have to say, every time I look at that dull menu screen I die a little bit inside. It's like they didn't even bother trying.

[megatron-uk]

Ok, confirmed. These are the hex codes of the single byte fonts in Cyber Knight. It's very convenient that they're sequentially numbered.
I have a suspicion that the 0x1n codes refer to the dialogue box bezel tiles, but that still needs checking out.

EDIT: Ok, no the bezel tiles don't appear to work in the same way, replacing text with 0x11 (which would be the left hand bezel image according to the numbering sequence used for fonts) causes the game to reset on reaching the menu screen. That's fine, we're not interesting in hacking graphics yet.

[megatron-uk]

I've mapped all of the single character fonts to their ASCII and SJIS equivalents.

Although each character prints correctly when embedded directly within the menu text or one of the introductory cinematic dialogue boxes, the hex representations don't match what is in the dialogue text strings.

E.g

Code: [Select]

0C BC BD C3 D1 5C C6 20 45 4D 50 C0 DE D2 B0 BC DE 21
Displays the text as shown in the attached image, but the hex codes used to generate that display don't match those that my mapping of hex to font tiles show (other than the plain ASCII characters). Yet if I swap out a normal ASCII hex code (for example the uppercase 'E' at the start of 'EMP') with one of the Japanese charactrs my table says corresponds to 0xfb (a 'square' character) my lookup seems to work correctly, as the second image shows.

So it would seem that dialogue text is a bit weird. The thing is, there are more bytes in the sequence (at least 17, depending on what seems to be the start byte) than needed to represent all the characters (14), so it can't be compressed.

[megatron-uk]

Hold on. I've just realised something - all the dialogue I've seen so-far in this game has been printed on two lines.

I wonder if that text is indeed compressed and contains data for both lines, with the top being (I assume) accents or other character modifiers that can be seen in the various screenshots I've posted? I think that the code 0x5c has something to do with it

Yes, I'm almost sure of it.

Let's look at the 'EMP' example:

Code: [Select]

Byte pos: 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16 17
Hex vals: 0C BC BD C3 D1 5C C6 20 45 4D 5C C0 DE D2 B0 BC DE 21

Let's presume that the first sequence of bytes deals with both text lines, it then issues a 0x5c at byte 5, which I'm guessing means 'switch to literal one line output', it then prints a 0xC6 which does match my font table, a space, and then the ASCII sequence 'EMP'. At byte position 10 it then issues another 0x5c and presumably switches back to two-line mode so that it can print the remainder; some of which do require output on two lines.

[cabbage]

the accents are the 0xDE bytes, which tell the game to stick a ゛ above the last byte/character. it is printed on the row of tiles directly above, hence the double-spaced nature of the text which leaves room for these dakuten

the 0x5C is a control code to swap between katakana/hiragana output
e.g. シ and し are both 0xBC and which one is displayed depends on which character set is currently active

[megatron-uk]

Thanks,

Byte 0xDE is one I couldn't find a match for in JWPCE - however, the character code I've got that matches the first Japanese text shown after the 'P' is 0xE0. And the letter at the start of the string should be a 0x9C, not a 0xBC.

So the katakana/hiragana toggle code is doing something with the relative value of the hex code (-32). The default behaviour appears to be hex - 32, then after 0x5C the address becomes literal. Would that seem to be right?

EDIT: Thanks for the clarification. So it would seem that I need to work out if the default behaviour is for one character set or the other (default based on the above example would be show font for address - 32), then, when I detect an 0x5c, swap to the other, and swap back again when I get another 0x5c.

[megatron-uk]

Note sure I've quite got it.... if I work on the assumption that the default mode requires (hex-32) I go from this:

Code: [Select]

Byte pos: 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16 17
Hex vals: 0C BC BD C3 D1 5C C6 20 45 4D 5C C0 DE D2 B0 BC DE 21

Giving: しすてむに EMPため―し!

To this:

Code: [Select]

Byte pos: 0  1  2  3  4  5  6  7  8  9  10 11 12 13 14 15 16 17
Hex vals: 0C 9C 9D A3 B1 5C C6 20 45 4D 5C A0 BE B2 90 9C BE 21

Which would print:
シス』あに EMP せい‐シせ

The first two characters are correct, but the next two are not - the middle is correct, as it uses the literal values after the first 0x5c. But the last sequence is incorrect as well.

Hmm, not as straight forward as I though.

The sequence should be:

Code: [Select]

Byte pos: 0   1   2   3   4   5   6   7   8   9   10  11  12  13  14  15  16  17
Hex vals: 0C  9C  9D  E3  F1  5C  C6  20  45  4D  5C  E0  DE  F2  90  9C  DE  21
Modifier: 0  -32 -32 +32 +32  0   0   0   0   0   0  +32 +32 +32 -32 -32  0  0

Giving: システムに EMPタメ‐シ!  (and matching the screengrab)

[cabbage]

cyber knight does some things in strangely (like so many pce games, hehe)...

your table must have some mistakes, so try working from the data already in the game to rebuild it to match what the game expects.

hiragana and katakana are 1:1, so try making a table (from known data in the rom, not data you have changed to try and figure out what gets displayed from each value) just for hiragana...
then, the katakana part occupies that same space.
シ and し are both 0xBC in the game script. in this case they happen to be in different parts of vram, but that doesn't really matter if you're just trying to make a table

[megatron-uk]

So really I need a table with 3 columns:

Code: [Select]

hex value, before 0x5c, after 0x5c

[cabbage]

are you making a .tbl file for use with romhacking?

[megatron-uk]

That was my eventual aim.

[cabbage]

I'm not aware of any elegant way to support both character sets with a single table when they use swapping like this. Hopefully someone could enlighten us but I won't hold my breath hehe!
I know someone (Nightcrawler?) was working on a new table file standard which would allow for table switching, but I don't know if any tools support it yet (e.g. cartographer/atlas/hex editors)

You can just make two table files--one for hiragana and one for katakana--but that doesn't help very much for script dumping/insertion without special tools... hence the appeal of the new table file standard

Really, though, as long as the hiragana and katakana overlap 1:1, a good translator should be able to proceed if the whole script is dumped just using one or the other. The 0x5C would even serve as a flag to alert them to the switch for added context.
So they would be reading along, "blah blah blah japanese text <SWAP>some katakana data, shown as hiragana text<SWAP>some more japanese text blah blah", and just know that the text surrounded by <SWAP>s is meant to be displayed as katakana. It would be read just the same...