gcvideo - Open source GameCube component cable solution

I found the connectors on eBay but the only ones I could find come from China. One set was 2 male connectors and the other set was 2 female connectors. They're $4.99 each. I've never bought things from Mouser before. Do they accept PayPal or is there another, more common, connector I could use?

I have a friend like that... Well that means I could keep it connected to my HDTV with everything except the Dreamcast and my good old Windows 98 desktop I grew up with. The TV lacks VGA. Speaking of the Dreamcast, can this project be adapted for it? I've heard that it outputs a resolution that most monitors squish to 640x480.

 

Yes, it should be possible. There is a DAC on the Dreamcast from which you can tap the digital signals. From what I have heard however it is pretty hard to solder wires onto this DAC unfortunately.

I might look at it after N64 and GC, as long as the soldering seems feasible.

 

Wow, that's expensive - my usual "local" source for this (Reichelt in Germany) wants less than 50 Euro-cents per connector.

You don't have to use those connectors specifically, it was just the first thing that came to mind as a easily-available (from my perspective) connector that is rarely seen in practice. You can certainly use other connectors for this purpose if you want to.

The Dreamcast seems to have a digital video bus exposed on its board, but I would characterize it more as a rewrite than an adaption. Maybe I'll take a look at it one day, after some of the easier targets (Wii) are done.

 

I thought soldering to the Wii was also quite hard. If you can do that, then I think Dreamcast should be possible too.

 

The Wii is an easier target for me because I expect that it's video bus is very similar (if not identical) to the one from the Gamecube. Soldering usually takes less time than development. =)

 

Yep - the digital vid format on the Wii should be pretty much the same as the GC AFAIK.

Only thing is, the DAC on the Wii has quite fine-pitched pins, and I think the vias are all very small too, so it would be a pain to solder to.

The DAC in the Dreamcast should be doable as well, as the pins are slightly wider pitched.
Should be able to solder some Kynar to that quite easily.

The DC DAC also uses an 8-bit bus running at around 54MHz IIRC.
I think it uses multiplexed RGB instead of Component though.

I was looking to use my HDMI board on most of these machines, but I'm not sure I'll ever get the PCB layout finished at this rate.

One of the hardest things is keeping the board small enough so it will fit into all the different consoles / computers fairly easily.
The current design has the HDMI socket on a separate smaller daughterboard via a ribbon cable, which should make it easier to install.

As you know, your design could in theory be used on practically any console with access to the digital video bus.

Hell, even the Intellivision.

OzOnE

 

Ok. When wiring up the connectors, should I wire a ground pin in between each signal, like pin 1(signal) pin 2(ground) pin 3(signal) pin 4(ground) etc.?

I'm excited for that! Hopefully it won't be too difficult. How much of an image quality difference would there be using the Wii version of GCVideo compared to playing games on the Wii U via HDMI?

 

The slightly annoying difference is the signal level, the Wii seems to run at 1.8V which means it will need a seperate bitstream if I want to use the same FPGA board since all I/O banks are wired to 3.3V on that one.

IIRC it didn't look that bad to me the last time I dismantled my Wii - the PSOne may actually be worse, 24 bit RGB on adjacent pins of a 0.5mm TQFP chip.

Interesting, the schematics I saw seemed to suggest a 12 bit bus and seperate HSync/VSync lines.

GBA is relatively simple too, 555 RGB plus a few control signals. The pixel clock is shut down when it's not needed though and the video timing is very far away from any standard, so a complete frame buffer is required.

Is yours the one shown on retroactive.be? Pleeease finish that, I'd love to have HDMI on my N64 and I'd prefer to let other people worry about its weird pixel clock. =)

Actually I cheated a bit: My (DVI) design runs on an existing commercial FPGA board instead of another custom design. It's reasonably cheap, quite small and (at least for now) I can live with its flaws.

I was going to object that you need a level converter for that one, but on such an old system the signals are probably slow enough that resistor dividers would be enough.

The original connector on the cube uses one ground pin every two signal pins, but using more shouldn't hurt.

Currently unknown =)

 

Has anyone tried this yet? I was looking at the back of my DOL-101 and there is little to no room on there for a custom connector. There is a big gap under the board on the left side that the FPGA might be able to fit in. I cannot test this at the moment because I lack the FPGA and the other parts to try it on my DOL-101. That same gap could also be used for a custom connector that can be mounted on the left side of the system. I would provide more details but my cheap 4.5mm security bit is stripped and I could only see through the vents on the back of the cube. I'm buying someone a birthday gift which, coincidently, just so happens to be a GameCube 1019 memory card so I'll order a new (and hopefully better) bit with it and then take and upload some pics of the spaces I'm talking about.

