XenoShell Custom Green Splash Screen after XenoGC Port

[seeWood]

Hello gc-forever Community,

i would like to share an Open Source Project for the XenoGC but it is not already finished. I need aknowledge for Debugging on the Gamceube.

A talented Friend of mine and me have ported the XenoGC Modchip to a Microcontroller Board that is cheap and easy to get. Things are working, the Drive patches now a lil faster... but!

Now we need some Debugging to get things fully working, moduleload, XenoShell and more, if you like

When we have success on Debugging we are able to:
- Flash the XenoGC without wiring things up like the Atmega8
- XenoShell is fully working (and hopefully swiss should work as .gci on Memory Card)
- No more need of a burned mini DVD, we can Access XenoShell with every original Gamecube Disc
- no more need of tweakin' the Laser (access to XenoShell with original Gamecube Disc)
- maybe we can write a module as .gci file that get access to sd2sp2 or GeckoSD in an automated process and loads swiss from the SD Card

So if you like to help us out, feel free to contact me and we can make the XenoGC great again

best regards
sWd

[seeWood]

Additional information for the Devs and everyone who is interested:

Actually the Main issue is that the XenoShell Payload is not working properly. We need someone who can check the Code from the XenoShell and take a look behind if there is something wierd.

Additionally we can check if there is a way to load code with a payload, module or Script from the memory card or directly from the SD Card. Or we find another way to load code from MC/SD.

Of course, the very main Goal is to load swiss!!

Here is the Code, the Pull Request is already merged into the Master!
https://github.com/andreacampanella/XenoGC328

[emu_kidid]

How big is the flash you're using? Try to put iplboot as your shell.

[seeWood]

The Chip we are using is a Atmega328 and the Flash Memory is 32kb. Its way bigger than the XenoGC Code on the Atmega8 (8kb) but to small for the iplboot. it is conceivable that someone can write a new Shell that fits the 32kb Flash perfectly from the Atmega328. (but thats only an Addition)

First of all, and thats the reason why we need help in Debugging on the Gamecube, we wanted to look into the XenoShell Code or Drivecode.

for this reason I registered and asked if anyone could help

[seeWood]

I changed the name of the thread. I think it's clearer now what this is all about. And... icontinued my work on that Chip

i compiled the XenoShell Custom from the original Fork an added it to the ported XenoGC. I can now reproduce the Failure i get when booting into the XenoShell Custom.

On the Screen "Press A/B to Load dol from MemCard A/B" happens the following:

Press A: It starts scanning the Memory Card and for a short second a "Green Screen" appears and it goes back to the "Press A/B to Load dol from MemCard A/B" Screen

Press B: It starts scanning the Memory Card and for a short second a "Green Screen" appears and then it goes into a Blackscreen and the Gamecube wont wake up again.

i added some pictures to show you guys how it looks like. Someone here who is familiar with the XenoShell Code and can help me out? I can test and compile everything by myself but i need someone who is willing to help me. I'm afraid I'm not familiar with the XenoShell Code.
https://user-images.githubusercontent.c ... 2ac7f0.JPG

https://user-images.githubusercontent.c ... 236bad.JPG

The XenoShell Custom Code can be found here:
https://github.com/emukidid/xenogcfork/ ... ell/source
You can submit me changes and i can compile it as soon as possible, test and gave a quick response.

Additionally i added the compiled XenoShell.bin from the official fork to my Port. it's just easier to reproduce for those who wanted to help me and test it.
https://github.com/seewood/XenoGC328

[seeWood]

I checked several Settings with the XenoShell and compiled it but it was not successful.

No one who can help me out or want to make ongoing development on the XenoGC?

Keep in Mind, that this Port has a faster Drive Patch than the original one on the Atmega8!

Feel free to contact me, check out the github: https://github.com/seewood/XenoGC328 and of course, lets use this Thread to work on it.

[emu_kidid]

The lack of replies on here should be indicative of how useful (or not) such a thing is to use in this day and age, but don't let it discourage you.

I'd recommend you make the DOL work in standalone in an easier to debug setup and then worry about booting it off the Xeno

[seeWood]

Thanks for that Answer.

Yeah i thought, that a maintained Open Source Project for our beloved Gamecube should be a great Deal these Days. Most Modchips are closed Source.

I check if i can create a DOL that works in standalone. Can i post it here and you check it? But keep in Mind that it is the XenoShell Custom from the official Fork - so when the XenoShell Custom works on a Atmega8 as a .bin, it should work as a DOL as well. But i check that!

One more thing i want to know is: When i start a burned Swiss Disc and have the sd2sp2 Adapter plugged in, it redirects me automatically to the sd2sp2 micro SD Card Files. Is it possible to isolalte the automated Redirection from the siwss code and put it in a payload?

So than we can start to check if it is possible to replace the XenoShell by holding the START Button on the Controller at the bootup to start the XenoShell. Maybe we can use this redirection from the "isolated Payload" to scan and start a swiss.dol file from sd2sp2/GeckoSD by hold START at bootup with original Disc in the Drive.

[Papy.G]

Additionally we can check if there is a way to load code with a payload, module or Script from the memory card or directly from the SD Card. Or we find another way to load code from MC/SD.

The 007:AUF save exploit is only 3 blocks big on a memcard, so the isolated payload code to run a .gci forwarder off the MC should fit in the additionnal memory you have in the 328.

