The USB Gecko open source project is now listed below:
http://code.google.com/p/geckodownloads/ (http://code.google.com/p/geckodownloads/)
Downloads:
http://code.google.com/p/geckodownloads/downloads/list (http://code.google.com/p/geckodownloads/downloads/list)
All PCB files, schematics, VHDL files are included under the BSD license.
Gecko OS is licensed under GPL V2 due to various GPL sources used.
SVN will be set up VERY shortly.
MOD EDIT: link fixed
Is this the latest source code for Gecko 1.9.2.
I hope not.
Last time WiiGator f#*%? every thing up and Nuke stop't
giving out new updates for a long long time.
This looks like history repeating it's self again.
............NOT GOOD........... :(
The sources had to be uploaded for reasons I do not want to comment on. It's to prove that Gecko itself and all official USB Gecko applications have nothing to do with piracy in any way!
For 1.07 - the damage has been done. So you might say Gecko 1.9.2 might have a better apploader - however: for backup loaders they patched discs to get compatible.. so they used methods to make games compatible which is not possible to achieve with Gecko >1.8 - releasing the apploader now makes no real difference.
It had to be done, we didn't want to do it either!
Quote from: memorris on August 01, 2009, 10:22:42 AMLast time WiiGator f#*%? every thing up and Nuke stop't
giving out new updates for a long long time.
This looks like history repeating it's self again.
............NOT GOOD........... :(
While we did not appreciate Gecko OS being turned into a warez loader, what really was unacceptable for us was the credits being left as is - we don't want our names to be associated with a warez loader! :mad: With these new sources the credits are being left out; that way if someone decides to modify them they will not be directly associating the changes they made with us by not making clear what they changed. Also we now have a disclaimer (http://wiird.l0nk.org/forum/index.php/topic,3976.0.html) to explain clearly that we are not involved with, nor do we approve of, warez loaders that have been created from modifying our sources.
Is haven't been able to find the WiirdGUI's sources anywhere, is this just me or are those left out on purpose?
Quote from: Romaap on August 01, 2009, 02:38:13 PM
Is haven't been able to find the WiirdGUI's sources anywhere, is this just me or are those left out on purpose?
The WiiRd GUI sources are kenobi's property.. kenobi is hard to reach at the moment and the GUI is obviously not able to condone piracy in any way as the GUI visibly only controls the WiiRd console.. therefore there are good reasons to leave it out of the collection
Quote from: Link on August 01, 2009, 11:07:18 AM
The sources had to be uploaded for reasons I do not want to comment on. It's to prove that Gecko itself and all official USB Gecko applications have nothing to do with piracy in any way!
For 1.07 - the damage has been done. So you might say Gecko 1.9.2 might have a better apploader - however: for backup loaders they patched discs to get compatible.. so they used methods to make games compatible which is not possible to achieve with Gecko >1.8 - releasing the apploader now makes no real difference.
It had to be done, we didn't want to do it either!
Sorry you don't know what you are talking about. The code that prevents patched games to be loaded could be just removed from Gecko OS if somebody really wanted to make another backup launcher based on Gecko OS. Also i just saw that Gecko OS did not apply 2 "patches" to the loader that make more games compatible and are methods that have to be used on all games backup or retail doesn't matter for it. Also the patching of discs is useless on usb loaders anyways. Region patchers are useless, because video mode patching in a loader(if i saw that correctly, that feature is still missing in Gecko OS) works much better. Does Gecko OS have code to patch Country Strings? That's required to get some import games to work, for example Punch Out US version on japanese Wiis. And last but not least, the lastest method to get games to work, is loading the real game .dol directly and skipping the main.dol, which would perfectly work on Gecko OS too, and if debugging is not possible in some of the multi .dol games, with alternative .dol loading it might be.
I just wanted to point out that Gecko OS might be a nice loader and the 1st of his kind, but the backup scene wasn't dependent on it after the 1st release.
Quote from: WiiPower on August 02, 2009, 04:04:27 PM
I just wanted to point out that Gecko OS might be a nice loader and the 1st of his kind, but the backup scene wasn't dependent on it after the 1st release.
True that, multiple improvements were done.. the applications have gone different paths which is quite natural.. still you can expect many of the things which were changed in between on Gecko OS to move into backup loaders.
Sorry I guess I posted in a false way but I really did not mean it.
Quote from: Link on August 02, 2009, 05:04:09 PM
Quote from: WiiPower on August 02, 2009, 04:04:27 PM
I just wanted to point out that Gecko OS might be a nice loader and the 1st of his kind, but the backup scene wasn't dependent on it after the 1st release.
True that, multiple improvements were done.. the applications have gone different paths which is quite natural.. still you can expect many of the things which were changed in between on Gecko OS to move into backup loaders.
Sorry I guess I posted in a false way but I really did not mean it.
I guess your are right, but Gecko OS really could use some of the improvements i made. I think Gecko OS 2 main features for disc game launching are region free and debugging/ocarina, and for the 1st one, backup loaders work better right now.
I thought backup loaders couldn't hook on all games?
how does this make them "better"?
Quote from: hetoan2 on August 03, 2009, 02:33:21 AM
I thought backup loaders couldn't hook on all games?
how does this make them "better"?
If you can't play a game at all, but hook into it, that's better? And US people with non HDTVs, get black&white playback on half PAL games, but hooking works, that's better too?
I'm not against this being open source, hopefully someone uses the source so that I can actually use it with USBloader on more recent games.
I'm not saying that this will aid piracy, but If pirates weren't so damn cheap then they wouldn't really care that they cant hook CoDWaW with their backup loaders. Honestly, its not too hard to burn a disk and use modified IOS's.
Well, it's true sometimes the focus for Gecko OS was highly on Hooking compatibility.. fact is: well, Gecko is developed as an enhancement for the USB Gecko to allow debugging games and also to allow cheating in games.. both functions require hooks if you want to do it in real-time with unpatched games (okay.. assembly modifier codes would work without hooking).. but true, that's probably too much the focus.. if Gecko were only about playing import games.. then I guess hooks would be much less relevant.. as we however kinda want both.. imports AND debugging functionality, some ways have to be found.
For backup loaders the obvious focus is "Get that game to work" (though I respect that point is probably hard enough seeing 002 protections and general cIOS stuff) and not like ours "Get that game to work and also so that I can debug it". Aims are different.. and sometimes it's really hard to find the gap between "This is priority" and "No, that is priority" is kinda low.
But yes: if we only wanted perfect import compatibility then Gecko 1.9 would have to copy many achievements which have been succesfully made on the backup loader side..
Thanks for making it open-source.
First, GeckoOS. Next, Microsoft Windows. Oh, then the world.
How come the download website is telling me "google error forbidden your client does not have permission to get URL /p/usbgecko/downloads/list from this server" But before I could?
http://code.google.com/p/geckodownloads/downloads/list
MOD EDIT: fixed
Same here.
Just got my USB Gecko today & I went to access http://code.google.com/p/geckodownloads/ & I can't.
Trying to head straight to http://code.google.com/p/geckodownloads/downloads/list gives me a 403. I thought it was public access, is this just a temp glitch w/ googlecode or something? Is there a mirror to the files by chance?
I know that most stuff is on the disk but I wanted to make sure I have all the latest drivers, tools, & such before hand.
Thanks much
MOD EDIT: link fixed
We're going to restore access soon.. Nuke deleted the project without brkirch's or my knowledge.. so well.. we're a bit puzzled.. we'll get in contact once it's online again! Everything is backed up, no worries!
Quote from: Link on February 23, 2010, 09:01:42 AM
We're going to restore access soon.. Nuke deleted the project without brkirch's or my knowledge.. so well.. we're a bit puzzled.. we'll get in contact once it's online again! Everything is backed up, no worries!
Sweet! That's a bummer that Nuke "nuked" it... I ended up spelunking around & found a link to latest driver here in this post (http://wiird.l0nk.org/forum/index.php/topic,4782.msg41792/topicseen.html#msg41792) from Ian. I got WiiRD & had a copy of gecko 1931 on my PC & I spaced it (anyone looking for gecko they have 1901 on the WiiRD blog (http://wiird.l0nk.org/wp/download)).
I started messing around and poking out a few codes last night. Thanks for keeping us posted Link & you have a good one. :)
http://wiird.l0nk.org/projectfiles/
I also uploaded one of the latest SVN snapshots.. we are very probably going to set up a new SVN and everything should be back to normal.. for now.. sorry, right now that's all I can offer :(
Thanks GREAT news .... 8)
Keep us posted .... ;D
AX
Hi, I've been trying to compile from the source provided (using the svn in link's projectfiles) and I've run into a few problems. I'm using the latest version of devkitPro as well as the zlib pre-compiled library for said version of devkit pro under Windows 7.
Firstly, the source as provided doesn't compile, I believe this is because line 126 of gfx.c is
Vector axis =(Vector) {0 , 0, 1 };
when it should be
guVector axis = (guVector) {0,0,1};
and the same again on line 179.
Also /libpngu/pngu.h at line 440 refuses to compile since its looking for zlib.h as a non-system file (assuming that this is supposed to be the pre-compiled zlib header I changed it to a system file reference, <zlib.h> instead of "zlib.h" and added $(PORTLIBS) to the makefile , which causes it to compile. But there are a lot of warnings, however most are about non-explicit casts and different signedness and incompatable pointer types, which should theoretically be fine assuming they are are left in there due to a lack of cleanup desire as opposed to because they are actual errors, which can be hard to tell without a detailed inspection (and I confess to being unfamiliar with the PPC architecture, although I'm fairly familiar with C).
Now I have a boot.elf and a boot.dol.
Since Gekoo OS uses the boot.elf , I take the boot.elf and notice a problem in passing, the proper boot.elf is 494 kb , my boot.elf is 882kb, I assume that this is just to the proper boot.elf being packed and proceed on my way (I tried packing it too later on using dosbox since the packing program is 16-bit and suffice to say it doesn't change anything except needing to edit the makefile in the packer directory to add the appropriate entry point as the readme says easily enough done by looking at the format from the gecko_src makefile).
Program boots , (great) , no option to launch rebooter or channels (fine, what I'm trying to do is modify this to run off of IOS 236 if IOS 36 isn't patched (mine isn't) and IOS 249 lacks the identify patch (which the current version of it does), so that's what I'm expecting), try and launch WiiSports DVD (which I've already started through the properly compiled Gecko OS and it works), and I get a (Program) Exception has occured and Stack Dump screen.
Any help or insight ?
Thanks
Elaugaufein
If you are lucky this code dump is random and comes from bad IOS Reload code in libogc. Here's the description how to get the libogc that i use(and got rid of some IOS Reload related errors by it):
This application is compiled with devKitPPC r21 and a patched libogc 1.8.3(+libfat 1.0.7 + zlib). To rebuild the used libogc, get the source for libogc 1.8.3 and replace s32 __IOS_LaunchNewIOS(int version) with the one from libogc 1.7.1:
s32 __IOS_LaunchNewIOS(int version)
{
u32 numviews;
s32 res;
u64 titleID = 0x100000000LL;
STACK_ALIGN(tikview,views,4,32);
#ifdef DEBUG_IOS
s32 oldversion;
#endif
s32 newversion;
if(version < 3 || version > 0xFF) {
return IOS_EBADVERSION;
}
#ifdef DEBUG_IOS
oldversion = IOS_GetVersion();
if(oldversion>0) printf("Current IOS Version: IOS%d\n",oldversion);
#endif
titleID |= version;
#ifdef DEBUG_IOS
printf("Launching IOS TitleID: %016llx\n",titleID);
#endif
res = ES_GetNumTicketViews(titleID, &numviews);
if(res < 0) {
#ifdef DEBUG_IOS
printf(" GetNumTicketViews failed: %d\n",res);
#endif
return res;
}
if(numviews > 4) {
printf(" GetNumTicketViews too many views: %u\n",numviews);
return IOS_ETOOMANYVIEWS;
}
res = ES_GetTicketViews(titleID, views, numviews);
if(res < 0) {
#ifdef DEBUG_IOS
printf(" GetTicketViews failed: %d\n",res);
#endif
return res;
}
res = ES_LaunchTitle(titleID, &views[0]);
if(res < 0) {
#ifdef DEBUG_IOS
printf(" LaunchTitle failed: %d\n",res);
#endif
return res;
}
__ES_Reset();
newversion = IOS_GetVersion();
#ifdef DEBUG_IOS
printf(" IOS Version: IOS%d %d.%d\n",newversion,IOS_GetRevisionMajor(),IOS_GetRevisionMinor());
#endif
if(newversion != version) {
#ifdef DEBUG_IOS
printf(" Version mismatch!\n");
#endif
return IOS_EMISMATCH;
}
return version;
}
A compiled version for windows of this libogc is available here:
http://www.mediafire.com/?2918dox8zls229l
But i don't really think this will help, i got a similar issue the last time i tried to compile it. I fear you need to manually hunt down the problem.
Anyways, i think you should change some of the code if it wasn't done yet. If you use a patched IOS36, then i recommend to require ignore signatures, patched nand permissions and ES_Identify patching. This will allow you to just access the files of the channels directly without using ES_Identify, and then identify as the channel before launching. If you patch newer IOS for ES_Idenitify, it only works once per IOS Reload, while Gecko OS was written for IOS36v1042 which can't access files directly, but can use ES_Identify as often as you want.
And before anyone gets a dumb idea, IOS36v1042 does not work on over the half of all Wiis and could even "kill" your HBC if it uses that, so don't install it!
PS: It could still be an IOS Reload related problem. Before doing an IOS Reload, you need to shutdown all subsystems, like storage devices and WPAD.(PAD does not need to be shutdown)
isn´t it a secret built? :confused:
I thought we aren´t supposed to post it on the public section, whatever...
The new built won´t improve anything for "gct cheaters" anyway, only for coders :D
Quote from: Bully@Wiiplaza on May 15, 2011, 12:40:15 PM
isn´t it a secret built? :confused:
I thought we aren´t supposed to post it on the public section, whatever...
The new built won´t improve anything for "gct cheaters" anyway, only for coders :D
Now that i see were this was posted I'm not sure, so i've removed the post. oops
This thread is old.
The source code for Gecko OS has always been linked off wiibrew.org, the hardware vhdl files however are pretty old but I linked to the final vhdl in this forum.
I keep downloads here now:
http://code.google.com/p/geckodownloads/downloads/list
It is old code now and quite bad code but it is good starting point to make own / better loader.
Gecko OS 2.0 will get a release but I need to r&d some new features, as it not worth releasing until I have something fresh / cool to bring you folks.
Just a few random suggestions:
- Make it possible to lower Arena1Hi by 16/32/64 KB for lots of memory for codes
- Gamecube Ocarina&debugger
- A more easy way to implement main.dol/code handler/fst patches. I think some codes are actually patching the main.dol or the code handler, so moving them to the gameconfig.txt would free up some memory available for codes. But other than Brawl+ and similar i haven't seen this being used. Hmm, the same format as the .txt but with the title id of the game? For moving the code list & patches. Maybe that's already implemented, it's been a while since i looked at Gecko OS' source code, if it is, it might need more promotion. I know that changing this stuff as codes is required if the game does a .dol loading process, but these games are rare.
- Video mode patches to allow component cables to be used on more games and playing (almost?) all import games in color even if the tv doesn't support the other region
Some GC games are not working by just booting MIOS, Eternal Darkness and Starfox Adventures for example. This is due to the audio streaming, which has to be enabled before booting BC.
#define IOCTL_DI_DVDLowAudioBufferConfig 0xE4
static u32 bufferin[0x20] __attribute__((aligned(32)));
static u32 bufferout[0x20] __attribute__((aligned(32)));
s32 setstreaming()
{
u8 ioctl;
ioctl = IOCTL_DI_DVDLowAudioBufferConfig;
memset(bufferin, 0, 0x20);
memset(bufferout, 0, 0x20);
bufferin[0] = ioctl << 24;
if ( (*(u32*)0x80000008)>>24 )
{
bufferin[1] = 1;
if( ((*(u32*)0x80000008)>>16) & 0xFF )
{
bufferin[2] = 10;
} else
{
bufferin[2] = 0;
}
}
else
{
bufferin[1] = 0;
bufferin[2] = 0;
}
int Ret = IOS_Ioctl(__dvd_fd, ioctl, bufferin, 0x20, bufferout, 0x20);
return ((Ret == 1) ? 0 : -Ret);
}
This function executed after reading the disc id fixes this problem.
Quote from: WiiPower on May 18, 2011, 09:29:30 AM
- A more easy way to implement main.dol/code handler/fst patches. I think some codes are actually patching the main.dol or the code handler, so moving them to the gameconfig.txt would free up some memory available for codes.
i think this also has to do with the way the website is laid out. i large portion of the codes i have uploaded to the website are one-line 04 codes that are patching some ASM in the main dol. they could just as easily be added to the gameconfig.txt using its poke( ... ) feature. but i dont think the code website has any support for gameconfig.txt hacks, and therefore no code downloader ive tried can get the codes. so, AFAIK, the only way to share these haxx via the website is by making them into a 04 code to be put in the gct.
I asked Mathew_Wi to update his GCT editor to include GPF support. If he gets it working, then you can just take 04 codes from the database, drop them into his app, and it will spit out the GPF file that you can place on your SD card. No need to mess with gameconfig.txt.
....doesn't the gpf only run once?
Yeah. It runs once, I think after the dol was loaded into memory, but before control is passed over to it.
Simple ASM patches (like nop'ing the stw) only need to be written once. It won't work for data hacks like inf health because that needs constant writes, and it won't work for C2 codes because the C2's ASM won't be loaded into memory. But when you're struggling to fit all your codes in, being able to load the simple ASM patches from something other than your GCT file can give you that little bit of room that you need.
Quote from: dcx2 on June 03, 2011, 02:37:32 PM
I asked Mathew_Wi to update his GCT editor to include GPF support. If he gets it working, then you can just take 04 codes from the database, drop them into his app, and it will spit out the GPF file that you can place on your SD card. No need to mess with gameconfig.txt.
@WiiPower, does the new GeckoOS Mod with the newer code handler also support GPF's for GameCube games? (I don't know anything about how GPF's are implemented, which is why I didn't look at that feature when I sent you the modified sourcecode.)
Gecko OS mod does only support the code handler and a very small part of the gameconfig.txt stuff. And that only for wii games.
So I had this great idea. Make an application that cuts and pastes new code handlers into the .dol of a homebrew app that's running an old code handler (e.g. Gecko OS Mod). This idea is nice because then I can start releasing custom code handlers instead of having Gecko.NET patch them.
So I looked through Gecko OS Mod and pretty easily found the code handler binary blob. Three copies, actually, which makes sense; codehandler, codehandlerslota, codehanderonly.
The same search on Gecko OS 1931...fails. 1932 fails as well. I can't find the binary anywhere. I searched both the dol and elf. Maybe the elf is packed or something?
If your code handler is bigger, i expect some problems when your code handler is bigger than the old one. And for Gecko OS mod, it would be easy as well to just add it to the source and recompile.
Yeah, there are some limitations on how much blank space is left at the end. It seems like there's about 332 bytes of blank space at the end, and that's assuming I'm trying to patch the smallest code handler.
Recompiling isn't easy for me because I don't have devkitppc or any of that installed. And I was hoping to make something generic so that anyone can patch any homebrew loader with any custom code handler.
Quote from: dcx2 on August 14, 2011, 06:34:11 PM
Yeah, there are some limitations on how much blank space is left at the end. It seems like there's about 332 bytes of blank space at the end, and that's assuming I'm trying to patch the smallest code handler.
Recompiling isn't easy for me because I don't have devkitppc or any of that installed. And I was hoping to make something generic so that anyone can patch any homebrew loader with any custom code handler.
Isn't that the reserved space for variables? So if your code handler is bigger, that space if moved and then overlaps something else. Well, i'm not very good at this, so i could be wrong.
The code handler sits in the reserved area of memory, 80001800 to 80003000. However, the C array that the code handler is "stored" in (codehandler.h) is 0x10C0 bytes. That puts the end of the code handler at 800028C0 - which is precisely where the code list begins. The code list then consumes the remaining portion, from 800028C0 to 80003000.
The space isn't so much "moved", as it is "reduced" or "pushed back". If I added 0x40 bytes of patches to the code handler, then I would push the start of the code list back to 80002900. Technically I would be over-writing where variables are *supposed* to go, but it doesn't depend on the initial values and it wouldn't write to anything above 80003000. It just means that the debugger would have fewer code lines to work with, which is already true when Gecko.NET connects. EDIT: on second thought, this would also break SD Cheats, because the code list wouldn't be where the loader expected it to be. This could probably be worked around with gameconfig.txt
I'll have to try manually splicing a new code handler in with a hex editor. But none of this answers why I couldn't find the code handler in Gecko OS' dol or elf files. Is there some sort of packing that can be done on homebrew executables?
Quote from: dcx2 on August 15, 2011, 01:54:17 PM
The code handler sits in the reserved area of memory, 80001800 to 80003000. However, the C array that the code handler is "stored" in (codehandler.h) is 0x10C0 bytes. That puts the end of the code handler at 800028C0 - which is precisely where the code list begins. The code list then consumes the remaining portion, from 800028C0 to 80003000.
The space isn't so much "moved", as it is "reduced" or "pushed back". If I added 0x40 bytes of patches to the code handler, then I would push the start of the code list back to 80002900. Technically I would be over-writing where variables are *supposed* to go, but it doesn't depend on the initial values and it wouldn't write to anything above 80003000. It just means that the debugger would have fewer code lines to work with, which is already true when Gecko.NET connects. EDIT: on second thought, this would also break SD Cheats, because the code list wouldn't be where the loader expected it to be. This could probably be worked around with gameconfig.txt
I'll have to try manually splicing a new code handler in with a hex editor. But none of this answers why I couldn't find the code handler in Gecko OS' dol or elf files. Is there some sort of packing that can be done on homebrew executables?
There are .dol compressors in existence; one of them is at http://www.fuzziqersoftware.com/projects.php . So yes, that could be the reason why.