Hacking The One Missing Piece

  • Thread starter Thread starter m-cid
  • Start date Start date
  • Views Views 56
  • Replies Replies 0
  • Likes Likes 1

m-cid

New Member
Newbie
Joined
Dec 2, 2020
Messages
1
Reaction score
1
Trophies
0
XP
70
Country
France
Hello! I'm My Custom IDentity, a PSP homebrewer.

I like this console because it sits right in the middle of things: a great balance between hardware quality, portability, the richness of its catalog and its capabilities, the innovations Sony pushed into it, and all the hype around the hacking scene and the enthusiasm developers had, and that many still have today, for this little marvel.

Let me thank the pioneers, as well as those who built and continue to maintain the open source PSPSDK, those behind the psp.jim.sh documentation, and the more recent ones that have since seen the light of day. A special thanks as well to Pierrelouys for their enormous work in preserving, archiving, and recovering PSP source code, documentation, tools, homebrew games, plugins, and other materials that might otherwise have been lost. In short, thanks to those who keep the scene alive, to those who just arrived, and to those who will make it thrive.



It revives, this is what is happening to the scene, even if actually, it never died. Some people always kept making things for the PSP, they even created different communities to ease the exchange and improve things. It's amazing how such small devices can bring people together, a shared interest, intentions all pointing in the same direction.

There is so much going on and that has recently been done. The incredible work and contribution around the ARK project, the recent transition to ARK5, the work on N64 game ports (such as OOT, SM64, Perfect Dark, StarFox), on exFat, the Zig SDK and not to forget, the Rust SDK. We can find recent revelations around the execution of custom ARM9 payloads on the WLAN chip, as well as a new PSP emulator project Kanastation which looks very promising. The improvement of TempGBA4PSP, or DaedalusX64 which is still in progress. The ongoing projects around the Media Engine and the VME, which we will talk about further on. Other recent projects include Battery Steve, wavezbg or 2Tuff.wav. There are in fact many devs with new ideas and projects. Many who, working in the shadow of this little machine, contribute to keeping the scene alive.



Virtual Mobile Engine​


Now comes the time to enter into the technical side of the Virtual Mobile Engine. "no one has been able to interpret its firmware yet" is a sentence left on the psdevwiki, and it caught my attention. A mystery to solve, something that seemed a little lost somewhere at the bottom of this ocean of information where so much work was surfacing, while the VME stayed down there, like a creature lurking in an abyssal trench. The one missing piece.

Today I am able to tell you more about it. The VME is a Coarse Grained Reconfigurable Architecture, a hardware accelerator specifically made to handle audio and multimedia signal processing. It can switch between contexts in one cycle, which means it can actually change its behavior, updating its datapath in one single cycle. Its input and output scratchpad has a 24 bit data width, the 24 bit word is actually packed into 32 bits and the upper 8 bits are sign-extended from bit 23.

From my experiments, the VME has 4 Processing Elements. Each Processing Element is composed of two Functional Units, a primary and a secondary. Each FU has two dedicated configuration registers, which can act as masks or constants for example. The FUs are composed of two MUXes, a computation unit, a saturator and a shifter. The primary FU operates in ALU, Logic, MUL, MAC, VMAC, Rotation and Clamping modes, among others. The secondary FU appears to lack MUL and MAC capabilities. Each PE of the VME also has 3 AGUs, two READs and one WRITE, enabling operations such as input data addressing, word reversing, pre-FFT butterfly reordering, as well as output data restructuring, and other things. The FUs accumulators are 64 bits, which gives us a very comfortable headroom to avoid overflow.

All of this happens over the context memory, which can be loaded via DMAC or through the dedicated MMIO hardware registers. The context memory has an area for the interconnect, which allows us to rewire the datapath, controlling how data flows between PEs, FUs and AGUs.



Well, this is what I got after digging into this hardware, by feeding it as well as the related hardware registers with data and values, sometimes somewhat random ones, then observing and understanding its feedback. This was done and continues to be done on physical hardware, in order to get direct feedback on its actual behavior. This, combined with reverse engineering of part of the host MIPS CPU kernel. I have started writing examples of how to use it and how to take advantage of it in homebrews. Now, it is time for the scene to become more aware of it, and to see future homebrews integrate it. Some game ports have already started doing so, which is a very good start, and I believe others will follow.



Thanks for reading, and here is the link to the repo hosting the sample codes:
psp-virtual-mobile-engine-ext

I hope you will find interest in this and that some of you, if it is not already the case, will join or rejoin the PSP scene, maybe as a pioneer, or as a newcomer who may someday come and share, whether by telling us about an experiment, a story, or simply a hello, I'm <Your Custom IDentity>, a PSP homebrewer...
 
  • Love
Reactions: xhai

Site & Scene News

Popular threads in this forum