I have not managed to run my ATMEGA8L.
The programming is going well, avrdude says it is OK.
I programmed my ATMEGA8L with the file "XenoAT.1.05.hex" from the archive
I tested the following fuisibles but it did not work:
- lfuse->0xE4 hfuse->0xD8
- lfuse->0xC4 hfuse->0xD9

when I plug my ATMEGA8L in my dvd reader, the original games will launch but not the backup disc.
When i press START, nothing happens

It's been some time since the last post here. Has anyone been able to compile this with a completely Open Source library (liboGC)? I am interested in making my XenoGC load something from the SD Card (eventually) but I don't want to start mucking with source if I can't compile to test the results.

<@costis> if so, that guy stalked me and found a ton of my e-mail addresses
<@costis> and spammed shit to me

But what is this gclib we have here in the thread?

I have taken some time to look through the XenoGC Source and the GCLib that is attached in this thread.

I've come to the conclusion that the the GCLib in this thread is, indeed, Costis' GCLib (See the opening comments such as "GC_Debug.c by Costis\n\nVersion 1.0"). I've also been looking through the XenoGC Map files and found that the GCLib the Xeno Author used was compiled from source and that source bears an uncanny resemblance to Costis' GCLib. This is based on the file structure having huge similarities (file naming conventions) and even some of the functions having identical names to Costis' GCLib (See xenoflash.map:67 "GC_VIDEO_INIT" which is used in DvdTest\Main.cpp:1278, etc.).

Someone please correct me if I'm wrong, but I think we "only" need to get our hands on a more recent copy of Costis' GCLib in order to compile the programs associated with the XenoGC. This would be a huge boon to the community!

This might be a little offtopic but is there another way to use the flasher DOL to flash the XenoGC to 2.0 without the need of bridging the GND to any of the XenoGC letters? I am not sure how it works, but maybe using uldorel to disable the chip before it starts to flash?

Alberto, not to my knowledge. That is a function of the ATMega8L on the XenoGC and that specific pin (I believe it's the reset pin) triggers something in the Xeno.

One feature I would like to implement in an updated Xeno firmware is the ability to trigger the reset from the Uploader (XenoFlash.dol) but I am not at that point yet. (This would still require an update though, it would just be additional functionality.

Another update vector could be to upload the updated firmware to the ATMega by an ISP Programmer (for a cheap programmer use an Arduino with the ArduinoISP sketch) but this would still require some soldering.

This might be a little offtopic but is there another way to use the flasher DOL to flash the XenoGC to 2.0 without the need of bridging the GND to any of the XenoGC letters? I am not sure how it works, but maybe using uldorel to disable the chip before it starts to flash?

Thank you.

The purpose of connecting ground to the XENO letters is to put the chip in a reset state to allow writing update files. The flasher/software will detect the status of the chip to ensure it is in RESET status else nothing can be written..

dantheman2865 wrote:Alberto, not to my knowledge. That is a function of the ATMega8L on the XenoGC and that specific pin (I believe it's the reset pin) triggers something in the Xeno.

One feature I would like to implement in an updated Xeno firmware is the ability to trigger the reset from the Uploader (XenoFlash.dol) but I am not at that point yet. (This would still require an update though, it would just be additional functionality.

Another update vector could be to upload the updated firmware to the ATMega by an ISP Programmer (for a cheap programmer use an Arduino with the ArduinoISP sketch) but this would still require some soldering.

I hope this is helpful!

RESET on the Atmega can only be achieved thru a hard wired connection. No command line functions will allow the chip to go into a true reset status..

There is an issue with using an ISP to flash updated files...
the xeno board was not designed to allow dual interface to an IPS connection while also being connected (soldered) to the GC. Doing so will cause failure of the chip to boot and the ISP will fail to establish communication to the chip. Modification to the Xeno board will be required to allow both 1. permanent GC connection & 2. ISP communication..

however, to use the xenoflasher.dol the chip must be put into reset status by physical connection of ground to reset pin..

emu_kidid wrote: beer is like WD40 for megalomaniac's brain, gets the gears moving

Anybody knows which bugs have been fixed between the 1.0 and the 2.0 version? Besides the Shell to load multigame discs
I've read somewhere years ago that somebugs were corrected but it didn't mention them

The XenoGC installation I have done is a bit messy to risk adding two more solder points. I am not good at soldering (but I should learn, all this stuff is very interesting)

Maybe I could solder a cable to GND in an alternative point which is far, but I am not sure which. By the way, there are some holes on the drive board that seem to do connection once a cable is inserted on them. Has anybody tried?

the Xeno or Atmega8 (Xeno clone) can be upgraded/downgraded (or initial programming for Atmega) using the various xenoflash.dol's included in the source..
In order to put the microcontroller in program(write) mode, RESET pin (1) must have constant contact with GND during the write process.

The printed letters "XENO" are in contact with RESET therefore connecting any of those letters with GND will put the chip in program mode. The letters are quite big and make for easy soldering of a wire lead. Also GND can found anywhere on the GC, such as the metal cage around the optical drive which also makes for easy soldering.

These two leads should be connected to an on/off switch rather than a reset (push) switch.
ON = leads have contact
OFF = no contact

After pressing A it will perform a flash erase and a flash write. When the process is completed, reboot and set switch to [OFF] . The software does not perform error checking to confirm if the switch is in the right position, nor will it indicate if the microcontroller is in programming mode.

I have successfully written all three versions using the xenoflasher.
here are a few pics: