Dead Horse Beating: Gamecube Digital AV to direct HDMI

[cvmagic]

This is more directed at OzOnE and megalomaniac who were at one point working on Gamecube's Digital AV and well the lack of parts(the IC) to make new cables. In reviewing the notes from OzOnE's previous posts and of others who've discussed the Digital AV out from the gamecube, it seems that needing to remake the wheel is absolutely not needed.

Analog Devices' AD9889B is a HDMI Transmitter which perfectly suited to handle this situation built in without additional supporting chips it has color space conversion, deinterlacing on 480i, passes through the S/PDIF audio, and comes in a semi friendly 80-LQFP package. A great deal considering it's cheap at the $10.24 non-bulk price tag(http://www.digikey.com/product-detail/e ... ND/1551341). There are still the flags to deal with which a CPLD can handle like Altera’s MAX II.

I thought I'd put the suggestion there are both threads have been closed and I wanted to be a bit constructive in suggesting a less resource intensive direction.

[iamdablasta]

I'm not good with tv signals, barely understand hertz, interlaced/progressive, and resolution.
Therefore I am not trying to see if this could work, could someone please explain how and why this does/doesn't work?

[novenary]

I guess this would require a bit of signal preparation (FPGA needed), but it does sound interesting. I don't find anything about scaling in the data sheet though so we still need an HDMI scaler to go with it. OzOnE's FPGA solution was meant to be an all in one thingy that you install inside the Cube. Nice find anyway.

[megalomaniac]

please do a little homework and research on what is being done and why...
here is a hint: there is no "video" coming from the digital port

[novenary]

I do know for a fact that the digital port is raw data coming straight from the Flipper. So no pre-encoded video.

[megalomaniac]

right..
also, that exact same raw data goes to the AVE which creates the analog audio and video(composite,s-video, RGBpal, audioLR)


so if the AVE is taking the exact same data as the MX, then that should explain what the MX is doing...

[cvmagic]

@megalomaniac I do realize there is no encoded analog video coming from this port. The job of the MX chip was to take the data coming from that port which was in fact YCrCb encoded video serialized and with flags thus the need for a CPLD or a FPGA(54Mhz is a bit fast for a CPLD). The point I was driving at is that we've figured how to get the digital encoded video from that port but struggling with what an inexpensive specialized chip can already do for us(deinterlacing, color space conversion, eventually being fully HDMI compliant). Reference http://tinypic.com/view.php?pic=33ehc1k ... yYmaXW9inQ OzOnE himself posted this when making attempts to convert the color space of the video to a usable RGB.

@Streetwalker There wouldn't be a need for upscaling, at this point your television can handle that on it's own if wanted to do that otherwise with 480i or 480p it will output a minimum of 480p@60hz without altering a single pixel going out. If you want to use an external upscaler after that you can otherwise I trust my TV's Manufacture to make sure that 480p signal looks good on my specific TV.

[novenary]

The raw data is not /encoded/, it barely uses the YCbCr colorspace.
And we need a decent scaler because most TVs suck ass at scaling.

[cvmagic]

The raw data is not /encoded/, it barely uses the YCbCr colorspace.
And we need a decent scaler because most TVs suck ass at scaling.

Well I apologize for my ignorance, I was not aware. I was under the impression that was in the YCbCr color space due to the prior posts and what looked like a logic analyser output.

Would you mind going into further details?

[Diminuendo]

OK, I'm unsure of terms here, will this de-interlace interlaced component and send it out as a progressive signal?

will this convert the signal to hdmi or keep it component?

[megalomaniac]

The raw data is not /encoded/, it barely uses the YCbCr colorspace.
And we need a decent scaler because most TVs suck ass at scaling.

scaling 480p?

Well I apologize for my ignorance, I was not aware. I was under the impression that was in the YCbCr color space due to the prior posts and what looked like a logic analyser output.

Would you mind going into further details?

what further details?
- there is no video output on the digital port
- the AVE and the MX do the exact same thing with different end result
- using an HDMI chip or any other type of video conversion IC is useless without a properly formatted video input


maybe you meant to ask a more specific question??

[Diminuendo]

there is no video output on the digital port

Mega, I'm curious, would using component video from a PAL cube and deinterlacing it produce an acceptable result in your opinion?

[megalomaniac]

RGB 480i is already available on PAL GC which looks very good
if you specifically need component 480i, then maybe a converter or something like the TGX mod would work for you...http://www.tg16pcemods.com/

...35$ is a hell of a price considering the other options

[cvmagic]

The raw data is not /encoded/, it barely uses the YCbCr colorspace.
And we need a decent scaler because most TVs suck ass at scaling.

scaling 480p?

Well I apologize for my ignorance, I was not aware. I was under the impression that was in the YCbCr color space due to the prior posts and what looked like a logic analyser output.

Would you mind going into further details?

what further details?
- there is no video output on the digital port
- the AVE and the MX do the exact same thing with different end result
- using an HDMI chip or any other type of video conversion IC is useless without a properly formatted video input


maybe you meant to ask a more specific question??

@megalomaniac Not sure why you're being so defensive about this topic. Personally I want to work on this project as well but thought to put the suggestion out there seeing that it didn't look like a direction people had discussed about previously.

That said lines are labeled VDATA0-7 going to both the AVE & the MX and that in the patent & in http://www.gamesx.com/wiki/doku.php?id= ... odigitalav encoded 8bit 4:2:2 color information is being fed through along with HSync/VSync so anyone can really confuse that as video information. It would take little effort to encode that for use in a HDMI Transmitter. I was asking was in relation to the YCbCr color space comment, if it isn't using the YCbCr color space then what is it using in place of it I'd like to know more of what research has gone into the video data being fed into the MX branded chip.

[Diminuendo]

RGB 480i is already available on PAL GC which looks very good
if you specifically need component 480i, then maybe a converter or something like the TGX mod would work for you...http://www.tg16pcemods.com/

...35$ is a hell of a price considering the other options

any idea if this can output 480p?

[novenary]

Diminuendo : no progressive scan on either AVE. Enabling progressive mode will disable the composite signal on PAL cubes. With RGB it still looks awesome in interlaced mode though.
Mega : yes, scaling 480p. Modern TVs do not scale very nicely even for movies. And all the stuff they apply (filtering, non-integer scaling...) may be suited to movies, but not to games.

[megalomaniac]

Diminuendo, exactly as Streetwalker said...
once the video mode is flipped over to progressive you will lose composite. so you cannot strip sync anymore with the lm1881 or similar. i have not done enough testing on a PAL mainboard to see if i can find some simple improvement or easy mod, but i do plan to take a look later...
i do not expect to find anything and since RGB is already there might as well use the RGB.
At least to me thru my own observations,RGBpal480i looks as good as a component cable displaying 480i YPBPR

RGBpal480i is a major improvement over composite in terms of color separation and sharpness




Streetwalker: would you rather "handmade" device upscale the native 480p GC video to 1080i for compatibility for your TV or trust the technology already built into your TV? who has a greater chance of getting the information displayed on screen accurately??
also, i dont remember if you stated having a component cable, but have you ever had the chance to test your TV with one to determine how "your" tv displays gamecube progressive?? I do agree, there are some shit flatscreen flatpanel ultra-smart HDTVs out there that look like crap with 480i/p...get a 480p capable CRT TV and make all those issues go away...


actually, to further add, while testing something totally unrelated, i recently connected my component cable to an old CRT TV. I was amazed (fucking shocked) at how fantastic an old tube tv looked with 480i ypbpr...
looked better than my latest greatest smartTV.
I am currently on the hunt for a 36" 480p tube. I dont care if i need a crane to move it into my home. im getting one so i can be done with compensating with TV resolution issues.

[megalomaniac]

@megalomaniac Not sure why you're being so defensive about this topic. Personally I want to work on this project as well but thought to put the suggestion out there seeing that it didn't look like a direction people had discussed about previously.

That said lines are labeled VDATA0-7 going to both the AVE & the MX and that in the patent & in http://www.gamesx.com/wiki/doku.php?id= ... odigitalav encoded 8bit 4:2:2 color information is being fed through along with HSync/VSync so anyone can really confuse that as video information. It would take little effort to encode that for use in a HDMI Transmitter. I was asking was in relation to the YCbCr color space comment, if it isn't using the YCbCr color space then what is it using in place of it I'd like to know more of what research has gone into the video data being fed into the MX branded chip.

not being defensive, just was not sure what direction of information you were hoping to obtain from such a generic question...

the color space is YCBCR "data" but it is not delivered as Y CB CR signals as typically found in modern devices such as over bluray hdmi. it is a proprietary / non-standardized delivery of the information

[cvmagic]

@megalomaniac Not sure why you're being so defensive about this topic. Personally I want to work on this project as well but thought to put the suggestion out there seeing that it didn't look like a direction people had discussed about previously.

That said lines are labeled VDATA0-7 going to both the AVE & the MX and that in the patent & in http://www.gamesx.com/wiki/doku.php?id= ... odigitalav encoded 8bit 4:2:2 color information is being fed through along with HSync/VSync so anyone can really confuse that as video information. It would take little effort to encode that for use in a HDMI Transmitter. I was asking was in relation to the YCbCr color space comment, if it isn't using the YCbCr color space then what is it using in place of it I'd like to know more of what research has gone into the video data being fed into the MX branded chip.

not being defensive, just was not sure what direction of information you were hoping to obtain from such a generic question...

the color space is YCBCR "data" but it is not delivered as Y CB CR signals as typically found in modern devices such as over bluray hdmi. it is a proprietary / non-standardized delivery of the information

Nor do I expect it to, it predates the standardization of HDMI 1.0(2002) and DVI(1999) did not support YCbCr so it won't be in the appropriate encoding for an HDMI Transmitter. Incidentally the folks behind the HDMI standard made it quite easy by supporting YCbCr 4:2:2 out of the box, and the sampling I've been getting out of my own logic analyser makes it seem like it'd be quite possible with little(relatively) work if we toss out deinterlacing and upscaling. Obviously we can't just toss out 480i as it would mean games not supporting 480p would not work, I think that's where OzOnE hit a snag and where I am suggesting we use a chip (after we've converted the signal using an FPGA or CPLD for use with the HDMI transmitter) designed to handle both interlaced and progressive video for us as well as implementing the rest of HDMI standard. I personally don't care about upscaling because I believe it never enhances the quality in the signal, it can only maintain it in the most ideal situation or make it visibly worse.

