Hacking Nintendont

  • Thread starter Thread starter sabykos
  • Start date Start date
  • Views Views 10,170,210
  • Replies Replies 42,894
  • Likes Likes 194
How are you supposed to get past the black screen in metroid prime? I was able to boot into the actual story mode by ear but the screen is still black.
 
How are you supposed to get past the black screen in metroid prime? I was able to boot into the actual story mode by ear but the screen is still black.

I heard it's broken in v1.69

Try v1.61 where I heard it works. Never tested it myself.
 
I heard it's broken in v1.69

Try v1.61 where I heard it works. Never tested it myself.


Yeah, I tested it last Saturday and the game did indeed work fine on 1.62, except I might have encountered an in-game bug and got stuck in the first tunnel (on the spaceship at the very beginning, before escaping( after you shoot the doors open., I just got stuck. The collision detection must have screwed up or the ISO image somehow got corrupted. The game did indeed load up just fine, but now 1.69 no longer works with it?
 
'm not sure if you people can't read or you just don't understand how loaders work with nintendont, .

Do you understand the difference between "parameter passing" via command line (in memory) and via a config file (I/O via SD/HDD)?

Take a look at how WiiFlow plugins for emulator works.

Take a look at how USBloaders load Wii Games and how they work with Dios Mios. Although they are not using exactly command line parameters, they don't need to access SD/HDD just to pass the game name/path.

Of course, its no big deal writing to SD/HDD just for that but the concept of that is not right.
You don't want a program to write to a file constantly unnecessarily. Image if Nintendont re-writes a config/ini file every time it starts/Stops (via HBC) even though there is no changes in the configuration.
You might argue that the game name/path may change but that is totally avoidable via parameter passing and is in common practice.

Nintendont doesn't support command line parameter now doesn't mean it can't be implemented nor it should be hard to do so. And yes, USBloaders need to be updated to use the feature.

Priority-wise, I will leave that to the devs.
 
Do you understand the difference between "parameter passing" via command line (in memory) and via a config file (I/O via SD/HDD)?

Take a look at how WiiFlow plugins for emulator works.

Take a look at how USBloaders load Wii Games and how they work with Dios Mios. Although they are not using exactly command line parameters, they don't need to access SD/HDD just to pass the game name/path.

Of course, its no big deal writing to SD/HDD just for that but the concept of that is not right.
You don't want a program to write to a file constantly unnecessarily. Image if Nintendont re-writes a config/ini file every time it starts/Stops (via HBC) even though there is no changes in the configuration.
You might argue that the game name/path may change but that is totally avoidable and is in common practice.

Nintendont doesn't support command line parameter now doesn't mean it can't be implemented nor it should be hard to do so. And yes, USBloaders need to be updated to use the feature.

Priority-wise, I will leave that to the devs.

I wasn't talking about the way the settings are handled though; I do not have enough knowledge about the matter and to be honest, I don't really care. Unless you can prove that it would actually make a difference for users other than having or not having a file in the sd/hdd.

My post was meant to clarify to other people what WiiFreasko and I were talking about when we said that it would be a good idea that Autoboot is turned off after the game has already been loaded, to avoid having autoboot on if we're loading through HBC after loading it through an usbloader. People seemed to misunderstand that doing so would disable autoboot altogether, when the reality is that the loaders would still be setting it to On when loading a game, even if it's turned off after the game is loaded.

On an extra note, since apparently you're well versed on this kind of thing, why don't you rewrite the code so it works like you think it should? Nintendont is Open source, no one will stop you from changing things if they'll help the project.
 
How are you supposed to get past the black screen in metroid prime? I was able to boot into the actual story mode by ear but the screen is still black.
do you have font_ansi.bin or ipl.bin on the root of the place you have the games?

metroid prime 1 and 2 boot perfectly on 1.69 at least for me dkn why ppl edited the compat list saying it black screens when i just tryed it and it boots up perfectly
 
do you have font_ansi.bin or ipl.bin on the root of the place you have the games?

Srs who is editing the compatibility with false claims? metroid prime 1 and 2 work perfectly on 1.69 for ppl that get black screen they either miss the ipl/font ansi bin or they arent using 1.69

If you're sure the black screen is due to a missing font_ansi.bin / ipl.bin ; then add a note in the compatibility list "Black screen on boot if missing ipl.bin or font_ansi.bin"
 
If you're sure the black screen is due to a missing font_ansi.bin / ipl.bin ; then add a note in the compatibility list "Black screen on boot if missing ipl.bin or font_ansi.bin"

yeah lots of games we dont know if hose files are required becuase they only started worked after we had the files on the root of the SD/usb probably metroid prime needs one, i playing the game right now on 1.69 so it doesnt black screen for sure like someone edited on the compat list for some reason.

A freeze i found is if you leavue the main menu on for some time it will freeze but if you press A fast your safe
 
yeah lots of games we dont know if hose files are required becuase they only started worked after we had the files on the root of the SD/usb probably metroid prime needs one, i playing the game right now on 1.69 so it doesnt black screen for sure like someone edited on the compat list for some reason.

A freeze i found is if you leavue the main menu on for some time it will freeze but if you press A fast your safe

Have you tested the game without the .bin files? If you haven't, then you can't be sure that's the reason why you don't get the black screen. It could be due to something else, but the only way to be sure is that you try it without the .bin files (I would do it, but I don't have those games)
 
Have you tested the game without the .bin files? If you haven't, then you can't be sure that's the reason why you don't get the black screen. It could be due to something else, but the only way to be sure is that you try it without the .bin files (I would do it, but I don't have those games)

just tryed the game without font or ipl bin and still works great so its people here probably forgetting to delete their nintendont created files that might cause the issue the game boots fine in 1.69

people having problems with 1.69 just delete the three files created by nintendot when testing a new rev that will fix most of the issues the only thing you need to do is remenber to turn mcemu back on on nintendont when booting it up again.
 
I think the confusion with Metroid Prime (not skihji's problem) seems to lie with how the wiki was edited. I went back through the history and saw that someone updated it to 1.69, changed its status to Works, but left the black screen message, so I believe it was a mistake; the game worked fine for them, but they merely overlooked it.
 
took out the black screen on both metroid prime nots on the wiki they run just fine, everyone who is having problems plese try deleting the nintendont created files on the root of your device.

The only issue right now is that when using a hid controller the wiiu crashes after 40min to 1hour 30 depending on the games which makes playing some games hard like metroid where you go a long way without saving, but so far no one found out how to fix the hid crash after awile.
 
I wasn't talking about the way the settings are handled though; I do not have enough knowledge about the matter and to be honest, I don't really care. Unless you can prove that it would actually make a difference for users other than having or not having a file in the sd/hdd.

No, the config file has to be there for obvious reason but we don't need to write to it unnecessarily.
End users should not notice any difference, its just minor wear and tear and programming practice.

My post was meant to clarify to other people what WiiFreasko and I were talking about when we said that it would be a good idea that Autoboot is turned off after the game has already been loaded, to avoid having autoboot on if we're loading through HBC after loading it through an usbloader. People seemed to misunderstand that doing so would disable autoboot altogether, when the reality is that the loaders would still be setting it to On when loading a game, even if it's turned off after the game is loaded.

That's fine. But with Parameter passing, you don't need to touch the autoboot setting at all.
Let the autoboot setting do what its name implies - if its on, run the named game in the config file. If the game never change, you don't need to set the config every time ( I think this is the way it is if you run Nintendont from HBC)

On an extra note, since apparently you're well versed on this kind of thing, why don't you rewrite the code so it works like you think it should? Nintendont is Open source, no one will stop you from changing things if they'll help the project.


Thanks. I know a little bit of programming but not well versed.
 
v1.69 breaks a lot of games for me, Mario Sunshine gets stuck at progressive mode prompt, Kirby Air Ride randomly crashes, Sonic Adventure 2 crashes at mem card selection and many others, all perfectly working with v1.67 and before
 
v1.69 breaks a lot of games for me, Mario Sunshine gets stuck at progressive mode prompt, Kirby Air Ride randomly crashes, Sonic Adventure 2 crashes at mem card selection and many others, all perfectly working with v1.67 and before

delete the nintendont created files on the root of the SD/usb that fixes all those issues


PPl we need a disclaimer saying 1.69 needs the nintendont created files deleted to work correctly or it might cause issues like many users said here delete the 3 files that are created on the root of the device and then when going back into nintendont dont forget to turn mcemu back on.
 
delete the nintendont created files on the root of the SD/usb that fixes all those issues


PPl we need a disclaimer saying 1.69 needs the nintendont created files deleted to work correctly or it might cause issues like many users said here
Ok this is funny. I had already deleted those files but it kept not working, and I did intensive testing, always with the same result. Now after trying several old revisions, all of them working, I retried v1.69, and now it's working just fine...
EDIT: if I load v1.69 after having loaded a previous version, it works. If I load v1.69 more than once consecutively it doesn't work...
 
Ok this is funny. I had already deleted those files but it kept not working, and I did intensive testing, always with the same result. Now after trying several old revisions, all of them working, I retried v1.69, and now it's working just fine...

yup the ninconfig.bin and nintendont 1.69 dont seem to play nice lots of users reported bugs until they deleted the bin and letted it creat a new one on 1.69 why? i have no idea lol
 

Site & Scene News

Popular threads in this forum