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.