I was thinking about connectors and an IDE port might fit but I counted how many pins you would need if you put a ground between each signal and it totaled to 44. There happens to be a 44 pin D-Sub connector: male connector and female connector. It might be easier to wire a 25 pin D-Sub exactly the same as the Digital AV port on the DOL-001s with 3 extra ground pins (54MHz signal would be ground-54MHz-ground and the 3rd extra ground would be between VDATA6 and +3.3V or pins 23-25 could be the extra ground pins). Keeping things external would be great in case something needs replacing or if the FPGA needs updating or upgrading.

 

@Unseen - ahh, you could be right - the DC does have a 12-bit video bus.

It might actually use YUV (YCbCr) on that bus then?
I recall reading in the HOLLY documents that the digital bus is RGB (time-muxed), but I could be wrong.

The DC uses a Rohm BU1426KS DAC, which is similar to these...

http://www.datasheet4u.com/share_search.php?sWord=BU1426

I'm tempted to give my prototype HDMI board a try on the DC now, 'cos so many people keep mentioning it. lol
I have about 3 DCs to try it on. A dab of flux and some Kynar wire, and it shouldn't be too hard.

The board on retroactive.be is Marshall's design.
It looks very nice, and he's still working on it when he gets time.

I actually asked him about his board again on IRC yesterday, as I was wondering if it was worth me targeting the N64 with my board.
He said he still wants to finish his soon, so I'll leave the N64 HDMI stuff in his far more capable hands.

His board will no doubt have a nice OSD and decent scan-doubler / de-interlacer.
I think he was working on better ways to handle the resolution changes without making the TV re-sync, and also on basic 1080p up-scaling.


I see you used an FPGA board from fpga4fun btw.

The Pluto-II was my very first FPGA board, and I still have it somewhere.
I used it for sequencing RGB LEDs in DLP projectors, so I could replace the crappy mechanical colour wheel.


I think using a "custom" connector on each console and keeping the HDMI box external could be a good solution actually...

I kind of threw out the idea originally, as I wanted to keep everything internal.
But, a simple connector would mean that we don't have to worry about the size of the HDMI board so much.

My current board design only measures 47 x 38 mm, so that's pretty small already.
A slightly larger board would make it easier to add things like SDRAM though, and also keep the HDMI connector on the same board.

Continued...

OzOnE

@MonkeyBoyJoey - I'm hoping to target the GC with my new HDMI board.

The GC is one on the main reasons I wanted the HDMI socket on a separate little daughterboard, so everything can fit inside easier.

I made a few vid captures from it. Digital audio is working great via HDMI too.

(the quality is way nicer without the capture / YouTube compression, but you can see it looks very nice already.)







I think the best way to go for the GC is to use a "modchip style" adapter board which simply fits over the pins on the PCB for the Dig AV port.
It could then be soldered easily to the required pins, with a ribbon cable over to the main HDMI / FPGA board.

But, using a custom connector on these machines might be a good compromise too...
You could then have the same output connector on any machine, and keep the HDMI box external (a bit like a DC VGA box design).

The connector would likely need to be better quality than a standard IDE (40-way IDC) connector though, as the digital video bus in the GC and other machines are fairly high-speed.

I was kind of hoping to keep everything internal, just so I could say "I have an true HDMI Gamecube", or "I have a true HDMI Dreamcast".

I suppose having a small external box would solve a lot of problems, and make it far easier to mod the different consoles.

A DVI connector should work OK, and have enough pins for most consoles (24 pins, plus a few pins meant for "analog").
Would a DVI connector be a bit large though?

The DVI connector would be for transferring the "console native" digital video rather than actual DVI of course, and that could bring it's own problems...
eg. you then have to worry about people plugging a normal DVI cable into it, as it would very likely short some of the signals and damage the console.

