Cloning the Gamecube component cable

The place for all discussion on gaming hardware
thebigcheese
Posts: 707
Joined: Sun Aug 21, 2016 5:18 pm

Re: Cloning the Gamecube component cable

Post by thebigcheese »

Unseen wrote:New release: GCVideo 3.0a. Fixes a likely flash memory corruption when saving settings.

I didn't hit that bug because my system already had a valid v6 settings record from development. If you didn't have that, there was a 1 in 8(?) chance (depending of the number of previous settings records) that you would only suffer from settings that would not load on restart instead of corrupting the flasher bitstream.

Edit: Oh, and using the internal update function to install 3.0a from 3.0 should be safe.
Thanks for the quick update! Seems to be working perfectly now. I've restarted the console several times and it continues to work and the settings are saved. Looking forward to never having to open the console up for this again :)

Out of curiosity, I notice one of the (new?) settings is for the digital video format. By default, this is set to RGB-F, which is fine. But it seems like changing it also changes the analog video format. For example, I'm using RGB over analog and setting it to RGB-L also sets changes the analog output. Is that the intended behavior? It's not a big deal for me, just curious.
User avatar
Extrems
Posts: 540
Joined: Sat Jan 30, 2016 5:01 pm
Contact:

Re: Cloning the Gamecube component cable

Post by Extrems »

https://github.com/ikorb/gcvideo/tree/master/Firmware#note-about-hardware-with-analog-output
GCVideo-DV is primarily designed to provide a high-quality digital video output, but some hardware implementations of it feature an additional analog video output. This output is strictly treated as a second-class citizen, it cannot be configured fully independently of the main digital output. For example, if you enable RGB limited range, this will also affect the signal range on the analog output if that is set to an RGB mode.
User avatar
Unseen
Posts: 723
Joined: Sun May 25, 2014 8:12 pm
Contact:

Re: Cloning the Gamecube component cable

Post by Unseen »

thebigcheese wrote:But it seems like changing it also changes the analog video format. For example, I'm using RGB over analog and setting it to RGB-L also sets changes the analog output. Is that the intended behavior? It's not a big deal for me, just curious.
Yes, it is intentional. There is only space for a single color space converter in the FPGA, so the analog output in RGB mode gets whatever the digital output uses. Analog in YPbPr mode just splits off the signal before the color space converter, so it is not affected by the brightness/contrast/saturation settings in the picture menu.
thebigcheese
Posts: 707
Joined: Sun Aug 21, 2016 5:18 pm

Re: Cloning the Gamecube component cable

Post by thebigcheese »

That's what I figured. No worries then. Thanks again!
Lostdotfish
Posts: 17
Joined: Tue Feb 06, 2018 12:01 pm

Re: Cloning the Gamecube component cable

Post by Lostdotfish »

Can you explain how the updater works please? Is the new firmware actually encoded into the video signal by the homebrew and then picked up by the current firmware while in update mode? Does this mean future updates will just require running the new updater? Will it automatically support all hardware variations?

Also, any guidance to get 3.0a on my gcplug?
User avatar
Unseen
Posts: 723
Joined: Sun May 25, 2014 8:12 pm
Contact:

Re: Cloning the Gamecube component cable

Post by Unseen »

Lostdotfish wrote:Can you explain how the updater works please? Is the new firmware actually encoded into the video signal by the homebrew and then picked up by the current firmware while in update mode?
The updater just shows whatever image data is embedded to it, most of the "magic" happens on the FPGA with a special configuration, running the firmware update tool. When booted, a modified version of GCVideo starts on the FPGA that is missing some features (e.g. audio) and instead uses the space to implement a module that can capture selected lines from the image.

Each line in the image has a marker at the beginning, followed by "coordinates" that identify which copy of the firmware and which part of it the line belongs to. The data itself uses a slightly weird encoding and it's also compressed and scrambled to save space and make the flickering effect more even - with the current 8 firmwares, the updater.dol switches between two different images every two frames because they don't fit on a single screen. To speed things a bit up, lines are not flashed sequentially, instead the hardware has a list of lines that are still needed and captures the first one that it finds.

The firmware update tool is actually the first thing that starts when the Gamecube/Wii is turned on - it checks if the main firmware is present and has the correct checksum to detect failed/aborted update attempts. If everything looks good, it starts the main firmware and you can only barely notice it in a short glitch of the LED blink sequence. If the main firmware is missing or the checksum is incorrect, it instead shows a message on screen and starts looking for an update. In theory this should make it hard to completely brick an installed GCVideo board, even when the power fails the firmware update tool should still work. In practice... No idea, let's see what happens. =)

