psp slim outputting 1080p

[edepot]

Is it possible?

1920x1080x4(rgba) = 8MB

Just take 8MB from the 32MB extra memory of the slim.

Manually take over the outputing to the component lines in assembly
if possible.

Or trick the processor (if it uses one) by filling the video ram from the
8MB of memory and remove the "end of the horizontal" signal before
it gets output to the TV, and put it back in at the end of the 1920 line.
If it is not fast enough you can do it interlaced. Since the PSP slim can manage 720x480 progressive at a minimum, you know it can at least manage 720x960 interlaced.

Or better yet, fill up the 1920x1080p in blocks. Should not take more than 4 passes to fill up the 1920x1080 (480x4=1920 and 272x4=1088). Just time it right and you get about 15fps with 4 flickers per frame.

As for fonts, and text display, is there a library that does this?
I think the smallest fixed sized font that looks normal is 6x8 pixels.
The 6 pixels are needed horizontally for m and w character. The 8
vertical is needed for dropdowns like gjqy. Maybe someone can make
semi-fixed font system with 4x8 pixels (using two font cells for w and m).
Or better yet a proportional font system with 2 to 6 horizontal pixels (i for thinnest and m and w for widest). I think this is needed because of the many people who are currently interested in making the touchscreen attachment a reality for the psp fat and slim. You can take power from the ports at the headphone jack or from the usb power jack. Getting it to output signals to the ubs is probably challenging (emulate a gps mode to send the serial information?). Maybe doing it via the new slim headphone
port is easier with the extra 6 pins there must be better serial support
(higher speed).

So if 6x8 pixel font is possible then you get 80x34 character display which is better than the standard 80x25 display for old displays. If you use
just one line of the display at the bottom you can fill it with all 26
alphabet plus capitals and 10 digits and you still have used only 62
characters of that line. Leaving 18 characters for punctuations and
entering other character modes for international text entry. Using just
8 pixels on the bottom of the PSP for touchscreen text entry would be
great. But if it is too small to touch then maybe a standard keyboard
layout of 5-6 lines, which would reach near the top of the analog nub
on the psp, and would not take up the whole length of the screen,
just a small little box on the right or left bottom corner. Maybe the
pspsdk can incorporate this, or some homebrew coder up to the
challenge? It is not too difficult, given all the technical info needed
for implementation has been given above.

[Jim]

barking

[gambiting]

PSP TV tuner is made for 640x480 output MAX and it WON'T output any higher resolution.And if you connect it to 1080p TV it's upscaled to fit the resolution,but by TV itself,not by psp.

[Mihawk]

Or better yet, fill up the 1920x1080p in blocks. Should not take more than 4 passes to fill up the 1920x1080 (480x4=1920 and 272x4=1088). Just time it right and you get about 15fps with 4 flickers per frame.

Can you explain that once more in detail? My math must be a little rusty ;P

(maybe explain in amount of pixels not width and height so I can better understand)

[edepot]

Actually, the psp slim can output dvd quality display at 720x480 progressive. (That is the output for umd video and xmb by the way). Even the psp games output at this resolution (but only 480x272 is the game screen with a surrounding static filler border)

As for the math, I was waiting for someone to catch it, but yeah it is
supposed to be 16x not 4x (given you need 16 psp displays to fit
into 1920x1080). At 3.75 fps. But I was also waiting for someone to come in and point out the fact that because 720x480 is supported, you actually can use this resolution to fill up the 1920x1080p, so it is actually 6x (6 720x480 screens fit into 1920x1080 pixels), so you only see 6 flickers per frame and it comes out to be 10fps (frames per second). And if you use interlace mode (720x960) it is EXACTLY 3x at 20fps (frames per second).

20 frames per second is approaching 24fps of dvd movies, so this is
not bad. This is assuming the video chip or cpu chip cannot catch up with
the extra bandwidth. If the chip can handle it, then you don't even have
to worry about it, just do a quick hardware blit of the corresponding
screen data from the 8MB and you are all set, no flickers. Of course this is assuming you can trick the chip (maybe it even supports the mode natively?) or do it manually by coding a special prx and use assembly. Hope everything is not hardwired and is programmable. I believe the
psp slim chip related to tv ouput is the Sharp LR388A1.
It not then it is probably for the 1-seg over the air digital tv display
feature in japan (pretty small at 320x240 resolution though).

But if in the end 1080p cannot be made to work it is still feasible to squeeze everything into 720x480. In this case when the PSP is
drawing the black borders, you can actually force it to draw stuff from
memory. Then you can program apps or games using the full 720x480
display. But if it can do 720x480p then it might be possible to do
something like that game Sonic 2 for Genesis (two player split screen
mode) and use interlace to get 720x960i resolution. Of course if it is hardwired and not changeable then the small fonts will come in handy for 480x272 native display.

