I haven't really played on my Wii that much lately, so I could be missing a lot here.
My SD can open the Homebrew Channel and many other channels such as the snes9x emulator and Gecko OS, NeoGamma, etc..
But the problem is, when I try to use Ocarina on Gecko OS 1.9.3.1, the latest version, it loads the game just fine, but when it tries to load the Ocarina codes, it says "SD not found."
When it shows that, the game just starts in the settings you have chosen, it just doesn't load the cheats from the SD, since it could not be loaded.
Is there something I need to fix this? As I said, I haven't played on my Wii much lately, meaning I basically left all the HBC stuff aside, and never looked back at it.
Help would be appreciated.
When you try to load the game with cheats does it say, "No SD Card found." or "No SD Codes found." If it's not recognizing the SD Card, you may have to try a different one, but if you can load other apps with it, I doubt that's the case.
I think you might not have the proper directory for the codes, causing the "No SD Codes found" message. I believe that they should be stored at:
SD:\Codes\GameID.gct
The gct can be made from Geckocodes, or from the PC Code Manager.
It says that no SD card was found, I just checked the folder, and there are 8 .gct files in there right now. The game I am trying to use cheats with is Zelda: Twilight Princess. I made the gct with the PC Code Manager, and there is a RZDP01.gct file in my SD:\codes folder.
When I also try to SAVE my settings with Gecko OS 1.9.3.1, it also says that there was no SD card found.
Is there something I need to do with IOS or anything? I've been away from this to long.
If you have access to another SD card, you could try that.
Also, you could try formatting the SD card to FAT32, if it's not already. (Backup your data first.)
You could try re-inserting the SD Card when in Gecko OS.
Other than that, I'm not sure how much help I can offer.
To cheat on Wii games, you do not need to touch IOS. The only reason you might want to touch IOS36 is to enable channel cheats.
What size of SD card is it? Is it SDHC? What system menu version do you have? What HBC version?
You could try backing up everything on it and then formatting it. But yeah, if it can load Gecko OS, it's reading it from the SD card...
My System Menu version is 4.3E and my Homebrew Channel version is 1.0.8
SD card is a 4GB SDHC.
I just reformatted the SD card, and now putting back all the cheats I had on it. I am going to give it another try, I will edit the post when anything happened.
Just reformatted, put the cheats back on, opened Gecko OS: same thing, doesn't work.
I know sometimes the Wii struggles with SDHC. But I know it works sometimes, too. What brand is your card?
It's a Kingston.
I don't get it, I NEVER had any problems with this a long time ago, and from the looks of it, Gecko OS hasn't even updated ever since.
This is unlikely to fix the problem, but you could redownload the application. (You could also try the last version , 1.9.3)
Other than that, I think I'm out of ideas :S
Well, I tried it all.
Reformatting my SD card, reinstalling/downloading Gecko OS 1.9.3 AND 1.9.3.1
But yet, it does not work.
My Wii says that the SD card is inserted, and the HBC shows the apps I have on my SD card, yet it shows it can not find a SD card on GeckoOS or other channels such as NeoGamma, a USBLoader channel.
There might be one more possibility, which is Riivolution, so I'll try that.
EDIT: It works totally fine with Riivolution, I think I'll have to stick with that then
...odd. If Riivolution works (which requires a clean IOS37) and Gecko OS doesn't (which can use a patched IOS36), then I would be suspicious of any changes to IOS36 somehow interfering with your SD stuff. As a last ditch effort you could try re-installing the latest clean IOS36 using e.g. Dop-Mii, and then using Simple IOS Patcher if you need to patch for channel cheats.
After reformatting, does it still complain if you try to save Gecko OS settings to SD card?
I'll have to try to reinstall the IOS later, not possible to do it now.
And yes, it still complains when I try to save my settings.
Gecko OS will support different cards when using different IOS. But i didn't expect a change from IOS36 to IOS37. I only knew that using IOS61 instead of IOS36 makes some(most?) sdhc cards work. Making the latest Gecko OS use IOS61 is a bit complicated, because last time i tried, i wasn't able to boot any games with my compiled Gecko OS.
Maybe Riivolution replaces some of the IOS sd card code? I wouldn't be surprised if they did some tuning to support more sdhc cards than with the unpatched IOS37. They also could use AHBPROT for sd access before the game is loaded...
Not that I would recommend trying this without bootmii as boot2 but would it be possible to put IOS61 into IOS36 slot?
Quote from: dcx2 on August 06, 2011, 01:33:02 AM
Not that I would recommend trying this without bootmii as boot2 but would it be possible to put IOS61 into IOS36 slot?
Yes, it should be possible. And there would be a chance to brick Wiis by doing this(like priiloader installed using IOS36), so the advice to only do it with BootMii boot2 is someting i agree with 100%.
Which version of Gecko OS used IOS249? Installing IOS61 as IOS249 should be safe.
From what I've experienced, Gecko OS lacks SDHC support, so that's why I use either a normal SD card, or Riivolution to use cheats.
Try the most recent version:
http://wiird.l0nk.org/projectfiles/Gecko1931.zip
Not sure if the sd library was updated before this was compiled.. but worth a shot if you need it.
(but the wiibrew entry doesn't say that it is compatible with SDHC so it may not be: http://www.wiibrew.org/wiki/Gecko_OS )
a-ha! I was looking through the gameconfig.txt documentation and I saw something wicked cool. You might be able tell Gecko OS what IOS to load with!
---
[value] startupios - Specify the IOS to switch to when starting Gecko OS.
Example:
startupios = 36
Always load IOS 36 when starting Gecko OS (the default unless IOS 36 does not support channel loading).
---
I'm not sure how this works, though. If Gecko OS can't read your SD card, and gameconfig.txt is on the SD card, will it be able to find it? Would it reload its own IOS? It also says it will go after a different IOS if IOS36 doesn't support channel loading...
It all comes down to Gecko OS not being compilable. I think you can adjust it to not throw any errors with the latest libogc, but as i said, last time i tried, it doesn't really work. It boots up, but has trouble loading games. If that was fixed, you could easily adjust it to load IOS36 at startup for general stuff, IOS61 just for storage access and then load the game IOS before booting the game. Look at my highly modded Gecko OS, it allows you to load codes using IOS61 (almost) that way.
It's just ridiculous that Gecko OS is open source, but you can't even do small stuff like this.
I always thought Gecko OS was closed source, but then I found it today. Perhaps I should try to see if I can get it to compile. But I've never tried to build a Wii app so I don't even know where to start, heh.
What is the problem? Does it just depend on an old libogc? Could we just hex edit the .dol file to load a different IOS by default and avoid compiling anything?
I think the only change between 1931 and 1932 were some changes to the code handler's debugger. I don't think anything changed in the actual Gecko OS source, so we could just dump a binary blob from a game running 1932 and hex2c it.
I think my own compiled Gecko OS 1.9.something compiled fine with the libogc that was recent to that time, but it crashed during the loading process for some games. I'm sorry i don't have more information about this, but other than the new code handler and the new GUI, the newer Gecko OS doesn't have anything important to offer compared to the old 1.0.7b. So i didn't care much about it.
Just hex editing the IOS36 loading should be fine. By compling the Gecko OS you have the source for with IOS36 and IOS61 once, you should be able to find the place to patch in the most recent version. It will of course be unable to load channels with codes.
It looks like some features were added, like channel loading and multidol hooks. I think you already do multidol hooks on your own, though.
If you patched IOS61 for ES_Identify, wouldn't you still be able to load channels?
Also...I never really understood how rebooter works, but perhaps it would be possible to use rebooter somehow to convince it to use a different IOS?
Gecko OS 1.07b had multi .dol hooks already, and i use the code from Gecko OS for that. The multi .dol hooks for gamecube games are something i did. But it's only putting the hook code together with the on-the-fly patch code. About the channel loading, i have a another project that does that too, but with more features. It was released shortly after Gecko OS' source was released, but not much code from Gecko OS' channel loading is inside it, if any. And the rebooter is kinda uninteresting to me, i don't really get its point. (other than loading Sam & Max with codes or something...)
What do you want to do with the rebooter? It loads the system menu .dol into memory, patches it, and then executes it. What would you get by running the system menu with IOS61 instead of IOS36? Recent sytem menus use an IOS with sdhc support anyways...
Honestly, I don't get the point of the rebooter, either. Somehow I thought it was supposed to enable loading games with cheat codes from the disc channel or something. I know Y.S. said he used a code with rebooter to adjust Arena Hi, but from what gct does rebooter pull codes?
Can Gecko OS Mod do Wii games? I always thought it was just for GC. If it works for Wii games too, could OP just use Gecko OS Mod instead?
Yes, but it's only using IOS36 for games, and does not load the correct IOS. It's kinda on the todo list, but i am more lazy than usual lately.
Using the rebooter and codes works this way:
The loader checks which disc is inserted
Loads the codes and the code handler into memory
Loads the multi .dol handler into memory
Loads the system menu .dol into memory
patches it for stuff(too lazy to look it up now)
and then starts the system menu .dol
And when you boot the game from disc channel then, the multi .dol hooks, actually hook into the game.
So using rebooter is useless in this application because it has to read the SD still.
as far as todo list, I would much prefer an updated code handler to any other features, personally. I've actually considered just inserting the updated code handler by hand into the Gecko OS Mod binary. lol, "Gecko OS Mod Mod"
I'd prefer having the source of the code handler too and not just the binary. It would help with porting it for the gamecube stuff, and updates, like the bug fix you wrote. Yes, i still think the best place for that is in the code handler itself and not the app running on the PC...
The 1931 code handler source is in here. http://code.google.com/p/geckodownloads/downloads/detail?name=geckoos_source.zip
I don't think 1932 code handler source was ever posted anywhere, but the 1931 handler is in there, complete with batch files that create a C declaration of a byte array.
The bug fixes are only important for the debugger, not for the regular cheaters. Gecko.NET tucks the bug fixes away at the end of the code list; they use up 12 code lines so far, which isn't very much, and applying the fixes in-line might only save you two or three code lines.
Quote from: WiiPower on August 09, 2011, 07:51:05 PM
I'd prefer having the source of the code handler too and not just the binary. It would help with porting it for the gamecube stuff, and updates, like the bug fix you wrote. Yes, i still think the best place for that is in the code handler itself and not the app running on the PC...
All I had to do to port the Wii code handler to GameCube was change the address of the EXI registers. I'm pretty sure everything else worked out of the box. I think I marked those changes in the source I sent you. If anyone else wants info on that, I can look through my notes for details.
I think you arlready told me that. I still think it would be better if it was part of the code handler. Since there are 2 code handlers, it wouldn't affect the codes only one.
Quote from: biolizard89 on August 09, 2011, 08:02:55 PM
Quote from: WiiPower on August 09, 2011, 07:51:05 PM
I'd prefer having the source of the code handler too and not just the binary. It would help with porting it for the gamecube stuff, and updates, like the bug fix you wrote. Yes, i still think the best place for that is in the code handler itself and not the app running on the PC...
All I had to do to port the Wii code handler to GameCube was change the address of the EXI registers. I'm pretty sure everything else worked out of the box. I think I marked those changes in the source I sent you. If anyone else wants info on that, I can look through my notes for details.
It would be possible to apply the change to a binary. But it's messy, imagine stuff like this goes on and then you have a pages long description on how to build the latest code handler instead of just the source to compile.
I could try to make a code handler source file with in-line debugger patches, and I could probably also make a conditional assembler directive that allows you to specify whether you're building a GCN or Wii handler.
Quote from: dcx2 on August 09, 2011, 08:57:07 PM
I could try to make a code handler source file with in-line debugger patches, and I could probably also make a conditional assembler directive that allows you to specify whether you're building a GCN or Wii handler.
Nice. Hmm, if you do that, i have to update my stuff...
If you do that, how much work would it be to update it even further? Like to allow to specify where the code handler is put? 0x80001800 or 0x817FC000 for example. This could actually encourage me to write the high memory stuff, which would also allow more code lines. Would that help with the other topic?
Other than writing a new breakpoint handler, it should just be a matter of giving new command-line parameters to the build process so that it targets 817FC000 instead of 80001800, and then changing how the apploader hooks. If there's a way to pass in symbols to the assembler from the command line, it's even easier, otherwise you might have to edit one line at the beginning of the source to make it target GCN instead of Wii.