[Pikachumanson]

Ok I cannot find the intro text to Jaseiken Necromancer anywhere. So I narrowed it down to to two things. One, it is most obviously compressed. Two, I'm thinking it might be a graphics sprite in which case I might have to make another table or find a way to decompress the graphics. Which leads me to my question. What compression techniques do TG16(especially those by Hudson Soft) games usually use?

[FAST6191]

The PCE/TG16 is a seldom hacked console and I am not sure how many around here, or indeed in general, hack the console with an eye to ROM hacking style hacks, I certainly am not one that does anything there; indeed the only things I have ever really played of the libraries are the awesome versions of bomberman it has (genesis/megadrive and SNES bomberman and then some is the usual description) and a go on the castlevania to say I have- I have not even sampled the supposedly awesome library of shmups it has.
Older consoles compression then.... the 77 in LZ77 refers to the year it was cooked up so pretty much any compression you would have read about as part of ROM hacking is viable, however what I have seen of consoles of this vintage says they usually opt for the low end compression methods like RLE and the dual tile encoding although fairly primitive (which is not to say easy to work with, decode by hand or handle in general) LZ/LZSS and Huffman are certainly available. My lack of PCE/TG16 knowledge will betray me once more as I can not even tell you if whatever passed for the SDK had something (or a primitive version of zlib got a port) or if the PCE BIOS had functions in it, indeed anything I say will be the result of a search along the lines of "PCE BIOS functions list" so I will not even pretend.
I can however link up my present favourite document in the introduction to compression stakes, https://ece.uwaterloo.ca/~ece611/LempelZiv.pdf . Although it is mainly about LZ (although not an exhaustive work it could certainly be the basis for one) it covers the likes of RLE and Huffman quite well.

I did however come here mainly to say have you tried corruption? I can talk in broad terms about compression methods and possibilities at some length but having an example of the would be section. To that end if you can corrupt the ROM image until the section you want breaks and then figure out where it is that is a far nicer starting point. Do try to make sure you have not just caused a crash at the right time, though figuring out what is a crash and what is corruption is part of the trick to the method I guess.

That said compression and text rendered as graphics at compile time are two of the three usual suspects for this so do carry on with this line of logic; the third, especially as far as title screens and intro sequences are concerned, is that it is a different encoding to the rest of the game.

[Pikachumanson]

Thank you Fast6191, as usual your posts are helpful. What do you mean by encoding? As in a different table or are we talking ASM code here?

[Klarth]

The TG-16 only has 8KB of RAM, IIRC.  This really limits the types of compression techniques used.  Any data of respectable size (such as graphics), you'd have to write the compressed bytes directly to VRAM (or use a small buffer in RAM).  You couldn't decompress a whole block at once nor keep it in RAM, so Huffman is probably a better choice because you can have pointers to data blocks inside of Huffman compression.

That said, how many techniques have you tried to find the text?  Relative search?  Some encodings aren't alphabetical, especially with the Japanese alphabet.  Savestates?  DTE?  7-bit encoded text?

[dshadoff]

1) On a HuCard, the first thing you should do is find the font.
2) The sequence in which the characters are stored, will likely give you the character encoding for text.
3) Then try relative search; don't assume that they are using SJIS or anything of the sort (although sometimes you might get lucky).

[Pikachumanson]

@Klarth I have used saved states to see the intro text. The characters that show up correspond with my table. If there were a way I could use the save to alter that text permanantly I'd do it in a heartbeat. As for DTE I am studying up on HU280 assembly so i can actually use it. I see how it's done on Nes and snes so id imagine it is similar. But i don't know as I dont fully understand what i am doing there yet. I have no idea what 7-bit encoding is. I'll have to look that up along with RLE. I think I'll try what dshadoff suggested and hope for the best. I know finding the intro text is only half the battle and I definantly have to implement DTE in this game to get even a half decent translation. Thank you everyone for your suggestions. As always, I'd love to hear more and learn.

[MooZ]

Hopefully the font is stored in raw 1bpp in the rom.

The rom used here came from the no-intro set. If you are using the old good-pce set, you'll have to add 512 (200 hex) to the offset.
From a quick check, it seems that the text for the intro is stored in the 9th bank (offset 12000h). I hope you are using the mednafen debugger

Good luck with the compression routine.

[Pikachumanson]

I was using that program last night to look at the font as well along with Fatility. So i was looking in the wrong place in the 15000 to 16000 hex range. Hopefully i can figure out how to configure the rom path in mednafen emu. I only took a cursurary look at it when i downloaded this bad boy earlier in the week. Thanks for the info my good man.

[KingMike]

I have no idea what 7-bit encoding is.

Where each text characters is stored in 7 bits instead of 8 bits (1 byte).

This gives a possible range of 128 values. Still possible, I know Hudson had use a hiragana/katakana table swap at least on the Momotarou series.

Such that if you had byte 0123

Code: [Select]

01 23
In binary
Data in binary   00000001 00100011
Bits for char 1  -------
Bits for char 2         - ------
Bits for char 3                 -- (and continues to next byte)
character 1 = 0000000 = $00
character 2 = 1001000 = $48
Obviously would need a custom program to unpack/pack the text.

[MooZ]

The text is fetched at $f151:

Code: [Select]

lda ($a0), Y
The first sentence of the introduction is: 8f 9b 9c 4f 8f A9 A2 97 8f 8b 9d 4f
The text is not contiguous. The read sequence is:

Code: [Select]

12191: 8f <
12000: ff
12002: ff
12004: ff
12010: ff
12064: ff
12066: ff
12169: 9b <
12000: ff
12002: ff
12004: ff
1206b: ff
1206d: ff
12076: ff
12078: 9c <
12000: ff
12099: ff
12153: ff
12174: ff
1218f: ff
12192: 4f <And if you replace the value at $12191 with $2A (A), you'll get:

This means that the compression is either LZxx or dictionary based.

[Pikachumanson]

Nice! I'll get right on it! Thanks a bunch! I'm giving all you guys credit for this hack when its done!
November 02, 2012, 10:08:31 am - (Auto Merged - Double Posts are not allowed before 7 days.)@Mooz or anybody else who knows. All right I got mednefan and I found the lda $f151 fetch address you were talking about. Now I have 4 questions, one are all lda commands fetch or pointer addresses? Two how did you know what adress it pointed to? And finally three, how  do you get to the point where you can see and change the intro text like that? Did you use Mednefan to do all this? Sorry i ask so many questions but mednefan documentation isn't exactly the greatest for beginnrs like me.

[KingMike]

lda ($a0),y
means:
read the pointer at zero page address $A0-A1, or RAM address $20A0-20A1 (from what I read, "zero page" (which is $0000-00FF on most systems, hence the name) is instead hardcoded to $2000-20FF on the TG16)
now read from address: that pointer you just read, plus the Y register.

I guess he means that ASM instruction "lda ($a0),y" is located at CPU address $F151.
But what ROM address would that correspond to? You'd need to check what ROM bank is mapped into the TG's internal memory mapper MPR7. Not sure if the debugger will tell you, it's been awhile.
But I've also read that typically CPU address bank 7 (addresses $E000 to $FFFF) are mapped to the first ROM bank (or ROM $0-1FFF), so that would be ($F151 modulus $1FFF, or $1151).

I'll agree that mednafen has a powerful debugger but it's not easy to navigate.

[Pikachumanson]

YESSSS!!! Thank you fellas, I finally got it! Now to figure out if its dictionary compression or LZ77!