News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Valendian

Pages: [1] 2
Those are good findings. Nice work. This Tracker is an awesome application. I starred you on github. I'll have to keep an eye on this.

I'd be happy to wiki-fy the info for you. But I would prefer if you had your own login.

Newcomer's Board / Re: How to Learn how to use a PSX debugger?
« on: August 23, 2019, 03:34:35 pm »
There's a good tutorial here for the pSX debugger

Totally agree with what Fast6191 said, Just search the savestate for the data you wanna work with and then corrupt the data in memory. You can learn a lot by seeing how the game breaks by changing values.

Its great to see someone using these tools. You are gonna love making cutscenes. The only real limitation is that you have to use the animations that are already available in the game.

PRG (Program) files are executable programs. They mostly contain software but also contain data. These files can be converted to a human readable form using a MIPS disassembler. You wont get much benefit from reading that unless you have knowledge of programming and a lot of patience. The original developer has complete freedom in how data and software are arranged. Generally the disassembler makes no attempt to separate data from the software, so a human must decide which is which.

I'm looking at the font in video memory right now. I'm trying to trace it back to where it came from on the disc. I can lift out the font for you.

June 07, 2019, 04:56:17 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
The font is stored in BATTLE\SYSTEM.DAT at offset 0x1E0F0. The image is 4bit 256x96 pixels and is 0x3000 (12288) bytes in size. Each character is 12x12 pixels and they are arranged in a 21x8 grid.

There are many fonts in this file. This font appears to be a portion of a larger image containing other fonts. There is another 12x12 font immediately before this dialog font and it is also 12x12. And there is a tiny 8x8 font running vertically along one edge of the entire image, which makes use of the fact that 21 characters leaves 4 bytes (8 pixels).

The entire image is blitted to video memory in a single copy operation. The full image begins at offset 0x1ABF0 but it does not appear to have a file header. I have no idea how tall it is, only that it is at least 256x192 and not larger than 256x256. I have not found the CLUT (Color Look Up Table), so the font does not have correct colors. There appear to be many CLUT's each containing 16 colours (4-bit) but I have not found the right one.

Newcomer's Board / Re: How to get Vagrant Story's speech bubble font?
« on: June 05, 2019, 02:55:54 am »
BATTLE.PRG has an embedded font. It most likely is the one you want. I dont have the notes to hand right now but I will have a look and get you the offsets.

Notes say this
Code: [Select]
233eC graphics (?) $800 bytes, 32*32, font

These commands are for a cross compiler. You need to get you development environment set up first.

If you are on Windows you first need to get a Linux machine setup. Best to get virtalbox and install Ubuntu

Once Ubuntu is set up do the following

Code: [Select]
sudo apt update
sudo apt install build-essential
sudo apt install make
sudo apt-get install gcc-arm-linux-gnueabi
sudo apt-get install arm-gcc-none-eabi
Once those are installed you can build for ARM. But you will need to study the reference manual to do anything of interest.

This is what make prints when everything has already been built?

What's your makefile look like? I'm not a make guru, but I know the basics. I can take a look for you.

Programming / Re: How do I skip an operation, or a section of code?
« on: April 10, 2019, 03:38:11 am »
That's it alright R6 stores a count down, but it likely refers to frames not seconds. Leave it with me I might be able to wait for T to go negative (say -0x0120 or so)

April 13, 2019, 03:47:36 am - (Auto Merged - Double Posts are not allowed before 7 days.)
Okay got it, you can play around with the value 0x0180, this timer counts up over time

Code: [Select]
8010397C: 8e07989c lw r7,-0x6764(r16)
80103980: 00000000 nop
80103984: 28e20180 slti r2,r7,0x0180
80103988: 104000ef beq r2,r0,0x80103d48
8010398C: 3c028006 lui r2,0x8006

Programming / Re: How do I skip an operation, or a section of code?
« on: April 09, 2019, 03:54:18 am »
You're welcome.

One last thing: about that counter, is it possible to set other conditions like "when T > 3s, proceed"? I was just thinking it might feel better with a small pause there, before the loot phase comes in.

Only one way to find out. Looking at the code though you probably just wanna compare to a T value smaller than 0x0030 (say 0x0006). You can also use beq vs bne
Code: [Select]
beq r2,r0,xxx # jump if T >= x
bne r2,r0,xxx # jump if T < x

