Hacking Nintendont

  • Thread starter Thread starter sabykos
  • Start date Start date
  • Views Views 10,173,546
  • Replies Replies 42,894
  • Likes Likes 194
no, the USB is only for battery charging. It's not used to send controller's data thought it.
If you want to use the WiiU pro controller with nintendont, you need an adapter to convert bluetooth signal to USB.
For example: http://www.mayflash.com/Products/NINTENDOWiiU/W009.html
 
Is there a known good data base in Dolphin , that we can grab the dsp for the different games or Nintendont or do we need to dump them some how with a tool to help dev get rolling ? Just wondering where the dsp 10 was found or do we need to have an USB gecko to even help?
I will be more than happy to post once USB is emplemented. One game at a time sd is crazy unless we have a list of the dsp and regions we need to help .
 
Is there a known good data base in Dolphin , that we can grab the dsp for the different games or Nintendont or do we need to dump them some how with a tool to help dev get rolling ? Just wondering where the dsp 10 was found or do we need to have an USB gecko to even help?
I will be more than happy to post once USB is emplemented. One game at a time sd is crazy unless we have a list of the dsp and regions we need to help .

To be clear, the patches I made are not necessarily specific to just the games in the comments. I matched the comments that were in there where there is a single example for each DSP. I don't have a complete list. I was hoping people would be updating the compatibility guide with the the version numbers. There are two ways to do this. The easier of the two is to just let Nintendont tell you. It's in the log after you run a game. (Note that the the log is only created on the WiiU, but you can turn it on in the Wii version by commenting out the IsWiiU line in the dbgprintf function in vsprintf.c. [I don't have a usbgecko, so that section isn't useful to me.]) The other option is to use Dolphin. If you look in UCodes.cpp, there's a list of special CRC codes. The ones marked Wii don't matter for Nintendont. There are 15 gamecube codes there. I would imagine the list of crcs (not the list of games for those crcs) in Dolphin is complete or close to it. I have at least one game with 9 of the codes, so there's an example for them in the patch.c.

In the Dolphin UCode_Rom.cpp file, is the chunk of code that will dump the DSP file, but it's surrounded in #ifdef statements, so you have to build Dolphin yourself, either as Debug, or comment out the #ifdefs. This will create a file named with one of the CRC sections. This CRC is not the same as the one sha-1 that are in Nintendont, it's the one in UCodes.cpp. You can generate the sha-1 from the file in Dolphin creates.

The two sha-1 values in patch.c I don't currently have an example for are probably the ones labeled Alien Hominid and Pikmin-Pal in the Dolphin UCodes.cpp file.
They would show up in Nintendont's log as V6 or V7. If the sha-1s aren't known, they will show up as unknown in Nintendont's log. Getting the compatibility list updated for as many games as possible would be helpful. The others in UCodes.cpp may or may not be useful. If anyone knows how to, I would like to know how to dump the IPL file from either my Wii or my Gamecube. I don't have a broadband adapter for my gamecube, which I think I saw mentioned as the way to do it.

One of the changes I made in r33 was to fix the DSP version reporting in the logs, so some games that were previously reporting unknown, should now report their version number.