And because I don't like updates where the user has to select the correct file from a jumble of options, the updater.dol actually contains all 8 possible builds in a single package(*) and the firmware update tool picks the one whose hardware ID matches the ID that it read from flash.(**) The theoretical limit is 76 firmware variations in a single updater.dol, but I think that would be too large for the Gamecube's RAM.

(*) I just realized that putting the Gamecube-only firmware into the Wii updater.dol is a bit useless, so the next release will omit them.
(**) If it fails to find a hardware ID, it shows a menu of all options it found in the video data and lets the user decide. This is of course not completely brick-proof since you could install the wrong one and it will then happily boot into it because the checksum is correct. Even then you could still recover by holding the IR button on power-on and re-flashing the correct version. It's unlikely that a normal user will encounter this problem unless the firmware is mis-flashed from the start, but the feature was occasionally useful during development, so I kept it as yet another emergency recovery option.
Does this mean future updates will just require running the new updater? Will it automatically support all hardware variations?
Yes, you just need an updater that contains the version you want to install, built for the hardware you have. I plan to release only updaters that contain firmwares for all hardware variations that are supported in my repository. Other hardware variations could be added, but since the bitstream must be built individually for each hardware variation, new ones would need an updater.dol that includes them.
Also, any guidance to get 3.0a on my gcplug?
I don't have a GCPlug and a quick search on the net did not uncover any information if it uses a custom pin assignment or can use one of the existing version from my bitstream.
Lostdotfish
Posts: 17
Joined: Tue Feb 06, 2018 12:01 pm

Re: Cloning the Gamecube component cable

Post by Lostdotfish »

Unseen wrote:
Also, any guidance to get 3.0a on my gcplug?
I don't have a GCPlug and a quick search on the net did not uncover any information if it uses a custom pin assignment or can use one of the existing version from my bitstream.
Thank you for your detailed response. That's a very clever approach to updating firmware. I'll guess I'll pull my Wii apart one more time.

With regard the GCPlug, it's based off Dan's open source design.

https://www.reddit.com/r/Gamecube/comme ... own_gcplug

The only binary I didn't try yet is the Pluto one. I tried the GCDual and Shuriken V3 and both bricked the GCPlug. I've reverted back to the 2.4d dump I took for now.

I wonder if it's possible to get the GCPlug on your list of hardware targets moving forward. There's a lot of them about.

Thank you for your work
User avatar
Unseen
Posts: 723
Joined: Sun May 25, 2014 8:12 pm
Contact:

Re: Cloning the Gamecube component cable

Post by Unseen »

Lostdotfish wrote:I tried the GCDual and Shuriken V3 and both bricked the GCPlug.
A quick check of the PCB images on OSHPark seems to indicate that it's a new variant that does not match any of the releases in my repo.
I wonder if it's possible to get the GCPlug on your list of hardware targets moving forward. There's a lot of them about.
It should be possible if I can get the pin assignments. In the worst case, it's possible to reverse engineer them from the PCB images on OSHPark.
Lostdotfish
Posts: 17
Joined: Tue Feb 06, 2018 12:01 pm

Re: Cloning the Gamecube component cable

Post by Lostdotfish »

Unseen wrote:
Lostdotfish wrote:I tried the GCDual and Shuriken V3 and both bricked the GCPlug.
A quick check of the PCB images on OSHPark seems to indicate that it's a new variant that does not match any of the releases in my repo.
I wonder if it's possible to get the GCPlug on your list of hardware targets moving forward. There's a lot of them about.
It should be possible if I can get the pin assignments. In the worst case, it's possible to reverse engineer them from the PCB images on OSHPark.
I think the information might already be on the citrus3000psi fork of gcvideo. I'm not certain though. Maybe Dan can confirm?
User avatar
djc5166
Posts: 101
Joined: Thu Nov 30, 2017 9:50 pm

Re: Cloning the Gamecube component cable

Post by djc5166 »

thebigcheese wrote:
Unseen wrote:
thebigcheese wrote:Hope the GCDual fork comes soon
You could just install the GCDual build from my repository?
Oh! I though Dan had a special version or something once upon a time. Guess I'll just do that, then.
I also thought Dan's fork had some special changes in it relative to his hw. I will try to update with this also if it's compatible.
User avatar
citrus3000psi
Posts: 668
Joined: Wed Dec 25, 2013 11:56 pm
Location: Indiana

Re: Cloning the Gamecube component cable

Post by citrus3000psi »

I am compiling firmware now. I actually have a few board revisions such as WiiDual 1.0/1.1 that have different constraint files. And yes the GCPlug has a different constraints as well.
User avatar
Unseen
Posts: 723
Joined: Sun May 25, 2014 8:12 pm
Contact:

Re: Cloning the Gamecube component cable

Post by Unseen »