Programming / Re: How do I skip an operation, or a section of code?
« on: April 08, 2019, 02:33:40 pm »
Excellent work, this is extremely elite stuff your doing. And now for the cherry on top, here's the audio fix mixed in with your changes above. Looks like 0x00045988 is the play sound effect function. Most of them we wanna keep but need to get rid of two of them (start up sample and a looping sample)

Code: [Select]
801038F8: 0C041503 jal 0x0010540c        (change to 00000000 nop)
80103968: 0C011662 jal 0x00045988        (change to 00000000 nop) *** NEW ***
80103974: 0C011662 jal 0x00045988        (change to 00000000 nop) *** NEW ***
80103988: 1040000D beq r2,r0,0x801039c0  (change to 104000EF beq r2,r0,0x80103d48)
801039B0: 0C041935 jal 0x001064d4        (change to 00000000 nop)
80103A6C: 0C041935 jal 0x001064d4        (change to 00000000 nop)
80103B00: 0C041935 jal 0x001064d4        (change to 00000000 nop)
80103C64: 0C04182A jal 0x001060a8        (change to 00000000 nop)

Not bad work at all, very polished

Programming / Re: How do I skip an operation, or a section of code?
« on: April 07, 2019, 06:56:56 am »
Don't worry if it doesn't make sense, I work beside professional programmers who can't understand assembly (honest).

That break point is a leftover from previous attempt and is not important.

Basically when you step through the GPU frames, each drawing action is captured in details shown on the top right of the GPU window. For each drawing command the GPU window will show you the following
Code: [Select]
Time that the drawing command was issued
Address of the drawing command data
Size of the drawing command data
PC (Program Counter) or the code that issued the drawing command
We care about the PC because it brings us to the exact code that issued the drawing command. That's where we place a break point. But we don't really care about this code (it just draws the image) what we really care about is where the code came from (thats where the higher level "boss killed" function is found). When the debugger breaks we can view the call stack. This will let us find the "boss killed" function. In this case the code we really care about is in the region 8010384C...80103D84 (from MENUF.PRG).

This function contains calls to drawing functions, they will look like this:
Code: [Select]
80103910: 0C04182A jal 0x001060a8        # Draw the Roulette

You can toggle those drawing functions off by replacing with zeros
Code: [Select]
80103910: 00000000 nop                   # Don't draw the Roulette

That's kind of all you need to know. The hack would go something like this.

First get rid of the visuals
Code: [Select]
80103910: 0C04182A jal 0x001060a8        # Draw the Roulette
80103914: 24C6FEF0 addiu r6,r6,0xfef0
# change to ...
80103910: 00000000 nop                   # Don't draw the Roulette
80103914: 24C6FEF0 addiu r6,r6,0xfef0    #

# and also
80103A68: 8C47989C lw r7,-0x6764(r2)
80103A6C: 0C041935 jal 0x001064d4        # Draws for "PRESS BUTTON"
80103A70: 24060030 addiu r6,r0,0x0030
# change to ...
80103A68: 8C47989C lw r7,-0x6764(r2)
80103A6C: 00000000 nop                   # Don't draw "PRESS BUTTON"
80103A70: 24060030 addiu r6,r0,0x0030

There's also a count down timer that needs to go too
Code: [Select]
80103984: 2CC20030 sltiu r2,r6,0x0030    # This may be a count down timer
80103988: 1040000D beq r2,r0,0x801039c0  # When T<30 check for circle button
# change to ...
80103984: 2CC20030 sltiu r2,r6,0x0030    # This may be a count down timer
80103988: 104000EF beq r2,r0,0x80103d48  # When T<30 we are done

Now there is still a visual for "PRESS BUTTON" (entering from stage right), I have no time but you may be able to track it down by removing the jal functions or by adjusting a different count down timer (sltui r2, ...)

Programming / Re: How do I skip an operation, or a section of code?
« on: April 06, 2019, 04:23:40 pm »
The GPU debug window is absolutely one of the best tools pSX has to offer (even if it is extremely buggy). It let's you find things in record time. Here is a walk-through of how to make the most out of it.

1. Fire up Vagrant Story in pSX

2. Get a roulette wheel on screen

3. Open a debug window

4. Open a GPU window

5. Menu->GPU->Capture

6. Step through the drawing process until it starts drawing the Roulette

7. This image is interesting, take note of the Program Counter (PC)

