Hacking Nintendont

  • Thread starter Thread starter sabykos
  • Start date Start date
  • Views Views 10,174,339
  • Replies Replies 42,894
  • Likes Likes 194
He talked about DevkitARM_r42, which is used now to compile Nintendont r45+
he didn't tell you to update to nintendont r42 (you should update to r44 instead of 42).
i did that and i still get the same error on my 1tb western digital hd and 8gb flash drive
 
Atm the kernel has only access to the usb device OR sd-card, not both at the same time. All files needed by the kernel to do its job has to be on the device the game is readed from (nincfg.bin, controller.ini, ninmem.raw and ndebug.log).

It would be better to make the loader accept arguments and or use a specific spot in memory to load/write the configuration but thats up to the dev team.

I agree with this. I'd say keep the first argument as the calling location, as that seems to be the standard. Then, either combine all the config settings into the second argument comma separated or each setting into its own argument. I'd lean to the second one. Something like:
argv[0] = "sd:/apps/Nintendont/boot.dol"
argv[1] = "CONFIG_CFG_AUTO_BOOT=1"
argv[2] = "CONFIG_GAME_PATH=/games/Zelda/game.iso"
argv[3] = "CONFIG_CFG_USB=1"
I like using strings so that if settings change, old code would still work.
You'd want these to override the settings in the config file, so it would processed after the ConfigReset, but before asking the user for USB/SD.

I would also like to point the kernel to a location in memory where it can read the config, rather than from a file. Maybe near 0x[1|9]0004100, as we're already using that area to communicate between the loader and the kernel. The loader could write the config structure to memory there, and the kernel could read it, rather than using file access.

In a related a note, a common header file with all global memory locations in it would be nice, rather than having hard-coded values like the 90004100/10004100 in loader/main.c and kernel/common.c.

While I'm making wishes, at some point I think we're going to need to replace the ARAM DMA patches with code that does the memcopy in the kernel, rather than in the PowerPC where it's being done now. ARQPostRequest and ARStartDMA accept requests to copy memory from the main RAM to the ARAM on a gamecube which are normally handed off to other hardware, with a callback function for when its done. This mode isn't supported by the Wii, according to http://wiibrew.org/wiki/Hardware/DSP. The patches just immediately do the copies instead and immediately call the callback. This method appears to work in most cases, but it will likely cause stuttering in game, during the copy. It would probably work better to have the ARM do these copies instead. Maybe using a method similar to the way the Disk interface patches work? (see dip.cpp/h, DI.c/h). It would probably need to have a max size to process at one time, breaking the copy into multiple chunks in the while loop in main(), so that controller information is still updated at a reasonable rate.

Glad to see some new committers and others working on this. If anyone else wants to start working on these, feel free. I don't have time myself right now, but I'll probably start looking at some of them myself eventually if no one else does.
 
This is very odd. On r44, Rayman 3 loads to the menu when it is on the SD Card, but when it's on the USB, it has a black screen on boot. Regardless, controller is not registered, but this may indicate compatibility differences between USB and SD Card.
 
Did Nintendont work before?

nope it never did all it gave me was a black screen or that fat device error

I got an error with the latest rev, it said it dosent found any fat device, whatever I select sd or usb O.o somone kow what I did wrong?


Edit: Nevermind, I was supposed to use fat32 on my HDD XD Fixed


Hmm so did u format the fat32 to 32k cluster size ,or did you leave it as default or something?
 
Was anybody able to get USB loading working with the Wii U pro controller and mayflash adapter? Whenever I try, it gets stuck on "Init HID device. But it works fine when I load games from an SD memory card.
 
GOOD EVENING PEOPLE!!!! I CAN PLAY Mario Kart Double Dash already!!!

Fix: I had "PollType=0; i changed to 1! and my controller worked and game with SUCCESS!!!!
 
Never had any input lag with double dash. I test that game a lot to

Edit: the only game I have ever had input lag on was digimon world 4
 
Si a mi tambien me pasó lo mismo cuando probé el control DualShock 3! (translate spanish to english)
You are aware the main language is english here and it is your own responsibility to translate your language to english?

About the input lag, i can confirm this happening in menu's of some of the games (using USB), but not in the gameplay.
Also the lag itself is not really that bothersome for me, its like waiting at most 2 extra secs..
 

Site & Scene News

Popular threads in this forum