Starting point for creating 480p patches?

[Shenmue_Trilogy]

I am looking into creating PS2 480p patches compatible with ps2 hardware (not the same as non interlaced) Is there any tutorial or guide? I am also looking into removing post processing filters. A starting point would be helpful thanks.

[Agrippa]

What do you mean by 480p patches compatible with PS2 hardware? Regarding the filters, it is mostly a trial and error. If you have a luck, then some traces are left by developer in the ELF. If the executable has got full symbols left inside, then you hit the jackpot. Without any helpful hints, you have to disable the functions one by one basically, until you find anything interesting. Then you have to analyse the code. Generally, it is time-consuming, boring and often frustrating task.

[Shenmue_Trilogy]

Thanks. Simple 480p patches for 480i ps2 games like RR5. Forget about the ps2 hardware part

[Agrippa]

Ridge Racer V is a field rendered game. There is a patch for it in the thread. "No interlacing" patches are meant mostly for PCSX2 to disable interlacing and uprender all the way up. I see no benefit in using them on the original hardware, because the resolution is halved vertically in fact.

[Shenmue_Trilogy]

Ok let me be more precise:

1. I would like to create 480p patches for PS2 games to run them on PS2 hardware.
2. Interlaced patches with field rendering games look bad on PS2 hardware
3. I need some how a starting point

Thanks

[Agrippa]

I have explained why they look bad (in the GSdx SW mode too). Interlacing gives an illusion of higher resolution by alternating different (even and odd) fields every 1/60 or 1/50 second. If you disable the interlacing you will get only one field all the time, so the resolution will be halved effectively.

To look for the codes, you have to disable the deinterlacing in the GSdx settings, set a breakpoint on the GS registers:
1. CSR 0x12001000 (control status register - read and write).
2. DISPFB1/DISPFB2 0x12000070/0x12000090 (display circuit buffer - write only).
3. DISPLAY1/DISPLAY2 0x12000080/0x120000A0 (output frame settings, e.g. height or width - write only).
4. PMODE 0x12000000 (display circuit settings for PCRTC - write only).

Majority of the display output related codes will be around the read or write opcodes to these privileged registers.

[Shenmue_Trilogy]

I fully understand why non interlaced look bad on PS2..but non interlaced (240p) and 480p codes are two different things:

https://youtu.be/plVNaQAdiOY?t=22

Thanks for the hints. Are these for non interlaced or 480p codes?

[Agrippa]

Both have got interlacing disabled, but the second one has got a back buffer enabled. But not every field rendered game has got a full height back buffer to enable. I am afraid the Ridge Racer V, as one of the earliest games, has got a 240p back buffer instead. And some games could render the HUD/post-processing effects to the downsampled front buffer, instead to the back buffer.

These registers are related to the display output of the GS itself. Buffer addresses could be near the write opcodes of the DISPFB1/2 registers. There is no general rule. Best way is to analyse existing patches, especially if the game has got a debug symbols left inside.

[Agrippa]

Ok, here we go with an example how to spot the buffers. Let's start with the Colin McRae Rally 3 PAL (SLES-51117). For deep code analysis, there is a demo version with debug symbols left on the OPS2M Demo Disc 27. But we do not need it at all in this case.

The game does use a full-height back buffer and downsamples it to the two half-height front buffers. Let's set a breakpoint at the 0x12000090 (DISPFB2) register. There is a opcode at 0x246C0C writing a 0x9000 value there. It is a frame buffer address divided by 2048. Continue the execution of the code. Few seconds later we have got an another store opcode at 0x247A64, writing a 0x9080 value in the register. Looks like it is executed after every vsync. The code for calculating that value looks similar to the earlier one we found after starting the game. Let's try to nop that opcode (to stop updating the register) and write manually the earlier 0x9000 value. Right click on the DISPFB2 register, click "Change lower 64 bit" and substitute the 9080 for 9000. Bingo! It seems the image has been "zoomed in". Seems we find out the full height back buffer.

Now look at the SMODE2 register. Its value is 3. But we have to convert that hex value to the binary one. It is a 11. These bits are settings for the PCRTC video output. The right bit (INT) does set the interlace mode (1 on, 0 off). The left bit (FFMD) is checked only if the right bit has been set to 1 - it sets the PCRTC to read either the whole frame or the field only. Let's change the left bit to zero, so the register value should look like that in binary - 01, and 0x1 in hex -> right click on the SMODE2 -> "Change lower 64 bit" and we have got the full height back buffer output. We can activate the DTV 480p mode, but since the frame buffer is 511x511 there will be black bars on the TV output.

How to apply the changes? We have to nop the code writing 0x9080 value to the DISPFB2 register and patch the code writing the SMODE2 settings. The first one we have already patched. Set a breakpoint at 0x12000020 and restart the game. 0x246B9C is writing the value 3 there. We have to patch the a0 register to have a 1. In order to do it, patch the 0x246B90 li a0,0x3 to li a0,0x1. The pnach file should look like that:

patch=1,EE,00246B90,word,24040001
patch=1,EE,00247A64,word,00000000

There are still some drawbacks. It seems the speedhacks (cycle rate and cycle skipping) impact the rendering, causing flickering of models or missing weather effects.
EDIT: This bug is related to the VSync handling function. Fixable by patching the code.

As you can see, the developer helped us to locate the back buffer address quickly. Some day I may write how to find the Snowblind Engine buffer before the supersampling (1280x448 resolution).

[hellbringer616]

I wonder... is it possible to find the vertical rendering resolution within the games and patch it to be 2x that value? That would solve the issue with the resolution being halved on real hardware