"Export PSP screen to PC" on slim 3.71m33 ?

Sidelve · Post by **Sidelve** » Thu Oct 04, 2007 1:47 am

Hi !

I'm trying to export my psp screen to pc with this guide:

http://www.ngine.de/index.jsp?pageid=4292

Before I try to find help and post my problems, I would like to ask, is this at least possible on PSP Slim with firmware 3.60m33 ?

Are there any special requirements for linux (Xorg version or something...) ?

J.F. · Post by **J.F.** » Thu Oct 04, 2007 6:26 am

You'll need a newer version of remotejoy. A version for 3.60 M33 was never done - update to 3.71 M33-2 and use "RemoteJoySDL107b + 371 PRX.rar". You'll find that someplace else, like MaxConsole.

Sidelve · Post by **Sidelve** » Thu Oct 04, 2007 6:39 am

I used svn version, so, after upgrade to 3.71 should I use svn or these, which you wrote ?

Fejwin · Post by **Fejwin** » Thu Oct 04, 2007 7:23 am

Use iR Shell 3.7! It is shipped with the new version of RemoteJoy.
You'll just have to update to 3.71m33

Sidelve · Post by **Sidelve** » Fri Oct 05, 2007 3:38 am

OK, I updated fw to 3.71m33-2, but I'm new psp user, so I would be really grateful if someone could shortly tell me what exactly to do now..

or just which things from this guide http://www.ngine.de/index.jsp?pageid=4292 to omit...

Sidelve · Post by **Sidelve** » Sat Oct 06, 2007 1:52 am

OK, I don't know how to use remotejoy from irshell so i'm still trying to do it from guide on ngine.de:

# on the PC end, go to the usbhostfs_pc folder and run ./usbhostfs_pc
# now turn on your PSP and select the PSPLINK app from the memory stick menu
# if all goes well, you should see "Connected to Device" in the usbhostfs terminal , and the PSP should go to a black screen

works (it's just, first I have to run psplink app from ms, and then run ./usbhostfs_pc - with guide steps I dont have "connected to device")

# now, in a different terminal, navigate to the pspsh folder, and execute ./pspsh
# this should give you a shell on the PSP. try "help" for guidance.
# Finally, run the display window for your PC on a third terminal, by invoking "./pcsdl -d -c" in the tools/remotejoy/pcsdl folder
# A black wIndow should come up
# Now, all the programs are running, but nothing is displayed yet. That is because the remotejoy,prx was not started yet. Thats next:
# on the pspsh shell, issue the following commands:
# "reset vsh"
# "ldstart flash0:/vsh/module/vshmain.prx"
# "ldstart ms0:/joy/remotejoy.prx"

And here is the problem, because after "reset vsh" on psp shell I have in usbhostfc_pc terminal:

Code: Select all

Read cancelled &#40;remote disconnected&#41;

and I cant do anything on pspsh terminal - I musst restart it (pspsh),
I think, this is already wrong, but I'm trying to go to next steps, but when I type:

"ldstart flash0:/vsh/module/vshmain.prx"

in restarted pspsh terminal, I have

Code: Select all

Error in socket 0, magic B7EE8E76

in remotejoy terminal - and like in pspsh terminal, I musst restart it

And after this, no matter what I'm trying to do, I just still have black window (remotejoy), nothing wants to show up :(

I have svn version (for today) of every tools and really dont know what to do...

Can someone help me just a little ?

Post by **TyRaNiD** » Sat Oct 06, 2007 2:56 am

I personally wouldn't recommend using the irshell version :) Nothing against ahman etc (bar him always keeping source closed :P) just it will not work outside of irshell itself cause it has been modified in such a way to prevent it. Some days I really wish I had kept psplink source completely closed.

Cpasjuste · Post by **Cpasjuste** » Sat Oct 06, 2007 3:29 am

I dont really understand why you are helping ahman. He had always done some closed source stuff with some crappy "protections". More than 80% of irshell is the work of the community.

Sidelve · Post by **Sidelve** » Sat Oct 06, 2007 3:51 am

OK, but I wrote, that I'm NOT using irshell :P

i'm using svn version of all tools, like it's in the guide..

btw, thank you for all your work and for keeping it open source :)

Can you tell me, what to do, to finally see psp screen on my computer ? :)
What am I doing wrong ?

Post by **TyRaNiD** » Sat Oct 06, 2007 3:54 am

