Prometheus – uncovered!

From what I heard, people are somewhat scared about making the move to Prometheus and it’s online service due to my (excuse this please) badly chosen terminology inside of PROCFW and lack of comparisons to alternatives like Xlink Kai or Adhoc Party.

In response to this I felt like giving you guys a… bit more technical insight into the inner workings of Prometheus, what the used terms mean and how the whole functionality (or lack of therefore) comes to be.

I will also cover the crucial differences between Xlink Kai, Prometheus and Adhoc Party.

The Core Problem (y u not give me more ram?!)

The most problematic part about Prometheus and its code is the following…

The Sony Adhoc Library has a ~ estimated ~ RAM footprint of about 400KB… this is the ammount of RAM the library NEEDS to function… while the Sony Infrastructure Library (the one for Internet Access) requires about 750~800KB to function…

As we want to get Adhoc running over the Internet and thus need the Infrastructure Library, we already have a RAM negative of about 350~400KB here… RAM that we need… but don’t have… as the game modules eat the remaining user memory for internal use…

So its clear what we need… more RAM… afterall we will not only need the Infrastructure Libraries working, but our own Adhoc Emulator Libraries too… (which weight in at about 600KB aswell… 200KB if we remove pspnet_miniupnc.prx, which is a optional component).

This is the reason why only 2g+ units are supported, however that isn’t the whole story to it…

The Origin of the 2g+ Extra Memory

By now pretty much every scener knows that 2g+ PSP models feature a extra 32MB RAM bench on its mainboard, and that we, the hackers, made it available for cool homebrew use…

But how exactly does this work? And where do we steal it from? Afterall it has to be in use somewhere right? Right.

This part is tricky to explain so concentrate and try to follow me here!

PSP is split into runlevels… the foul tongue calls them “modes” – you probably heard of those…

• GAME Mode
• VSH Mode
• POPS Mode
• APP Mode

Each of those runlevels has a module list, and a set of runlevel settings, which it uses to setup the RAM partitions (offset, size, read / write permissions, etc.) and the required modules to make the runlevel operate the way it should.

Basically… runlevels are used to make sure only the components we REALLY need are loaded, its a way of saving RAM by leaving out unneccesary modules.

A good example is that usb.prx isn’t loaded in the POPS (Playstation 1 Emulator) runlevel, as the emulator doesn’t require USB access.

The thing to keep in mind here is that depending on what runlevel is executed, the available 64MB RAM are divided differently, based on the runlevel settings.

Interesting for our cause is the GAME Runlevel, and its UMD Cache RAM Partition (Partition #9), which is used by OFW to buffer UMD disc contents to reduce loading times.

The foul Deed – aka. Reassigning Memory Blocks

A basic thing everyone should know about RAM is that there is a difference between physical and virtual addresses…

The physical address, if we simplify the whole picture here, can be seen as the real position of a memory block inside your computer, while a virtual address is used by applications to address physical addresses…

Basically its like a table that has the virtual addresses on one side, and the matching physical ones on the other, allowing applications to find the RAM cell in which its data should be stored to or read from.

Every row in this table… is called a memory partition on PSP. It contains data on how to link virtual and physical addresses and is managed by sysmem.prx on your system.

So when we “unlock” the extra 32MB memory on your PSP we do the following…

1. Unload the UMD-Cache PRX module from RAM, as it would malfunction if we steal RAM from its memory partition (P9).
2. Patch sysmem.prx to remove the P9 virtual to physical mapping.
3. Patch sysmem.prx some more to add the extra physical memory to P2 – the user memory partition.
4. Remove the physical memory block read / write security checks by patching the hardware registers.

Doing so results in Partition #2 (P2) to increase in size… as we linked in a whole bunch of new physical RAM cells, thus… we now have enough RAM available to feed not only the game itself, but also the Infrastructure Library aswell as our Adhoc Emulator. Sweet!

Broken Homescreen? What?!

This one is in fact very embarassing to explain as its our (Team PROs) fault… our high memory unlock code has a critical flaw… a bug if you want.

So lets roll this one up backwards, starting at the problem…

What happens? – When high memory is unlocked… it’s impossible to return to the VSH via the homescreen. Pressing Exit Game will freeze the system and require you to shut it down via the power switch. That is all that happens.

Why does it happen? – Our high memory unlock code sets a flag in the reboot buffer range, storing the “next reboot memory layout”… due to a fault in our code however, this layout data is ignored and instead interpreted as a 55MB high memory layout…

When exiting to VSH, your game system will – technically – reboot to a new runlevel, apply this faulty configuration of ours and in turn crash the VSH with the unexpected RAM layout.

This is why you can’t use the homescreen properly when high memory is activated.

Can it be fixed? – Yes, it’s just a bug like any other in PROCFW. I’m working on it.

Xlink KAI & Adhoc Party VERSUS PRometheus

People have been wondering where the differences are and to be honest I didn’t expect I would have to point them out as I thought they would be rather obvious, but here we go anyway so people have a way of easily comparing them.

Adhoc Party

+ officially supported by SCEI (Sony)
+ highest game compatiblity due to 100% emulated adhoc interface
+ supports Playstation Vita PSP emulator

– requires a PS3 (costy…)
– requires PS3 to be ethernet wired to free up the wlan interface for the adhoc interface
– requires PSP player to be close to PS3 all the time (might aswell just play a PS3 game…)

Xlink Kai

+ supports Playstation Vita PSP emulator
+ supports other consoles like Xbox, PS2, etc.

– requires a Xlink Kai compatible wlan adapter (25+ bucks)
– captures data via pcap + interface polling (this can be deadly for PTP based psp games)
– requires voodoo tricks to switch PSP adhoc networks (known as SSID switching to Xlink Kai players)
– requires PSP player to be close to PC all the time (might aswell just play a PC game…)

Prometheus

+ designed with PSP gaming in mind thus optimized for PSP
+ fully replaces the Adhoc Library with internet optimized implementation of the Adhoc Protocol
+ works standalone (no wlan dongle required, no ps3 or pc required)
+ provides a built-in minimalistic chat system to be fully PC independant if required
+ allows for real-time player monitoring on www.prometheus.uk.to

– still in beta stage so not all games work properly (or at all, but can this be seen as a minus point considering xlink kai doesn’t support all games either?)
– hacked PSP with PROCFW required (this might be a minus point for TN or ME users, however if neur0n or TN ever wanted to support Prometheus I would be more than willing to help)

Overall this comparison could be summed up in a single sentence…

Adhoc Party is SCEI’s baby, so of course it has the best game compatiblity out so far, while Xlink Kai isn’t specifically aimed at PSP users and Prometheus is.

I hope that I was able to properly address and destroy those fears some newcomers had about Prometheus.

~ Coldbird

Update by Wololo: With Sony announcing yesterday that they are closing the SOCOM servers for PSP, prometheus is showing even more the point: when Sony wants to discontinue their console, the only support we can hope from the PSP will be from the underground community!