Cyber Knight translation

[megatron-uk]

Can anyone confirm what I believe to be the case with Cyber Knight? That it, its script and artwork assets are stored as compressed in the rom?
I'm having no luck with Tile Layer Pro, TMOD2 or YY-CHR when trying to viewing any sprite or font data.

This thread started out in early 2014 as an attempt to find any English text or assets in the RPG/Strategy game Cyber Knight, it has now turned into a full English translation project.

Translation tools, patches and other assets will be continuously updated on my github page and anyone can download and use them. The project now has a 99% complete Ascii/Hiragana/Katakana translation table, a 99% complete Kanji translation table, working extractor and injector scripts and work has started on writing patches for the game text. These take the form of individual JSON that correspond to a particular section of the rom file. This way we can extract and re-insert seperate sections of text and not have to create a single, giant all-encompassing patch.
The patch files mostly correspond to certain, common sections of the text - all the ship menu structures, all the item names, battle screen dialogue, dialogue for each world/town etc.

https://github.com/megatron-uk/cyberknight-pce


Edit (April 18th, 2014):
The battle interface is almost 100% complete - all menu options, status text, messages from the computer etc and all translated. There are some minor spacing and linebreaks to test visually, but the text itself is all done. Unfortunately a side effect of doing more translating of the main game dialogue has broken the scrolling intro - it will need work again (possibly someone to adjust it's location in the rom). Here's a video of several battles on the way to the first main quest in the game (the crashed ship 'Europa'):

Edit (March 30th, 2014):
Lots more translations done, virtually all weapons/items, character names and now in-game text too. Here's the full English menu structure for the ship:

Edit (March 3nd, 2014):
Scrolling 'the story so far' text that appears after the intro cinema is now translated. Updated patch files now on github.

Edit (March 2nd, 2014):
Intro cinema now fully translated!

Edit (Febrary 28th, 2014):
Quick example showing some of the translated menu and dialogue: Cyber Knight PC-Engine initial translation test

Edit (Febrary 26th, 2014):
Updated player character name entry screen, started translating npc name lists (incomplete).

Edit (Febrary 25th, 2014):
Main menu screen is now translated (patches/test.json on github) as a test of the extractor and injector utilities.

Edit (Febrary 23rd, 2014):
All code and assets I've produced to extract/inject script data will be available on github here: https://github.com/megatron-uk/cyberknight-pce
For now this includes a 99% complete translation table and a 'mostly' working script extractor; which we need more text dialogue location information for!

[megatron-uk]

Hold on, I think I can see partial font data in TLP if I switch to 1BPP format (why?), but it doesn't look right - the fonts are all offset and corrupted, different to any of the other hucard games I've looked at so far.

One good thing about this is that it does have a full western character set (both upper and lower-case) in there though.

Tried Nana too - it also seems to show the font not being byte-aligned.

[TurboXray]

Looks like data(a byte or two) is interleaved between some of the font graphics. Look at "C" and "D", appear to be corrupt. Some of the others, while not corrupt looking, are probably offset because of header bytes or control codes (for sequencing through the font?).

Edit:
 Actually, just looking at it - it appear to be compressed via RLE variant. Look at the "C", and look right at the first break. See that pattern of pixel? You see the same thing on the number "1". And the same thing for "D". The byte is probably something unique that doesn't exist in the whole font (graphically) and thus is a control code. When encountered, the following bytes are probably the paramenters for the control code (run length). Pretty poor compression method. They would have been better off using a mask 1bit repeat method. Typical lousy compression schemes uses on hucard games (ugh).

 Anyway, that's my guess.

[megatron-uk]

That makes sense Tom.

I'm following some of MooZ's postings here where he describes looking for writes to the vram at the locations where the font ends up in order to find out what  code is doing the decompression. According the bg/sprite viewer the font occupies 0x1210 to 0x2ff0 in vram.

I'll see if I can trace what is decompressing and loading the font.

[megatron-uk]

Well I think I found the code thats clearing vram before the copy:

Code Select Expand

EAD3    SEI
EAD4    STX $0002
EAD7    STX $0003
EADA    CLI
EADB    DEC $34
EADD    BNE $EAD3
This seems to be running for the entire vram region, so I presume it's clearing it before writing sprite/tile/font data. Still looking for the font decompressor, off to peeps now though.

John

[megatron-uk]

So it appears as though the ASCII used in the game is stored clear in the rom - the phrases I've found in English so-far:

"CYBER KNIGHT" - In the title bar of the (dreadful!) blue start screen (seriously? could they not do a better effort than that?) appears three times in the rom (once in the header, once misspelled as 'CYBER NIGHT' and once more for the title screen) and when edited to other ASCII codes represented by the included font is reflected in that screen.

"MAX!" - Appears in one of the dialogue boxes from the crew during the intro while the ship is under attack and is present in the rom exactly once; having briefly played the SNES translation I think it refers to 'Hyperdrive now charged at MAX!' or something similar.

Judging from the control codes embedded in some of the text strings I'm also guessing that 043c is the flashing 'more text' graphic that appears at the end of dialogue boxes a that sequence is very heavily used.

There's also the name of the ships computer "Mica", which occurs quite regularly throught the rom.

Also another point - when you create a new character the name of the player you create is stored as a plain ASCII or single-char Japanese representation at 0x2400 in main memory.

With that, although we don't have a font to extract (yet) because of the encoding (and, actually as it already has full upper and lower case western characters with punctuation, we wouldn't necessarily need to replace it), I should at least be able to make a start doing a table of characters to font tiles (as at least the western font tiles are sequential).