If you do it via MC boot forwarder (DoLauncher), you'll have to provide a way to put such a file on an MC first, or it won't solve the problem most people are already facing when installing a game save exploit.

- maybe we can write a module as .gci file that get access to sd2sp2 or GeckoSD in an automated process and loads swiss from the SD Card

So if you like to help us out, feel free to contact me and we can make the XenoGC great again

I don't know anything about coding on the GC, AVR nor C: code, and don't specially care about modchips as I want to keep my consoles as genuine as possible, but for the sake of the community, if I can help in anyway by testing .gci or .dol on my PAL consoles, I'll be glad to do so, as I already did for the Viper modified IPL.

[seeWood]

Thanks for that offer! I appreciate that.

so the isolated payload code to run a .gci forwarder off the MC should fit in the additionnal memory you have in the 328.

But that means i need to have the 007:AUF Disc right? So i want to trageting that EVERY Original Disc can Load that "isolated payload". No one needs to check if this or that Game is "exploitable", so the Payload stays on a MemCard and can easily be loaded with a Modchip by Holding Start at bootup!

[Papy.G]

If you feed your code in the drive's data stream, you'll need a disc, but not specifically one or another.

I suppose the payloads in game exploits rely on some routines that are in the GC's rom, as they just load data from a memcard, then run this code, thus, are smaller than the forwarders to USB-EXI/SD cards that have to embed specific code to support any device structure/FAT format that are not natively supported by the cube.

May someone better informed on the topic correct me if I'm wrong.

[seeWood]

I suppose the payloads in game exploits rely on some routines that are in the GC's rom, as they just load data from a memcard, then run this code, thus, are smaller than the forwarders to USB-EXI/SD cards that have to embed specific code to support any device structure/FAT format that are not natively supported by the cube.

Yeah i think thats right. The MemCard Drivers are there - SD/exFat Drivers need to be adpoted or created. On other platforms it is also the case that the memory card drivers work directly. Can Someone confirm that for the Gamecube?

If you do it via MC boot forwarder (DoLauncher), you'll have to provide a way to put such a file on an MC first, or it won't solve the problem most people are already facing when installing a game save exploit.

The gci file would need to be put on the memory Card by someone who already has access to Homebrew - thats right (like FMCB for the PS2).

If you feed your code in the drive's data stream, you'll need a disc, but not specifically one or another.

it would be nice when we can implement the Code to the Data Stream.

What we need is a Swiss Loader on the MemCard:
The Payload should only be load the Memory Card via BIOS Call and start the Swiss Loader on the Memory Card. It should not be that much Code. Should be around 10 Lines. Hopefully emukidid or someone who has advanced aknowledge on the Gamecube can tell us more - to get that working.

[Diego borella]

Good. I downloaded these files from xenoGC 328.
my xeno is a common 8kb. 2.0
I wrote 1.1 for the xenoflash.328 .dol files

nothing happens. no 1.1

in the 0.98 beta shell,
pressing Y_
freezes.
pressing Z_
looks for the boot, but ends up on a green screen.
tried other keys, nothing ..

sdgecko flashes green led.
the screen happens even with nothing in the inserted slots.

the only way to get Xenoshell 1.0 is to clone xeno?
the xenoshell menu doesn't appear because i use xeno 8k?

[seeWood]

You have to compile the hex file and you have to Flash it to a atmega328 i.e Arduino Pro Mini.

It does not work on a Atmega8/8L.

XenoShell 1.05 is working Fine, but the XenoShell Custom isnt.

So no one is writing Code in assembly anymore and i cant find one who is willing to help me out.

The Drivecode works very well and better as the official clone but the XenoShell Custom is useless for now

[Diego borella]

It does not work on a Atmega8/8L.

friend, i'm telling you: the beta version of 0.98 is working on xeno atmega 8k! #
all the flashes in your package worked on my xeno.
I am now in version 0.98 beta.
recording was done! #

everything worked 100% every xenoflash 328.

I thought it was weird, but it worked and it works so far #

XenoGC 328 package.
Warranty!#

[seeWood]

Yeah, but this files are only from the official fork. If you want to create a hex build for atmega328 you have to compile it. there is no per-built hex file for it.

The other hex files are untouched from the official fork.

[Diego borella]

my arduino is on its way ... R3 uno.
it comes with the 328 chip. It was for 10 dollars. and remittance from Brazil.
I still think I can program more Atmega chips with it.
I don't think I need anything else to program it. there is ???
Look:

[Diego borella]

Better Idea, - pressing a button combo?

point 1
the atmega 328_ because it is bigger and faster. this speed must be taken advantage of.
point 2
any original disc must be used.
point 3
press the buttons any Z or Y etc.
boot and also boot2
a chip to read backups, focused on boot launcher.

[Maddkatt]

What about using an ic big enough to store a SWISS dol boot file and writing a button combination to load said bootfile in place of the auto load for dvd? Even better fool the dvd rom drive into thinking there is the swiss boot disc in the tray if the button combo is pressed?

[Diego borella]

but which Ci_chip would adapt to the xeno code?
you would write the code for this new Ci.
there is already a hyperboot that does this, but it is closed source.
xeno depends on a disc as far as i know.
this diskless job is what everyone is looking for ...
swiss is above 3 megs and I think it will get bigger ...