Possible XMB Folder Hack?

**NeonGenesis** · May 27th, 2008, 02:52

I'm not sure if this is best placed in this forum or another, but hey...

I've quite a selection of games/apps that run from my XMB's game menu, and even with the CPU clocked up for the XMB the load time to show all of the apps is getting a little excessive, not to mention sifting through the list to get where I want (No, I don't want to drop the backgrounds to speed it up

) Now, of course, like half the PSP scene I've contemplated just coding a replacement shell in Lua that does exactly what I want, but I really don't have the time to invest in that project at the moment.

What I'd like, ideally, is to be able to separate PSP games, PS1 games, and Applications into separate subfolders.

XMB hacking has advanced quite a bit over the last year, and so I'm curious: Is there a hack that allows the 'Game' list of the XMB to be subdivided into folders similar to the 'Photo' or 'Music' folders?

If not, is that potentially possible (and does anyone want to code it)? It'd be a great organizational help to my PSP, most certainly...

**pspmodel1001** · May 27th, 2008, 04:52

I would also like this because when using HostCore, I would like to put them in sudfolders since it takes me around 5 seconds or so to reach the bottom.

**Cloudhunter** · May 27th, 2008, 10:18

It's definitely possible, but not without a bit of hackery.

I've considered doing it myself, but it may cause some trouble with the hooks M33 already puts in place, and solving that would be beyond my expertise - and as such I've not really looked at it. Also, any implementation I do would likely be very ugly considering my reversing skills - or more accurately, complete lack of.

Cloudy

**boumboum** · May 28th, 2008, 14:33

I launched the idea a few month before to code a XMB extension homebrew looking exactly the same than the XMB but acting like a folder explorer in GAME folder

**NeonGenesis** · May 28th, 2008, 23:43

First off, I've thought about it a little, and here's what I'd expect would go into it.

Rather than actually creating subfolders within the PSP\GAME directory, I would think it would be more realistic to treat it entirely separate of the memory stick's file system. A plugin could have a config file where users enter a list of the eboots/ISOs that the user has in their already present 'Game', 'Game150', 'Game3xx' and 'ISO' folders. This config file could then have next to each identified eboot/ISO a subfolder that it should be placed under.

For example:

PSP\GAME\NesterJ\eboot.pbp = "Emulators"
PSP\GAME\SNES9XTYL\eboot.pbp = "Emulators"
PSP\GAME\FFVII\eboot.pbp = "PS1 Games"
PSP\GAME\Filer\eboot.pbp = "Utilities"
PSP\GAME\Bookr\eboot.pbp = "Applications"
ISO\Wipeout Pure.iso = "PSP Games"
ISO\Lumines.cso = "PSP Games"

etc....

This would eliminate any errors you'd get from actually messing with actual subfolders on the memory stick, breaking any functions of the firmware or other apps/plugins that rely on the specific folder layout of the PSP. Obviously, then, the real trick becomes forcing the XMB to show the apps within the subfolders that list establishes in a similar fashion to, perhaps, the 'Photo' folder.

It'll really come down to a knowledgeable PSP firmware hacker that wants that functionality as well to get that to happen.

I think actually creating a full on extension for the already present XMB that would allow for actual folder management/exploration in a file tree sort of fashion is probably not particularly likely, unfortunately. Most of the true XMB hacks that affect the user interface seem to be entirely based on either hacking the RAM, as is the case with the Update hiding plugins and would likely be the case if this subfolder hack were to be produced, or in adjusting variables and graphic resources that affect the placement and graphics of the items present on the XMB (at least as far as I can tell). A hack as boumboum describes would require a much more major recoding of the XMB, I would think, and therefore increases quite significantly in difficulty.

The most viable option for expanding/customizing the functionality of the XMB beyond the simply visual is just to code a replacement shell, either in C or in the recent LuaplayerHM releases, which has a ton of shell-type functions added to it. As I said, it's something I've considered, and even somewhat ventured into, but it takes a bit of time and effort to do right. Eventually, I'll go ahead and do it, but my two year old is particularly resistant to the idea.

Anyways, just my thoughts on it.