Hacking Homebrew Custom Hiyoko NSP Creator

[DarkAkuma]

This project has been discontinued, as it has been merged into CaVE Database Manager. Please now go to that thread and use that for custom Hiyoko NSP creation.

 

[hippy dave]

Great work!

 

[rantex92]

nice!!!

 

[Reshiban]

Thank you

 

[Imancol]

The emulator is using the main CPU(CPU0), used in the whole system, the other cores are left unused (CPU1,CPU2). This causes some slowdown in the system due to its high consumption.

If there was a way to move the load to another Core, the console would appreciate it.

 

[ThePanda]

Thanks!

 

[DarkAkuma]

I added a list of command line arguments I dumped from the emu, to the OP.

Not everything is useful, and nothing had context. I provided what little I could myself.

Machine Type may seem a bit unexpected and hopeful, with sgb (Super Gameboy) and agb (Gameboy Advance). But that seems to not mean Super Gameboy and Gameboy Advance games are supported. Its still limited to GB/GBC games. Think of it as meaning "You are emulating a GB/GBC game on Gameboy Advance hardware".

The default Gameboy Pocket color settings I provided could probably be made more accurate. More black and white, less green/yellow.

Super Gameboy doesnt seem to use the special palletes of official Super Gameboy games like Donkey Kong (probably not borders either).

There's a lot of options that have "file" or "filename" as a parameter. These don't work because you can't make a valid path. I'm not an expert on this, but my conclusion is that dev hardware allows differences in where and how it writes files. I think it does it to the romfs (rom:/) dir, which is of course not supported on retail hardware.

I have tried sd:/, cwd:/, save:/, temp:/ prefixing a dummy file name with various save options, and it just causes a crash on boot. Those are all the other drive labels I can think of/find. For all I know, using "--save-on-quit=save:/test.sav" is effectively processed as "--save-on-quit=rom:/save:/test.sav". Meaning the emu is supposed to handle the drive, and it expects just the file name like "--save-on-quit=test.sav". But that didn't work for me either.

I'm mentioning all this so people understand and don't have their expectations high. And, maybe with the proper information someone else can figure things out.

 

[masagrator]

The emulator is using the main CPU(CPU0), used in the whole system

OS is using only Core #3.
It's easy to check with Status Monitor.

 

[Imancol]

OS is using only Core #3.
It's easy to check with Status Monitor.

Which Core does homebrew use?

 

[masagrator]

Which Core does homebrew use?

Homebrew and games have access to cores #0-#2 by default. You can force access to #0-#3 by editing nacp.

 

[Imancol]

Homebrew and games have access to cores #0-#2 by default. You can force access to #0-#3 by editing nacp.

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)



If you can get this emulator to use CPU#3 it would greatly improve Homebrew loading

 

[Reshiban]

Hi everyone
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)


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


EDIT: The problem seem to be the SDK in ExeFS part

 

[DarkAkuma]

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)

There are 4 games in the leak, among the 15 folders.

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)

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.

In fact, by chance that was the version I ended up using for most of my testing I think. It works with GB and GBC games.

As for the other versions of the emu, are you certain you have set the correct machine type? Well, if you are in this thread, I will assume you are using my package, so yes? Else if you are manually messing with things, you have to ensure -mtcgb is set in the default_cmd.txt.

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'm not sure what 3 "advanced versions you are talking about. The 3 2.7MB mains? I haven't tried them yet. I mostly worked with the above Zelda 0005, 0011, and 001b binaries when testing.

The rest... Im not sure I follow. But yea. Now that I know about the 3 larger binaries, ill look at them.

EDIT:

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".

EDIT2:

Upon looking further, it looks to be the difference of compiling in Debug mode rather than release mode. The larger files contain more debug code and text. Even a few debug specific command line arguments. Its very likely that these 3 binaries don't work, specifically because they require debug environments. Like, they cant output debug information to retail hardware, but need to. And thus results in crashing.

 

[Reshiban]

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.

Bruh yes I missed this one, he works fine thanks

EDIT:

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".

Yes the 2.7MB ExeFS has some debug things. I though it was significatly advanced due to their multiple functions, but that's maybe just a debug build without more yes.

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

 

[masagrator]

If you can get this emulator to use CPU#3 it would greatly improve Homebrew loading

? Choking system core would not improve anything.

 

[FinnaGun]

thx a lot

 

[ZachyCatGames]

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.

 

[DarkAkuma]

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 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.

 

[ZachyCatGames]

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.

 

[DarkAkuma]

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.

It's the more common thing thats corrupt. But in some titles, another thing is corrupt too. For example, in 01004b9000490003_000012c30000_Program.nca the "sdk" file is corrupt in addition to the "subsdk0" file.

I haven't thoroughly examined all the files of all the titles. I have just gone through as far as focusing on the subsdk0's as those are what happens to be corrupt with the debug versions. I can probably compile a better list of whats corrupt and what isn't if needed.

I'll take anything that gives a chance at making it boot. The dev version is clearly different, and offers more features. For one, it looks to have IMGUI options like Sloop. Probably not the same exact interface, but something. There is even a --ask argument that I suspect may allow the inclusion of more than 1 ROM with each game, and a menu selection among them. Rather than 1 game per title.

EDIT:

Corrupt files:

• 01004b9000490000_000017234000_Program.nca: subsdk0
• 01004b9000490001_0000070ac000_Program.nca: subsdk0
• 01004b9000490003_000012c30000_Program.nca: sdk
• 01004b9000490003_000012c30000_Program.nca: subsdk0
• 01004b9000490003_000008470000_Program.nca: subsdk0
• 01004b9000490004_00000356c000_Program.nca: subsdk0
• 01004b9000490005_000005cf0000_Program.nca: subsdk0
• 01004b9000490006_000013fec000_Program.nca: The nca itself seems bad.
• 01004b9000490006_000004930000_Program.nca: subsdk0
• 01004b9000490014_0000153a0000_Program.nca: subsdk0

The things shown in orange in the OP do not have corrupt files, but instead something else that makes them not boot.

EDIT2:

The corruption of the subsdk0's in the following two pairs are the same, fyi. As in, they are the same exact data.
for 0015 that can make sense, as its the same game probably recompiled with a fix. But for 0003 and 0004... not so much. They are different games, with different testing goals (Touch controls vs. normal controls).

• 01004b9000490003_000008470000_Program.nca: subsdk0
• 01004b9000490004_00000356c000_Program.nca: subsdk0

&

• 01004b9000490015_000006d44000_Program.nca: subsdk0
• 01004b9000490015_0000094b8000_Program.nca: subsdk0

For 0002, there appears to be a string sanitization/localization error in the control.nacp. At a glance it would seem like corrupt data, but my experience finds it consistent with not converting the string format between Unicode/UTF-8 and such. But such a issue could certainly be the cause for a failure to work.

Im not sure what the issue is with the first 0013 not booting, or what the issue is with the first 0006 nca not reading correctly.