[J.F.]

The kind of frame accumulation you describe isn't new, the Amiga 2024 monitor used that sort of frame accumulation to do very high-res screen by combining several low-res screens. I did support for that monitor in our Mac emulator. However, it requires both hardware support in the monitor, and software support in the OS. All Sony did was route the video lines of the current VPU to a video encoder chip. There is nothing there that will support your flights of fancy.

[edepot]

I think the A2040 monitor is only 2 bits greyscale per pixel,
and the software feeds 4 screens of these low bandwidth screens at
one time. This might not work for psp color displays.

Well, for all its worth, if everything comes down to being hardwired, then
there is a possibility of putting the psp slim in umd video mode (with
the 720x480p display), and instead of giving video data, give it
game frame buffers. Then you get to program apps and games in 720x480p
(might have to skip a few frames if your code doesn't keep up).

Can the 3d graphics engine can render 720x480 screens? If not you
can always split the screen into 4 blocks and feed each to the 3d
accellerator and merge the final screen for the output.

But I doubt that is the end of the line. The video chip must support more
modes, and you just need to enable it via some undocumented flags.
I think the 2MB embedded ram might limit the resolution to something just greater than 800x600 (4bytes per pixel). This is assuming the slim still
has that limited 2MB video ram (from combined 4MB shared with the main cpu). Could they have added more embedded ram this time around?
Can the 2MB for the other processor be used for the video processing?

In any case at least the 720x480p for homebrew games and apps is
finally a reality. All you need are some modified prx and homebrew
programs to take advantage of it. I think using remotejoy you can even up it to 1020x768 but requiring a separate program running on the pc side will hinder the adoption rate. (not to mention the difficulty compiling and setting it up).

[Jim]

pass the crack pipe.

[J.F.]

Look, the PSP uses a plain VPU that generates one display from the embedded DRAM. It doesn't handle the framebuffer (or part of it) in system memory. You cannot devote 8M to a framebuffer as there is only 2M of EDRAM for the VPU. This in turn hooks to a plain NTSC/PAL video encoder chip that generates a plain NTSC/PAL component/s-video/composite display. None of your ideas have any merit on the slim as it exists.

While it MIGHT be possible to get the VPU to generate a 1920x1080 display, it would be like doing the same on the PS2 - the TIMING is for a 1920x1080 display, but the video is actually a much smaller resolution stretched to fit the output using the HMAG and VMAG registers. Since Sony didn't stretch the PSP display for games to match the output resolution, it's clear the PSP VPU doesn't have this ability that the PS2 has. So we are left with what Sony did - a 480x272 square in the middle of a 720x480 display.

[TyRaNiD]

Admittedly that isn't strictly true, you can use normal ram for a framebuffer :)

[J.F.]

Admittedly that isn't strictly true, you can use normal ram for a framebuffer :)

Is it? I stand corrected. I was under the impress that the framebuffer (the target of rendering) needed to be in EDRAM. If the framebuffer CAN be in system RAM, that does open the door to more interesting video modes out on the slim.

Sorry, edopt. Guess I shouldn't poo-poo you too soon. :)

[TyRaNiD]

For a start the impose menu (i.e. the home button menu) uses main ram for its framebuffer, however you probably get shocking performance from it, whether it would stand a chance of doing 1920x1080 is open to debate :)

[edepot]

Lets not all get too excited and rush things. I think this should be a
step by step approach. Since Tyranid has done similar stuff with the
remotejoy, he can probably whip up something really quick.

The first step is to get the 720x480p display mode up because that is
the easiest to do. The psp slim can handle that natively for many of
its normal display modes. We know for a fact that it can display
all the pixels for 720x480p because if you plug in a umd disc and
output it to the external display ALL 720x480 pixels are displayed.
So we just take that mode and instead of reading from the umd disc
(or iso if you have put it on the memory stick), feed it data from
a game. I think tyranid can probably do this in less than 2 days.
Perhaps a function call to a user mode function that in turn calls
a custom kernel prx that tricks the psp slim to accept the new 720x480p
mode. All the programmer has to worry about is putting appropriate
graphics data in the 720x480 address space and maybe a flipbuffer call to do doublebuffering. (the flipbuffer would of course end up calling that
special prx, to make it simple). 3d accelerated stuff is optional at this
stage, but if the prx can handle this as well even better (if difficult, maybe
provide an x,y offset for accellerated 480x272 3d processing inside the 720x480 so you can at least do 3d stuff in small stages). 720x480p
fits inside 2MB, so this is the easiest to do. So tyranid, when you are
ready feel free to step in (feel free to give credits if you feel like it). :)

