Ok, so that's where I get slowdowns when using Homebrew and CPU#0 is close to 100%. SM3DAS SM64 uses CPU#1 unlike NSO, (SM3DAS Pause menu uses others)Homebrew and games have access to cores #0-#2 by default. You can force access to #0-#3 by editing nacp.
There are many versions of the Hiyoko emulator.
Many of their ExeFS are 360KB, but three of them are like 2.7MB (example 01004b9000490015)
(one of these 2.7MB is the only version with a GBC rom included, all others only include GB rom and crashes on my side with GBC roms)
01004b9000490000 = Zelda DX (2.7MB main)
01004b9000490001 = Super Mario Land
01004b9000490002 = Super Mario Land (Touch Input v0)
01004b9000490003 = Super Mario Land (Touch Input v2)
01004b9000490004 = Tetris
01004b9000490005 = Tetris (Touch Input v0) & Zelda DX
01004b9000490006 = Tetris (Touch Input v1)
01004b9000490011 = Super Mario Land
01004b9000490012 = Super Mario Land (Touch Input v0)
01004b9000490013 = Super Mario Land (Touch Input v1)
01004b9000490014 = Super Mario Land (Touch Input v2)
01004b9000490015 = Qix (Touch Input v1) (2.7MB main x2)
01004b9000490019 = Tetris
01004b900049001b = Tetris (Touch Input v1)
01004b900049001c = Tetris (Touch Input v2)
The problem is that some .nca doesn't boot (Yuzu + real hardware), and all the 3 "advanced" versions of the emu are affected by the problem.
I try to check and fix the ExeFS header with switchbrew docs and HxD, but I'm not sure we can do anything...
Does anyone know how a NSO header works and if that's the problem here ?
It would be very helpful to restore an advanced emu
I hadden't looked at the sizes. I guess I will to see what extra data there is in the 2.7MB bins. But I believe you missed the 01004b9000490005_0000322e4000_Program.nca. That contains Zelda DX too. A GBC game.
Actually... at a glance, those are different in that they contain debug strings. Which is good for poking around, but doesn't mean they are "more advanced".
It's corrupt. All of these were deleted shit recovered from a dev unit's USER partition using a bruteforce NCA header scanner that performs no validity checks (besides basic checks on the content type, keygen, etc to make sure it's not garbage that happens to decrypt to "NCAx" magic).The broken part seem their sdksub0, it looks like ciphered...
Idk if there is anything to recover/replace it, it could be cool to play with debug options
It's corrupt. All of these were deleted shit recovered from a dev unit's USER partition using a bruteforce NCA header scanner that performs no validity checks (besides basic checks on the content type, keygen, etc to make sure it's not garbage that happens to decrypt to "NCAx" magic).
Since it was deleted content some titles were completely or partially overwritten with other shit.
If main is intact you can probably pull the sdk/subsdkx/rtld NSOs from some other one, iirc most/all of these used the same sdk version and libs.
I see. Hm, if subsdk0 is the only corrupt thing in all of them I'll have to go back and manually check to make sure the scanner didn't fuck up anything, because that feels off.I have been trying to do just that the past few days, with no luck. It's odd that what just so happens to be corrupt is just the subsdk0 in all 3 debug titles. Well, the subsdk0 is the main/only thing corrupt in more than just those three. Everything thats list in RED in the OP.
But swapping in the good subsdk0's from others does not allow it to boot. Those lack some data thats needed, and fail when trying to call some code from the non-debug subsdk0. Either due to it not existing, or not being in the same spot.
It's possible that a hack can be done to make it work, as I have been trying. But im afraid the effort will ultimately prove to be too much of a task. Just fixing or bypassing one issue, only for things to halt at the next issue.
But Im not giving up yet. Im still exploring some ideas.
I see. Hm, if subsdk0 is the only corrupt thing in all of them I'll have to go back and manually check to make sure the scanner didn't fuck up anything, because that feels off.
Otherwise if it'd help I can probably grab the Develop version of the lib used as subsdk0 (glslc I think?) for 6.4.0 or w/e.