[PS3 Dev Request]: Have a PSP and familiar with .RCO files?

[Field]

Can't stress enough of how much of a newbie I am, but anyway, lol.

Had a look at bigblockchev's RCO and loaded them up within RCOEdit. Camera_plugin and camera_plugin_mod1_uncompressed both loaded up, but I didn't see any difference between General Resource, Text Data, Page Data and Anim Data. Everything was there, except info relating to PS3 rco data.

This got me thinking. Looking at the 3 PS3 RCO, they all have the same header FRP etc [first 16 bytes 4652 5000 0000 0107], and then they appear to follow the same format as the PSP code layout. I'm not a genius but it has the same header, then code which is spaced out heaps.

I.e. ..D..........#............(................

I wonder if these are the GIM files. Cause afterwards, it has written commands that look like this - M.o.v.e R.i.g.h.t.

After more i see words like this - snd_oskenter....snd_oskcancel...phonekey8...bg..bg 2 (etc) I like that osk_plugin has snd. I assume Sound file for enter and cancel.

Then after that I see more hex that doesn't make sense, yet it's more detailed, more dense, more extreme, if that makes sense. eg. RG.v.x..s..5.30`...`..&..h.$.....W..Y.|....A*.@B.z ..@Y...

Now the reason why I wrote this is that is seems that there are 3 main sections to the RCO. Top is code, middle is info releating to PS3/PSP commands, followed by extreme (lol) hex code.

The PSP follows the same format. The only time this doesn't happen is with friendim_plugin which is all the header and the 'extreme' code.

So maybe the point being is that we'd have to split the sections and paste into a PSP RCO for it to recongise the commands that we want to extract. Maybe ???

I also had a look at the difference between the PS3 osk_plugin (thanks CJPC) with the PSP osk_plugin.

PS3 file size is 31Kb compared to the PSP which is 403KB. Weird. RCOEdit couldn't open the PS3 RCO, but maybe someone could try the Resurssiklunssi method too.

Both have their respected headers, though the coding is not the same, but it has the same sections. First heaps of spaced out hex, then english and (yep as CoreTX stated - different languages). Both have some same commands like snd_oskcancel and phonekey8. There is a lot more for the PSP.

Oh just checked the PSP osk_plugin and it has GIMs and VAG titled snd_oskenter. So indeed I'm guessing that the section will need to be split for better, maybe??, working with an editor or opening the file wide open.

Then it continues with the dense code, till the end. Oh and both have SE06_Keyboard_OK and SE7_Keyboard_NG near the bottom of the RCO file.

So I guess it's probably time to write out a whole new RCO, I might try to inject just a little. If anyone else wants to have a crack, I think (again I'm not a hex master) that the RCO have 3 sections that all relate. That maybe why pasting the whole PS3 RCO into the PSP one didn't work as the code wasn't in the right sections.

Hope this helps someone, good luck to everyone.

[bigblockchev]

It became clear this morning with fresh eyes and after reading what Field posted. The header information is almost identical between the psp and ps3 rco files. More noticeable is how each 4 bytes is simply in reverse order. The header may not need to be adapted, it needs to be reversed.

Reversed sections:

offset 0x00: 4 bytes: (col 0 - 3)
00 50 52 46 (psp)
46 52 50 00 (ps3)

offset 0x00: 4 bytes: (col 4 - 7)
00 01 00 00 (psp) (missing 07)
00 00 01 07 (ps3)

offset 0x00: 4 bytes: (col C - F)
20 00 00 00 (psp)
00 00 00 10 (ps3)

offset 0x10: 4 bytes: (col 0 - 3)
A4 00 00 00 (psp)
00 00 00 A4 (ps3)

offset 0x20: 4 bytes: (col 4 - 7)
CC 00 00 00 (psp)
00 00 00 CC (ps3)

From offset 0x00 to 0xA0 all the data is simply reversed. I am going to reverse it all right now and run friendim_plugin.rco through Resurssiklunssi.

The second half of line offset 0x60 is different on the ps3 having FF's and 00's where the psp file does contain data. No changes made to this line.

Results:

Resurssiklunssi passed "Working with header..." and failed at "Working with languagetables..." powering down the psp 10 seconds later.

Is there a better method for reversing data? How many more bytes might need to be reversed?

At least the header seems to be recognizable now.

Attached result.

Attached Files

reverse-header-results.rar (110.4 KB, 4 views)

[bigblockchev]

After plenty of hex editing I've learned camera_plugin.rco is entirely different from friendim_plugin.rco and even replacing similar sections between files does not provide tangible results with Resurssiklunssi.

I've been comparing psp .rco files and just noticed that the msvideo_plugin.rco file from the 2.70 psp firmware has the same layout as friendim_plugin.rco (ps3). These two are very similar. Decompressing msvideo_plugin.rco with Resurssik works perfectly. Swapping the byte-order to big-endian on the header in the friendim_plugin.rco file has given me my best results so far. Resurssik does not even mention "Working with headers..." if I only swap the first 4 columns (2 bytes) and skips straight to "Working with languagetables..." and fails.

What do the experts think? Seems like the ps3 .rco files need to be converted to big-endian to run properly on the psp with Resurssiklunssi. I am new to this depth of hex and doing my best.

I will try swapping header info around now and further learning the file format.

Attached msvideo_plugin.rar.

Attached Files

