Using the TV out in homebrew, whatever cable, full screen

[J.F.]

0x25F47F96 sceSysconGetVideoCable

int sceSysconGetVideoCable(int *type);

Dont have a slim with me right now so I cant test it.

As I posted a while back, int sceImposeCheckVideoOut(int *val); also returns the cable info. It returns an error if no cable is detected, and 0 if there is. *val contains the cable type when 0 is returned. Impose probably calls the function you give above. :)

that impose function calls the hprm function i use in my prx, and i guess that one use the syscon. I didn't use the impose function, because it returned an error if executed in game config.

I was able to call it by putting it in a kernel mode prx. Called that way, it works fine. What I couldn't fugure out was how to switch to TV out... which you've dealt with.

The prx code for that function is:

Code: Select all

int CheckVideoOut(int *val)
{
	unsigned int k1;
	int err;

	k1 = pspSdkSetK1(0);
	err = sceImposeCheckVideoOut(val);
	pspSdkSetK1(k1);
	return err;
}

[MysticWhiteDragon]

I tried to compile the PRX and EBOOT.PBP and I can compile the the PRX no problem, but when I go to compile the EBOOT.PBP it gives me the following error below. The makefile is similar to the Makefile in the example. Any idea why I get this error?

Code: Select all

src/pspDveManager.s: Assembler messages:
src/pspDveManager.s:5: Error: unrecognized opcode `stub_start "pspDveManager",0x40090000,0x00010005'
src/pspDveManager.s:6: Error: unrecognized opcode `stub_func 0x2ACFCB6D,pspDveMgrCheckVideoOut'
src/pspDveManager.s:7: Error: unrecognized opcode `stub_func 0xF9C86C73,pspDveMgrSetVideoOut'
src/pspDveManager.s:8: Error: unrecognized opcode `stub_end'

[MysticWhiteDragon]

I found out that for some reason my pspDveManager.s file will not include "pspstub.s" because of the #. If I copy all or pspstub.s to pspDveManager.s it works fine. Does anyone know how to fix this and also is it possible to make all of this code into a single EBOOT rather that an EBOOT and PRX?

[J.F.]

I found out that for some reason my pspDveManager.s file will not include "pspstub.s" because of the #. If I copy all or pspstub.s to pspDveManager.s it works fine. Does anyone know how to fix this and also is it possible to make all of this code into a single EBOOT rather that an EBOOT and PRX?

You have to use .S, not .s. Using .S means that gcc processes the file first, so you can include .h files and do things like #define.

[MysticWhiteDragon]

for some reason it doesn't matter if it is .s or .S neither work for me. I just get the same message as before. The only option that work for me is to add all the file info from the included stub file into to file that I call the functions from.

[J.F.]

No, the "pspDveManager.s" needs to be "pspDveManager.S". It's not the pspstub.s file that is the trouble. "pspDveManager.S" is the one doing the #include'ing, so it needs the .S.

[MysticWhiteDragon]

Sorry, what I meant is if I try .S is still reads the #include as a comment and not an include.

[moonlight]

Maybe you have an outdated toolchain.

[J.F.]

Sorry, what I meant is if I try .S is still reads the #include as a comment and not an include.

Are you trying to run it through psp-as in the makefile? That would make it ignore the .S. You need to run it through psp-gcc and let it pass it off to psp-as. The default build script does this, so you'd have to be doing this yourself in the makefile.

[MysticWhiteDragon]

Here is the makefile I used. btw, I use Portable Dev-C++ so I can develop programs on any PC with a USB Drive.

Code: Select all

TARGET   = Target
FOLDER   = VideoOut
OBJS     = src/eboot.o src/pspDveManager.o

#BUILD_PRX   = 1
#PRX_EXPORTS = src/exports.exp
PSP_FW_VERSION = 371

INCDIR   = include src
CFLAGS   = -O2 -G0 -Wall
CXXFLAGS = $(CFLAGS) -fno-exceptions -fno-rtti
ASFLAGS  = $(CFLAGS)

LIBDIR   = lib
LIBS     = -lpspkubridge -lpsprtc
LDFLAGS  = 
#USE_PSPSDK_LIBC = 1
#USE_KERNEL_LIBS = 1

EXTRA_TARGETS    = EBOOT.PBP
PSP_EBOOT_TITLE  = VideoOut Test
#PSP_EBOOT_ICON   = res/ICON0.PNG
#PSP_EBOOT_ICON1  = res/ICON1.PMF
#PSP_EBOOT_PIC1   = res/PIC1.PNG
#PSP_EBOOT_UNKPNG = res/PIC0.PNG
#PSP_EBOOT_SND0   = res/SND0.AT3

