Support for 576p in OPL menu

[J013k]

Issue checklist

Note: these are not necessarily requirements

• [x] I have checked existing OPL issues for duplicates and found none @ http://psx-scene.com/forums/official-open-ps2-loader-forum/ & https://github.com/ifcaro/Open-PS2-Loader/issues

Open PS2 loader version

...OPL 1357...OPL 1377

Issue description - Describe the problem you are having

Is there any chance to also support 576p for consoles lower than SCPH-750XX in OPL menu?

Currently 576p works only for games in all consoles: https://www.psx-place.com/threads/graphics-synthesizer-mode-selector-gsm.19028/page-2#post-133183. Commits for that at github should be started on Aug 5, 2018: https://github.com/ifcaro/Open-PS2-Loader/commits/master?after=3cb4707de8e2622dffd022371d5df72aa808f66c+209.

Currently if I'll select (Display settings->Video mode) EDTV 704x576p @50Hz 24bit (HIRES), EDTV 640x512p @50Hz 24bit, I'll get BSOD e.g. on SCPH-50004, 70004. Since code for 576p exist and it supports "older" consoles why not also add it into OPL menu?

[rickgaiser]

BSOD should never happen and is a bug in my opinion.

A simple solution would be to force 576p back to 576i option when the console does not support it, as ps2sdk/graph does: https://github.com/ps2dev/ps2sdk/blob/master/ee/graph/src/graph_mode.c#L145

But I would prefer to add the 576p 'hack', similar to this (based on an example from @sp193 ): https://github.com/rickgaiser/gsKit/blob/fullhd/examples/modetest/1080p.h https://github.com/rickgaiser/gsKit/blob/fullhd/examples/modetest/1080p.c Note the example is for 1080p. however 1080p does not work correctly in this example. But perhaps with recent progress made by @frno7 we can add working 1080p support as well? https://github.com/frno7/linux/blob/ps2-master/arch/mips/boot/compressed/dbg.c#L624 (EDIT: line number updated)

Note that HIRES 3D rendering would not be possible with 1080p. But with 2x scaling, it would be possible to display 1080p, but render 3D at:

• 1920x540
• 970x1080

[TnA-Plastic]

@J013k: I am not even sure if I ever tested that. Shouldn't it work with down to SCPH-50k's as well currently (and after the suggested change with almost, if not every model)?

@rickgaiser: 970x1080? You mean 960x1080 do you not?

[J013k]

I do not fully understand you. My 1st post can be confusing, so I'll try to explain it better. Consoles from SCPH-750XX or higher supports 576p natively. I don't know if they have got additional code for it or something else, but If I set 576p in e.g. SMS, OPL menu my TV will display image. If I'll do the same thing (the same TV\cables) on SCHP-700XX or lower I'll have BSOD. In OPL theoretically after changing resolution confirmation warning should be displayed for 10 sec (e.g. do you accept current setting?). Unfortunately even after that period of time nothing will happen on "unsupported" consoles, I'll only get BSOD and I'll have to restart PS2.

Some time ago SP193 added something into built-in GSM code that can "activate" this resolution for all consoles. If this code can be used for launching game with GSM, why not also add it into OPL menu, to avoid "unpleasant situation".

[Tupakaveli]

576p is not supported on consoles with a ROM version less than 1.80.

[J013k]

I'm not sure if it was ROMVER 1.80, so I'll add quote:

The 576P (0x53) mode was added with ROM v1.80, for the PSX. The PSX seems to have the same GS revision as the SCPH-75000, even though it was about a year older. The v1.90 ROM for the SCPH-50000a and SCPH-50000b do not support this mode, as with the SCPH-70000 (v2.00).

https://www.psx-place.com/threads/graphics-synthesizer-mode-selector-gsm.19028/#post-132933.

[Tupakaveli]

Ah yes, I'm using 50002 with v1.90 and it is unsupported.

Also you're right, when the timer runs out on the confirm video mode screen it doesn't return to the previous resolution.

[frno7]

