Hacking USB Loader GX

[Cyan]

I knew you had a list!
You are probably the only user who reported games not compatible with proper 16:9.
You play too much !


I see you are linking WiiXplorer uStealth mod in your signature.
Is it working?
I did that mod but didn't test it. I had a report that it didn't work.
Maybe you are not using my mod but another one. if yuo have a working one I'll add it to ustealth first post.

 

[OriginalHamster]

I knew you had a list!
You are probably the only user who reported games not compatible with proper 16:9.
You play too much !

I see you are linking WiiXplorer uStealth mod in your signature.
Is it working?
I did that mod but didn't test it. I had a report that it didn't work.
Maybe you are not using my mod but another one. if yuo have a working one I'll add it to ustealth first post.

Yeah it's your mod, it's working, not sure if the download link is dead though

 

[VinsCool]

So am I the only one with OriginalHamster having latest USB loader GX, latest Nintendont, working fine through autoboot, HID Gamecube adapter and USB Hard Drive?
This issue for some people and some not having it is really strange.

 

[Cyan]

The issue with HID+autoboot is also random?

I'll see tomorrow what changed in nintendont which could affect HID+autoboot setting in USBGX.
Most issues appeared when users wanted to use multiHDD at the same time.

Everything worked fine when they had ONE drive, and they needed to disconnect port0 to switch drive, disconnect WiiU HDD every time etc.
When they started to want to keep WiiU HDD always connected to use nintendont on port1, using multi port, switching IOS, etc. that's when every issues emerged.
Why can't you just connect ONE single HDD when you are on vWii?
just disconnect other drives, use port0 for vWii, use cIOS like before instead of IOS58, and everything should work again.

though, on the hdd test thread, it's also contradictory. Using one HDD like before is not helping. reverting back to old revision which used to work is not helping either...
so, if it's not the loader's fault, not the hdd fault, not IOS fault... it could be the console's fault. Users with issues all have latest version of WiiU?
are there any users with latest WiiU version and no vWii issue?

 

[shoemaker]

The issue with HID+autoboot is also random?

I'll see tomorrow what changed in nintendont which could affect HID+autoboot setting in USBGX.
Most issues appeared when users wanted to use multiHDD at the same time.

Everything worked fine when they had ONE drive, and they needed to disconnect port0 to switch drive, disconnect WiiU HDD every time etc.
When they started to want to keep WiiU HDD always connected to use nintendont on port1, using multi port, switching IOS, etc. that's when every issues emerged.
Why can't you just connect ONE single HDD when you are on vWii?
just disconnect other drives, use port0 for vWii, use cIOS like before instead of IOS58, and everything should work again.

though, on the hdd test thread, it's also contradictory. Using one HDD like before is not helping. reverting back to old revision which used to work is not helping either...

Multiple drives are not the issue. The crash occurs, at least on my end, with any HID controller connected to a port on the back and Autoboot. That means even with zero drives connected, it crashes.

 

[VinsCool]

Multiple drives are not the issue. The crash occurs, at least on my end, with any HID controller connected to a port on the back and Autoboot. That means even with zero drives connected, it crashes.

I use front ports for HID and I have no issues though.

 

[Cyan]