As a side note, do you happen to know where I can source some connectors for this port? Well apart from scavenging from the already hard to find component cables. Right now I have leads soldered to the mainboard.

[megalomaniac]

best place to find a connector is from the cable itself...
these are proprietary connectors and cannot be found in a parts store/ warehouse/ distribution outlet / etc etc...
also, a similar substitute for the connector has yet to be identified...

you are better off not wasting additional time looking for a connector and just continue using the soldered wires as you are currently...

[novenary]

I don't have a component cable. Only rgb and composite. I do however know that RGBS is at least as good as YUV in 480i mode because I already compared that on other devices.

[cvmagic]

So my current game plan, I don't have that HDMI transmitter on hand yet but have the datasheet so I am going to wire up my XC9572XL CPLD dev board to the Vdata0-7 lines on the gamecube, see if I can synthesize a circuit small enough to fit into the tight 79 macrocell budget and still be able to output parallel 8bit YCbCr 4:2:2 along with HSync and VSync. To confirm it's working I'll pass it through my Spartan 6 board where I'll convert it to VGA.

[emu_kidid]

cvmagic, we could use you on some more projects we had in mind for GameCube

[cvmagic]

To say the least, it was not exactly what I was expecting, the way the data is formatted it's designed to be fed into devices intending to convert it into analog. It made it simpler logic wise than I expected. I've been able to get it to feed the FPGA YCbCr with timing errors occasionally which I'll have to address. Right now I have it reading and passing bits 0,4,5, and 6 from the flag bytes; the remaining are for NTSC/PAL and analog encoding.

I do have a bit of a problem with my original idea though, in trying to get a copy full copy of the transmitters' datasheet. It seems to get it an NDA and an HDMI license is required. I am okay with the NDA but not so much to the cost in getting a HDMI license. So we have to explore alternatives, we could go with a Component encoder as they are open and require no license, or VGA. Either direction it will be Analog coming out of this.

Going the encoder route, it will remain relatively low cost as the CPLD will do half of the MX chip was doing, the encoder will in turn allow you to use regular component cables to the Gamecube.

The VGA route will require the use of an FPGA because of the cross domain timing requirements, 480i can work but decent deinterlacing can be expensive logic wise and may require external components like SRAM or SDRAM.

Alternatively if digital output is an absolute must this option is the most expensive, going full out on a Spartan 6 using it's TMDS IO to simulate a HDMI signal. A Spartan 3A might work for this too, but in the expensive side and might not come in a hand solderable package.

[novenary]

For VGA there's always the option of generating Hsync and Vsync with a CPLD and using a PAL board for RGB. If you can write code that does just that then it would be a great and cheap alternative to the MX chip. Especially since a simple analog circuit can get us component too.