The next step (after people can do 720x480 programs and games and
3d accelerated ones too) is to test the limits of the tv-output to see if it
can accept undocumented modes built inside the chip (if it uses one?).
HDTV accepts all types of weird modes. I think it only has 3 lines. 2 for
red and blue and the green contains both horizontal and vertical sync.
So as long as the tv can accept the sync you can experiment with all
sorts of display sizes and frames per second.

After these experimentations you can try to do what was outlined in the above post (tricking it so it can do 1920x1080) after knowing the
limitations of speeds and modes.

[Brunni]

For a start the impose menu (i.e. the home button menu) uses main ram for its framebuffer, however you probably get shocking performance from it, whether it would stand a chance of doing 1920x1080 is open to debate :)

Cool! Is there any source code on how to do this, please? :)

[TyRaNiD]

*cough* psplinkusb/tools/debugmenu *cough*

[edepot]

Ok I can confirm that 720x480 works for homebrew. The 720x480 is set when you plug your video cable to the psp slim and go to the display menu option. (and choose the external display) Note that it only supports ntsc interlaced and non interlaced. once that is set if you start a game the standard sony logo pops up, but that area of that logo is actually bigger than 480x272, it is actually filling up most of the 720x480. So whatever that sony logo is doing, it is using the 720x480 mode natively. After that your normal game would take up 480x272 centered in the middle of the screen.

I can also confirm that the xmb is using 720x480. One way is to compare
the length of the screen for displaying on the psp and on the external
display. The other is to overlay a text menu on top of the display, you will
find that the letters are actually smaller and if you count the number of
characters that can fit across the screen it is 90 characters. (8pixels per
character * 90 = 720). So at least in kernel mode you can use the whole
screen (720x480) for your homebrew program. So in this mode you just
need to write to the video memory and you can use the whole display.

So how do you get a game to use this mode? Well, the easiest is to
take over the xmb display after you have connected the video cable
and switched over to the new mode. There are a lot of software
out there that already do this so maybe map a button to your own code
and once it is pressed your program takes over. These software
usually hook into a custom kernel though, or uses an exploit like
the old tiff exploit. I think the home key in m33 does this too. But I have a feeling there is an official api when you start your program that can can call request this new video mode. But in any case the easiest might be
to write a prx and put it into the custom kernel seplugin folder that intercepts a key so you can manually load your code and take over the whole screen while the xmb is in display, but if you boot an eboot.pbp your game goes into that small 480x272 box.

[Jim]

1080p = 200MB/s = 1.6Gb/s. Just to hammer the frames to the display, ignoring where one might get that data from in the first place, or how one might set it as a display mode.

Jim

[TyRaNiD]

Tbh it is probably something simple like passing different options to sceDisplaySetMode as that already has a mode parameter which afaik is used on the devkits to select between lcd and vesa output.

Try calling sceDisplayGetMode in the VSH and see what you get :)

[Jim]

We have a 300MHz CPU and a bus with a maximum throughput of 4Gb/s. Even if you could muster 1.6Gb/s to drive the display, that's only 0.15 seconds from memory (32MB) without any compression. And then memory stick bandwidth is under a 10th of that, at 15MB/s. Where's the data going to come from? Again, forget the technicality of actually setting the mode, there's no way of doing anything useful with it.

Jim

[edepot]

I am not familiar with the bandwidth constraints, but how does 1080p = 200MB/s?

If you take RGB (3 bytes per pixel) * 1920 * 1080 = 6MB/s = 48Mb/s.
48Mb/s is WAY smaller than 1.6Gb/s.

If you must byte align on 4 bytes (RGBA) per pixel... 1920 * 1080 * 4 = 8MB/s (which I originally stated in the first post) = 64Mb/s, that is
STILL way smaller than 1.6Gb/s.

Given the PSP can handle 664 Million pixels per second fill rate max then
that means the PSP can handle 9 more 1080p screens per second?

I didn't know the Memory stick is 15MB/s if it is, 8MB/s is half of that
so you can probably drive uncompressed 1080p video or game data
from it with some spare.

In any case a 1080p display allowing text display, 2d games, or
even 3d games would be great even if it did not support 60fps. I have
many ideas requiring a large display and if the psp can do it that would
be great! But at least from this thread 720x480 is possible... maybe
800x600, 1024x768, 1440x900, and 1920 x 1080 are possible too.
(But I think hdtv are not quite aligned on those numbers but close).
I hope at least 720x480 gets included in the pspsdk (if it is needed
at all). Otherwise a simple setdisplaymode call would be easy I think.

