Remove Corrupt PrxEncrypter from Tools

[TheMindVirus]

PrxEncrypter is breaking the pspsdk build. It needs to be removed immediately. This can be done by moving the folder out of tools and editing pspsdk/tools/Makefile.am to comment out the line like this: #SUBDIRS = PrxEncrypter The pack-pbp command (should ideally be called elf2pbp) will then build with a few minor warnings about fread(). The reason for this is that Stackless Python is missing or has obfuscated/obstructed bindings to libgu for the graphics core. Just breaking the C++ toolchain to favour Python is not the answer, both are required.

[sharkwouter]

Hey @TheMindVirus, thanks for the report. What exactly is broken within the toolchain? We are not the ones maintaining stackless python and the toolchain is building fine in our CI.

PrxEncrypter allows people to build software which can run on official firmware, which is not a feature we want to just disable.

[TheMindVirus]

That's ok, I'm not suggesting to remove it completely, only to remove it from the compulsory part of the manual build process. Some of the instructions in the docs have got a bit mangled and point to files that don't exist or are now created only after running certain other commands in a different sequence.

In my edge-case, the PrxEncrypter being part of the build process resulted in an error that made it look like it was building fine but actually ended up stopping compilation of the PBP archiving tools. Adding this as an issue should be enough to hint to builders facing this same issue.

As for the Stackless Python part, that was a test app to compare against the pspsdk (and possibly also built using parts of it). I used it to develop a custom version of the elf2pbp tool, similar to elf2uf2 for Raspberry Pi Pico and Bootloaders for Pi4 etc... This was the result of that development: https://github.com/TheMindVirus/PiX-iES/tree/pspdev-nw

[artart78]

PrxEncryptor is an essential tool for many people and there's no reason to remove it, it is built the same way as the rest.

What is your error when you compile it exactly?

[sharkwouter]

As a workaround, until we figure out what problem you are running into when building, we have a pre-build toolchain available for download which should contain everything you need: https://github.com/pspdev/pspdev/releases/tag/latest

I wrote some documentation which you can find at https://pspdev.github.io/

[TheMindVirus]

Thanks for this. I've written a custom GNU Makefile that writes to the framebuffer without using cmake that makes EBOOT.PBP only around 668 bytes.

However, it seems the PSP requires the sceDisplaySetMode and sceDisplaySetFrameBuf (etc...) set of syscalls for the framebuffer to be displayed.

The major drawback with this approach so far has been none of the syscalls actually get written into the output.

When they are selectively introduced with defines, their actual assembly implementation is incredibly long-winded instead of 3-4 instructions.

This can be overcome by writing the assembly by hand, but the emulator doesn't seem to respond in the expected way. Using actual hardware would be bad.

I will give the linked cmake examples a try and see how many syscalls get included. There seems to be a standard set of around 100 that are in each game. Updates:

• Hello World seems to be working after a little coaxing, with ~372 syscalls.
• A new CMakeLists.txt makes the 3D cube demo work: https://github.com/TheMindVirus/PiX-iES/tree/pspdev/gu/cube
• So this called for a new development branch: https://github.com/TheMindVirus/PiX-iES/tree/pspdev

[sharkwouter]

@TheMindVirus can this be closed or is there something we can do here?