Can not read SD.

[Skyground95]

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.

[James0x57]

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 )

[dcx2]

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...

[WiiPower]

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.

[dcx2]

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.

[WiiPower]

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.

[dcx2]

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?

[WiiPower]

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...

[dcx2]

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?

[WiiPower]

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.

[dcx2]

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"

[WiiPower]

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...

[dcx2]

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.

[biolizard89]

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.

[WiiPower]

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.

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.