+  RHDN Forum Archive
|-+  Romhacking
| |-+  ROM Hacking Discussion
| | |-+  PSX's OT usage in debug purposes
Pages: [1]
Author Topic: PSX's OT usage in debug purposes  (Read 2 times)
Griever
Guest
« on: September 02, 2009, 05:30:56 am »
I'm searching for an opportunity to use ordering tables in hacking/translation cases via debug.
Just simple example: almost every PSX game has VWF and you're gonna edit width table anyhow. Right now I know only one way: search relative or anyhow somewhere near font graphics for sequence of bytes. That's like a blind method - no good.

Is that possible right now to find width table with actual debugging? Font is displayed on the screen by means of Ordering Table - every letter is rectangle primitive, which is displayed from frame buffer and has it's own height and width - that's where we can catch the beast.
But one issue: I've never used debugger for OT tracing: only frame buffer writes, ram read/write, sound stuff. No OT tools are available right now (?)
Um, yup, I've seen pSX or something has some dma stuff, but it is as buggy as hell - I get it crashed every moment and it's no good, really.
So, any ideas, or maybe someone did such stuff before?
mz
Guest
« Reply #1 on: September 03, 2009, 05:22:15 pm »
What exactly is an "Ordering Table"? (I'm very new to ROM hacking. Cheesy)

Quote from: Griever on September 02, 2009, 05:30:56 am
Is that possible right now to find width table with actual debugging?
What I usually do, is to set a "RAM read" breakpoint on the address of one of the letters of a word that is currently being displayed on screen. Then, you can find where it gets the width from, in one of the next few lines.

It will probably look something like this:
Code:
LBU     $v0, 0x22($v1)
ADDU    $t2, $t2, $v0
Then you only need to look what $v1 is, add 0x22 to that, and you get the RAM address of the width table...
« Last Edit: September 03, 2009, 05:30:54 pm by mz »
Griever
Guest
« Reply #2 on: September 04, 2009, 10:32:41 am »
Quote
What exactly is an "Ordering Table"?
The Newbie Package of REQUIRED Material
All data regarding drawing and drawing environment are sent as packets to the GPU. Each packet tells the GPU how and where to draw one primitive, or it sets one of the drawing environment parameters. The display environment is set up through single word commands using the control port of the GPU. Ordering Table - is actually the list of these packets.
ROMHacking.net FAQ: You ask, we answer!
ROMHacking.net Getting Started Section: Newbies Go HERE!
ROMHacking.net Documents Section!
How to ask questions the smart way.
On the Essence of ROM Hacking

Quote
Then, you can find where it gets the width from, in one of the next few lines.
Why is that? How is font's char width related to letter code reading procedure? I mean that's not necessary to do something with letter's graphics right after reading actual letter of the text - it can be absolutely different functions...
Also, what is that code supposed to mean? That's a usual reading from ram, why should v1 be width table pointer?
mz
Guest
« Reply #3 on: September 04, 2009, 12:35:32 pm »
Quote from: Griever on September 04, 2009, 10:32:41 am
Why is that? How is font's char width related to letter code reading procedure? I mean that's not necessary to do something with letter's graphics right after reading actual letter of the text - it can be absolutely different functions...
I suppose the game would only use the char width after reading a letter; I can't think of any other situation where the width table could be used.

Also, there's not enough space in the registers to hold whole blocks of text, so you can only process one char at time and immediately do the necessary routines with it.

Quote from: Griever on September 04, 2009, 10:32:41 am
Also, what is that code supposed to mean? That's a usual reading from ram, why should v1 be width table pointer?
It was only a quick example which loads a value and adds it to another register. After reading a letter, if you find a piece of code like that, it usually means that is getting the width and adding it to the current x position.


Here's a real example of Penny Racers:

Suppose this game has the letter "0x9F" in 0x80000022, and the game's width table starts at 0x801C0040, so this char's width is at 0x801C00DF (0x801C0040 + 0x9F).
Code:
; a3 was set earlier to 0x80000022
LBU     v1, 0000 (a3) ; load into v1 the letter in address a3 (0x9F)
; insert some instructions here to draw this letter in the current x position
; then:
LUI     at, 801C      ; load the value 0x801C0000 into at
ADDU    at, at, v1    ; at = 0x801C0000 + 0x9F (0x801C009F)
LBU     v0, 0040(at)  ; load char width of 0x9F into v0 (from 0x801C00DF)
ADDU    t0, t0, v0    ; *
ADDIU   a3, a3, 0001  ; advance a3 to point to the next letter
; repeat code from start for the next letter etc. etc.
*t0 would be the current x position, so we add the char width here to move the x position v0 pixels to the right. The next letter would be drawn at this new t0 position.
Griever
Guest
« Reply #4 on: September 05, 2009, 06:31:11 am »
Oh, now I see your point.
Quote
Also, there's not enough space in the registers to hold whole blocks of text
Register can be saved in RAM in no time.
Quote
I suppose the game would only use the char width after reading a letter;
Nah, check out Metal Gear Solid's char processing procedure:


 The letter is read in the very beginning of the procedure, and got drawn in the red zone (closer to bottom). So red zone - is another large procedure, which contains procedure of reading char width and it loads char code right inside third nested procedure from RAM, so the only solution I see is to trace out all RAM reads and writes of char value, which is close to impossible... I guess OT way cold be more straight and flexible.
Gemini
Guest
« Reply #5 on: September 05, 2009, 07:53:33 am »
I call it Konami Krack. Usually games don't go all the long way to just send one stupid character to the OT.
Griever
Guest
« Reply #6 on: September 07, 2009, 11:44:08 am »
OK - here we have BoF4 text processing (Namco, I guess):

Just save it and zoom in.
Still no trace of width table - all constant addresses is not a width table - pretty sure in it, just changed them in ram dumps and loaded back - also they do not look like width tables.
I.S.T.
Guest
« Reply #7 on: September 07, 2009, 11:45:13 am »
Capcom, not Namco.
Gemini
Guest
« Reply #8 on: September 07, 2009, 12:23:28 pm »
Are you sure 0x80174418-0x20 isn't a width table using nibble values (XY, X for centering, Y for the real width)? Because the code seems to use the values pulled from that range to adjust some sort of x coordinate.
Griever
Guest
« Reply #9 on: September 07, 2009, 01:46:03 pm »
Quote
Are you sure 0x80174418-0x20 isn't a width table using nibble values

It looked pretty suspicious, but first of all - all values are 08, and secondly I've poked this values in the debugger to 04 right before text is displayed and nothing changed...
Pages: [1]  


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