citrus3000psi wrote:I am compiling firmware now. I actually have a few board revisions such as WiiDual 1.0/1.1 that have different constraint files. And yes the GCPlug has a different constraints as well.
Please define distinct hardware IDs for them so users don't accidentally flash something to their board that is not compatible.
User avatar
citrus3000psi
Posts: 668
Joined: Wed Dec 25, 2013 11:56 pm
Location: Indiana

Re: Cloning the Gamecube component cable

Post by citrus3000psi »

Any pattern to your current method?
Lostdotfish
Posts: 17
Joined: Tue Feb 06, 2018 12:01 pm

Re: Cloning the Gamecube component cable

Post by Lostdotfish »

citrus3000psi wrote:Any pattern to your current method?
Note about modifications
The firmware update process identifies a compatible update using a 4 byte identification code, e.g. "P2XG" for the p2xh-gc target. If you plan to release a board that requires a bitstream that is not compatible with one of the existing boards, please add your own target configuration to the top-level Makefile and choose a different identification code (HWID). This ensures that users do not accidentally flash an incompatible bit stream to their board, possibly bricking it. Identification codes should consist of four ASCII characters. All existing ones use G as the last character if they target a Gamecube and W if they target a Wii, but this is just a guideline and not a strict requirement.

If everything works as planned, just changing the HWID should be enough to build a compatible flasher and firmware image. To include it into the updater alongside the other firmware versions, you'll also need to edit build-all.sh and build-updater.sh.

Also, please consider contributing any bug fixes or changes back to the original project.
From - https://github.com/ikorb/gcvideo/tree/m ... cvideo_dvi

EDIT - https://github.com/ikorb/gcvideo/blob/4 ... i/Makefile

Line 40 onwards for current HWIDs
Last edited by Lostdotfish on Tue Jan 14, 2020 2:36 pm, edited 1 time in total.
Lostdotfish
Posts: 17
Joined: Tue Feb 06, 2018 12:01 pm

Re: Cloning the Gamecube component cable

Post by Lostdotfish »

citrus3000psi wrote:I am compiling firmware now. I actually have a few board revisions such as WiiDual 1.0/1.1 that have different constraint files. And yes the GCPlug has a different constraints as well.
Thanks Dan. You the man!
User avatar
Konsolkongen
Posts: 2309
Joined: Fri May 16, 2008 8:28 pm
Location: Denmark

Re: Cloning the Gamecube component cable

Post by Konsolkongen »

I wasn’t aware there was a difference in firmwares. I assembled the internal GCvideo board (GCHDMI 4.0) myself from Dans shared OSHpark files and I bought the Wii Dual from Videogamesperfection. What firmwares should I get for those? :D
User avatar
citrus3000psi
Posts: 668
Joined: Wed Dec 25, 2013 11:56 pm
Location: Indiana

Re: Cloning the Gamecube component cable

Post by citrus3000psi »

Here are firmwares: http://dansprojects.com/firmware/

I think GCHDMI that you made is based on the shruiken V3.
thebigcheese
Posts: 707
Joined: Sun Aug 21, 2016 5:18 pm

Re: Cloning the Gamecube component cable

Post by thebigcheese »

citrus3000psi wrote:Here are firmwares: http://dansprojects.com/firmware/

I think GCHDMI that you made is based on the shruiken V3.
So if I flashed the stock 3.0a firmware, I should be able to use the software updater to flash this? Actually, come to think of it, how would I even use the updater? I see there's a .dol file on the GitHub, but if that has the firmwares baked in, I imagine it wouldn't work with Dan's firmwares. What are the differences and, if I'm going to have to flash the old way anyway, is it even worth using the custom ones?

I see there are two versions of the GCDual firmware as well, what's the difference? Sorry for all the questions.
Last edited by thebigcheese on Tue Jan 14, 2020 7:07 pm, edited 1 time in total.
kloow
Posts: 5
Joined: Sat Dec 28, 2019 11:25 am

Re: Cloning the Gamecube component cable

Post by kloow »

citrus3000psi wrote:Here are firmwares: http://dansprojects.com/firmware/

I think GCHDMI that you made is based on the shruiken V3.
Thanks! And a big thank you to Unseen for creating this awesome project and for his continued support! :D
User avatar
Konsolkongen
Posts: 2309
Joined: Fri May 16, 2008 8:28 pm
Location: Denmark

Re: Cloning the Gamecube component cable

Post by Konsolkongen »

citrus3000psi wrote:Here are firmwares: http://dansprojects.com/firmware/

I think GCHDMI that you made is based on the shruiken V3.
Thank you :)
Lostdotfish
Posts: 17
Joined: Tue Feb 06, 2018 12:01 pm

Re: Cloning the Gamecube component cable

Post by Lostdotfish »

citrus3000psi wrote:Here are firmwares: http://dansprojects.com/firmware/