Cpasjuste, trust me I am not helping him in anyway, not much I can do about people taking BSD licensed code. Still in the end at least he is decent enough to actually give credit for the stuff he uses of mine unlike some others. Just wish that if improvements are made that it was at least fed back. Perhaps I should have used a GPL license :)

Post by **TyRaNiD** » Sat Oct 06, 2007 3:56 am

Get weltall's pre-built binaries for 3.71 and use that instead of following the ngine.de guide which is somewhat wrong imo as you dont need psplink at all :)

Sidelve · Post by **Sidelve** » Sat Oct 06, 2007 5:29 am

Yeah, it looks much easier to do it now :P

But...

I do have :

Code: Select all

Connected to device
Bulk Write dev 0x81c54a8, ep 0x2, bytes 0xbf918cac, size 4, timeout 1000
Bulk Write returned 4
Bulk Read dev 0x81c54a8, ep 0x81, bytes 0xbf918aac, size 512, timeout 0
Bulk Read returned 12
Magic&#58; 782F0812
Command Num&#58; 8FFC0000
Extra Len&#58; 0
Bulk Read dev 0x81c54a8, ep 0x81, bytes 0xbf918aac, size 512, timeout 0
Bulk Read returned 24
Async Magic&#58; 782F0813
Async Channel&#58; 00000004
Async Extra Len&#58; 16
Bulk Read dev 0x81c54a8, ep 0x81, bytes 0xbf918aac, size 512, timeout 0
Accepting async connection &#40;4&#41; from 127.0.0.1
Bulk Write dev 0x81c54a8, ep 0x3, bytes 0xb7e38094, size 20, timeout 10000
Bulk Write returned 20
Bulk Write dev 0x81c54a8, ep 0x3, bytes 0xb7e38094, size 20, timeout 10000
Bulk Write returned 20

so connection works (I'm using usbhostfs_pc from svn psplinkusb - this is good, right ?)

After this I run remotejoy from weltall's binaries but there's still just black window and nothing appears...

Maybe it's something with my Xorg ?
I'm using Slackware 12 with original X 1.3...

weltall · Post by **weltall** » Sat Oct 06, 2007 3:46 pm

i remember when i used slackware back two years ago that it was crashing my tty whathever i used usbhostfs_pc

ahman · Post by **ahman** » Sun Oct 07, 2007 12:03 am

TyRaNiD, I've no problem to post back the changes I made. I don't mind to post any open source that I took and modify. I used to post the modified source code when the official iR Shell forum was still active. Now, I only posted source codes in my private beta testing forum when ppl ask. I never stopped them from re-distribute the source code. Anyway, I'm happy to post back any changes I made to any open-source project, doesn't matter what license it uses.

I didn't change remotejoy to prevent it from using outside iR Shell. The problem for UMD compatibility was that the original remotejoy was using the volatile memory at 0x08400000. This area is used for system dialog boxes (such as save/load, name entry, etc) and also sleep mode. Thats why UMD game crashed when it tries to open the load/save dialog box. I change this address (the memory for your screen buffer) as a parameter passed by iR Shell when starting remotejoy. The reason for not fixing this address is iR Shell will pass different addresses depending on whether WiFi is running under iR Shell. I'm also using the extra 32MB RAM for the slim. Anyway, the best memory area to use is around 0x88380000 for PSP Phat. Note this area will be used if UMD Video is playing, but it's possible to relocate it to user memory when UMD Video is active. I also force it to only use 16bit graphics for remotejoy display to save memory.

Here is the modified source:
http://rapidshare.com/files/60665599/remotejoy.zip.html

Capsjuste, since you said 80% of iR Shell is the work of the community, why not you spend a little time and add your 20% to it. Then, you'll have an iR Shell clone and you can choose to have it fully open source. See, that's a piece of cake and I know you can do it in no time. ;)

Cpasjuste · Post by **Cpasjuste** » Sun Oct 07, 2007 11:41 pm

Well i must apologize because i was a little violent in my words. I also remember that you shared your nethost sources with me when i needed them and i thanks you again for this. But i still don't understand why people aren't sharing (on the psp scene) theire sources. (i think to dark alex for exemple with is custom firwmares).

Post by **TyRaNiD** » Mon Oct 08, 2007 12:34 am

