+  RHDN Forum Archive
|-+  Romhacking
| |-+  ROM Hacking Discussion
| | |-+  Playstation VRAM
Pages: [1]
Author Topic: Playstation VRAM  (Read 453 times)
RedComet
Guest
« on: April 27, 2007, 03:15:13 pm »
Is there a way to accurately view the contents of VRAM? I've dumped the contents of VRAM with pSX and due to its pixel instead tile nature it has successfully thwarted all of my attempts to view it using conventional tile editors. Perhaps I'm overlooking something?

I know that a pixel is either 2 or 3 bytes which when combined determine the color of the pixel, and that VRAM is an 1024x512 bitmap. Then the display is a rectangle within this bitmap. Assuming that that's all correct, I'm thinking I would simply need a bitmap editor (for want of a better term) analogous to tile editors as they relate to tile based systems. Problem is all of the tile editors assume you're working with X bytes organized in to WxH tiles, which doesn't help me at all. I'm looking for an editor that organizes X bytes in to 1 pixel and at N starts over at the next row of pixels.

Does such a thing exist? Or am I misunderstanding something? Any help would be greatly appreciated. Smiley
Kajitani-Eizan
Guest
« Reply #1 on: April 27, 2007, 03:38:11 pm »
tried tile molester? i'm pretty sure it has bitmapped modes.
DaMarsMan
Guest
« Reply #2 on: April 27, 2007, 04:12:22 pm »
I think there was a plugin created by my friend rveach to dump all the data into bmps of different bpp.
RedComet
Guest
« Reply #3 on: April 27, 2007, 04:14:10 pm »
That helps a little. Looks like Tile Molester allows user-define codecs. I'll have to check that out. At the moment I managed to *finally* figure out how to view VRAM with pSX, which is doing everything I need. At least until I break something. *ahem*

Thanks for the help. Smiley

DMan: Any idea if there's a copy of this plugin floating around online anywhere or did it go up in smoke?
Gemini
Guest
« Reply #4 on: April 27, 2007, 04:26:10 pm »
Tile Molester is not the best option for PSX VRAM. There is a program made by agemo you can find here. 1-9 buttons are used for switching between several bitplane modes, A-S-D-W are used for chaning x-y texture coordinates and directional arrows are for moving the CLUT area when working in non-greyscale 4/8 bpp. Give it a binary VRAM dump or an uncompressed ePSXe savestate and you are ready to go.
RedComet
Guest
« Reply #5 on: April 27, 2007, 04:59:52 pm »
Thanks for the program, Gemini. Looks..interesting.

I got a question that you can probably answer for me. Is it possible for a font to be stored as a texture in vram? And if so is that a common method of storing a font?
Gemini
Guest
« Reply #6 on: April 27, 2007, 05:18:07 pm »
It depends on the game. Most American and European games (and a few japanese RPGs, too) tend to store the whole font as a texture, while most Japanese games render in vram only what's necessary for a dialogue. The general rule is: if you have A TON of characters, store them as 1BPP somewhere in ram and then convert them when necessary, otherwise just stick the whole thing in vram and leave it there.
RedComet
Guest
« Reply #7 on: April 27, 2007, 05:45:17 pm »
I'm pretty certain that's what's going on here. There's some 1500 kanji or so, so the font's stored in ram and then loaded as needed. Then it makes it's way to the frame buffer where it's used as a textured sprite.

The only thing left to figure out as far as display goes is when the font gets written to the frame buffer. I've found (thanks to pSX - I love that emulator Grin) where the command packets are stored (still need to track down the routines that handle those, but that shouldn't be too hard) that are responsible for making the magic happen, at least as far as displaying the entire string goes.

Another question, how are you assembling your code? Please tell me there's an assembler available and that you're not assembling your code by hand, because that would be INSANE.

There is one other thing that's stumped me. I know that the PSX.EXE contains the initial PC and stack pointer (got that bit of info from this). What I DON'T know is how the PSX.EXE makes its way into RAM. Thus far I've just assumed that the BIOS searches for the SYSTEM file, retrieves the location of the EXE and then loads it to a fixed position in RAM, and from there begins execution at the specified address. Is that correct?

Also, thanks a lot for taking the time to answer my questions. Smiley
Gemini
Guest
« Reply #8 on: April 27, 2007, 05:58:37 pm »
Quote from: RedComet on April 27, 2007, 05:45:17 pm
Another question, how are you assembling your code? Please tell me there's an assembler available and that you're not assembling your code by hand, because that would be INSANE.
I'm using spasm. It's not really... "comfortable", but it's the only 100% working assembler out there.

Quote
What I DON'T know is how the PSX.EXE makes its way into RAM. Thus far I've just assumed that the BIOS searches for the SYSTEM file, retrieves the location of the EXE and then loads it to a fixed position in RAM, and from there begins execution at the specified address. Is that correct?
The console searches for a "SYSTEM.CNF" (boot information, something like autoexe.bat) or "PSX.EXE" (doesn't need SYSTEM.CNF, Ps2 doesn't recognize this) file, then loads a sector from the executable, which cointains a structure used for defining stack pointer and other stuff. When everything is settled, it loads the remaining part of the main exe and transfers it to a variable location in RAM, depending on what is specified by its header.

Exe structure:
Code:
struct EXEC {
      unsigned long pc0; Execution start address
      unsigned long gp0; gp register initial value
      unsigned long t_addr; Starting address of initialized text section
      unsigned long t_size; Size of text section
      unsigned long d_addr; Starting address of initialized data section
      unsigned long d_size; Size of initialized data section
      unsigned long b_addr; Uninitialized data section start address
      unsigned long b_size; Uninitialized data section size
      unsigned long s_addr; Stack start address (specified by the user)
      unsigned long s_size; Stack size (specified by the user)
      unsigned long sp; Register shunt variable
      unsigned long fp; Register shunt variable
      unsigned long gp; Register shunt variable
      unsigned long ret; Register shunt variable
      unsigned long base; Register shunt variable
};
Pages: [1]  


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