I think GCHDMI that you made is based on the shruiken V3.
Successfully flashed to my generic CGPlug. Thank you again Dan. And thank you Unseen for all your work on this project.

Is there a way of getting your hardware variations permanently added to the main GCVideo repo so that they automatically get new updates or is that harder than it sounds?
User avatar
citrus3000psi
Posts: 668
Joined: Wed Dec 25, 2013 11:56 pm
Location: Indiana

Re: Cloning the Gamecube component cable

Post by citrus3000psi »

I can send unseen the constraints file. Likely should since the GCPlug is being sold all over now, even on amazon.
User avatar
Unseen
Posts: 723
Joined: Sun May 25, 2014 8:12 pm
Contact:

Re: Cloning the Gamecube component cable

Post by Unseen »

citrus3000psi wrote:I can send unseen the constraints file. Likely should since the GCPlug is being sold all over now, even on amazon.
I don't mind adding them, at the very least it gives me a reason to make the build system parallelizable ;) (a full release build currently needs ~30 minutes on a Xeon E3-1225v3)
fernan1234
Posts: 2175
Joined: Mon Aug 14, 2017 8:34 pm

Re: Cloning the Gamecube component cable

Post by fernan1234 »

What are the "non-standard modes" referred to in the changelog? And what is the advantage of bypassing the image processing for those non-standard modes?
User avatar
Unseen
Posts: 723
Joined: Sun May 25, 2014 8:12 pm
Contact:

Re: Cloning the Gamecube component cable

Post by Unseen »

fernan1234 wrote:What are the "non-standard modes" referred to in the changelog?
Anything that is very different from standard CEA video modes, for example some of the modes used by GBI.
And what is the advantage of bypassing the image processing for those non-standard modes?
The advantage is that you might get a usable picture instead of being guaranteed to get a corrupted one because some of the video processing in GCVideo is built based on the assumption that it receives a standard video mode.
User avatar
Extrems
Posts: 540
Joined: Sat Jan 30, 2016 5:01 pm
Contact:

Re: Cloning the Gamecube component cable

Post by Extrems »

Unseen wrote:Anything that is very different from standard CEA video modes, for example some of the modes used by GBI.
It's technically over 3/4 of them. :P
thebigcheese
Posts: 707
Joined: Sun Aug 21, 2016 5:18 pm

Re: Cloning the Gamecube component cable

Post by thebigcheese »

What are the differences with Dan's custom firmwares vs the ones Unseen put out? It sounds like I have to reflash the manual way instead of via software to get those, so I'm just wondering if it's worth the bother. I also notice he has two for the GCDual, one labeled ADV7125 and one labeled CDK404. Are these for different revisions? Just trying to figure out which one I should use.
User avatar
Link83
Posts: 342
Joined: Tue May 21, 2013 2:39 am

Re: Cloning the Gamecube component cable

Post by Link83 »

thebigcheese wrote:I also notice he has two for the GCDual, one labeled ADV7125 and one labeled CDK404. Are these for different revisions? Just trying to figure out which one I should use.
They are two different models of DAC chip (It should actually be the CDK3404 but I think Dan made a typo in the 3.0a update filename)

Early GCDual used the CDK3404, but Dan switched to using the ADV7125 as the CDK3404 became difficult to source:-
https://twitter.com/citrus3000psi/statu ... 1435746304
You should be able to tell which DAC you have by reading the code from the chip when you look at the GCDual board (For example the CDK3404 is the smaller chip at the top of this photo)

If I have understood correctly then hopefully the 3.0a update will be the last update that requires dissasembly and manual updating with a CH341A programmer:-
https://www.youtube.com/watch?v=RSG9kC6o0G0
Future updates should be possible with GameCube homebrew loading methods, and it should also hopefully automatically identify the type of update required.
thebigcheese
Posts: 707
Joined: Sun Aug 21, 2016 5:18 pm

Re: Cloning the Gamecube component cable

Post by thebigcheese »

Ah, perfect. I have already put the "stock" 3.0a firmware on, so I was hoping for an easy swap over to Dan's custom ones, but I guess I have to open it up to see which chip it has anyway. Like the 20th time I'll have opened it up this week... Oh well.
User avatar
Link83
Posts: 342
Joined: Tue May 21, 2013 2:39 am

Re: Cloning the Gamecube component cable

Post by Link83 »

thebigcheese wrote:Ah, perfect. I have already put the "stock" 3.0a firmware on, so I was hoping for an easy swap over to Dan's custom ones, but I guess I have to open it up to see which chip it has anyway. Like the 20th time I'll have opened it up this week... Oh well.
It would probably be best to wait for now, since it appears there is an issue with 3.0a:-
https://twitter.com/citrus3000psi/statu ... 6733148161
Although i'm not sure if GCDual is affected or not :?
Post Reply