I guess what I'm trying to say is that although the graphic assets appear encoded in some fashion, the text itself now doesn't appear to be.

[megatron-uk]

... and I think that that the code 0x52 switches between character sets - as it occurs right before and right after any ASCII text (when that text has Japanese characters before or after it), so it must be interpreted as a char mode toggle.

[TurboXray]

Yeah, if the font has everything you need - you could leave it as is. But you will need a vram dump of it, and need to identify all those japanese characters, so when you dump the game script you'll now what char is one is referring to (I usually do a small table to convert the game JP chars to SJIS and write them to a doc/txt file). JWPCE will read plain text files with SJIS chars (and ascii as well). Just use the .SJIS extension instead of the .TXT

[megatron-uk]

Well I've got the vram screenshot of all the western and single tile Japanese characters and have now divided into a grid so that I can (slowly) go through it and identify all the characters and recheck that key phrases I've been looking at in Windhex start to look correct with the new table added. This bit is going to be slow...

I think the some of the control codes in the text strings are to switch to/from double width/byte characters as the second screen dump from Mednafen, further down the vram memory map, shows some Kanji and 'large' fonts. But it's not sequential like the first font set. You can see that you get the top half of one set of characters in one row, then the top half of the next, then the bottom of the first half, then the bottom of the second set.

[TurboXray]

Ahh, I see. There's another approach I've seen over at RHDN. First, you have to find the main print routine and figured out the smallest and largest character values. Then you take that vram dump and write an app that goes through the entire valid character range, and spit out the vram assembled graphics to a bitmap file. Then present the file to RHDN or whatever translation site, and request an identification of said chars.

 Of course, you can do this without writing an app, but it's slower. You save state the emulator, over-write the corresponding text string with sequential values, and take visual snap shots of each set of sequential output to the text box.


 As far as the font itself, assuming you want to change it, you can always expand the rom and write a hook to monitor font decompression routine (because it could be used for more than just the font) and jump to alt code that updates vram with your new font. No need to decompress the old one and re-compress a new one.

[megatron-uk]

I would probably just keep the font as-is, but expanding the rom image is a good idea. It would be nice to jazz up that main menu screen and some of the dialogue box bezel images.

To be honest, about 50% of what you've just said is probably over my head but I'll keep plugging away to create this table in the first instance

Edit: actually, just looking at that second set of fonts, I bet it's only used in the in-game menus as it certainly matches the menu options I've seen in the game so-far.

[TurboXray]

Have you done this type of translation hacking before? If this is your first project, it just takes a little bit of time to get used to all of this. Lol - after your first project is done, you feel like you can translate any game at that point - haha.

 If the script is uncompressed, then that makes this twice or three times as easy as a compressed script game. I really hate Huffman compression Necro-whatever PCE game uses it. I took a look at it for a hacker over at RHDN, because they're trying to translate the game. I really didn't want to write the decompressor... ugh. Dunno - something about huffman (binary trees) that I never liked/clicked with me (LZSS for me alllll day). If you talk to MooZ, see if he's interested in dumping the script to Necro-whatever for PCE. There's already a group waiting on the script. I have my notes, somewhere around here...

 That aside, have you thought about upgrading any of the graphics? They're probably in 2bit/3bit format. If you expand the rom, you could hook the character/sprite upload routine to upload upgraded 4bit versions of the graphics. A LOT of early hucard games used simple 1/2/3bit graphic formats, because there is no decompression resource penalty (planar graphics) and can be uploaded to vram on the fly without decompressing to a buffer first.

[megatron-uk]

Have you done this type of translation hacking before? If this is your first project, it just takes a little bit of time to get used to all of this. Lol - after your first project is done, you feel like you can translate any game at that point - haha.

I haven't done any hacking before