For what it's worth, the change I made to the DSP for v10 and v11 was to try and fix the ACCA register in the DSP. Apparently, in the gamecube, the address for the ARAM is at 0x00000000 or 0x80000000 (memory map). However, on the Wii, if the DSP attempts to talk to that address, it will hit the main RAM, which will cause all sorts of problems. The ARAM address on the Wii is at 0x10000000 or 0x90000000. The change is to get accesses to this address adjusted. Crediar had left just enough comments/hints in the code to figure out what he was doing to the dsp. He had overwritten some of the code in the halt section to do this (I don't know if any games ever halt the DSP.), because changing DSP code length might cause problems, so you have to add additional instructions without altering the code behavior. The two that I modified had some unused nops at the end (using or instead of add, because I think it's safer). I also modified ACSA and ACEA in the same way, as I think they should probably be adjusted as well. I've been attempting to combine duplicate code in DSP v4 to make room, but haven't gotten it working yet, nor am I certain it will work. I don't know if this is what's causing some of the other games not to work. All of the ones that have been fixed so far have been what Dolphin calls Zelda style DSP. v4 is what it calls AX style. None of those work yet, so there might be something else that still needs to be fixed for those.
 
no, the USB is only for battery charging. It's not used to send controller's data thought it.
If you want to use the WiiU pro controller with nintendont, you need an adapter to convert bluetooth signal to USB.
For example: http://www.mayflash.com/Products/NINTENDOWiiU/W009.html


Are those Mayflash adapters any good? I've heard nothing but mixed to negative results (same goes with the reviews) :unsure: I think they have Gamecube/Mayflash adapters too.
 
Mayflash Wii U pro controller adapter(WU009) doesn't work for me
with the current controller.ini (nintendont_wiiuprousb.ini).
 
To be clear, the patches I made are not necessarily specific to just the games in the comments. I matched the comments that were in there where there is a single example for each DSP. I don't have a complete list. I was hoping people would be updating the compatibility guide with the the version numbers. There are two ways to do this. The easier of the two is to just let Nintendont tell you. It's in the log after you run a game. (Note that the the log is only created on the WiiU, but you can turn it on in the Wii version by commenting out the IsWiiU line in the dbgprintf function in vsprintf.c. [I don't have a usbgecko, so that section isn't useful to me.]) The other option is to use Dolphin. If you look in UCodes.cpp, there's a list of special CRC codes. The ones marked Wii don't matter for Nintendont. There are 15 gamecube codes there. I would imagine the list of crcs (not the list of games for those crcs) in Dolphin is complete or close to it. I have at least one game with 9 of the codes, so there's an example for them in the patch.c.

In the Dolphin UCode_Rom.cpp file, is the chunk of code that will dump the DSP file, but it's surrounded in #ifdef statements, so you have to build Dolphin yourself, either as Debug, or comment out the #ifdefs. This will create a file named with one of the CRC sections. This CRC is not the same as the one sha-1 that are in Nintendont, it's the one in UCodes.cpp. You can generate the sha-1 from the file in Dolphin creates.

The two sha-1 values in patch.c I don't currently have an example for are probably the ones labeled Alien Hominid and Pikmin-Pal in the Dolphin UCodes.cpp file.
They would show up in Nintendont's log as V6 or V7. If the sha-1s aren't known, they will show up as unknown in Nintendont's log. Getting the compatibility list updated for as many games as possible would be helpful. The others in UCodes.cpp may or may not be useful. If anyone knows how to, I would like to know how to dump the IPL file from either my Wii or my Gamecube. I don't have a broadband adapter for my gamecube, which I think I saw mentioned as the way to do it.

One of the changes I made in r33 was to fix the DSP version reporting in the logs, so some games that were previously reporting unknown, should now report their version number.

For what it's worth, the change I made to the DSP for v10 and v11 was to try and fix the ACCA register in the DSP. Apparently, in the gamecube, the address for the ARAM is at 0x00000000 or 0x80000000 (memory map). However, on the Wii, if the DSP attempts to talk to that address, it will hit the main RAM, which will cause all sorts of problems. The ARAM address on the Wii is at 0x10000000 or 0x90000000. The change is to get accesses to this address adjusted. Crediar had left just enough comments/hints in the code to figure out what he was doing to the dsp. He had overwritten some of the code in the halt section to do this (I don't know if any games ever halt the DSP.), because changing DSP code length might cause problems, so you have to add additional instructions without altering the code behavior. The two that I modified had some unused nops at the end (using or instead of add, because I think it's safer). I also modified ACSA and ACEA in the same way, as I think they should probably be adjusted as well. I've been attempting to combine duplicate code in DSP v4 to make room, but haven't gotten it working yet, nor am I certain it will work. I don't know if this is what's causing some of the other games not to work. All of the ones that have been fixed so far have been what Dolphin calls Zelda style DSP. v4 is what it calls AX style. None of those work yet, so there might be something else that still needs to be fixed for those.

It's really interesting to read this. Unfortunately, I really no time at all right now for testing, because of exams. I will maybe have some time at the end of February/begin of March to add some DSP information to the compatibility list. Do you consider working on other DSP versions or is it too tedious?
 
GreyRogue turn it on in the Wii version by commenting out the IsWiiU line in the dbgprintf function in vsprintf.c. to let the people with Wii to help with the compatibility list.
can someone please turn this feature on for us an compile it and post it here please. i would like to help.
 
GreyRogue turn it on in the Wii version by commenting out the IsWiiU line in the dbgprintf function in vsprintf.c. to let the people with Wii to help with the compatibility list.
can someone please turn this feature on for us an compile it and post it here please. i would like to help.
/snip
EDIT : hmm, nevermind. I took that out of context.

Actually, yeah. I think the code is written that way because the Wii U can't run with a USB Gecko and so needs it more BUT it's not exactly fair to assume that Wii owners (especially family edition Wii owners who would be more attracted to this) would actually have a USB Gecko.

EDIT2 : Maybe once I implement LOLserial for Triinux I should just make it as a separate header file that anyone could add to their code. It's a lot easier to make your own LOLserial for debug than it is to find and buy a USB gecko.
 
/snip
EDIT : hmm, nevermind. I took that out of context.

Actually, yeah. I think the code is written that way because the Wii U can't run with a USB Gecko and so needs it more BUT it's not exactly fair to assume that Wii owners (especially family edition Wii owners who would be more attracted to this) would actually have a USB Gecko.

EDIT2 : Maybe once I implement LOLserial for Triinux I should just make it as a separate header file that anyone could add to their code. It's a lot easier to make your own LOLserial for debug than it is to find and buy a USB gecko.

So the normal Wii users can not update the DSP ? then or am i missing something. as i read it only Wii U users currently can update the compatibility list.
 
I believe the point being made was that only WiiU users get a debug log written to the SD Card, while Wii users need to use a USB Gecko. You can add debug log support to the Wii version by adjusting the source code and commenting out the IsWiiU check in the debug printf code.
 
Ah. So dios mios is still currently the best option for running GC games of a HDD?
Sorry to reply on a two weeks old post, had some busy couple of weeks, anyway to answer your question properly well that depends, if you're using a Wii then Dios Mios is your best option, you can also use Devolution though it's more hustle than its worth, if you're using a WiiU then Devolution is your only option, you also need a Wii and to own the games in order to get it working, if your computer or laptop is fast enough then by all means your best option is using Dolphin, really!

This isn't good. Either you got to keep an old Wii around, or you got to keep and old Wii around to make your games work on your Wii U. Bummer, seriously.
Or you can... you know, use a real Gamecube ;)

If you want to use the WiiU pro controller with nintendont, you need an adapter to convert bluetooth signal to USB.
For example: http://www.mayflash.com/Products/NINTENDOWiiU/W009.html
Well at least there's a way, I still think WiiU pro controller is the best solution to play GC on the WiiU because of the controller being the closest in design and let's face it it's more comfortable than a PS3 controller!
Honestly though would be really peachy if either Wii Classic Controller or Xbox 360 controller had support in future releases, at least they use letters for the buttons instead of Sony's "X [ ] O /\" icons!
 
  • Like
Reactions: KiiWii
Cheat support works fine.
I tested it with r1218_mod1 and nintendont r13 (or 20?) and Zelda Wind Waker PAL.

Do you have kenobiwii.bin in your /sneek/ folder?
it's required as it's now running in Wii mode (not using kenobigc.bin anymore, as DM/L did).

Edit:
It's giving me an idea, I can add another warning in usbgx if that file is missing (and maybe auto-download it).
 

Site & Scene News

Popular threads in this forum