[SilverSpring]

Tbh it is probably something simple like passing different options to sceDisplaySetMode as that already has a mode parameter which afaik is used on the devkits to select between lcd and vesa output.

Try calling sceDisplayGetMode in the VSH and see what you get :)

I can confirm that even on 1.50 the display & lcd libs natively support 720x480.

Try passing to 0xD2 to sceDisplaySetMode, which Ive seen will try to set to 720x480. In 1.50 sceDisplaySetMode:

Code: Select all

	switch(mode)
	{
		case 0x00:	LcdMode = 0;
				break;
		case 0xD2:	LcdMode = 1;
				break;
		case 0x1A:	LcdMode = 2;
				break;
		case 0x60:	LcdMode = 3
				break;

		default:	return(0x80000107);
	}

Mode1 sets to:

Horizontal pixels:
display - 720
sync - 61
Lborder - 16
Rborder - 61

Vertical pixels:
display - 480
sync - 6
Tborder - 30
Bborder - 9

@ 27 MHz

Mode0 is the default psp lcd:
480-41-2-2
272-10-2-2
@ 9MHz

Later fw add even weirder modes:
640x480 @ 25.125MHz (this one is almost standard vga, but not quite - border pixels different)
720x505 @ 13.5MHz
720x240 @ 13.5MHz

I havent had a chance to look at the slim (dont have one yet :P), but on 1.50 Ive looked at display stuff quite a bit.

Here some regs for the phat:

Code: Select all

#define LCDC_SET_USE_EXTERNAL_DISPLAY( E)	(_sw(E, 0xBE140004))

#define LCDC_SET_H_SYNC_PIXEL( P)		(_sw(P, 0xBE140010))
#define LCDC_SET_H_LBORDER_PIXEL( P)		(_sw(P, 0xBE140014))
#define LCDC_SET_H_RBORDER_PIXEL( P)		(_sw(P, 0xBE140018))
#define LCDC_SET_H_DISPLAY_PIXEL( P)		(_sw(P, 0xBE14001C))

#define LCDC_SET_V_SYNC_PIXEL( P)		(_sw(P, 0xBE140020))
#define LCDC_SET_V_TBORDER_PIXEL( P)		(_sw(P, 0xBE140024))
#define LCDC_SET_V_BBORDER_PIXEL( P)		(_sw(P, 0xBE140028))
#define LCDC_SET_V_DISPLAY_PIXEL( P)		(_sw(P, 0xBE14002C))

As far as 1920x1080 is concerned, well write directly to the registers and see what happens xD.

[edepot]

That is great, that means the experimentations will yield new possibilities.
I made a math error above. I forgot to multiply by 60 for 60fps.

To compensate maybe you can take the lowest graphic mode of PSP 16bits per pixel and a low interlace mode (30fps interlaced)...

2 (2 bytes for 16 bits per pixel) * 1920 * 1080 * 15fps (interlaced for 30 fps) = ~ 62MB/s

That would be for movies and games.

If it is possible to lower the frame rate even further (for typing and text display and 1080p photo display) to support the mode then new possibilities abound!

[BlackDiamond]

I am not familiar with the bandwidth constraints, but how does 1080p = 200MB/s?

If you take RGB (3 bytes per pixel) * 1920 * 1080 = 6MB/s = 48Mb/s.
48Mb/s is WAY smaller than 1.6Gb/s.

If you must byte align on 4 bytes (RGBA) per pixel... 1920 * 1080 * 4 = 8MB/s (which I originally stated in the first post) = 64Mb/s, that is
STILL way smaller than 1.6Gb/s.

Given the PSP can handle 664 Million pixels per second fill rate max then
that means the PSP can handle 9 more 1080p screens per second?

I didn't know the Memory stick is 15MB/s if it is, 8MB/s is half of that
so you can probably drive uncompressed 1080p video or game data
from it with some spare.

In any case a 1080p display allowing text display, 2d games, or
even 3d games would be great even if it did not support 60fps. I have
many ideas requiring a large display and if the psp can do it that would
be great! But at least from this thread 720x480 is possible... maybe
800x600, 1024x768, 1440x900, and 1920 x 1080 are possible too.
(But I think hdtv are not quite aligned on those numbers but close).
I hope at least 720x480 gets included in the pspsdk (if it is needed
at all). Otherwise a simple setdisplaymode call would be easy I think.

I think you forgot that you need to send multiple frames per second.
Uncompressed 1080p is 237MB/s at 30fps, 189MB/s at 24fps and 119MB/s at 15fps.

EDIT: Nevermind, you figured it out for yourself :p