I did a lot of Unix systems programming (C, Posix threads, OS design, that kind of stuff) about 15 years ago at University, but the last proper C/systems-programming was probably about 10 years ago.

The everdrive-fat code is the first bit of decent coding I've done for a long time (and I'm enjoying it again!); I'm a Unix systems manager in my day-job so the kind of stuff I do on a daily basis tends to be shell scripting, Python, Ruby, maybe a bit of Java. But the programming side of it is just a tiny bit (just enough to keep my skills from going rusty) it's mainly managing virtual machines, doing dba work, designing middleware libraries etc. Nothing as low level as this!

I think this is one that's definitely worth persevering with - the script is already translated via the SNES and everyone really rates the game.

Graphical upgrades would be the icing on the cake - the SNES version already has some better in-game sprites (although the ship navigation screens look nicer on the PCE, imo) and I would oh-so-love to put a snazzy mecha background on that menu screen

[Xak]

Very very interesting topic. thank you for posting and keep us updated.

[TurboXray]

I haven't done any hacking before

Well, looks like you have a knack for it then.

 Both MooZ and I have a few PCE translation works under our belt. Feel free to ask questions if you get stuck.

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.

Graphical upgrades would be the icing on the cake - the SNES version already has some better in-game sprites (although the ship navigation screens look nicer on the PCE, imo) and I would oh-so-love to put a snazzy mecha background on that menu screen

Let me know when you get to that point. I can definitely help out there (I have a lot of experience with writing hook code for loading alternate stuffs, for PCE related games).