PSPSDK=../../Compiler/PSPDev/psp/sdk
include $(PSPSDK)/lib/build.mak
#include $(PSPSDK)/lib/build_prx.mak

#all: $(TARGET).prx
all: EBOOT.PBP
	-rm -f $(TARGET).elf PARAM.SFO
	-rm -f src/*.o
#	-mv -f $(TARGET).prx ../../PSP/GAME/$(FOLDER)/
	-mv -f EBOOT.PBP ../../PSP/GAME/$(FOLDER)/

[J.F.]

Ah! You've got "#BUILD_PRX = 1" in the makefile. You cannot load kernel modules in 3.xx unless you use "BUILD_PRX = 1" instead.

[MysticWhiteDragon]

I uncommented that line and still no luck. Same errors as before

[J.F.]

You should probably post everything. The bits and pieces you've shown so far have had problems, so there's probably problems all over.

[cooleyes]

Code: Select all

  pspDveMgrSetVideoOut(2, 0x1d1, 720, 503, 1, 15, 0); 
  pspDveMgrSetVideoOut(0, 0x1d2, 720, 480, 1, 15, 0); 
  pspDveMgrSetVideoOut(0, 0x1d1, 720, 503, 1, 15, 0); 
  

why use x=1, y=15, z=0?
if I want to turn off the TV out, use which values?

pspDveMgrSetVideoOut(0, 0, 480, 272, 1, 15, 0); ??

[hlide]

Sorry, what I meant is if I try .S is still reads the #include as a comment and not an include.

Maybe your devkit doesn't make a difference between .s and .S by default.

[hlide]

Sorry, what I meant is if I try .S is still reads the #include as a comment and not an include.

Maybe your devkit doesn't make a difference between .s and .S by default. I can only suggest you to use Cygwin. most issues are solved with it.

[MysticWhiteDragon]

I use cygwin through Dev-C++. Oh well, at least I got it to work copying the pspstubs.s file into the pspDveManager.S file. Anyway, I am trying to compile the TVOut Sample and have no idea on how to include the files that are needed:

Code: Select all

int sceHprm_driver_1528D408();
int sceImposeSetVideoOutMode(int,int,int);
int sceDve_driver_DEB2F80C(int);
int sceDve_driver_93828323(int);
int sceDve_driver_0B85524C(int);
int sceDve_driver_A265B504(int,int,int);

Does anyone have a clue on how to compile the TVOut Sample without a prx file? In case anyone is interested, I planned on making it automatically switch to the TV if a correct cable is attached, otherwise it would just display it on the PSP screen.

[J.F.]

You really shouldn't make something like that automatic. Just because they have the cable plugged in doesn't mean they want to use the TV, or that the TV is even on. Give the user an option and wait for them to tell you to switch.

[internal]

Is it possible to play game or ppa on tv via av cable(3 lines)? It's sooo exciting! Because every tv has this traditional interface.

[weltall]

Is it possible to play game or ppa on tv via av cable(3 lines)? It's sooo exciting! Because every tv has this traditional interface.

read this thread from the beginning

[cooleyes]

Is it possible to play game or ppa on tv via av cable(3 lines)? It's sooo exciting! Because every tv has this traditional interface.

I will release a new version PPA soon, it support TVOut. :P

[internal]

Is it possible to play game or ppa on tv via av cable(3 lines)? It's sooo exciting! Because every tv has this traditional interface.

read this thread from the beginning

I did. I mean we support it in system level. By now if you start a game or ppa via simple av cable, psp'll send you back and say you need a better cable. if we can bypass this check, then every game or homebrew could have tv output without rewrite.

Is it possible to play game or ppa on tv via av cable(3 lines)? It's sooo exciting! Because every tv has this traditional interface.

I will release a new version PPA soon, it support TVOut. :P

hope it's as nice as dvd:D

[moonlight]

Is it possible to play game or ppa on tv via av cable(3 lines)? It's sooo exciting! Because every tv has this traditional interface.

read this thread from the beginning

I did. I mean we support it in system level. By now if you start a game or ppa via simple av cable, psp'll send you back and say you need a better cable. if we can bypass this check, then every game or homebrew could have tv output without rewrite.

Is it possible to play game or ppa on tv via av cable(3 lines)? It's sooo exciting! Because every tv has this traditional interface.

I will release a new version PPA soon, it support TVOut. :P

hope it's as nice as dvd:D

And still, read this thread from the beginning ;)
http://forums.ps2dev.org/viewtopic.php?p=59623#59623

I patched that check -> no working still, odd lines, disconnection, etc. I had to patch then impose.prx and display.prx in the reboot to change some parameters. Result -> appart of the problem of the interlace, the games were really SLOW, unplayable.

Sorry, the composite cable will always be slow, nothing can be done about that.

[J.F.]

hope it's as nice as dvd:D

And still, read this thread from the beginning ;)
http://forums.ps2dev.org/viewtopic.php?p=59623#59623

I patched that check -> no working still, odd lines, disconnection, etc. I had to patch then impose.prx and display.prx in the reboot to change some parameters. Result -> appart of the problem of the interlace, the games were really SLOW, unplayable.

Sorry, the composite cable will always be slow, nothing can be done about that.

Uh - we're talking VIDEO here, not games. The video out from the PSP is very nice and full speed, as you can see with any UMD video disc. It stands to reason that properly written, PPA TV out should be full speed for video as well.

Also, I think your test for games over TV out was probably flawed somehow - there's already one emulator out using TV out (gpsp - a GBA emu), and no one with composite has complained about speed, just the flicker from interlaced mode.

[moonlight]

He was also talking about using it in general for games.

And believe me, composite cable is slower than component-interlace. But obviously, fast enough for videos.

[J.F.]

And believe me, composite cable is slower than component-interlace. But obviously, fast enough for videos.

That doesn't make any sense. Composite should be identical to component interlaced. There's no difference in the signals other than component using Y/Pb/Pr and composite using Y+C. I can't imagine that making any difference in program speed. No one has reported this with the GBA emu I mentioned. The timing is the same, the memory is laid out the same, so why should one be faster than the other?

[cooleyes]

And believe me, composite cable is slower than component-interlace. But obviously, fast enough for videos.

That doesn't make any sense. Composite should be identical to component interlaced. There's no difference in the signals other than component using Y/Pb/Pr and composite using Y+C. I can't imagine that making any difference in program speed. No one has reported this with the GBA emu I mentioned. The timing is the same, the memory is laid out the same, so why should one be faster than the other?

I had released a new version PPA, it supported TVOut .
I use more framebuffer to make video out fast,
so when use composite cable to TVOut, it still ok, :P

[internal]

And still, read this thread from the beginning ;)
http://forums.ps2dev.org/viewtopic.php?p=59623#59623

I patched that check -> no working still, odd lines, disconnection, etc. I had to patch then impose.prx and display.prx in the reboot to change some parameters. Result -> appart of the problem of the interlace, the games were really SLOW, unplayable.

Sorry, the composite cable will always be slow, nothing can be done about that.

Thank you for your hard work. Hope this general fix would work someday. I always doubt if it's technic impossible or just to sell more bravias...

[J.F.]

And believe me, composite cable is slower than component-interlace. But obviously, fast enough for videos.

That doesn't make any sense. Composite should be identical to component interlaced. There's no difference in the signals other than component using Y/Pb/Pr and composite using Y+C. I can't imagine that making any difference in program speed. No one has reported this with the GBA emu I mentioned. The timing is the same, the memory is laid out the same, so why should one be faster than the other?

I had released a new version PPA, it supported TVOut .
I use more framebuffer to make video out fast,
so when use composite cable to TVOut, it still ok, :P

Great! I love PPA. It's what I use the most for playing videos. :)

EDIT: for those who have trouble finding PPA, here's a link to the latest.
http://www1.cngba.com/thread-16816469-1-1.html

[cooleyes]

That doesn't make any sense. Composite should be identical to component interlaced. There's no difference in the signals other than component using Y/Pb/Pr and composite using Y+C. I can't imagine that making any difference in program speed. No one has reported this with the GBA emu I mentioned. The timing is the same, the memory is laid out the same, so why should one be faster than the other?

I had released a new version PPA, it supported TVOut .
I use more framebuffer to make video out fast,
so when use composite cable to TVOut, it still ok, :P

Great! I love PPA. It's what I use the most for playing videos. :)

EDIT: for those who have trouble finding PPA, here's a link to the latest.
http://www1.cngba.com/thread-16816469-1-1.html

or you can get ppa source from googlecode svn
svn checkout http://pmplayer-advance.googlecode.com/svn/trunk/ pmplayer-advance

and you can download the english version PPA in here
http://code.google.com/p/pmplayer-advan ... loads/list