As far as I know, at least SCPH-30004, SCPH-30004 R, SCPH-37000 L, SCPH-39004, SCPH-50004, SCPH-70004, SCPH-75004 and SCPH-77004 hardware support all video mode resolutions given in:

https://github.com/frno7/linux/blob/c94ed72e624d28f05c2f1f034917fa432d259bc2/drivers/video/fbdev/ps2fb.c#L173-L256

With Linux for the PlayStation 2, which isn’t using ROM routines, these are

# cat /sys/class/graphics/fb0/modes | column
S:640x224p-60   S:720x480p-60   S:1920x1080p-50 U:1124x644p-60  V:800x600p-60
S:640x256p-50   S:720x576i-50   S:1920x1080p-60 U:1688x964i-50  V:800x600p-75
S:640x448i-60   S:720x576p-50   U:576x384i-60   U:1688x964i-60  V:1024x768p-60
S:640x512i-50   S:1280x720p-50  U:576x384p-60   U:1688x964p-50  V:1024x768p-75
S:720x240p-60   S:1280x720p-60  U:576x460i-50   U:1688x964p-60  V:1280x1024p-60
S:720x288p-50   S:1920x1080i-50 U:576x460p-50   V:640x480p-60   V:1280x1024p-75
S:720x480i-60   S:1920x1080i-60 U:1124x644p-50  V:640x480p-75

as the most common video modes. Many if not most other video modes can be obtained by supplying an appropriate standard frame buffer modeline. 1920×1080p etc. work with component video, all PS2 HDMI adapters that I have tested, as well as the open source scan converter (OSSC).

[TnA-Plastic]

@frno7: You can make your own Output-VModes, no problem...

It's just that some VModes or 'profiles' for them are included in the BOOT-ROM and instead of manually setting up a custom GS-Configuration, we can choose to set up the VMode, via "calling" the function with a 'profile' instead of manually setting up a VMode...

On those consoles where those are not available, we have to manually do the configuration...

Regarding your last paragraph... Well, you are confusing internal (rendered) and output-resolution and you don't need a frame-buffer for those shown frames, but you can also have/use a line-buffer or a split-frame-buffer, which is uploaded and rendered during frame-drawing. A complete FullHD-Frame in 16Bit would already be ~3.96MiB solely for the shown frame and no textures... The PS2's VRAM is only 4MiB tho'.

@J013k: I understood you right from the beginning... I thought some SCPH-50xxx up to those which you mentioned (up to SCPH-75xxx which definitely supports it), would support 576p as well via the normal "calling" of a profile, instead of manually setting up the VMode/GSConfig!

[frno7]

Regarding your last paragraph... Well, you are confusing internal (rendered) and output-resolution and you don't need a frame-buffer for those shown frames, but you can also have/use a line-buffer or a split-frame-buffer, which is uploaded and rendered during frame-drawing. A complete FullHD-Frame in 16Bit would already be ~3.96MiB solely for the shown frame and no textures... The PS2's VRAM is only 4MiB tho'.

The maximum practical full-frame resolution is 1920×1080p at 16 bits per pixel, that requires 4147200 bytes of local GS memory, leaving 47104 bytes for e.g. a tiled font stored as a texture. With 8×8 pixel glyphs and a minimum 4 bits indexed texture palette that is at most 1464 texture mapped characters for a text console. The two CRT hardware (split screen) circuits are used in Linux to do YWRAP acceleration (infinite vertical scrolling), making the console about as fast and efficient as it can get.

Using HSYNC interrupts, I guess 1920×1080p at 32 bits per pixel could be possible as well, unless the memory bandwidth is exceeded somehow. It would require 8294400 bytes for a full frame, which is almost twice the total amount available in the GS, but video resolutions can be displayed with far less by reusing memory.

[rickgaiser]

Using HSYNC interrupts, I guess 1920×1080p at 32 bits per pixel could be possible as well, unless the memory bandwidth is exceeded somehow. It would require 8294400 bytes for a full frame, which is almost twice the total amount available in the GS, but video resolutions can be displayed with far less by reusing memory.

That is actually what "HIRES" mode in gsKit does to render 3D at 1080i resolution. For 3D at 1080i you need at least 1 frontbuffer, 1 backbuffer and 1 depthbuffer. At that's at least 3x2MB, not even including textures.