[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 Expand

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.

[TurboXray]

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 Expand

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 Expand

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 Expand

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 Expand

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 Expand

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 Expand

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 Expand

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...

[megatron-uk]

Yeah, I think I'll probably have to write my own extraction tool (once I find out how to access all of the script) and a parser to load the 'swap' logic as each string is read - for example, the dual line thing doesn't make any sense as I can just lookup the correct symbol for a character with a dakuten/handakuten when I write the script file to disk (I'm hoping that the SNES translator will be willing to part with a copy of the translated script for that version).

[TurboXray]

You already seem proficient in C, you should just write your own. I always write my own extractors and inserters.

[megatron-uk]

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

I think this is the problem - I've got very little to go on, which is why I've been picking out phrases with at least some ASCII codes in them, as without that, I've got nothing to search for in a hex editor.

[megatron-uk]

I've been using the menu screen to go through and make a new table. First off I did all combinations from 0x20 - 0xff and it matches my existing table. I've now added the 0x5c control code at the beginning and am doing a second column - so far it does seem to be a 1:1 mapping between Katakana and Hiragana, I think they switch places, but need to complete the table to confirm this.

e.g.
pre-0x5c a 0xFD = ン

after a 0x5c a 0xFD = ん

[megatron-uk]

Ok, I now have a translation of all fonts in the game, both those before a 0x5c control code, and those displayed after a 0x5c sequence.

There are about half a dozen fonts I cannot identify from the very small tiles included in the game, I may need some help with those at some point, but I have around 200 characters identified now.

[TurboXray]

Have you figured out the pointer system yet?

[megatron-uk]

Not yet, I haven't really thought about where to start with that yet - Ive just been using some obvious text strings to work out the fonts, but I don't know how to start looking for all the locations of the text.

Any "pointers"?

[TurboXray]

Lol.

If there's a chunk of text, the pointer block might be near by. You can usually identify a pointer block, visually, in a hex editor. The values in the pointer block might be relative, might 10bit, or might be logical (16bit). Or possibly something weird in format.

 Give me an address to some text, and I'll take a look.

[megatron-uk]

These are the three main sections I've been using to extract the font details as they have ASCII characters in the display...

Main menu
Description, the main game menu.
Text reads CYBER KNIGHT
ROM location: 0001CB00
0D 06 43 59 42 45 52 20 4B 4E 49 47 48 54 00

Opening Cinematic
One of the first dialogue boxes displayed as the players ship starts to take fire. I would think most text in the game would be in a similar format or pointed to in the same way as this as it seems quite standard with all of the other dialogue box text (0x3c at the start and 0x04 at the end).
Text reads システムに EMPタメ‐シ!
ROM location: 0002A142
3C 0C BC BD C3 D1 5C C6 20 45 4D 50 5C C0 DE D2 B0 BC DE 21 04

Scrolling Intro
The intro text scrolls up the screen once the intro cinematic has finished and before the game begins.
Test begins AD2352.11.21 (and continues over several lines)
ROM location: 0001BAD6
41 44 32 33 35 32 2e 31 31 2e 32 31 00

[megatron-uk]

It's go-to-bed time here, but before I do, someone on RHDN shared a few interesting pieces of information from his looking at Cyber Knight quite a number of years ago:

0xC7EC - font decompression routine
0x2C21F - compressed font (*16:001F logical)
0x28200 PC - some dialogue, pointers seem to be 2-byte, little endian
$CEF5 - dialogue load routine

[TurboXray]

It's go-to-bed time here, but before I do, someone on RHDN shared a few interesting pieces of information from his looking at Cyber Knight quite a number of years ago:

0xC7EC - font decompression routine
0x2C21F - compressed font (*16:001F logical)
0x28200 PC - some dialogue, pointers seem to be 2-byte, little endian
$CEF5 - dialogue load routine

I saw that table. But the text in the beginning of the game appeared to use hard offsets. So I didn't get any break points on that table yet. But I only took a 5 minute glance at it.

[megatron-uk]

Looks to be a possibility of a second (slightly bigger) pointer table at 0x2D409 (rom + header) / 0x2D209 (no header).

I can't figure out the address format for either though - relative to start of the table, absolute plus some offset, nor how many entries are supposed to be in the table. More testing to do!

EDIT: Now found what appears to be yet another table at 0x26F4A (no header).

[NightWolve]

I haven't done any hacking before

Well, looks like you have a knack for it then.

Yeah, could've fooled me!! Well, welcome to the fan tran club then, megatron. ;) I thought you were just knee deep in that Everdrive tinkering and what not. I didn't expect to find this all of a sudden from ya! Good luck, at any rate.

[megatron-uk]

Ha ha! Thanks Still early days yet though.

Right now I'm trying to get my head around where these pointers are actually referencing - I've read David Shadoff's post here and it makes sense, seeing as the PCE only maps an 8k window onto the rom at any point in time.

What I probably need to do is find an in-game piece of text, such as something said by one of the villagers in the first settlement you visit, work out the hex for the text being displayed, find the match in rom, and then try and find it in the CPU logical view in mednafen stepping through just before the dialogue displays.

[megatron-uk]

Found what should be a helpful piece of dialogue text to track down what pointers are being used:

ROM position: 0x01DEFE (without header)
Hex sequence: 4D 49 43 41 A2 BB B8 BE DD 5C B4 D8 B1 5C B6 D7 20 CA BD DE DA C3 B2 CF BD A3 08

It's a phrase from MICA, the ships computer that appears whenever you try and wander off just after landing - basically if you go anywhere other than the city or your ship, that phrase appears.

Now I need to step through what happens just after triggering that phrase to see where the pointer to it is being loaded from.

[megatron-uk]

Is there any way of having Mednafen put a breakpoint at logical address? - as I'm having a bit of a pain tracking down where this text string is being loaded from and when the section of rom is being swapped in to be read from.

I'll probably call it enough for the weekend now - I've got to prepare for a job interview tomorrow.

[OldMan]

*(page):(address)   => ie, *02:ffef  will break on that exact address only.
(addr)                      => ie         0fff  will break on that address in any page, when mapped in.

The second one will generate a lot more breaks; you have to check the mpr registers to see if it's the page you want.  Try both and see which one you need - thought it's probably the first, at this stage.

[TurboXray]

There's also external address breaking that isn't bank mode: so *15:8c44 can be done as *2ac44. And you can do a range as well *2ac44-*2acff. And you can have multiple range reads, but just make sure your 'long' address ranges come last in the window. So something like: 57ff 2066 7ff0-7fff *2ac44-2acff. Another pro tip; you can put more arguments/parameters than what will fit in the text window. Use the arrow keys to scroll back and forth, because it won't show the whole thing.

[burn_654]

When I've been working here and there on Momotarou Katsugeki the script worked much the same way - that control code to switch between hiragana and katakana, and a control code to put dakuten/handakuten on the previous character. What I ended up doing was similar - making a table for each - but there are tools that can make the extraction easier for you. I had good luck extracting snippets (ie, a hex range) with romjuice by putting that control code as my 'switch tables' identifier, hooking up my two tables and it spat out some nice txt dumps. Atlas can do this too (and probably the tool to use for complete dumps) but I found it a bit harder to use for simple tests, it seems intended for script dumps when you have a pointer system figured out. It was just my experience dumping a sentence or two with a table change mechanic worked well in romjuice.

This makes me want to resume my work as well - I'll be following this! For katsugeki I'm still cracking away at trying to figure out how to alter the tilemap for dialog boxes.

[megatron-uk]

Thanks for the read-break pointer syntax help! The mednafen docs could do with some extra examples!

But, we have a winner! The image below is with a read break on a single address - *1DEFE - immediately after the dialogue box is shown and before the text is printed, so the pointer must have been fetched just before this point.