forums.ps2dev.org

I've written a small tool that can force some games to run at 480p. I'm interested to get any feedback from you guys experienced with the platform.

The tool patches parameters to sceGsResetGraph() and can adjust the DY value in tGS_DISPLAY2 (some games pass a smaller value when in 480p, causing the screen to cut off at the top). This latter part is most of the work. :)

One outstanding problem is that some games run at an unnaturally high frame rate after being forced to 480p. Any thoughts about that?

Tool page: ps2force480p

...maybe VSync interrupt handling also has to be patched somehow (depending on how a particular game uses VSync synchronization)...

EEUG wrote:...maybe VSync interrupt handling also has to be patched somehow (depending on how a particular game uses VSync synchronization)...

That was my immediate thought too. I'm not very familiar with this, but I speculated that the game was getting vsync interrupts for every half-frame in interlaced mode, and was coded to only update on odd/even ones based on some flag. I further speculate that this flag is true for every interrupt in progressive mode...

I see that tGS_CSR has bits VSINT (VSync interrupt), NFIELD (NFIELD output) and FIELD (??), so I'll try to check these values and see if their behavior changes by mode.

EDIT: Seems like FIELD flips between 0/1, which makes sense. Traced in an emulator, it flips even when the display is at 480p but I think this is imperfect emulation.

I found code in the game that registers an INTC_VBLANK_S handler that returns -1 when CSR FIELD is 1 (preventing dispatch to other handlers). If I patch this check out, the game runs in turbo mode even at regular 480i -- from this I infer validation of the theory above.

I guess I need to think of a clean way to patch in a toggling CSR FIELD bit when at 480p.

(I'm still just guessing though, so any experienced developers please speak up to confirm or deny.)

I've done something similar in the past to force a specific video mode and also handled the screen position.

Rather than patching the video code directly I set a hardware breakpoint at the GS register(s) to detect any write attempts. On a breakpoint hit, I simply modified the original values that were written to the registers to fit my needs.

misfire wrote:Rather than patching the video code directly I set a hardware breakpoint at the GS register(s) to detect any write attempts. On a breakpoint hit, I simply modified the original values that were written to the registers to fit my needs.

That's an interesting idea, I'm surprised hw breakpoints work on those registers. You did this manually, or inserted the breakpoint programmatically (i.e., injected to existing code)?

That approach sounds potentially cleaner than patching, but I can't find information on setting up hw breakpoints with the r5900. This document discusses a Debug Data Break on Store (DDBS) exception but not really how to set it up.

I think the CSR register is read-only though, so this probably won't help with the non-flipping FIELD bit.

I did it manually using a loader that sets up everything before starting a game.

Take a look at section 13 of the following document:
http://lukasz.dk/files/tx79architecture.pdf

(The TX79 is very similar to the EE.)