The following is an interview with Ingo Korb, one of the developers behind the GCVideo project. GCVideo is an effort that analyzed the GameCube’s digital AV output in order to produce a more affordable way to get high-quality video out of the system. As a user of one of its implementations, I wanted to know more about the process.
Where are you from, and how did you get into video games?
I’m from Germany and I was gifted a Commodore 64 in the late
1980s, which has a pretty great selection of games. An SNES with a few games
joined the collection sometime in the early 90s, but except for an N64 that I
bought for exactly two games (Ocarina of Time and Majora’s Mask), I stayed on
the PC side for gaming for a bit. When the Dreamcast went on clearance, I
grabbed one and a few cheap games and got back into console gaming, picking up
the other contenders in that generation whenever I found a good offer.
A long time ago, I happened to be sitting in the games room
of a convention talking with ikari_01 about that pesky [GameCube] component
cable and how it was ridiculously expensive already (he was lucky because he
bought one much earlier). Since we both knew our way around FPGAs[1]
(he from the SD2SNES, me from dabbling
with them over the years), we both wondered why nobody had yet tried to decode
the digital video from the console and feed it to a DAC[2]
to clone that cable.
What were some of the most interesting technical
challenges?
Making the product easily configurable required some work.
For example, the original release of GCVideo-DVI did not have an on-screen
display. Instead, you had to select line-doubling and scanline settings using
jumper wires to various pins of the FPGA board. I had expected that users would
just choose one set of options and be done with it, but someone announced on a
forum that he planned to add switches for everything to his console-or maybe he
showed a completed version, I don't remember exactly. I didn’t want to
encourage people to do that, so I decided to put the flexibility of an FPGA to
good use by adding a CPU with enough peripherals to the system to build an OSD.
The nice thing about doing that on an FPGA is that you have full control over
these peripherals-with a standard microcontroller, if some part of it does not
work exactly how you need it to, you can only work around it, but with an FPGA
I can just make it work exactly as I want.
Other times the challenges were more annoying than
interesting. For example, when you have a digital AV interface, most consumer
devices will just show a variation of “no signal” if you don’t get it mostly
right. Debugging that can be a pain because the only option is to capture what
your design generates and then comparing it manually to something that is known
to work. There are professional analyzers that could tell you what you did
wrong, but they are pretty expensive even on the used market, if you can find
one at all.
One of the biggest challenges overall that I can remember
was the ICAP[3]
interface of the Spartan 3A though. It is an internal interface of the FPGA
that is used to reboot the chip into another configuration, and while the
documentation looks good at first glance, it glosses over lots of tiny details.
There are some other projects on the internet that also access that interface,
but they mostly just to tell the chip to reboot with a different configuration,
which only needs to write to that interface. GCVideo needs more than that
though: The internal flasher tool can be started either when the console is
turned on, in which case it should just silently start the main firmware, or it
can be started on user request to upgrade the firmware. The only data in the
entire FPGA that survives that reboot is in the ICAP interface, so I had to be
able to read data back from it that was written before the reboot. I have not
found a single project online that does that on a Spartan 3A FPGA, but some old
discussions on the chip vendor's forums pointed me in the right direction. It
took me about two weeks to find a sequence of accesses to make that thing work
reliably and I still can’t fiddle with that part of the code too much because
it breaks easily.
What are your future plans (GCVideo or otherwise)?
That’s a secret. =) I find it easier not to talk about
future plans for a project because that allows me to scrap them if they don’t
work out. Announcing plans in public creates expectations on the user side that
such plans are eventually realized and it is much nicer to suddenly hear that
there is a new release with some new feature than to hear that the feature you
were waiting for will never come.
I’m tempted to do a release with 720p HDR capability on the
first of a certain month in the near future, but I'm not sure if I have enough
spare time to make that happen. ;)
[1]
Field-Programmable Gate Arrays-a technology that enables mimicking other
hardware without having to build an exact replacement.
[2]
Digital-to-analog converter-converts a digital signal to its analog equivalent
(or vice versa).
[3]
Internal configuration access port-does pretty much what the name says.
No comments:
Post a Comment