detecting EDTV mode

[Tybor]

Hi!

I wan't to start a discussion about the method how to detect the EDTV mode of the Wii.
Currently the only known method would be to check the VICLK register wheter Bit0 is set to 1.
This indicates that 54MHz VI clock is used which is necessary for progressive timing.

I know, this solution was already introduced to libogc sometime, but removed.
So which solution can be implemented into libogc?

Another topic is to detect wheter a PAL Wii or NTSC Wii is used. The current distinction is done by the DCR[8:9] register
which returns NTSC if the Wii is set to EDTV mode. This is not completeley wrong but the selection
function would set the video mode to an NTSC timing/mode which is wrong if you have a PAL Wii and TV.

So what do you think?

gr33tz,
Tybor

[Eke]

Does the documentation for Wii specific registers exist somewhere ?
I've seen some stuff in LibOGC about YUV filter and some special configuration when EURGB60 TV mode is set but I have no clue what this mean...


Also, this is a little off-topic, but there is a persisting and annoying problem with homebrews build with libogc on PAL wiis running at 60Hz, with RGB scart cable (the famous "red&black" screen issue)...

Forcing rendering mode to a EURGB60 compatible one after Video_init() instead of a NTSC one sometime fixes the problem but not always (strangely, this seem a random issue... and this also make the system freeze when GX rendering is used, never got such issues on gamecube )

What could be the reason for this issue ? Bad or incomplete register initialization ? Something remaining from a previous video configuration (also the TP loader always force TV_NTSC when detecting anything else than TV_PAL) ?

Again, i never had problem using NTSC rendering modes with my gamecube & RGB scart cable, i'm wondering what I'm missing

[Tybor]

Yes, there are some really strange code lines in the Video source. I don't have a clue what/why data is sent
to the DAC over I2C. I hope WinterMute or shagkur will post in here to clarify.

Could you be more specific which video modes you tried?

gr33tz,
Tybor

[WinterMute]

Eke, can you give some more details on this "famous "red&black" screen" ?

Unfortunately there is very little in the way of public Wii specific register documentation and I'd be the first to admit the libogc video code is a little on the overwhelming side. Checking the VICLK register to detect EDTV mode isn't actually going to work since this is dependent on the Wii actually being configured for an EDTV mode. There are several circumstances where you may not have a mode already configured or your app has been booted in a non progressive mode. We are still investigating ways to determine capabilities and/or use the preferred mode from the Wii system settings. Updates will be forthcoming in the not too distant future.

System freeze when GX rendering is used was caused by the Twilight loader leaving that system in an indeterminate state - this was fixed by a later chainloader afaik. I certainly haven't had problems on startup with that recently.

[Eke]

Eke, can you give some more details on this "famous "red&black" screen" ?

on a PAL Wii, if you configure the video mode to a VI_NTSC one (like we did on GC homebrew), you will always have a wrong colored signal (seems to have red component only) from the RGB scart cable....

Using EURGB60 modes instead somehow fixe the issues but not always: for example, the first time you load the elf, display is fine, but when you reload the TP loader which then reload your app, screen is red only (this is random, sometime you have to reload a few times before getting a correct output)

The same thing can happen if I first load a dol loader (modified to use EURGB60) then load a new app: the "red screen" issue might happen (or disappear) when the loaded dol starts...

I tried also to properly shutdown libogc before calling the TP reload stub or launching a new dol from a loader (I don't know if this is required ???) but it didn't change anything...

Another things:
.the screen is always fine when using the default video cable (RGB encoder specific issue ?)

. when the "red color" issue occurs, switching into a VI_PAL video mode will make the video signal getting out of sync (no video signal on TV) then come back if you reconfigure to 60hz.
Using the default video cable has the same result.
When the color is normal, you can switch between modes without problems (for both cables)

System freeze when GX rendering is used was caused by the Twilight loader leaving that system in an indeterminate state - this was fixed by a later chainloader afaik. I certainly haven't had problems on startup with that recently.

in fact, this was some kind of bug on my side: I was calling GXinit and executing some GX_ functions at init without calling GX_flush (this is called later, during rendering). As result, if I was reloading the emulator without effectively doing some GX rendering (ie, playing a loaded game), the next time it will boot and try to start rendering, system hangs...

[Eke]

additional info:
From what I've read on many website, the "red screen" issue with RGB cable is generally due to YUV video signal being output instead RGB...

The PAL gamecube was not able to output YUV signal, this is probably why there was nothing to configure;
The PAL wii, on the other hand, can output YUV in 480p mode (I think), so there is probably a way to configure the Video encoder to one of the format...

Just curious, where can we get infos about the __VISetYUVSEL and __VISetFilterEURGB60 functions ? How has it been discovered that there was some kind of I2C device to configure ???

EDIT: I think fixed the problem:
in __VIRetraceHandler, replace:

if(dtv!=oldDtvStatus) __VISetYUVSEL(dtv);

with

__VISetYUVSEL(dtv);

no more red screen at all !

[Tybor]

Hi Eke,

Nice! But somehow strange. _viReg[55] which is read into dtv, is described in YAGCD as:

VISEL - VI DTV Status Register
this register allows software to read the status of two i/o pins

The current implementation looks like, that some Pin Status is changed and when changed it should be sent through I2C to DAC.
The __VISetYUVSEL is only called in the Retrace Handler by the above mechanism.
But inside this function also the currTvMode is used.
Calling the __VISetYUVSEL in Retrace Handler every frame is no good solution because the I2C function has
hardcoded delays which slows down the performance.

I think this function should be called also on a change of currTvMode.

@Eke: could you try this?

gr33tz,
Tybor

[Eke]

The fact is that viReg[55] is never modified so the test condition is never met (except maybe at init, depending on the initial value of oldDtvStatus) and the function never called during execution time

Anyway, I'm gonna try another solution (maybe calling it only if Video_Flush has been called or like you said, only if tvmode ahas been changed), this was just a quick and dirty fix because I was sick of getting this red screen issue


edit: it worked, calling the function in the retrace handler, only when tv mode has been modified, is enough to fix the issue...

EDIT: here's the modification I made

dtv = _viReg[55]&0x01;
tv = VIDEO_GetCurrentTvMode();
if((tv!=oldTvStatus) ΙΙ (dtv != oldDtvStatus)){

__VISetYUVSEL(dtv);
oldDtvStatus = dtv;
}

[Tybor]

Great!

I will make a patch for this.
So now we can go back to original topic

post from WinterMute:

Unfortunately there is very little in the way of public Wii specific register documentation and I'd be the first to admit the libogc video code is a little on the overwhelming side. Checking the VICLK register to detect EDTV mode isn't actually going to work since this is dependent on the Wii actually being configured for an EDTV mode. There are several circumstances where you may not have a mode already configured or your app has been booted in a non progressive mode. We are still investigating ways to determine capabilities and/or use the preferred mode from the Wii system settings. Updates will be forthcoming in the not too distant future.

Current implementation for detecting the other video modes is just the same thing. You check the registers for what is actually set. So until we have another way to detect it we should use the way I described. I see no drawback on using this method.

gr33tz,
Tybor

[Tybor]

So, unfortunately this discussion doesn't gets started.

It seems to me that my proposal with the VICLK is currently the only way to detect if the Wii is in
EDTV mode.

gr33tz,
Tybor