You would also need to feed power via the connector, unless a separate wall-wart is used (or a pass-through which borrows power from the console's power input).

Hmm. Worth another thought though.
Perhaps a small board could fit inside for voltage translation as well, so you could use the same physical design for the FPGA board?

Eventually, the ideal would be to have 4 or 5 spare IO pins on the FPGA for sensing the console type...
The FPGA could then switch to the correct decode block for each specific console / computer, making it a true universal solution.

(for many machines, the code is quite small, so it's feasible to fit many formats in one bitstream.)

You know what - I might just try the DVI connector thing later.

I have the proto board soldered directly to the GC atm, so it's a bit of a pain to move it around.

This would mean I could keep the current board design too (the PCB layout was done by the very kind [RDC] from gc-forever).

I'll keep you posted if I make any progress.

@Unseen - please keep us posted too - your projects are fantastic, and good to read about.


OzOnE.

 

Is the spacing of the GC Digital Port pins a common one? Perhaps it can be swapped for a different connector then.

I am not too sure about the external solution. With the N64 I already had trouble with impedance when I wired a DE1-SOC FPGA board to it.

 

The spacing on the GC connector is 1.7mm IIRC, but don't quote me on that.
The pins are actually very far apart, and easy to solder to using wires.

A proper adapter PCB would make more sense for a mod kit though.

Yep, impedance matching would be an extra issue for this as well, so I'm still thinking an internal mod would be better all-round.

I had lots of sparklies on the image on my original N64 HDMI test too, even with extra foil added to the ribbon cable, and trying to keep it quite short.

(In 480p / 576p, sparklies and drop-outs in the image are even more likely ofc.)

That's not to say that a custom connector wouldn't work, it's just that things like impedance and wire length would need to be controlled.

OzOnE.

 

Uh-oh, so much text to reply to...

Time-muxed RGB seems more plausible to me. It shouldn't be hard to figure out the details once the connections are in place.

Well, I can't really do a deinterlacer on the board I chose (no RAM), but an OSD is certainly an option:


(no extra buttons needed, just a single extra wire to the FPGA is enough to snoop the data from controller 1)

Yes - initially I planned to design my own, but being able to point people to a shop where they can just buy an assembled board is really convenient.

I with the Euro hadn't crashed recently, one or two more of them would be useful to mod my "main" cube and leaving the one I have available for development.

That's the downside of my attempt to keep the price as low as possible - the FPGA needs to handle the TMDS encoding itself and if I want audio in there, additional code is needed. Fortunately someone recently published a Neo Geo to HDMI-with-audio project on GitHub that works without an HDMI Tx chip, so "Enhanced DVI"(*) will probably be added to GCVideo in the future.

(*) The HDMI logo has this tiny little "TM" in the top right corner and I prefer not to get into discussions with lawyers about such things.

It's surprisingly resistant to interference:

I just need to make sure that the single gray wire (54MHz clock) isnt't bunched up against the others, that causes sparkles in the output. The audio signals and the snoop line for the controller required a bit of deglitching though (three-bit shifter after the usual synchronizer, copy to output only if all three bits agree). The wires between the connector and the FPGA board are 200mm, the flat cables between the Cube's PCB and the connector are about 100mm, with all GNDs intact.

 

It will probably be another month or two before I have the money to buy all of these parts, but once I do, I'll test it out on my DOL-101 and see how it turns out. My only way of capturing it would be a Hauppauge HD PVR and a cheap RadioShack HDMI to Component converter that has problems with some devices like my SCART to HDMI converter (the picture is out of place vertically; I can take a screenshot if it helps explain it and if anyone knows a fix for this that doesn't require buying a new converter that would be awesome).

I think DVI would be great as long as we use the version with all pins intact (I think its the DVI-I connector). I just checked with a DVI-D to HDMI connector and it should fit fine if it is mounted on the left side of the system towards the back and under the motherboard. So confusion and damage can be avoided, I recommend putting a label above the port that screams "Digital A/V Data Out, THIS IS NOT DVI!!! Using DVI cables to a monitor or adapter WILL DAMGE THE GC AND THE MONITOR/ADAPTER!!!". As for wire length issues, a box that attaches directly to the side of the system like the PS2 Network adapter or the Game Boy Player would mean that the only wires between the system and the FPGA are: system to DVI and DVI to FPGA with no DVI cable in between.

I'll be waiting for the results of everyone's tests and the Dreamcast version so I don't need to buy a better DC VGA box. Good luck to everyone and maybe one day we will have a universal HDMI box for everything including the Nintendo Color TV Game 6 and even the Magnavox Odyssey!


EDIT: I saw your videos Ozone and subscribed =) and btw, I want that Starfox game lol

 

I have to catch up on this thread for sure!

I have a HD-PVR 2, a Xrgb mini framemeister, and also access to the older HD-PVR 1.

Very interested in this for sure

 

You have an XRGB mini? I wish I could afford one. Each time I see them on eBay its usually from Japan and $300-$450. I would need an adapter to use Euro SCART on it for my US SNES and Genesis cables. I thought about getting an HD-PVR 2 but it doesn't do 1080p60 video recording.

 

I gave the VGA pixel clock generation a try (in order to sync VGA output frames with N64 output frames). At first I was unable to do so, but after changing the clock for the vga clock generation from 350 MHz to 300 MHz it was working. With 350 MHz I was getting an image on screen, but when looking at some signals with signaltap the frames clearly did not sync. I guess the clock was too fast for the calculation (I am using pretty big numbers for the calculations currently, I think I can still divide these by 2 a few times).

I generated a vga clock/2 signal and this signal I feed to a PLL that multiplies it by 2 again. Something silly is however that the PLL can only take inputs from a clock input pin or another PLL, so I output the vga clock/2 to an output pin and then connect it to a clock pin again.. I read that setting the PLL bandwidth to low will filter some of the jitter. I measured the clock signal with an oscilloscope and it seems pretty stable. I think this definitely has potential to use for HDMI clock generation. I will also look for some further measures to reduce jitter, perhaps I can also feed a vga clock/4 to the PLL for instance.

