+  RHDN Forum Archive
|-+  Romhacking
| |-+  General Romhacking
| | |-+  [PSX] Compression Routine - BoF4
Pages: [1]
Author Topic: [PSX] Compression Routine - BoF4  (Read 710 times)
Flashware
Guest
« on: April 11, 2007, 01:16:43 am »
Actually I'm working on a German translation of the game Breath of Fire 4

I think most of you think it's a complete waste of time to translate something in a language like German, but English is atm the only foreign laguage that I speak, anyhow I like romhacking. Further I like to enhance my English skills, 'cause I like this language.

Now to my problem:

The text / grafics are uncompressed as far as I see, except for the font.

I allready used the PSX debugger of Agemo and made a gpu upload break.
This way I was able to locate, when the uncompressed Font is written into the vram (via the vram viewer I was able to look this up).

I know that it is a 4 bit tile data.

And I got this informations:

8016d2e8 : SW      01000201 (a0), 0000 (1f8010a8 (v0)) [1f8010a8]

Now I dumped the ram and disassembled it. And looked to the adress, where I found this:
Code:
L16d2a0: ; 8016D2A0
8016D2A0 beq    s4, zero, L16d2ec [$8016d2ec]
8016D2A4 lui    v1, $0400
8016D2A8 lui    v0, $8018
8016D2AC lw     v0, $c3cc(v0)
8016D2B0 ori    v1, v1, $0002
8016D2B4 sw     v1, $0000(v0)
8016D2B8 lui    v0, $8018
8016D2BC lw     v0, $c3d0(v0)
8016D2C0 lui    a0, $0100
8016D2C4 sw     s2, $0000(v0)
8016D2C8 sll    v0, s4, $10
8016D2CC lui    v1, $8018
8016D2D0 lw     v1, $c3d4(v1)
8016D2D4 ori    v0, v0, $0010
8016D2D8 sw     v0, $0000(v1)
8016D2DC lui    v0, $8018
8016D2E0 lw     v0, $c3d8(v0)
8016D2E4 ori    a0, a0, $0201
8016D2E8 sw     a0, $0000(v0)
Now I wonder what I could do as a next step (I'm learning r3000a asm at the moment) and if i did everything right so far.


sorry for my bad english^^ but how I wrote above I try to get better.

greaz Flashware
Tauwasser
Guest
« Reply #1 on: April 11, 2007, 06:20:11 am »
Hey there,

it sounds like you did everything right =) Now you might want to understand what the routine you got is doing. Obviously it's not the whole routine (it doesn't load the font when the beq is true at the beginning). Either way. If you can find out the offset of the font then you're pretty much done. It's a sw, so I assume that it uses the native decompression in the psx bios, right? If so and the routine it uses is known, then you might just be finding a decompressor tool somewhere on the net or some docs at least to how it works.

And you shouldn't start your first post with an inflammatory assumption of any kinds. There are enough people here that do not translate only into English.

cYa,

Tauwasser
Flashware
Guest
« Reply #2 on: April 11, 2007, 06:33:47 am »
I just looked arround and found this:

Quote
The Motion Decoder (MDEC)
   The Motion Decoder  (MDEC) is a special controller chip that takes a compressed  JPEG-like images and decompresses them into  24-bit bitmapped images for display by the GPU. The MDEC can only decompress a 16x16 pixel 24-bit image at at time,called "Macroblocks" These Macrobock are encoded block that uses the YUV (YCbCr) color scheme with  Discrete Cosine Transformation (DCT) and Run Length Encoding (RLE) applied The MDEC also performs 24 to 16 bit color conversion to prepare it for whatever color depth the GPU is in. Due to the extremely high speed that the decompression is done, the decompressed RGB bitmaps can be combined to from larger pictures and then ,if displayed in sequential order, to produce movies. The maximum speed is about 9,000 macroblocks per second, thereby making a movie that is 320x240 able to be played at about 30 frames per second. MDEC data can only be sent/received via DMA channels 0 and 1. DMA channel 0 is for uncompressed data going in and channel 1 is for retrieval of the uncompressed macroblocks. The MDEC gets controlled via the MDEC control register at location $1f80_1820. The current status of the MDEC can be checked using the MDEC status register at $1f80_1824. The following is a layout of the registers.