I suppose users reported the issue on nintendont thread (I didn't read that thread this past 2 weeks).
I'll have to catch up with latest revisions and see what Fix94 is saying about that.
I don't see why loaders will affect autoboot or hid after a new nintendont revision, the loader is only loading the homebrew with arguments like before.
I can try to launch the loader with writing the nincfg.bin file instead of using arguments.

Nobody reported if they tried to switch the nincfg.bin option in USBLoaderGX global settings.
It shouldn't change the way nintendont is launched, but recently logic is weird.



Edit:
I just read r304 and see "HID is always enabled, whatever the setting from the loaders".
The issue with both autoboot+HID connected started on 303 or 304?
I suppose setting it to ON or OFF in the loader doesn't affect the compatibility in nintendont?

edit:
I see it had been incremented to v3.0
3.304

I'll have a lot to catch up.

 

[VinsCool]

I suppose users reported the issue on nintendont thread (I didn't read that thread this past 2 weeks).
I'll have to catch up with latest revisions and see what Fix94 is saying about that.
I don't see why loaders will affect autoboot or hid after a new nintendont revision, the loader is only loading the homebrew with arguments like before.
I can try to launch the loader with writing the nincfg.bin file instead of using arguments.

Nobody reported if they tried to switch the nincfg.bin option in USBLoaderGX global settings.
It shouldn't change the way nintendont is launched, but recently logic is weird.

Mine is set to "delete ncfg.bin everytime", so argboot indeed works

 

[shoemaker]

I suppose users reported the issue on nintendont thread (I didn't read that thread this past 2 weeks).
I'll have to catch up with latest revisions and see what Fix94 is saying about that.
I don't see why loaders will affect autoboot or hid after a new nintendont revision, the loader is only loading the homebrew with arguments like before.
I can try to launch the loader with writing the nincfg.bin file instead of using arguments.

Nobody reported if they tried to switch the nincfg.bin option in USBLoaderGX global settings.
It shouldn't change the way nintendont is launched, but recently logic is weird.



Edit:
I just read r304 and see "HID is always enabled, whatever the setting from the loaders".
The issue with both autoboot+HID connected started on 303 or 304?
I suppose setting it to ON or OFF in the loader doesn't affect the compatibility in nintendont?

edit:
I see it had been incremented to v3.0
3.304

I'll have a lot to catch up.

Correct, the issue arose in v3.304, which had the new HID controller initialization.

 

[bobmcjr]

For me, with USBLGX R1241 and the latest Nintendont, autoboot works with some games, but others just go to a black screen and return to the Wii menu. For example, Sonic Adventure 2 autoboots, but Sonic DX doesn't. This is on a Wii U using USB port0 with a Wiimote+Nunchuck, with the gx and nintendont dol's running from the sdcard. A handful of other games booted, but most didn't.

 

[tswntk]

all the loader does is pass arguments to Nintendont.
Problems arise after the HID setting was changed so I suggested the setting was removed and conflicts with the arguments but was proven wrong.
It makes no sense to me why other changes in Nintendont would conflict with argument passing and everyone said thats a ULGX's problem.

Edit:
from the code page, it is also the time Nintendont was updated internally to V3, could that confused ULGX that it belongs to an ancient config version?

Why DM(L) and devo versions can be detected reliably while Ninetdont still can't be detected reliably?

Edit 2:
Nintendont have made big advancement in compatibility, may be its time to forget about older config versions?

 

[sideskroll]

Sideskroll:
I'll try to answer everything, but most options are specific and you might not know what they are used for, that's why you think things are not working correctly, or not expectedly.

Cyan, I REALLY appreciate the time and dedication you put into your replies.
Thank you for that.

First, about the Channel name.

Spoiler

internal Channel's names are read at loader's launch. To access the NAND you need AHB access.
when launching from the forwarder, it's using IOS58+AHB which grants NAND access to the loader.
The loader then read the channel's list and titles, then reload to cIOS if requested by the user.

If you launch from HBC, AHB is not always granted.
It depends on your Meta.xml, it must contains <ahb_access/> tag to get NAND access at launch.
If you don't have it, the loader can't read the channels names, so they are either undefined, or listed based on their TitleID ("UNEO" or the ASCII number).

It should read the channel title correctly if you set your meta.xml correctly.

The metal.xml file I have is the one that came with USBLOADER GX. Was I supposed to edit it manually?

About video now:

Spoiler

On Wii, there's no "real" 16:9.


All games and application running in Wii mode are using a stretched picture.
To looks like the game is widescreen, the game is squeezing the picture (compressing, and losing pixel informations, details etc.) to fit more data on the picture.
Then the TV is stretching that squeezed picture to fit the full 16:9 area as if it was a real 16:9 picture. the circles looks like circle again, you see more data on the side, but you lost elements on the screen.

All wii games and gamecube games are rendered to 640*480p, 640*528, 640xHeight. everything is 640 width, even on widescreen setting. there's no more pixels rendered.
One resolution allows up to 708*480, which USBLoaderGX uses if the user has widescreen set (to enable more pixel on screen instead of fake stretched widescreen, but it's still not a real widescreen ratio).

It's hard to explain without a picture.


WiiU, on the contrary, has a real widescreen mode, with full resolution.
1920×1080, or 1280x720, or 854×480

Like you noted, games looks sharper when using 4:3, because they are rendered to their original size, the way they were designed.
There's no streched effect.
As the WiiU allows proper widescreen setting, or proper 4:3 setting by adding black borders (instead of setting the TV to output a 4:3 picture, it's done by the console, as some TV can't force 4:3 when using hdmi1080p).
So, nintendont added a setting to select if a game should use the WiiU 4:3 or 16:9 setting.

That setting is passed as argument from the loader to nintendont.
It's located in the nintendont settings section (global settings > loader settings > Gamecube > nintendont > WiiU widescreen)
This is the setting wich will affect the game's ratio when using nintendont.
If you don't enable WiiU widescreen, nintendont will always render in 4:3, it doesn't check the current video mode used by the console. It's a setting that the user choose in nintendont or in the loader.


As this setting could become useful for Wii games played on WiiU, I also added the ability to switch widescreen on/off inside the loader so the user can launch a Wii game with the video mode selected.
Wii games are not forcing the video mode, there's no setting, it's doesn't even know there is a real widescreen setting as wii never had such a setting, so it's keeping the current widescreen setting set by the user in the loader.

It's in features and not in "per game" setting because not all wii games benefit from 4:3. (resident evil, mario party)


I don't know if I made myself clear, as there are a lot of different element to take in account with video mode.
the game rendering mode is different than the console's output mode, and different than the TV mode.
You have 3 different thing to "play" with when rendering a picture. without understanding the one you are affecting it's difficult to display your picture correctly.

In addition to this 3 possibilities, Nintendont has a "widescreen patch", which fake the viewport to output even more data on screen.
It's the same setting that Wii game are using to fake the ratio setting based on the System menu video setting (the one used to squeeze and fake 16:9 by rendering more data on screen)


just remember that Wii doesn't have a real 16:9 and games looks better in 4:3, but you see less elements on screen.
you have to choose what you prefer. It could depend on the game you play too, how the ratio is affecting the sharpness etc.

USBLoaderGX is using a little more pixels in width, but it also looks better in 4:3, the fonts are nicer, as it's still not a full 16:9 but the TV is fitting the picture in full area so it's a little stretched.


One day, I'll try to make a visual representation of all I explained.

No need to. I understand everything you just said.
But I think it was ME who didn't express myself correctly. Let me try again:
Even though the AR inside the loader appears correctly, Elements like the pointer (hand) and some text are clearly stretched out. Like a "fake, FAKE 16:9"... I don't know if you get what I'm saying? Everything else appears to be correctly displayed. I find that odd to say the least to be honest. Is there something I could do to fix that? If only at my end to not give you any extra work----
Also, I just noticed some screen tearing while using my Wiiu in wiimode which I was almost certain wasn't there before.
So of course I turned to google for answers and lo and behold I found this right here in GBATEMP: Graphical issue in Wii mode
And a user in post #6 claims that apparently it's caused by USBLOADER GX.
I'm testing at the moment (trying 480p, 720p, 1080p and different loaders) to see if I can replicate or "fix" the issue.
But do you have any idea as what could be causing this? Or have you even experienced it?
That would be it so far. I managed to get everything set up OK and it's working fine so far (except for the screen tearing issue. Which I would consider a MAJOR one if it's indeed somehow caused by USBLOAR GX .
No corrupted HDD so far (knock on wood) and no issues with free space nor any DSI exceptions or freezes.
Everything is A-OK.
Again, let me know if you need more info or testing and ONCE AGAIN, I would be more than happy to help you with your implementation of neek2o if you decide to do it.
Thanks for everything.

​

 

[Cyan]

tswntk : yes, maybe I should drop old settings and allow only newer version of nintendont.
Though, I like to allow users keep their working version without forcing them to update. Some games might work better in specific revision (that's why users asked for a per-setting nintendont path).
I don't know up to which version I can remove. I guess anything below 2.0 can be removed? anything without arguments compatible maybe. If I don't find the "argsboot" string, it's too old.


sideskroll:
I think the pointer is not affected by the overscan GUI setting, if you set a non uniform scale value the pointer is probably looking stretched when rotating. I didn't find how to fix that yet.
About the fonts, It will probably require a full GUI revamp to scale and set new line size limit (text are cut and replaced with "..." on menus if text is too long). I hope to work on a new GUI after 3.1 to use all the TV screen instead of limiting the menu width to the center.


About the screen tearing issue, it happens when booting the loader using the forwarder only. From HBC this doesn't happen.
Users reported this issue when Asper converted the first Forwarder for vWii and claimed it was 5.1, while it was in fact 2.0
I released a "forwarder vWii Fix" with real 5.1 but didn't had any report about this issue.
Are you using the Fixed forwarder and still experiencing this screen tearing?

 

[sideskroll]

sideskroll:
I think the pointer is not affected by the overscan GUI setting, if you set a non uniform scale value the pointer is probably looking stretched when rotating. I didn't find how to fix that yet.
About the fonts, It will probably require a full GUI revamp to scale and set new line size limit (text are cut and replaced with "..." on menus if text is too long). I hope to work on a new GUI after 3.1 to use all the TV screen instead of limiting the menu width to the center.


About the screen tearing issue, it happens when booting the loader using the forwarder only. From HBC this doesn't happen.
Users reported this issue when Asper converted the first Forwarder for vWii and claimed it was 5.1, while it was in fact 2.0
I released a "forwarder vWii Fix" with real 5.1 but didn't had any report about this issue.
Are you using the Fixed forwarder and still experiencing this screen tearing?

Yes. The one from your Google code page.
How could a forwarder affect even the System Menu itself?...
By the way, my "humble" advice would be not to trouble yourself with petty things such as GUI but focus on stability and fixes.
I was only curious about the stretched elements but that is by all means irrelevant.

 

[Cyan]

I hoped the Fixed version would also fix the video issue.
Maybe the video initialization is not done correctly in the forwarder and affects all the video ratio afterward.
It's fixed only when you exit vWii.
So, that's another thing I need to fix, I'll add it to the buglist on my blog.

 

[sideskroll]

I hoped the Fixed version would also fix the video issue.
Maybe the video initialization is not done correctly in the forwarder and affects all the video ratio afterward.
It's fixed only when you exit vWii.
So, that's another thing I need to fix, I'll add it to the buglist on my blog.

I'd say that's a BIG one
So a temporary "fix" would be to launch it from HB then.
Should I add the AHB line to the meta file or an update from the loader would do the trick?

 

[Cyan]

That line should already be there.
if it's not, did you edit one of this setting in the loader ?
- Loader's IOS
- USBPort
- Boot USB at launch
- Doing a loader's reset from the home menu (I'm forcing a meta.xml rewrite when reseting to be sure the meta is using latest settings)

let me know if it deletes the <ahb_access/> line.
Let me know if you still have it but you can't read the channel's title.

 

[sideskroll]

That line should already be there. I don't know if it is or isn't there as I haven't checked on a PC. But from the looks of it (no channel info if launched from HBC) it appears to NOT be.
if it's not, did you edit one of this setting in the loader ?
- Loader's IOS No
- USBPort No
- Boot USB at launch No
- Doing a loader's reset from the home menu (I'm forcing a meta.xml rewrite when reseting to be sure the meta is using latest settings) You mean "Reset to default" or something like that from the loaders settings?

Do you have the "latest settings" of the mmeta file at hand to compare them?

IN HERE SO I CAN COPY/PASTE

 

[Cyan]

http://code.google.com/p/usbloader-gui/source/browse/trunk/HBC/META.XML

 

[sideskroll]

http://code.google.com/p/usbloader-gui/source/browse/trunk/HBC/META.XML

Well, the line is there. So I don't know why I can't access the NAND if I launch it from HBC.
Also, if launched through HBC some other issues appear such as GC games reverting to Widescreen even if Wiiu Widescreen is turned off in GLOBAL config (remember I told you about that)
Do you need me to try something else?