[RaidouJFlo]

Holy crap, man.  This is tougher than NES text hacking.

I just want to make sure I understand what I'm actually looking at here.

If anyone here has tried to translate, or simply text hack Devil Children Black Book, you'll notice how the PPU instead of showing all text characters at all times, will dynamically change to whatever text characters are needed.  Nah' mean?  If not Devil Children, perhaps other GBC games use this method maybe?

I've done famicom translating before and I've never encountered a PPU as dynamic as this.

I'll show some example pictures below.





So, I'm just going to focus on the top row text.

Looking at the MAP, the first address with text is $99C1, and ends at $99D2.

Proceeding through text as well will always display the same bytes in that address stream (DC, DE, DF, etc).

What I'm interpreting this as (and I might be wrong), is that $99C1 - $99E1 is always a fixed value, which are the bytes:

DC DE DF E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED

Those bytes are fixed on $99C1-$99E1, but the value they're pulling from is not.  Said "From" is the PPU, which is dynamically changing DC - ED's values.

You guys think crazy hacking is required to decipher this stuff? 

Or maybe, within the rom, there's a set of bytes representing what gets applied into the PPU for specific text use?  I never tried looking for that, and I'm not sure what the byte value of each character would be either.

Eh... Sorry if this explanation sucks.  Truth be told, I don't really get it but I'd like to understand it I guess.

[zonk47]

That shouldn't be too hard to find... the routine is used in the opening sequence, which comes right after you press start. Pause right after you press start, then step through until infinite loop. The text routine is right before the loop back.

[Gideon Zhi]

SNES games do this all the time. This is the foundation of proportional ("variable-width") fonts. Instead of tiling the font characters to the screen, they're drawn to a discrete section of ram which is then itself tiled to the screen. In the case of a game with a monospace font like this, it's likely done to minimize the amount of PPU memory taken up by the text; it's dramatically cheaper from a memory perspective to use 36 bytes (DC-FF, it looks like) for dynamic text than it would to store entire hiragana+katakana character sets. Of course, the tradeoff is that it takes more CPU time to draw the text, but especially when you're talking a monospace font that tradeoff is minimal.

[FAST6191]

What others have said -- it is fairly standard in newer systems.

What I mainly want to say though is this is the wrong way to set about text hacking on consoles like those. I might look at memory to maybe get an idea of the hex and the game itself to see what text to search for and other things (do I see something resembling markup) but if I am looking at a font in a VRAM viewer then it is because I am editing the font and not because I am changing the contents of the text, or the text in question is rendered as a picture.

Oh and VBA is nice enough for debugging/hacking you are probably better off with BGB http://bgb.bircd.org/

[RaidouJFlo]

That shouldn't be too hard to find... the routine is used in the opening sequence, which comes right after you press start. Pause right after you press start, then step through until infinite loop. The text routine is right before the loop back.

SNES games do this all the time. This is the foundation of proportional ("variable-width") fonts. Instead of tiling the font characters to the screen, they're drawn to a discrete section of ram which is then itself tiled to the screen. In the case of a game with a monospace font like this, it's likely done to minimize the amount of PPU memory taken up by the text; it's dramatically cheaper from a memory perspective to use 36 bytes (DC-FF, it looks like) for dynamic text than it would to store entire hiragana+katakana character sets. Of course, the tradeoff is that it takes more CPU time to draw the text, but especially when you're talking a monospace font that tradeoff is minimal.

With the English Alphabet (assuming only capital letters are being used) combined with punctuation, I'd have less than 36 bytes to use for text. 

So I guess if it's possible, I could have the PPU display the 26 english characters + 5 punctuation (!?'.,) characters at all times, right?

Provided I figure out how the PPU is changing though I guess...

Guess I better start reading up on Z-80 assembly.

What others have said -- it is fairly standard in newer systems.

What I mainly want to say though is this is the wrong way to set about text hacking on consoles like those. I might look at memory to maybe get an idea of the hex and the game itself to see what text to search for and other things (do I see something resembling markup) but if I am looking at a font in a VRAM viewer then it is because I am editing the font and not because I am changing the contents of the text, or the text in question is rendered as a picture.

Oh and VBA is nice enough for debugging/hacking you are probably better off with BGB http://bgb.bircd.org/

Thanks for BGB, this looks pretty good.

[zonk47]

Z80 is just x86 without neat things like MUL and DIV... no multiplication or division instructions on that early CPU... so you have to do the work in code that would otherwise be done in the processor. A multiply is the same number added X times... a divide is just repeated subtraction with a check for negativity each time (which the processor does automatically via its overflow flag)... the quotient is the number of times you can subtract the divisor from the dividend without going below 0. ASM isn't complicated or difficult... the mnemonics just make it seem that way when you're inexperienced with them. It can be time consuming though when you're doing it by yourself.

