Linux on the Nintendo GameCube and Wii

On Tuesday 27 January 2004 00:02, Carlos Correa wrote:
> point, and why some gamecubes have different problems the other from what i
> hear.

its almost certainly the different loaders that cause the problems... none of
them is perfect (and that also includes tmbincs ipl, and my own elfloader aswell)
and they all cause other weird issues :=P

gpz

On Jan 27, 2004, at 12:02 AM, Carlos Correa wrote:

> Razor123:
> =A0
> 26 January 2004: Preliminary framebuffer code in CVS=A0=20
> drivers/video/gamecube.c can clear the screen and hopefully soon=20
> display text.
> =A0
> =A0
> Nice code, but i would like to know who did it. I think it was mist=20
> but i could be wrong, also if needed i think i have some ideas on=20
> having text displayed, maybe even in color.
> also, i haven't test the kernel due to need to buy a bba and=20
> Pso(game), so would like to know what happenes up to this point, and=20=

> why some gamecubes have different problems the other from what i hear.

I can't say anything about the crashes at various points on different=20
machines.

The framebuffer code has been written by myself. Well, written is the=20
wrong term. Ripped. I used vesafb (because it seems to be the simplest=20=

and most generic driver), removed most of what deals with VESA and=20
hardcoded it to 16 bits/pixel. I know this won't produce the correct=20
result, because 16 bits means RGB 5:5:5, but we should already see=20
*something*. As soon as we do, we can finally implement the correct=20
algorithm for this colour coding.

At the moment, both tmbinc's console driver (which does not a=20
framebuffer driver, it only listens to puts() and prints that on the=20
screen using its own code) and the framebuffer driver are enabled, so=20
both should print on the screen. Unfortunately, only the console driver=20=

actually prints on the screen, but the framebuffer driver gets=20
initialized (the console driver prints a message about framebuffer=20
initialization), and the framebuffer driver also clears the screen when=20=

it gets initialized.

It may be a problem that the "framebuffer console" driver does not get=20=

used (as the console driver continues printing after framebuffer=20
initialization), but the kernel messages tell us that the kernel=20
switches the console to the framebuffer. Weird.

   Michael=