Hacking Nintendont

  • Thread starter Thread starter sabykos
  • Start date Start date
  • Views Views 10,171,712
  • Replies Replies 42,894
  • Likes Likes 194
Just tried the out r16 and it no longer updates my metaxml. Am i wrong or was that feature added? EDIT= Even the loader says i am on r86 even though i have updated the boot.dol
 
Cyan or FIX94
I found a systematic way to make nintendont crash on autoboot and I believe it's somehow related to the missing DSP patches
1. run Beyond good and evil via wiiflow 1073 (game and nintendont are both on SD)
2. start a new game and watch a bit of the intro (the sound will start looping here)
3. press the shutdown combo to load the stub R-Z-B-Down (this might work returning to wiiflow or freeze so hard reset)
4. run the game again or any other game for that matter using nintendont >> codedump
screenies of dump with v1.5 and 1.6:
34hctog.jpg

2hhp4l0.jpg
and here's a screenie of Wiiflow codedump that happened just after the freeze:
2cf4oih.jpg
this was found unrelated to MC-Emu option since it happens with this option on or off
Nintendont will keep on crashing until I load a wii game or dios mios or anything else,
A Hard reset or holding power button until off don't fix this dump only removal of the power cord do the trick.
so I believe there is some memory corruption from the wrong sound patch and leftovers in the memory that are causing this issue and they got overwritten only after successfully loading something else or removing the power cord.

P.S. I have wf loader in priiloader set as autoboot so I always bypass the SM
MaxP90 which game initiated the codedump sequence for you, since most games are running just fine

Edit: I believe it's DSP v4 problem I just tested kirby air ride and soulkaliburII and got same dump

Freasko
 
  • Like
Reactions: bm123456
Any game can code dump on me, also I had these from before the dsp patches where removed.

I've found that after the codedump if you run the game again or any other game for that matter using nintendont >> codedump
Any game can codedump true, but there is one that causes the problem first.
 
  • Like
Reactions: Yoni Arousement
Attention all users:
check your memory card files created by Nintendont, if they are created between r83 and v1.5, they might contains wrong data.
You can check them in dolphin's MC manager, or by searching /nintendont/ string or "Patch:Found" string in hex editor, or if you see the save path in the header.

the memory card wasn't properly closed after creation, and contains random dumps inside (gecko logs, nincfg.bin, device's partition sectors, etc.)
Delete them if they are corrupted. (keep a backup just in case)

Edit:
it seems dolphin's MC Manager doesn't correctly write saves.
nintendont doesn't see the save if written with that manager.
Tested with Mario Sunshine.
It worked when nintendont used a global card instead of per game one.
 
Hi,

I've been looking at the Nintendon't code, and I'm considering trying to add some functionality. (In particular, data compression [GCZ format] - this could potentially improve SD performance, since the SD slot is limited to 2 MB/s.) I assume Nintendon't loads in MEM2 instead of Starlet SRAM, so there's plenty of memory for a zlib implementation and decompression buffer. (Considering using miniz instead of zlib - http://code.google.com/p/miniz/ )

I'm going to do an initial attempt at rearranging some of the code to eliminate most of the #ifdef NINTENDONT_USB scattered throughout the files - instead, a single abstraction file will have the appropriate ifdefs for USB and SD mode.

EDIT: Looks like there aren't actually that many #ifndef NINTENDONT_USB uses. So instead of that, I'll start modifying DI.c to support on-the-fly decompression.

EDIT 2: Dolphin GCZ might be a little too complicated, since it's designed as a "generic" container. Instead, I'll try bringing back a project I was working on a while ago, "GCMDZ" - originally intended to compress Wii disc images such that it could be used on a CIOS (using the LZO algorithm), I never got around to actually implementing it in a CIOS. I should be able to add GameCube support relatively easily and then implement it in Nintendon't. LZO has some advantages over ZLIB in that it's faster and supports in-place decompression (lower memory usage), but it isn't as widespread.
 
Here is an interesting read about what happened with the Google Source Code Page a few days ago.
Take a look:

http://www.gc-forever.com/forums/viewtopic.php?p=24690#p24690


I'm not surprised in the least, and now that we have our own DSP code, he has no right to complain about it lol. He mad. He really mad lol! Anyways, glad that's over with! Nintendont is getting much, much better as time goes on :D It's already pretty awesome if ya ask me :P Now, I believe one of the next things to tackle was Bluetooth, correct?
 
I'm not surprised in the least, and now that we have our own DSP code, he has no right to complain about it lol. He mad. He really mad lol! Anyways, glad that's over with! Nintendont is getting much, much better as time goes on :D It's already pretty awesome if ya ask me :P Now, I believe one of the next things to tackle was Bluetooth, correct?
It would probably be game compatabily and MCemu. I don't think Bluetooth is high priority.
 
I'm not surprised in the least, and now that we have our own DSP code, he has no right to complain about it lol. He mad. He really mad lol! Anyways, glad that's over with! Nintendont is getting much, much better as time goes on :D It's already pretty awesome if ya ask me :P Now, I believe one of the next things to tackle was Bluetooth, correct?


And now he's saying that we're all trying to cause more drama by linking to the post on gc-forever
 
It would probably be game compatabily and MCemu. I don't think Bluetooth is high priority.


I mean, I did see Fix94 mention something the other day on how it might be worked on eventually, but yeah, MCemu and more games working would definitely take more precedence.

And now he's saying that we're all trying to cause more drama by linking to the post on gc-forever
Let him think what he wants, not our problem anymore ;) I'm glad he's not involved with Nintendont. Who cares what he thinks?
 
mc emu is close to 100% now i dont think there is much to improve on the mcemu department, next priority has to be compat increase for sure controllers can wait imo.
 
  • Like
Reactions: the_randomizer
Who cares what he thinks?
innumerable people who have enjoyed the fruits of his labors with the wii and homebrew. don't get me wrong, he's one of a handful of people in this world who immediately raise each and every hackle i have, but to summarily dismiss him and his body of work because he rightly cried foul on the theft of his intellectual property is pretty myopic.
 
Anyways, I for one look forward to seeing game compatibility improve, as well as MCemu (both of which have gotten tremendously better and continue to do so); with that said, I don't agree with how he handles situations like that, there were better ways he could have handled it.
 
I'm looking forward to game compatibility improvements. I know devs get irritated with game requests but I'm holding my breath for Eternal Darkness. That was a sleeper hit and it would be great if more people got a chance to play it. That's all.
 
I would like to see some sort of anti-crash update before they start with the compatibility.

If a game crashes, allow us to tap the power button to reboot the console. Pulling the AC adapter out isn't exactly the best thing.
 
I would like to see some sort of anti-crash update before they start with the compatibility.

If a game crashes, allow us to tap the power button to reboot the console. Pulling the AC adapter out isn't exactly the best thing.

Also if the game freezes don't make annoying sound.
 

Site & Scene News

Popular threads in this forum