Ahman, well yes I indicated it didn't work outside irshell cause it looked liked you passed in the address at run time :) The fat is a pain cause memory is abit tight, sometimes it is good sometimes not. I knew why the load/save dialog crashed just I wasn't especially bothered about it :) Ironically allocate out of partition 11 on the slim and you are sorted, even though you could use the av-out as well :)

Tbh in the end remotejoy with video was designed for outputting homebrew to my pc monitor so it could be put up on a projector, it was never designed for games and I am not about to make significant changes to it now.

ahman · Post by **ahman** » Mon Oct 08, 2007 2:31 am

TyRaNiD, I can feel your pain with the PSP Phat's memory. I've tried all different kinds of ways to squeeze memory out of it, so I can keep adding features to iR Shell without affecting UMD Game/Homebrew compatibility. When I first got my hands on the slim, that 32MB extra memory was like an open sea to me. I can't see any boundaries at all.

Although you didn't design remotejoy for games, it still works very well with them. Watching UMD Video with it wasn't bad either. :)

Post by **TyRaNiD** » Mon Oct 08, 2007 2:35 am

Well the only boundary with using the extra memory is when all the home brew arbitrarily uses that extra memory with no kernel allocation strategy and that walks over anything you have just used it for :P

ahman · Post by **ahman** » Mon Oct 08, 2007 2:38 am

Actually, I've already seen this happening in the latest NJ emus. It just uses the extra RAM without any allocation. I can also see this to become a widespread as they all seem to follow M33's SDK sample. lol

moonlight · Post by **moonlight** » Mon Oct 08, 2007 3:02 am

Cpasjuste wrote:Well i must apologize because i was a little violent in my words. I also remember that you shared your nethost sources with me when i needed them and i thanks you again for this. But i still don't understand why people aren't sharing (on the psp scene) theire sources. (i think to dark alex for exemple with is custom firwmares).

If there was a possibility of me sharing the sources, it was lost when the leak happened. Giving the source now would give the wrong message to the leaker "hey, if you want the author to open source an app, just steal the source and force him to release it". I will not give the satisfaction to the leaker.

Sony hadn't changed anything so much as when the source has been released. Yes, it could be a casuality or caused by them pissed because of the release of Pandora. I know they should be able to reverse too, and with better tools to do it. But still I can't stop of thinking of the casuality the changes happened now, they mainly attacked pops patches, but also the HEN core.

Anyways, I don't think that sharing the patches of M33 would really be that helpful to the community, at least while I last active, if someone is really interested on the full source or in a specific patch, he can reverse it, or he can ask me, in the past I never negated to do it, although the situation is very different now, after having suffered two leaks, one of them myself, and one of them as part of C+D, my reliability on people is very low.

TyRaNiD wrote:Well the only boundary with using the extra memory is when all the home brew arbitrarily uses that extra memory with no kernel allocation strategy and that walks over anything you have just used it for :P

I'm trying to hack the partitions now, but it is not being as easy as I thought. Just changing 0x1800000 to 0x3800000 doesn't seem to do the job, either done before sysmem is started, or much later.

Edit: well now i made it to work, new user memory size = 24+32=56M, In my app i could allocate between 54-55 max MB (same as in normal memory, you can allocate between 22-23 MB max). Let's hope in future versions of M33 people use allocation.

The patch shouldn't affect existing homebrew, but just in case I will add a setting to the recovery to use 32 MB only (by default, disabled).

Btw tyranid, is there any reason malloc doesn't work in an user prx? (and a plan to fix it?) It is not related to this patch, it never works, not in 1.50 either. Not a big problem, as people can still use static elf where it works perfectly, or use the AllocPartitionMemory in the prx.

cloudhunter · Post by **cloudhunter** » Mon Oct 08, 2007 7:46 am

Cpasjuste wrote:Well i must apologize because i was a little violent in my words. I also remember that you shared your nethost sources with me when i needed them and i thanks you again for this. But i still don't understand why people aren't sharing (on the psp scene) theire sources. (i think to dark alex for exemple with is custom firwmares).

Well, I was going to say why he didn't share his sources, but seems like he has already explained it.

As he said, many changes Sony made to the firmware were specifically to stop - or at least make more difficult - patching the firmware. Giving source out would like be saying: "Hey Sony! Have a look at this code, which is a low cost manual on how to stop me!" I think you'll agree, that isn't good ;)

Cloudy

Post by **TyRaNiD** » Mon Oct 08, 2007 8:12 am