The 1920x540 frame is devided into 3 parts of 1920x192, then using HSYNC interrupt:

• the part that was just displayed is re-used as the depth buffer
• the part that is currently being displayed is used as the front buffer
• the part that is going to be displayed next is used as the back buffer
• leaving a whopping 1.8MB free VRAM for textures Then using half pixel offsets in rendering, the 3D rendered image looks almost as good as 1080p (if de-interlaced properly)

Would be interesting to see if the ps2 can do 1080p 32/24bit... even if just for 2D.

[J013k]

Theoretically also these resolution might be handful for PAL uses. 1280x720p-50 1920x1080i-50 1920x1080p-50

No one menages to get it working\support, so it is for now only wishlist.

[sp193]

The PS2's video encoder has to be configured, rather than just setting the GS registers. Traditionally, PS2Linux would use ROMGSCRT to get video modes set up and its own code for configuring the video modes did not support the new video encoder on the SCPH-75000 and later. How are you compensating for this? Have you figured out how to configure the video encoders?

[frno7]

@sp193, I don’t recall that there is special handling for SCPH-75000 or later in Linux 5.x. The GS is currently initialised by uLaunchELF before the Linux kernel takes over.

In Linux 2.6 however, there is a GS revision check in

https://github.com/frno7/linux/blob/f3285c0c4bbfb4b6c97d0d0a261dab92148e1d35/arch/mips/ps2/gs.c#L601-L606

with differences between the video modes defined in syncdata0 and syncdata1. I have not investigated these differences in detail yet, though, as they appear to be minor.

[TnA-Plastic]

@frno7: That's exactly where I was hinting at! ;)

The output-resolution could also be 1920 x 1080 while the internal resolution is something else (even 640*480 with or without magnification)!

To have a native rendered resolution at 1080, the 'full-frames'/'frame-composition (1920 x 1080) are 'sliced' into 'frame-parts/slices'... For example 1920 x 360 times 3 and shifted to/rendered at the according position, is a frame-composition of fully rendered 1920 x 1080 (also shown on screen) even tho the frame-buffer only consists of one 'frame-slice' in size! Top-frame, mid-frame and bottom-frame (regarding their position on screen within the output-resolution/window) are rendered after another and then merged during uploading&rendering, to the 'full-frame'... A resulting frame shown on screen thus actually consists of 3 frames (in that case)!

You can even trim that down to more slices, resulting in even less VRAM used for the buffer/-s (down to 2 vertical lines if I remember correctly), but there is a giant drawback on slicing it down... How smaller the 'slice' is, so more often we have to re-upload a texture from EE-RAM to GS-VRAM... That means that while the VRAM-Usage for the frame-buffer becomes smaller, the amount of bandwidth (from EE to GS) needed, increases.

For example... You slice the full frame into 2 slices and have to upload textures twice as often (120 texture-reloads per texture in a 60Hz-VMode) or 3 slices (180 texture-reloads per texture in a 60Hz-VMode) and so on... Obviously these texture-reloads for one need time and second need A LOT more bandwidth, which means we need to find a good middle-spot for 'frame-slices/-slicing' (to spare VRAM) and 'amount of texture-transfers' (to spare bandwidth on the bus).