Is that the native decompression you mentioned?

My problem is that I'm not really know if i have already found the offset ^^".
And I've got a second problem. I opened the dumped vram file with tilemolester and looked at different 4bpp modes and other settings arround, but was not able to find the uncompressed font file...
Gemini
Guest
« Reply #3 on: April 11, 2007, 09:16:40 am »
As far as I can remember, BOF4 doesn't use any compression, not even for that font.
Flashware
Guest
« Reply #4 on: April 11, 2007, 09:31:01 am »
arg...

wonder why i haven't found it yet X_x...

anyway i keep my eyes open^^

and i keep on learning asm... when i see what's possible Oo
Odin
Guest
« Reply #5 on: April 11, 2007, 11:15:56 am »
Quote
As far as I can remember, BOF4 doesn't use any compression, not even for that font.

Correct, [PSX]BoF4 doesn't use any kind of compression for the text/font.

I think you've to use RAWUTILS writed by Vegetal_Gibber from spanish scene to find the font or you can see using Nana developed by Neil Corllet.
Tauwasser
Guest
« Reply #6 on: April 11, 2007, 01:56:30 pm »
Oh, so maybe that sw is just a dma thingy Smiley

Anyway. Somebody should make a program that is compliant to all of the standard bitplane architectures and has a good feidian file support (so you could see the whole file in what feidian would make out of it Smiley)

cYa,

Tauwasser
Flashware
Guest
« Reply #7 on: April 11, 2007, 02:17:40 pm »
Big thx to all of you!

Oh man... I just have to think 'bout: "A fool with a tool is still a fool" =D
Gemini
Guest
« Reply #8 on: April 11, 2007, 05:35:24 pm »
Quote from: Tauwasser on April 11, 2007, 01:56:30 pm
Oh, so maybe that sw is just a dma thingy Smiley
You mean this?
Code:
8016D2B4   sw     v1, $0000(v0)
No, it's just a simple store word command. It stores v1 as a 32 bit value in v0+$0000. Most DMA stuff on Psx is triggered by BIOS functions.
Tauwasser
Guest
« Reply #9 on: April 11, 2007, 06:21:41 pm »
Oh, I thought it was a software interrupt ^^"

cYa,

Tauwasser
magusneo
Guest
« Reply #10 on: April 11, 2007, 09:47:56 pm »
1.Locate the font data in the ram just before they are uploaded into the vram.

such as:
GPU Upload from $807ED110 , $F000 bytes
area X/Y(320, 0) W/H(128,240)

It's $807ED110.

2.Search the first some bytes of font data in iso or certain file with winhex if there is no compression.
Flashware
Guest
« Reply #11 on: April 12, 2007, 12:10:17 am »
Quote from: magusneo on April 11, 2007, 09:47:56 pm
1.Locate the font data in the ram just before they are uploaded into the vram.

such as:
GPU Upload from $807ED110 , $F000 bytes
area X/Y(320, 0) W/H(128,240)

It's $807ED110.

2.Search the first some bytes of font data in iso or certain file with winhex if there is no compression.


strange I alway found an upload $800 bytes, starting at $8004F000
and then at $8004F800 and so on...

but thanks anyway... I wonder at which address of the ISO I have to look now, and how I can find out in which data the font is stored..

@Odin: Thanks the tools are great, but can't really use RAWUTIL until it's spanish ._.
Gemini
Guest
« Reply #12 on: April 12, 2007, 01:04:54 am »
Quote from: Flashware on April 12, 2007, 12:10:17 am
@Odin: Thanks the tools are great, but can't really use RAWUTIL until it's spanish ._.
There is a much better alternative to rawutil: Tile Molester. It can easily manage almost every standard format used for Psx graphics.
Flashware
Guest
« Reply #13 on: April 12, 2007, 01:21:50 am »
wonder why i haven't found something yet ._."

arg this is simply... ^^

Ok Done I found it, thanks to all of you =D
« Last Edit: April 12, 2007, 01:30:04 am by Flashware »
Pages: [1]  


Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC