Remove Corrupt PrxEncrypter from Tools about pspsdk HOT 6 OPEN

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.

from pspsdk.

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

from pspsdk.

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?

from pspsdk.

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/

from pspsdk.

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

from pspsdk.

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

from pspsdk.