Another method would be possible as well, which would allow a 'line-buffer' (vertical line-wide frame-buffer) and no texture-reloads, but it would require rendering entirely on the EE (including it's Vector-Units). That's possible as well, but doesn't allow for things like the Overscan-feature...

Regarding 2D 1080i/p: I think that this might be possible at 24/32Bit with the current rendering-method as well. If we could spare some time/bandwidth on the bus, I rather vote for 24Bits because I think both would need the same amount of VRAM anyway. Didn't the GS setup a 24Bit-Mode just like a 32Bit-Mode (or similar, resulting in the same amount of VRAM used)?

Regarding Linux and its VModes: Didn't it manually set it up and was dependent on the RTE? I think it will not work properly on a 75k using the original RTE used in/for BlackRhino and Sony-Linux. I think it does work via Kernel-Loader (I vaguely remember @MegaMan [Edit: Oh dear, another guy with the same name on GitHub again...] writing something about it, possibly on the Kernel-Loader-Releasenotes on the website.)!

Well,... Those old Linux-distros also use a Kernel 2.2-Variation, while the others use a newer one like 2.6 (or even newer) and I am not sure, if this might have an influence as well.

[sp193]

Then whatever you are doing now, is possibly incomplete. Some video modes may work on some PS2 models, but could fail on others. It may also depend on the previous video mode used, since setting a video mode via the EE kernel would reconfigure the DVE. I think the SBIOS will configure the DVE for you, but it is only done for the "old" method of configuring the GS: https://github.com/frno7/linux/blob/f3285c0c4bbfb4b6c97d0d0a261dab92148e1d35/arch/mips/ps2/gs.c#L505

When we found that we could create video modes by manipulating the undocumented GS registers, we neglected the Digital Video Encoder (DVE) too. However, this resulted in the add-on 576P mode not working correctly on some PS2 models, due to a lack of configuration.

The GSM 1080P mode also had some strange effects for some people. Neither could I tell whether driving the pixel clock to allow 1080P mode will surely not break anything. After all, my second SCPH-10000 stopped working slightly after the experiments with 1080P were done in 2012 - but that console was already very old at that time and could be already having issues with its clock generator. Ever since it became clear to me that not configuring the DVE results in incomplete configuration, I tried to withdraw the implementation for the unofficial 1080P mode from GSM (at least the one within OPL). It doesn't work properly for everyone.

As for the DVE configuration code that I extended from Mega Man, it only supports CEX and DEX consoles. TOOL units have a different device, which requires much more initialization. Since very few people own one and it wasn't meant for gaming, I didn't copy the initialization logic from the EE kernel.

The GS chip was replaced at some point, hence the timings had to be changed. But that isn't what I am referring to. The 576P mode parameters I copied, do not fit the older GS, but still works as you wrote. The DVE settings were the same as 480P mode, so I could copy the DVE initialization code for 480P mode.

[TnA-Plastic]

I'd be interested in a 2560*1440 VMode (if possible... WQXGA-Support on the GS would be required tho'.), hahaaa! :)

I think it should possibly be restricted to VGA, because Component's standard only defines up to 1080i, even tho' some devices support other resolutions via that connection as well it is clearly non-standard, which MIGHT account for the problems a user (or some users?) was (/were) reporting.

[frno7]

@sp193, yes, Linux 5.x currently relies on uLaunchELF as a boot loader with some basic hardware initialisation. Until the hardware quirks are worked out, and if all else fails, Linux could use the same video mode as uLaunchELF to at least get started with something useful.

https://github.com/frno7/linux/issues/4 is about booting the Linux kernel directly off a memory card, and in that case perhaps such a boot loader would be simpler than uLaunchELF and the Linux kernel would need to do some more work.

Ever since it became clear to me that not configuring the DVE results in incomplete configuration, I tried to withdraw the implementation for the unofficial 1080P mode from GSM (at least the one within OPL). It doesn't work properly for everyone.

1080p works with all hardware models I have tried, including PS2 HDMI adapters, and for Linux I think people should decide on their own what video modes they want and can use with their hardware.

The output-resolution could also be 1920 x 1080 while the internal resolution is something else (even 640*480 with or without magnification)!

@TnA-Plastic, indeed, MAGV and MAGH can be used to great effect as well!

Regarding Linux and its VModes: Didn't it manually set it up and was dependent on the RTE? I think it will not work properly on a 75k using the original RTE used in/for BlackRhino and Sony-Linux. I think it does work via Kernel-Loader (I vaguely remember @megaman [Edit: Oh dear, another guy with the same name on GitHub again...] writing something about it, possibly on the Kernel-Loader-Releasenotes on the website.)!

Linux 5.x currently boots from uLaunchELF and no longer relies on the kernel loader used with Linux 2.6. Linux 5.x also discards the Sony BIOS and reclaims that memory, and so is intended to manage the hardware on its own.