_init might require working pthreads, due to C++ constructors using
mutexes and threads. Since libc does not require _init execution, we
simply reorder them.
This removes support for kernel-mode _init on user programs that run in
kernel mode (mostly old FW 1.5, but should not affect almost any
homebrew out there, since they don't use user-mode main thread).
fix for PR
renamed logo folder to image_display, renamed logo to image in source, changed image used, removed FW version from makefile, added header to source, added image_display to all samples makefile
Not sure where this originated. Possibly a leftover from old SDK
versions since the uint type appears in some archaic homebrew as well.
This was the only reference of `uint` in the entire SDK. Went ahead and
changed this appropriately to `u32`.
Daily was too often and this will be rebuild weekly with the changes to psptoolchain-allegrex anyway, because of the cascading effect build into the repos.
Fixes#123. Guards `_PSP_FW_VERSION` references with `#if defined()` to avoid the SDK headers returning warnings when compiling modules with the `-Wundef` cflag.
`MEMSIZE` would not be set as expected if `PSP_FW_VERSION` was set to `1` above firmware 3.90 and the warning was sent to the console. This is addressed.
I've also made the `MEMSIZE` field a make var (`EXPAND_MEMORY`) that gets set on/off in the tree and just gets used by `SFO` flags at the end of it, instead of setting them in multiple spaces.
Prompted by #46, I have taken the time looking at `pspnet_adhocctl.prx`
in older firmware versions via Ghidra (thanks @sajattack) and some
early Adhoc-capable titles like Ridge Racer and Hot Shot's Golf, I
have concluded that the order of elements in the `SceNetAdhocctlParams`
struct to have always been `nickname`, followed by `bssid`. Not changed
in any later firmware revision. This commit resolves this discrepancy.
The current state of building .SFO binaries is rather primitive --
as it stood, build.mak forced its own flags to be used, always.
If you were building without PSP_LARGE_MEMORY, build.mak would use
a deprecated tool for generation as well, one that cobbles together
undocumented flags in an array of bytes and shoves it into a file.
The first change this commit makes is by enabling use of the "new"
mkfsoex, which creates a smaller but still bootable SFO without
any arguments given. Developers are now able to provide custom
SFO flags now using this, added via `SFOFLAGS` in their Makefile.
This means that developers can now (at their own discretion) provide
custom region information, parental control level, minimum firmware
boot level, etc. with:
```make
SFOFLAGS = -d REGION=16394 -d PARENTAL_LEVEL=4 -s PSP_SYSTEM_VER=4.01
```
As a side-effect, this also makes the SDK more adapted to new
custom firmware releases that may add new SFO flags.
The second change made is turning `PSP_LARGE_MEMORY` into an opt-out
/enabled by default flag if developers are targeting a firmware
version newer than 3.90. Custom firmware versions starting from
4.01 M33 guard against expanding the user memory partition to 52mB
if the unit detected is PSP-1000. Therefore having this check in
place becomes redundant, potentially complicating Makefiles. A
warning is printed out allowing developers to be aware of this fact
and removing the flag from their Makefile.
Updated fourth argument of decompression routines.
When not NULL, the routines will store a pointer to the next unprocessed compressed byte (src + n_compressed_bytes_processed).
This can be useful to implement stream-based decompression, calculating number of processed compressed bytes, etc.