msvideo_plugin.rar (132.8 KB, 3 views)

[racer0018]

I have a psp with firmware 3.90-2 M33, i have played around with the psp enough to understand it. I also have the 60 gig ps3. Thanks

[PS3 News]

racer0018 and AbdouRetro: It's a little late for just "I want to help" posts... not sure why you guys haven't noticed the files are already posted.

Please read, and then examine the files followed by posting your findings as the others are now doing. I will probably begin removing posts that aren't focusing on the PS3 RCO file findings from this point forward.

[xfcj]

I've been comparing the uncompressed ps3 rco files to uncompressed psp rco files and like bigblockchev was pointing out the headers has the info in the same places, but the psp files are big endian while the ps3 is little endian. Unfortunately this doesn't apply to the whole file so I've started to make a chart of what needs to be reversed.

Header				Byte flip as 32 bit	correct
Information Table		Byte flip as 32 bit	not sure
Text Table			Byte flip as 32 bit	correct
Sound (VAG) Table		Byte flip as 32 bit	correct
Model (OMG) Table		
Image (MIG) Table		Byte flip as 32 bit		
Page Table			Byte flip as 32 bit	correct
Animation Table			
Message Text			Byte Flip as 16 bit	correct for dlna
Lable Table			NO Flip			correct
native:/ Table			NO Flip			not sure
Text Pointer Table		Byte flip as 32 bit	correct
Image (MIG) Pointer Table	Byte flip as 32 bit	correct
Model (OMG) Pointer Table	
Sound (VAG) Pointer Table	Byte flip as 32 bit	not sure
Page Pointer Table		Byte flip as 32 bit	correct
Animation Pointer Table		
Image (MIG) Data Section	NO Flip			not sure
Sound (VAG) Data Section	NO Flip			correct
Model (OMG) Data Section

The 1st column is the table name, 2nd is what has to be done and 3rd is what I think of the change. The ones I'm not sure of are guesses based on comparing the ps3 and psp files. The blank ones are tables that aren't found in either of the uncompressed rco files posted.

I've attached the modified RCOs that work with RCOEdit.

Attached Files

Modified_RCO_Files.zip (20.5 KB, 8 views)

[bigblockchev]

Thanks xfcj,

Ran your modified dlna_plugin.rco through Resurssiklunssi with partial success displaying only "Working with graphics... OK!" and exiting properly.

Also ran your modified osk_plugin.rco through Resurssiklunssi with same result. "Working with graphics... OK!" and exiting properly.

Output file sizes remain the same and are attached.

Attached Files

Modified_RCO_Files_PSPTestResult1.rar (21.8 KB, 6 views)

[Field]

Awesome work to bigblockchev and xfcj. I have no idea what you guys are talking about but those modified open with RCEdit. Opps just re-read xfcj's post where he states that. Umm, well I'm stumped. Sorry for this non-info post.

So now that RCEdit can open this PS3 RCO, though it looks like some of the info is not quite there, what can be done? Font hack? network hack?

Do the Dev's want the PS3 RCO to be workable with Resurssiklunssi or with RCEdit? I'm guessing that it'll be risky running one of these PS3 modified RCO files without proper testing.

Great to hear bigblockchev and xfcj. I hope the dev like the results.

[bigblockchev]

I reversed the sequence of byte-order on each group of 4 bytes per line per row to convert the entire file to big endian. I am no developer but can script and I used awk. The result of putting the new reversed file through Ressursiklunssi was discouraging:

"Working with header... error during decompression!"
"Skipping File!"

It's hard to say what result we have now. Reversing *just* the header info allowed Ressursiklunssi to pass "Working with header..." and attempt "Working with languagetables...". Now with a full reversal the header still seems to be recognised but we have a definite failure to identify DATA and the file is being skipped.

So, can we assume Languagetables occur after the start of successful decompression? Therefore assume that perhaps a new Languagetable is halting Ressursiklunssi? Even during a successful RCO conversion there is a 1-2 second pause at "Working with languagetables..." just before the PSP light really kicks in and seems to dump most data from "Working with graphics...OK!". Maybe it's the beginning of the Graphics process that is halting Ressursiklunssi.

Any ideas?

Attached Files

friendim_plugin_Reversed.rar (110.9 KB, 3 views)

[CJPC]

Originally Posted by Field Awesome work to bigblockchev and xfcj. I have no idea what you guys are talking about but those modified open with RCEdit. Opps just re-read xfcj's post where he states that. Umm, well I'm stumped. Sorry for this non-info post. So now that RCEdit can open this PS3 RCO, though it looks like some of the info is not quite there, what can be done? Font hack? network hack? Do the Dev's want the PS3 RCO to be workable with Resurssiklunssi or with RCEdit? I'm guessing that it'll be risky running one of these PS3 modified RCO files without proper testing. Great to hear bigblockchev and xfcj. I hope the dev like the results.

Well, since we are working on multiple fronts at once it gets a bit confusing, but we would like to modify (then eventually recompress etc) the RCO's to replace back on the PS3. Ideally we would like to do this all PC side, but there may be technical limitations as to doing that. Furthermore, we need to find a foolproof way to write to the PS3 flash (while the PS3 is on) without bricking the thing!

We all thank you all for your help, its definitely a plus, and expect part 2 of the flash news later this week.

Peek at the upcoming post -> the XMB on the PS3 also uses nice XML files to delineate most of its functions!