8. Place a break point

9. Now open the call stack and inspect

10. This one looks promising

11. Get rid of that conditional branch and test (debug -> run)

12. Okay found it, now let's open a Hex Editor and search for that instruction sequence

13. Apply the patch and save

Now that you know the basic process you can do similar things in future. You don't really need to understand everything that you see. Think of the branches as a sort of flow chart diagram, and blocks of code are only stitched together by the branches.

Programming / Re: Hacking the Linux Kernel?
« on: September 24, 2018, 06:39:49 pm »
What's wrong with pure C? No other language could replace it. You would have to outpace a planet full of engineers all churning out C. Think you can do better? Head on over to osdev and give it a shot. I did

Newcomer's Board / Re: I need help finding a ROM hacking tool...
« on: August 21, 2018, 03:06:35 am »
Sorry if I came off as rude. I don't doubt your ability or appetite. But there are no tools for what you want to do and thats a big blocker. Before investing the time in that, it may be worthwhile learning on a game that already has this support. It will pay off in the long run

Newcomer's Board / Re: I need help finding a ROM hacking tool...
« on: August 20, 2018, 05:02:47 pm »
You gotta start somewhere. But your first game the best advice is:

Start with a simple 8bit game
Start with a game that has all the tools you need

If there are no tools then you need to make them, or you will need to apply generic tools and some simple scripts.

Programming / Re: How to use syscall/ disc read in psx assembly?
« on: August 10, 2018, 04:10:38 pm »
You may have better luck tracking the data tables that store the LBA of the file data. That way your files will be treated just like the normal files. You can find these tables by placing breakpoints on CDROM DMA, then back trace the stack to find the original call point.

If this is not possible then you need to read the manual. This documentation is a great place to start:

A-Functions (Call 00A0h with function number in R9 Register)

A(A5h) - CdReadSector(count,sector,buffer)
Reads <count> sectors, starting at <sector>, and writes data to <buffer>. The read is done in mode=80h (double speed, 800h-bytes per sector). The function waits until all sectors are transferred, and does then return the number of sectors (ie. count), or -1 in case of error.

A(A6h) - CdGetStatus()
Retrieves the cdrom status via CdAsyncGetStatus(dst) (see there for details; especially for cautions on door-open flag). The function waits until the event indicates completion, and does then return the status byte (or -1 in case of error).

ROM Hacking Discussion / Re: [PSX] How to find a graphic in memory?
« on: July 16, 2018, 02:22:33 pm »
Texture and sprite data must be DMA transferred to VRAM. Polygons must be drawn. The pSX emulator has a debug menu which allows you to debug gpu commands. You can capture a number of frames and it will allow you to step through the rendering of each frame one polygon at a time. For each polygon you can see which function issued the draw command.

Yeah its always going to be tedious when you work so close to the metal. But every small step is progress and all adds up over time.

These values you're looking for, do you know roughly where the data lives? If you have some idea then corrupting that region of data will help narrow it down. This is much faster than walking through code.

Or do you know the function in which it should be accessed? Only thing to do here is set a break point at the function entry point, when that triggers the debugger will break. Take this opportunity to make a save state so you can rewind the clock. Nop out instructions and step through over and over again, that's all you can really do here.

Static analysis (reading the code) is difficult, it is better to use a debugger. The debugger will allow you to watch the code execute in slow motion so you can observe how the data flows through the registers. A debugger does this by allowing you to step through the code one instruction at a time and will pause until you manually step forward. Break points can save time. If you place a read/write break point on data, then the debugger will run like a normal emulator but will stop when the game reads or writes that data. You can also place execute break points on instructions.

ROM Hacking Discussion / Re: Help With ASM!
« on: May 01, 2018, 09:36:04 am »
Im not sure i fully understand the problem. But i can clarify at least one area of confusion. You are changing bytes and this effects the disassembly. There are two possible causes
1) the bytes are program instructions and by changing those bytes you are corrupting the program.
2) the bytes are data and just so happen to map to well formed instructions. This is possible and requires you to use reasoning to determine it is data.

Are there invalid instructions mixed in to this area of the program? If so then most likely it is data and the dissasembly has no meaningful information.
Otherwise the changes to the disassembly are purely because you changed the bytes. In this case you can assume that those bytes are part of the program and the data is elsewhere

Pages: [1] 2