Starting in 20.0.0, the browser needs more applet memory to function, so we can't steal as much any more.
Thus, we now steal 14 MB on 20.0.0+ instead of 40MB.
However, since this reduces memory available for custom system modules, we are adjusting to compensate.
ams.mitm's heap size has been reduced from 32MB to 12MB (recovering 20MB).
In addition, fs.mitm now uses a new mechanism for stealing memory from the applet pool while romfs is being built.
On net, we are compromising:
* Custom sysmodules lose memory available to them.
On 19.0.0/AMS 1.8.0, there was 30 MB available for custom sysmodules.
Stealing 14 MB instead of 40 MB, we lose 26 MB of that. Reducing ams.mitm's usage will gain us back 20.
Nintendo also appears to...use 4 extra MB, in 20.0.0, from my test homebrew.
So on 20.0.0/AMS 1.9.0, there should be 20 MB available for custom sysmodules.
On the bright side, on <20.0.0/AMS 1.9.0, I guess there will be 50 MB available for custom sysmodules now?
* totk mods will lose the ability to...put every file in the romfs on sd card. There will be some unknown maximum filecount for totk mods.
On the bright side, implementing the transient memory stealing should improve compatibility for some mods which strictly add files?
* dmnt_extension
* update type 8 extension
* clearify that bit 27 does not correspond to a button
* update cheat.md with new code type 0xC4
* implement code type 0xC4
* Add type 1 extension
* remove C0Tcr6Ma aaaaaaaa VVVVVVVV (VVVVVVVV)
* Type 9 extension for floating point math
* updated according to review
This change was made for #2255, but the issue creator never confirmed if it resolved the issue.
This *does* better reflect what Nintendo's pm does, though, so I'm going to commit it regardless.
Static save files do not require an entry in the save data indexer to mount.
Prior to 17.0.0, save data files were considered static if userid was 0.
In 17.0.0+, only 8000000000000000 is static.
However, some users using cfw do not have an entry for 8000000000000120 in the indexer,
for various reasons (but mostly manual nand-restore, I think). Thus, on boot of 17.0.0+,
FS will say 8000000000000120 is not present (not in indexer), and NCM will create it anew.
The 8000000000000120 save will then be empty, and then the firmware can't boot.
To workaround this, logic has been re-enabled on 17.0.0+ for building the content meta database.
Thus, if the user encounters this error, the 8000000000000120 save will be emptied, but then
it will be automatically reconstructed, fixing the problem.
* fs.mitm: skeleton the use of special allocation in romfs build
* pm: add api for ams.mitm to steal application memory
* pm/mitm: okay, that api won't work, try a different one
* romfs: revert memory usage increases; we'll handle torture games case-by-case.
* pm/romfs: first (broken?) pass at dynamic heap.
I cannot wait to figure out all the ways this is wrong.
* Release the dynamic heap a little more eagerly
* romfs: animal crossing is also not a nice game
* romfs: fix issues in close-during-build
* romfs: zelda is a blight upon this earth
* ams_mitm: add ability to mirror bluetooth device pairing database to sd card via a system setting
* ams_mitm: address requested stylistic changes
* ams_mitm: make use of R_SUCCEED macro
* ams_mitm: use settings::BluetoothDevicesSettings instead of libnx type
* ams_mitm: fix logic error when truncating pairing database on read
* Update .ini comment
* ams_mitm: missing R_TRY around call to fs::FlushFile
* stratosphere: remove union from BluetoothDevicesSettings type
---------
Co-authored-by: ndeadly <24677491+ndeadly@users.noreply.github.com>
