Discussion in 'Modding and Hacking - Consoles and Electronics' started by darcagn, Aug 31, 2014.
Sounds like the component cables is useful then.
The majority of games that are worth playing support 480p, and if you can run homebrew software, you can force 480p for the games that don't support it. It's a lot easier to do with a Wii, but it's possible with a Gamecube as well.
Quick question, European RGB Scart when compared to Component on a PAL system, is there really that significant of a difference between the two? I mean, are we talking day/night difference, or just a slight improvement? Because if the image quality is really that much better I'd probably be down for some Component cables.
As long as you use only 15kHz modes (576i/480i, SD-TV compatible) there is probably little to no difference - how much depends on the TV/monitor you use and how it handles RGB and component video input.
The reason the original component cable is so sought after in certain circles is twofold: First, NTSC cubes only output composite and S-video on their analog AV port, but no RGB - but this doesn't matter for PAL cube users who have RGB (but no S-Video) on that port. The second reason is that the component cable allows some games to run in 480p mode instead of 480i, which is usually regarded as a noticable improvement. Since the cable was (AFAIK) never released in PAL countries, PAL games do not support this though. This is only a software limitation though, so if you play imports or use a program like Swiss that can force games to run in specific video modes, PAL cubes can also output 480p video. In this case component would give you an advantage over RGB, although it requires a TV that supports EDTV resolutions (if it's HDTV, it supports EDTV - if it's a european tube TV, it most like doesn't).
However, this increase in quality isn't directly linked to the choice of RGB vs. component but instead it's the increased resolution that the Gamecube supports only on the digital video port. The original component cable (as well as my board that is discussed in this thread) can actually output either component or RGB even in 480p mode, although in my experience it's much easier to find a monitor/TV that accepts both 480i/576i (for the boot screens and non-480p-compatible games) and 480p on its component inputs than one that accepts both of these modes on the same RGB input. For example my Sharp TV here accepts 480i/576i RGB via SCART and 480p RGB via VGA, but if you feed it the other way around the only thing it displays is a "Not supported!" message - on the component input all of these modes just work.
.o(Oops, I'm in "long-winded explanation mode" again...)
Hey man, no need to apologise for being long-winded, its all good detail. It sounds like Component would basically let me make use of 480p rather than 480i, which sounds worth the cash in the long run, thanks for the info.
Sorry if there's an obvious answer to this and/or it's been answered already, but I've not yet seen this question answered. Myself, I've got one of the older GCNs with the Digital AV Out but I'm mainly bringing this question around again for curiosity's sake since I also have a few of the revised models laying around.
(DOL-101 Gamecube without Digital AV out)
Actually I don't know. The internal AV encoder chip uses the same digital signals that are present on the digital port, but is always clocked at 27MHz since that is all that is required for 480i. Over on the gc-forever forums someone has tried to connect an original cable directly to the correct signals in a DOL-101 cube, but he was unable to locate a 54MHz clock anywhere on the board and IIRC did not get any output at all when he used the 27MHz clock from the AV encoder instead. There may have been additional complications when attempting to convince the cube that a component cable was connected to get the "Use progressive mode?"-prompt in games to show up.
I don't have any DOL-101 Cubes though, so I can't test how GCVideo would react in this case. I'm reasonably sure that it will still generate a picture if fed with just the 27MHz clock as long as you only use 480i, so it might work on a DOL-101 cube if you grab all the required signals directly from the internal AV encoder.
While HDMI would be cool, I would rather have RGB / component internal mod than HDMI. I think there would be good demand for them if beharius had some built. As many have mentioned the component cables go for over 100 on ebay so a ~$50 mod would be a good deal for many gamers.
Im going to a pawn shop today to buy the digitail to componet cable today for 140 please convince me to keep my money by telling me someone can make me a cable soon
You people are ridiculous.
That's less than some eBay auctions have gone for.
Personally I have a set. And yes on my 480p tube F-Zero GX looks amazing but if I didn't get them for an absolute steal ($50) I would just use my Wii for 480p.
Can I use a Component to VGA cable to connect my GC to my non component tv? I hope I don't get the "no signal" message?
Here's the cable I am talking abou: http://www.ebay.co.uk/itm/3-RCA-Com...e-D-sub-HD-15-Pin-Video-Adapter-/121218355503
I very much doubt that adapter has a component to VGA converter inside of it I highly doubt it will work.
I just want to play GC on my 4:3 lcd TV as I do with DC vga. I don't like the way my hdtv upscales gc component image, also those black/ grey bars... DC image looks better than GC and with no bars!
I think it'd be interesting to see something to provide RGB video on NTSC systems. I know 480p is an improvement, but I keep my GameCube with my older systems which generally use RGB. I've even thought about getting a PAL cube modded in order to get RGB but never actually looked into it.
With this creation I guess it could be done.
Great to see more work being done on this.
About two weeks ago I happened to take another look at the HDMI design, and it's coming along nicely.
I might be uploading another vid later to test the compression quality etc.
The above vid just doesn't do it justice tbh.
EDIT: Oh dear - I tried using H.264 compresion at 15Mbps instead of MPEG-2, and YouTube has managed to make it look even worse. lol
I've added the simple LERP (Linear Interpolation) stuff for 480p mode now, and I2S audio via HDMI is working great.
The effect of the LERP on the colour samples is very subtle, but you can notice the difference.
I've also just tested using a PLL to generate the 54MHz clock from the GC's 27MHz vid clock, so it should in theory allow 480p to work on PAL GCs (with a mod chip ofc).
I have a few ideas for the best way to mount the HDMI board in the GC, and I'm thinking it wouldn't be too hard to add a DAC option for Component / RGB output.
Not wanting to promise too much though, as I have a string of previous unfinished projects.
The design that Unseen has made looks great too, and may even be preferable for the people who still use CRT monitors for Smash Bros tournaments etc.
As most of you know, almost all modern digital displays will add at least one extra frame of lag, and some say they can notice the difference in high-speed critical gaming.
I still want to keep the HDMI board generic though, and it should be possible to use it on many other consoles, like the N64, Game Gear, DC, Xbox, Neo Geo, Amiga, Jaguar, Intellivision.
Soldering is still an issue for some of those machines though, as the DACs on consoles like the original Xbox and DC have quite fine-pitched pins.
PAL cubes also have the 54MHz signal on the DV port, my design uses that exclusively. I'm thinking about switching to 27MHz though because the 54MHz clock is a bit sensitive to interference with bad cabling (like my "mess of wires" prototype setup).
I don't know what HDMI transmitter chip you use, but if it needs a 24-bit parallel input then that is more or less the same that common video DACs would use. Alternatively you could try the cheapskate route and use Sigma-Delta-Modulation. It's not commonly used with video, but a few tests here with just One-Bit-DACs (FPGA pin and resistor) into a PVM with 10x oversampling (modulator running at 135MHz, hold-type interpolation) was extremely successful. Unfortuately such a design really needs an analog reconstruction filter that removes the noise created by the modulator, otherwise displays with an ADC on its input (i.e. all TFTs) may show that noise as random color sparkles overlaying the picture. I have very little experience with analog circuit design, so I scrapped that plan.
Here is a video of that test on a PVM-9045, switching the Sigma-Delta modulator on and off to show the difference between plain 1-bit-per-channel video and the same using Sigma-Delta-Modulation:
Hehe, I know that problem =)
With some of these generating a valid HDMI signal from the incoming pixels may require non-integer (horizontal) resampling of the video because the pixel clock of the console is rather far from the pixel clock for any of the common video resolutions. You also might want to add the Wii to that list, I'm pretty sure it internally uses the same digital video format as the Gamecube - just with 1.8V levels. I2S also appears to be available right next to it.
Edit: Oh, and in theory you could add the NES to your list, if the console has been fitted with Tim's NESRGB board. It uses discrete resistors as DACs for its RGB outputs.
Firstly, are you the guy responsible for the SD2IEC firmware?
If so, it's a fantastic gadget, and I use one with my main C64C.
Ahh, I heard from megolomaniac and others on gc-forever that the PAL consoles didn't have the 54MHz output?
I may be mistaken though, as it was some time ago now. I need to test a PAL cube later.
Maybe the PAL cubes don't have the IO input on the Dig AV port for sensing the cable?
Could anyone with a Component cable please confirm if a PAL cube attempts to go into 480p mode ?
The idea for the new board is to keep it pretty much the same, but a bit smaller, and add a connector for the 24-bit video bus that goes to the HDMI chip.
This will allow a second board to be added for people who want Component / RGB output.
A proper DAC chip like you used would be good, but even simple resistor DACs would be fine tbh.
The HDMI board is running fine when using a PLL on the 27MHz output atm, so that simplifies things a tad.
I just need to make absolutely sure that the PLL output keeps phase with the input, but it's working so far.
I'm using the ADV7513 HDMI Tx chip, since it was the same as on my Cyclone V GX Starter Kit, so I already had a bit of code for writing to the I2C regs etc.
The datasheets are quite nice too, so it was a simple choice.
The current board was actually designed by [RDC] from gc-forever.
We worked together on it some time ago, but both got side-tracked with other projects etc.
I've had good success with sigma-delta mod on the RGB outputs too.
I tried it on an N64 a few years ago, and it looked fine even on a CRT and simple R/C filters on the outputs.
This was going from the 3V3 IO pins on the FPGA board directly to the R/C filters and through to the RGB on the SCART socket.
I had to run the modulator at a stupidly high speed though, and I think I even hooked it up to the oscillator for the RDRAM at one point.
Yep, I'm pretty sure the Wii uses the same video format as the GC too.
Soldering to the chip isn't too hard using Kynar wire as you know, but making a practical kit available for the public is a different story sadly.
I noticed the GC does only output a 640-pixel wide image, so I'm using DE (Data Enable) Generation on the HDMI chip atm.
This still leaves the narrow 40-pixel black bars at either side, but it looks fine on the TV.
I guess the image could be stretched horizontally to fill all 720 pixels, but the aspect ratio looks perfect as-is.
Thanks =) Maybe I should finish up the Cube stuff so I can finally reclaim the part of my desk where I used to put the C64 for developing sd2iec.
I think you may confuse them with the DOL-101 cubes which lack the digital AV port. I haven't seen a board for them myself, but a thread on GC-Forever seems to indicate that they don't have a 54MHz clock signal anywhere on the board.
They do have that and it's accepted by NTSC games booted using the usual methods - my current cubes are all PAL models, although I have an NTSC board lying around that I need to install some day.
The think I don't like that much about building an 8-bit DAC from resistors is that you need rather precise ones if you don't want to "throw away" the LSB and that makes the resistors a bit expensive. On the other hand most people probably wouldn't notice if the non-linearities of the DAC reduce the effective color resolution to 6.6 bits...
I've looked into quite a few encoder chips for my design and in the end decided to release an analog version first (for the bragging rights ) and use an FPGA with TMDS-capable output drivers for an eventual HDMI version because all the DVI/HDMI transmitter chips I found were quite expensive. Of course that means that my HDMI version of gcvideo is currently just DVI (so no audio), but it also allows me to target already-existing boards like the Pluto IIx HDMI (which has its own problems... but there is a small chance for a release running on it soon-ish).
CRT is easy though, they are naturally bandwidth-limited. At least some modern devices with an ADC on the input seem to assume that the signal is already limited to the bandwidth they expect, which results in pictures like this when you feed them something unfiltered:
That image was produced from a Gefen HD Mate fed with the same RGB signal that was in the video in my previous post. I also tried the simple RC filter method, but even with Cs that visibly smeared the image there was still a lot of noise visible.
Yes, it's easier if you can just tell your encoder to override the incoming blanking signal. I had to reimplement that myself and my current solution isn't exactly pretty.
Do you add black borders on all sides to force the picture to a standard resolution like 720x480 or do you pass something smaller to the display and hope that it accepts it? I've seen some issues with non-standard resolutions in a few HDMI sinks, for example the Elgato Game Capture HD refuses to record anything that is not one of the small number of supported resolutions. A small portable 10" TV I have is quite flexible in its accepted input resolutions, but often disables the 16:9/4:3 switching if it's something unusual and just forces the image to fill the screen.
It should be - the signal timing of the cube is (almost) the same one as for 720xwhatever standard CEA resolutions, so the games would be designed for that pixel aspect ratio.
Separate names with a comma.