[Gideon Zhi]

With the English Alphabet (assuming only capital letters are being used) combined with punctuation, I'd have less than 36 bytes to use for text. 

So I guess if it's possible, I could have the PPU display the 26 english characters + 5 punctuation (!?'.,) characters at all times, right?

THIS IS POSSIBLE BUT DEVIL CHILDREN IS A FAIRLY LARGE GAME AND YOU DON'T WANT IT TO SEEM LIKE IT'S SCREAMING AT YOU FOR THE FIFTEEN OR TWENTY HOURS IT'D TAKE TO PLAY THROUGH.

In all honesty, you're overthinking this. Getting the tile IDs from PPU memory in a situation like this is the wrong approach. Each character will almost certainly map to a specific byte in the game's own encoding; the engine is what causes the tiles to be drawn in that manner. You won't NEED to have all caps; you just need to figure out how the text is actually encoded, replace the Japanese characters with Roman letters, and re-encode the translated script using the new equivalencies. Honestly, this is translation hacking 101 stuff. You should probably read over some of the docs on text replacement in the Getting Started section.

[RaidouJFlo]

THIS IS POSSIBLE BUT DEVIL CHILDREN IS A FAIRLY LARGE GAME AND YOU DON'T WANT IT TO SEEM LIKE IT'S SCREAMING AT YOU FOR THE FIFTEEN OR TWENTY HOURS IT'D TAKE TO PLAY THROUGH.

In all honesty, you're overthinking this. Getting the tile IDs from PPU memory in a situation like this is the wrong approach. Each character will almost certainly map to a specific byte in the game's own encoding; the engine is what causes the tiles to be drawn in that manner. You won't NEED to have all caps; you just need to figure out how the text is actually encoded, replace the Japanese characters with Roman letters, and re-encode the translated script using the new equivalencies. Honestly, this is translation hacking 101 stuff. You should probably read over some of the docs on text replacement in the Getting Started section.

For the sake of making this experience easier, I'll do CAPS for now (I lol'd though).  Gameboy Tile Editor feels a lot better than TLP for GBC (since I can actually see the characters clearly), at least, and unfortunately I have to design my own font, so it'll be too much effort to me to make upper/lowercase.  I found the kana/gana characters, so I'll begin replacing all of them.

Z80 is just x86 without neat things like MUL and DIV... no multiplication or division instructions on that early CPU... so you have to do the work in code that would otherwise be done in the processor. A multiply is the same number added X times... a divide is just repeated subtraction with a check for negativity each time (which the processor does automatically via its overflow flag)... the quotient is the number of times you can subtract the divisor from the dividend without going below 0. ASM isn't complicated or difficult... the mnemonics just make it seem that way when you're inexperienced with them. It can be time consuming though when you're doing it by yourself.

I read ya, duderino.  If that's the case, I'll continue learning 6502.  I've done a bit of reprogramming in Zelda 1, but nothing to boast about (Having File Creation go to File Deletion, and File Deletion go to File Creation).  Oh yeah, something like having Dungeon 1's entrance in the world map go to the final Dungeon as well.  I'm an absolute goddamn mad man, aren't I?  Just kidding.

[tvtoon]

Z80 is just x86 without neat things like MUL and DIV... no multiplication or division instructions on that early CPU...

I have to rectify that the GB CPU is not Z80, but some 8080 variant.

[Gideon Zhi]

For the sake of making this experience easier, I'll do CAPS for now (I lol'd though).

And what will you do when you need numbers? To put it plainly, 36 tiles is not enough. My point is that the engine is already doing everything you need it to - there's more than 36 tiles in the actual game, after all. Why reinvent the wheel? Why redo the entire system when what's already there works fine?

[RaidouJFlo]

And what will you do when you need numbers? To put it plainly, 36 tiles is not enough. My point is that the engine is already doing everything you need it to - there's more than 36 tiles in the actual game, after all. Why reinvent the wheel? Why redo the entire system when what's already there works fine?

Oh boy... I'm a bit embarrassed at this thread now...

I'm clocking in what you're saying just now, and realizing the mistake I've made.

I will redeem this foolishness soon enough.


EDIT

OKAY.  I found the tile IDs using BGB save states (couldn't find them within BGB or VBA).  Here's the result, and I can also see everything on windhex after creating a table.

Again, my apologies for such foolishness.  It's no wonder you told me that 101 hacking thing earlier heh.  The PPU changing like that made me think that only what was there was available to use (since all I have is NES hacking experience).

Given that SNES using the same text rendering method as mentioned earlier, I won't make the same mistake with that.



Thanks guys!