^^I'm partially doubting him actually.  I've seen the header of 3.10 RCOs (the first section isn't encrypted/compressed) - nothing has changed in terms of structure, and I know that RCOs only contain 6 parts of data:

• Image resources (MIG/PNG)
  
• Sound resources (VAG)
  
• Object resources (OMG/GMO - eg waves)
  
• Text Data (eg menu labels)
  
• Page Data
  
• Anim Data

There's also some labels and "native" data describing the above, as well as the table entries of course.

Also, he claims that some RCOs were Gzip compressed (he says that on the same page).  I sent him this PM:

zinga Wrote:Yeah, PMd you cause don't want to get too off-topic in that thread :P

(14/03/2007 01:00 PM)michaelp Wrote:  well if you want to know more the rco's contain both zlib compression and Gzip compression :) try deflating some with Gzip :p, by the way your RCOeditor is really good :) you should have 3.03 file support though because not all 3.03 files are encrypted
pm me sometime when you're free ;)

Hehe, thanks a lot for that info.
I had a look at some random ones (auth and system_plugin_fg.rco) but wasn't able to inflate using GZip (is it somewhat different to zlib's deflate?  cause I believe zlib includes gzip handling functions...  dunno though - I've never really delved into compression before).
All I've been able to discover (if you didn't know this already - lol, my n00b findings :P):

- the newer compression achieves a slightly better compression ratio than what zlib can achieve (on level 9) - for example, the triangle image in system_plugin_fg is 200 bytes, one in 2.50 is 227 bytes.  Recompressing it squishes it down to 223 bytes.  If gzip's deflate is different from zlib's, is it this much different?

- In system_plugin_fg.rco, for the circle and cross images, the first ~64 bytes are identical...  this isn't the behaviour of zlib's deflate.

- Signature for the images is 0xD905 (2 bytes), but it seems that the first four bytes are required - the rest can be blanked without the PSP crashing

- For the header sections, things seem to be broken into components, but the signature seems to vary, but there's some common ones


Anyways, ignoring all that junk, I don't have any idea on how to decompress the 3.xx RCOs...  I do remember at one point, jas0nuk claimed that it could possibly be the 2RLZ compression algorithm.

Thanks a lot for bringing this up :)  Would be great if this could be figured out! :D

He never replied...
Basically, I'm not certain he exactly knew that he was right...  I dunno though...