Now I guess it is just a matter of making sure the VGA module is a bit behind with reading in pixels (one or two lines, I am using one framebuffer for reading and writing) compared to where the image is currently being written. Obviously I could just buffer a few lines in block ram. Now I just need to find out if my PAL N64 will output something more like 60 Hz if I swap some crystals instead of 61 Hz. Otherwise there is not really a point in doing this clock generation, since some TVs most likely do not accept 61 Hz. But I guess we are getting a bit off track here. Perhaps we should open a thread to just discuss DAC signals to VGA/HDMI/Component/RGB in general?

Anyways, the point I am trying to make here is that this advanced clock generation method seems to have some potential for weird pixel clocks.

 

Yep. I'm slightly wary about mentioning the HDMI thing too often, but then if / once I got a kit together, I'd still have to say it somewhere.
I know the lawyers might try to protect the protocol / license, but it's quite unfair that it's a ubiquitous signalling standard that we all have to use nowadays.

That's not too bad then. Maybe the GC is driving the video bus better than the N64 does, as the N64 did seem a bit more fussy about wire length etc.

I recently saw the project for the Neo Geo as well. The audio code is really handy too.
I prefer using a proper Tx chip though, as it ensures it will have the correct drive levels, and work with 99% of modern TVs.

I actually wanted to target the Neo Geo too, so looks like I missed the boat. lol

The Neo Geo makes sense though, as it's one of those machines that is much easier to mod than others.
I eventually want to mod my Neo Geo CD as well (I sold my Neo Geo cart board).

EDIT: Unseen - just wondering what sort of CPU core you're using for your OSD?
I've had trouble finding some pre-existing code which is easy to get firmware onto, and has good debugging / GCC support.

The ZPU core looks OK, and I have GCC set up on Ubuntu for that, but I'm not exactly an "expert" in Linux by any means.
I did write a simple OSD in Verilog years ago, but I'm curious to know if yours is coded in C etc.?

Thanks.

StarFox does look particularly nice on the direct stream.
Sadly, the quality doesn't translate too well to YouTube, even with high initial bitrates of 20-35 Mbps H.264.

I never realized until I uploaded those vids just how high a bitrate you have to use to get good quality on YouTube.
It's not the same as pre-filtered HD broadcast TV though - games have a lot of fine details which are hard to preserve.

Well, it does still look very nice, and the Zelda clip looks better than most others on YouTube (that aren't emulators), so I'm happy with that.


OzOnE.

 

It wasn't even the first one that targeted the NeoGeo, I saw another project a few months ago that used (linedoubled) analog output to a VGA monitor.

EDIT: You could add HDMI to Tim's NESRGB instead, it should also use discrete resistors as DAC like the Neo Geo.

It's a ZPU because that's the smallest (in terms of FPGA slices) softcore CPU with GCC support that I know. Specifically it's the ZPUflex core with a few simple, custom peripherals around it. It's quite fun to basically build your own microcontroller with whatever weird peripheral you need. =) If you just want a sample system to experiment with I can probably package up my current WIP sources.

As for debugging... I've survived on printf, ISim and occasionally routing signals to external pins connected to a logic analyzer. I think there are ZPU-extensions for JTAG debugging out there, but I haven't been desperate enough to look for them yet.

The OSD is a text-mode display, similar to the common VGA text mode FPGA modules, but unlike those it is referenced to the timing of the existing video signal. On the CPU side it's just a bit of RAM that happens to output its contents as a 45x30 text screen. Each char is mapped as a full word because the ZPUflex can't use byte load/store instructions in its internal RAM, but only 9 bits are actually stored (7 bits char code, 2 bits attributes). Everything from there is in software which I still need to write - the screenshot was a test if the menu was working as intended and one line in there is currently faked.

You could try to scale it to 720p or 1080p before uploading, Youtube seems to use lower compression for the HD versions of the videos.

You should try Twilight Princess some day, it has quite fine details in its title screen.

 

I think kevtris has the NES stuff pretty much wrapped up.

https://www.youtube.com/watch?v=QnQuBN3iYVA

Ahh, so it is ZPU.
It is quite a nice core, and could be made to be quite powerful as well.

Thanks. I might give that another try soon.
If you do decide to upload your OSD code, that would be awesome.

I recall seeing some great tutorials from Alastair (he did some great work on the Minimig core too)...

http://retroramblings.net/?page_id=1031

I did try that with one of the test vids, and it definitely made a difference. I noticed that YouTube seems to prefer certain codecs and bitrate combinations too.

OzOnE.