moonlight, urm malloc works fine in a user prx as far as I am aware. You do realise it only allocated 64KB by default? So if you try and allocate a large memory block it will fail immediately ? If you update to the latest pspsdk then you can use PSP_HEAP_SIZE_MAX() define which will now allocate as much ram as you possibly can.

moonlight · Post by **moonlight** » Mon Oct 08, 2007 8:19 am

TyRaNiD wrote:moonlight, urm malloc works fine in a user prx as far as I am aware. You do realise it only allocated 64KB by default? So if you try and allocate a large memory block it will fail immediately ? If you update to the latest pspsdk then you can use PSP_HEAP_SIZE_MAX() define which will now allocate as much ram as you possibly can.

I forgot about that completely lol

Btw, it seems the last 4 MB of the slim are used in sleep mode or something:(

I guess that's why it has its own partition... Damn, well if I can't fix it, we'll have 4 MB less for normal use, and 4 MB more of volatile shit.

Post by **TyRaNiD** » Mon Oct 08, 2007 8:42 am

The bastards :(

ahman · Post by **ahman** » Mon Oct 08, 2007 3:30 pm

Cpasjuste, Dark_AleX/moonlight doesn't mind to share some of his source code to developers. He has helped me in numerous occsaions and even sent me the popsloader source code. That's how I was able to add popsloader support in iR Shell. I can fully understand how he feels with the leak from those bastards. Also, most developers don't want to see their work being modified and release as clones with insignificant to no enhancements. I will be pissed if I see an iR Shell clone released and being renamed as blah blah blah ISO loader or something. If someday I decide to stop iR Shell development all together, I may pass it to someone else.

DA, it's good to see you can finally combine the memory together. I also hope people will use memory allocation with your next release. :)

Cpasjuste · Post by **Cpasjuste** » Mon Oct 08, 2007 3:46 pm

I still don't understand your choice, but i respect it. By the way, it's an awesome news moonlight.

moonlight · Post by **moonlight** » Tue Oct 09, 2007 8:07 am

The cause of the last partition filled with 0 after sleep mode is me_wrapper.

I've tried lots of things today, but I can't fix this without destroying applications that use audiocodec/videocodec, so we'll have 52 MB of user memory in the slim.

Maybe in the 1.50 kernel I can make the 56 MB partition to work, but wlan will not work in 1.50 in the slim (world is not perfect :p)

Also, the problem with the memory allocation thing, is that it will break applications that currently use it rawly, this is due to some allocation functions allocating the memory from the end, and writing rawly to the memory would destroy other data. The other problem is that kernel homebrew shouldn't use the partition 8, as it is possible that sysmem can't synchronize the content of partition 8 and 2. Dunno if this would break current remotejoy in irshell, probably the better would be recode it to use user memory, I don't know either if the use of 52 MB of ram will cause problems in games loaded by irshell, m33 will not activate 52 MB user partition when loading a game, but when irshell is loaded, it's too late.

Of course I will keep a setting in recovery, to keep things like before, but it will be off by default. A quick trick for an apllication that wants to force the 24MB would be to autoexecute itself using VSHMs1, as M33 will only make the memory combination in programs executed by VSHMs2.

Cpasjuste · Post by **Cpasjuste** » Tue Oct 09, 2007 8:33 am

To take advantage of this 52mb we will anyway need to modify the code of our applications so it should not be a very big problem for older applications. Also maybe you could do something like if an eboot have a certain flags, or is loaded at a certain address for exemple, the user memory is set to 52mb so we would just have to set something in our code to use this new partition scheme. Dunno if it would be possible. If not, maybe it will be easier to make a little bootstrap/loader code that will load our "52mb eboot", without the need to the user to go trought the recovery mode if they whant to load some older eboot's.

moonlight · Post by **moonlight** » Tue Oct 09, 2007 8:41 am

Well, the set of a flag, etc, would probably need something to be built in the pspsdk, something simple such as a SFO variable (best), a simple imported variable in the elf/prx, etc. I don't know if tyranid would like to do it :p

J.F. · Post by **J.F.** » Tue Oct 09, 2007 10:48 am

Maybe instead of doing away with the extra partion, you simply change the sizes of the two in question (and the start addr of the second). So instead of two partitions of 24M and 32M, you have two partitions of 48M and 8M. Leave enough memory in the new partition for the me_wrapper/codecs and a small UMD cache, while expanding the first partition to a more useful size.