gc-forever - Gamecube/Wii Forums

Posted: **Wed Jul 22, 2015 1:04 am**

Posted video of usage of Shuriken video V1 https://www.youtube.com/watch?v=rMpSMagFTyI

Posted: **Wed Jul 22, 2015 4:39 am**

double post

Posted: **Wed Jul 22, 2015 4:44 am**

megalomaniac wrote:
here is a quote from the very first post:
Unseen wrote:The board can output analog RGB (both CSync and HV-Sync available) or Component video.
here is another from page 3
Unseen wrote:
meneerbeer wrote:If you use the RGB output from the board and the game is 480p, can you then display it on a computer monitor with VGA?
Yes

RGBHV = VGA compatible

Thanks for the answer megalomaniac, I didn't know about RGBHV, I thought RGB meant 480i or 240p.
Very confusing for a beginner.

The PM was sent but apparently got lost since it's not in my messages sent box so sorry about that.
I was telling you about the kind of VGA cables I linked in my previous message and wondering if that when you'll be able to sell your " plug and play " board project, you could sell some of them plug and play for VGA too, and not only for component ?
But with your last answer I assume it shouldn't be a problem.

Posted: **Wed Jul 22, 2015 5:05 am**

For reference, SCART cables usually carry an RGBs (one connector for red, green, blue, and sync) signal and typically only go up to 480i. It's possible to send 480p through them I believe, like with the Toro Dreamcast VGA box, but it's very uncommon. A VGA signal only supports progressive scan (though could be the opposite of SCART and rarely allow for 480i, but I haven't heard of this before) and carries RGBHV which is one connector for each color, and then two connectors for a split horizontal and vertical sync.

Component is in a different colorspace (YUV vs. RGB) but is essentially an RGsB signal with the sync signal combined with the green signal into a single connector (really the color green is calculated as an offset in component video, but that's another story). If you're talking about actual RGsB it's referred to as sync-on-green.

Posted: **Wed Jul 22, 2015 5:50 am**

Also the hardware framebuffer uses YUV (actually YUY2) colorspace, so anyone who says the RGB cable gives more accurate colors is wrong.

Posted: **Wed Jul 22, 2015 11:59 am**

It has to be converted to RGB by the display anyway, using these luma/chroma based colorspaces only allows to reduce the bandwidth for composite and s-video by chroma subsampling and doesn't really make sense once you use better cables. The XFB uses this color space because it can be turned into composite which is the main output of the gamecube without any color space conversion.

Posted: **Wed Jul 22, 2015 4:20 pm**

Just ordered the parts for a board of my own, will take a couple weeks for the programmer clone to arrive but once I get it set up I'll probably post a video about the setup for getting it programmed and wired up.

Posted: **Wed Jul 22, 2015 5:05 pm**

That would be great for beginners who don't have a clue about this.

Posted: **Thu Jul 23, 2015 1:11 am**

Streetwalker wrote:It has to be converted to RGB by the display anyway, using these luma/chroma based colorspaces only allows to reduce the bandwidth for composite and s-video by chroma subsampling and doesn't really make sense once you use better cables.

Not true at all, HDMI supports YUV (YPbPr) colorspace. Nearly all blu-ray players use it so it's very widely accepted.
It is always best to let the display do the YUV->RGB conversion if possible.

Posted: **Thu Jul 23, 2015 8:28 am**

Fair enough, my point was that you have to do the conversion anyway. My monitor also supports YPbPr over DVI but you have to set it every time you turn it on so it's pretty annoying.

Posted: **Thu Jul 23, 2015 9:36 pm**

So for some monitors that support the YPbPr colour space you have to set it manual, does that
mean that some automatically configure it?

Posted: **Fri Jul 24, 2015 2:12 am**

DVI can't tell the monitor which color space you're using. My monitor is DVI-only and gc-video too anyway so it's not fixable.

Posted: **Tue Jul 28, 2015 10:44 pm**

I have some big news regarding the pluto 2x HDMI dev board. As some of you have been following my youtube videos of testing and usage of said devices I decided to mess around with the other pluto board I have. I flashed it with version 1.3 from unseens github and installed it in my crappy gamecube. I followed everything as directed and same outcome no picture on my TV so I had an idea. Instead of a 100ohm resistor from DDC 5v to vunreg I ran a wire. That little wire did it I'm getting a picture on one TV in my bedroom Nice! It runs in all modes now 480i,480p, 240p so far thats what I tried they work. OSD is working as well very interesting I can't believe a wire did it.

Ok some more time with it on the TV reveals that when you change video modes like starting a game in 480i then the game asks you if you want progressive scan and you press yes when it makes the change from i to p sometimes the picture ether won't recover or come back with artifacts in the picture. Other times its fine need to play around with it more

Edit: The pluto board does work on 4 TV's I've tried. It's not as sable as the Shuriken video though I also can't test the sound right now because I'm out of optical transmitters, I will order some more next week. The Shuriken video is much better at switching video modes I also don't ever have any problems with artifacts in the picture. That's something the pluto is still doing sometimes has some artifacts in the picture only once in a while it's kind of rare. But I got my OSD back I really like that feature

Posted: **Wed Jul 29, 2015 7:05 am**

Good stuff! The 5V is used as a HDMI detect to the TV. I know that my parents' TV needs this signal. My own TV just needs a ground and all TMDS pairs and that is it. I guess the 100 Ohm resistor was the problem then..

Ok some more time with it on the TV reveals that when you change video modes like starting a game in 480i then the game asks you if you want progressive scan and you press yes when it makes the change from i to p sometimes the picture ether won't recover or come back with artifacts in the picture. Other times its fine need to play around with it more

My guess is that your wiring is longer than with the Shuriken video. This problem sounds really like the problem I had with my own board. I changed the code a bit, which I described in the thread. I think that will fix your problem. I could compile a new version for you, but I will have access to ISE earliest this weekend.. My good PC is at my parents.

The fix works very well for me. Been playing with it the whole weekend and not a single problem occured.

If the fix works, then perhaps Unseen can add it to the Github?

Posted: **Wed Jul 29, 2015 7:27 am**

andre104623 wrote:Ok some more time with it on the TV reveals that when you change video modes like starting a game in 480i then the game asks you if you want progressive scan and you press yes when it makes the change from i to p sometimes the picture ether won't recover or come back with artifacts in the picture. Other times its fine need to play around with it more

I suspect this is because I had a workaround for this problem in the non-OSD versions that I planned to move to the software side, but then forgot to add there. You could try an older non-OSD version to check if it helps - although I'm planning to fix this in a different way.

meneerbeer wrote:If the fix works, then perhaps Unseen can add it to the Github?

If I can find it... I tend to ignore patches whose existence I'm not aware of. ;)

Posted: **Wed Jul 29, 2015 12:32 pm**

Unseen wrote: If I can find it... I tend to ignore patches whose existence I'm not aware of.

I will upload my modified file (do not have it right now) this weekend here, I guess. Together with a modified bitstream for Andre so he can see if it works.

In case you want to try it before then. Basically in the gcdv_decoder you need to store the VDATA and CSEL inputs into a register at the rising edge. For instance VDATA_BUF and CSEL_BUF for instance. Then you change the rest of the VDATA and CSEL entries to VDATA_BUF and CSEL_BUF. That way the path your input needs to go is a bit shorter. This has solved all instability problems I was having with 480p.

Posted: **Wed Jul 29, 2015 12:41 pm**

meneerbeer wrote:In case you want to try it before then. Basically in the gcdv_decoder you need to store the VDATA and CSEL inputs into a register at the rising edge. For instance VDATA_BUF and CSEL_BUF for instance. Then you change the rest of the VDATA and CSEL entries to VDATA_BUF and CSEL_BUF. That way the path your input needs to go is a bit shorter. This has solved all instability problems I was having with 480p.

Ah, that sounds reasonable. I thought I could get away witout registering the external inputs because in theory the sampling point (falling edge of Clock54) is during a "quiet" time in the signal, but it certainly wouldn't hurt anything. Thanks for the hint, I'll add it in the next release.

Posted: **Wed Jul 29, 2015 2:38 pm**

meneerbeer wrote:Good stuff! The 5V is used as a HDMI detect to the TV. I know that my parents' TV needs this signal. My own TV just needs a ground and all TMDS pairs and that is it. I guess the 100 Ohm resistor was the problem then..

Ok some more time with it on the TV reveals that when you change video modes like starting a game in 480i then the game asks you if you want progressive scan and you press yes when it makes the change from i to p sometimes the picture ether won't recover or come back with artifacts in the picture. Other times its fine need to play around with it more
My guess is that your wiring is longer than with the Shuriken video. This problem sounds really like the problem I had with my own board. I changed the code a bit, which I described in the thread. I think that will fix your problem. I could compile a new version for you, but I will have access to ISE earliest this weekend.. My good PC is at my parents.

The fix works very well for me. Been playing with it the whole weekend and not a single problem occured.

If the fix works, then perhaps Unseen can add it to the Github?

Wiring is very short maybe 1/4 inch or for you guys over seas 1.5CM maybe less. I placed it inside the cube this time

Posted: **Thu Aug 06, 2015 3:27 pm**

Ok finally got the pluto 2x HDMI installed inside the cube ( Again ). Everything is working on my TV in my bedroom but not on my TV in the living room ( The one in my shuriken video posting ) So those I2c lines must be still be problematic with some displays. I'm going to have to make a new video again to clear up my first GCvideo-DVI video which I was only able to use a computer monitor. My last attempt at installing inside my cube was a failure because A. I didn't secure the pluto well and popped in when plugging in the HDMI cable B. Some of my solder joints were not adequate as a result my picture was a little funny sometimes and there was no sound though the fiber optic line.

Everything is fixed and I got some really good epoxy which I don't really like to use because it's impossible to remove which is why I like hot glue but I made sure everything was working before I glued everything together.

Posted: **Sat Aug 08, 2015 9:48 pm**

Unseen, did you have a look at how well the GC's video output matches the CEA861 spec? I am trying to quickly hack HDMI audio support into the GCVideo code. Currently only trying to add it for 480P video. Is the hsync low, when it is active? Basically I need GCVideo's output for 480P to be fully compliant to CEA861, so hsync length of 62 pixels, front porch of 16 pixels etc. I have not been able to check how well video output matches the specifications. Chipscope seems to suck really badly and hooking up my GC to an Altera FPGA for SignalTap is a bit troublesome.

Posted: **Sat Aug 08, 2015 10:29 pm**

meneerbeer wrote:Unseen, did you have a look at how well the GC's video output matches the CEA861 spec?

Not down to the last pixel - the details may depend on the game that is running.

Is the hsync low, when it is active?

The bit in the flag byte sent by the GC appears to use 1 for "sync active" all the time, but the top level module translates this to low-active HSync and VSync.

Basically I need GCVideo's output for 480P to be fully compliant to CEA861, so hsync length of 62 pixels, front porch of 16 pixels etc.

If the timing sent by the cube is not sufficiently compliant, you could try to modify it - the blanking regenerator module does this to extend the active area to a full 720xwhatever.

I have not been able to check how well video output matches the specifications. Chipscope seems to suck really badly and hooking up my GC to an Altera FPGA for SignalTap is a bit troublesome.

It may be easier to measure this with a few counters directly on the FPGA and use the existing OSD to show the results. ZPUVideoInterface.vhd already measures the size of the active area that the GC generates.

Posted: **Sun Aug 09, 2015 10:14 am**

I see, I am using Charcole's hdmidirect code, which I modified to take video input and then mix incoming audio + video to an HDMI signal. The code seems to fail miserably when doing simulations. The Verilog tasks do not seem to be handled correctly (although I could be wrong of course), so I was afraid it was also not synthesized correctly. The SendPacket task bit shifts the packets that need to be sent. In simulation I do not see a shift happening at all.

I just tried to generate my own video signal with 480p CEA861 timings that is plugged into the modified hdmidirect code and I now have HDMI with sound working on a Xilinx fpga, so it seems it is actually synthesized correctly. It does not work with GCVideo however, so I think the video timings are different for 480p.

Oh uh, do not bother to help too much with this if you do not feel like it. As you are working on this yourself, most likely with a way cleaner implementation there is not really much of a point I guess. Right now I am just too lazy to write the packet generation with VHDL myself..

I will take a look at the video specs of the GC next I guess.

Posted: **Sun Aug 09, 2015 11:00 am**

meneerbeer wrote:I see, I am using Charcole's hdmidirect code, which I modified to take video input and then mix incoming audio + video to an HDMI signal. The code seems to fail miserably when doing simulations.

I haven't been able to simulate that code either, but there is another Spartan 3A HDMI project out there which worked for me both in simulation and on actual hardware. I think its implementation is a bit cleaner too.

I just tried to generate my own video signal with 480p CEA861 timings that is plugged into the modified hdmidirect code and I now have HDMI with sound working on a Xilinx fpga, so it seems it is actually synthesized correctly. It does not work with GCVideo however, so I think the video timings are different for 480p. :(

Could be, although I hope that many displays do not demand a "CEA-compliant down to the very last pixel" timing. Did you pass the pixel clock enable signal to the encoder? GCVideo always runs at 54MHz internally, but pixels from the Cube arrive at either 27 or 13.5MHz depending on the video mode - and since 13.5MHz is too low for DVI/HDMI, the DVI encoder is fed a synthetic enable signal that results in a 27MHz pixel clock for all video modes, effective doubling the horizontal resolution for 15kHz modes.

Oh uh, do not bother to help too much with this if you do not feel like it.

I like it when other people reduce my workload ;)

As you are working on this yourself, most likely with a way cleaner implementation there is not really much of a point I guess. Right now I am just too lazy to write the packet generation with VHDL myself..

We'll see... My initial code to send just one infoframe per video frame (to get things right before making it more complicated) was rather messy - so messy in fact that it was mis-synthesized, but figuring that out took a few weeks and a second FPGA running the HDMI receiver part of bunnie's NeTV to check the actual data on the wire.

The new version of that code is now much shorter and cleaner, but now I'm thinking about writing a microcode assembler because editing sequencer outputs in VHDL is tedious:

Code: Select all

    case address is
      -- preamble
                       -- enc     c3c0    bt4   shft  hmo   dmo   ldp   1st  done
      when  0 => data <= "010" & "0101" & "0" & "0" & "1" & "1" & "1" & "1" & "0";
      when  1 => data <= "010" & "0101" & "0" & "0" & "1" & "1" & "0" & "1" & "0";
      when  2 => data <= "010" & "0101" & "0" & "0" & "1" & "1" & "0" & "1" & "0";
      when  3 => data <= "010" & "0101" & "0" & "0" & "1" & "1" & "0" & "1" & "0";

Posted: **Sun Aug 09, 2015 6:49 pm**

Unseen wrote: Could be, although I hope that many displays do not demand a "CEA-compliant down to the very last pixel" timing. Did you pass the pixel clock enable signal to the encoder? GCVideo always runs at 54MHz internally, but pixels from the Cube arrive at either 27 or 13.5MHz depending on the video mode - and since 13.5MHz is too low for DVI/HDMI, the DVI encoder is fed a synthetic enable signal that results in a 27MHz pixel clock for all video modes, effective doubling the horizontal resolution for 15kHz modes.

Yes, I passed the clock enable signal. At first I thought the clock enable signal was a bit over engineering things, but it actually makes sense now. I guess it saves on PLL outputs. I have to say, your code is really nice to work with/hack things into!

I have something working now!

However, I pass the horizontal and vertical count as the sound samples, so all I can hear is an annoying buzz. Now I am going to solder the I2S lines to the FPGA, as I did not do that yet.

The new version of that code is now much shorter and cleaner, but now I'm thinking about writing a microcode assembler because editing sequencer outputs in VHDL is tedious:

Code: Select all

    case address is
      -- preamble
                       -- enc     c3c0    bt4   shft  hmo   dmo   ldp   1st  done
      when  0 => data <= "010" & "0101" & "0" & "0" & "1" & "1" & "1" & "1" & "0";
      when  1 => data <= "010" & "0101" & "0" & "0" & "1" & "1" & "0" & "1" & "0";
      when  2 => data <= "010" & "0101" & "0" & "0" & "1" & "1" & "0" & "1" & "0";
      when  3 => data <= "010" & "0101" & "0" & "0" & "1" & "1" & "0" & "1" & "0";

Interesting. I do not completely understand yet how that code would look, but I guess that should also be a lot easier to synthesize.

Posted: **Sun Aug 09, 2015 7:12 pm**

meneerbeer wrote:At first I thought the clock enable signal was a bit over engineering things, but it actually makes sense now. I guess it saves on PLL outputs.

Actually I'm just scared of working with multiple clock domains =)

I have something working now!

Cool!

Interesting. I do not completely understand yet how that code would look, but I guess that should also be a lot easier to synthesize.

It's basically the list of desired outputs for each pixel. A single data packet with all the surrounding bits is always 44 pixels long (8 preamble, 2 guard, 32 data, 2 guard) and the only thing that changes between different packets is the transmitted data, so it can be modeled as a counter that steps linearly through a ROM whose outputs control what should happen on the line (e.g. "set encoder mode to TERC4", "shift the packet data by one bit", "switch from calculating the ECC to transmitting it"). The HDMIDirect code mostly does this by checking for specific horizontal pixel positions, the table-driven approach just needs a counter that is started at some point and stops when the "done" output is active. It's similar to a microcoded CPU and it will probably save some resources because the table can be synthesized as a Block-RAM.

gc-forever - Gamecube/Wii Forums

Cloning the GameCube component cable

Re: Cloning the GameCube component cable

Re: Cloning the GameCube component cable

Re: Cloning the GameCube component cable

Re: Cloning the GameCube component cable

Re: Cloning the GameCube component cable

Re: Cloning the GameCube component cable

Re: Cloning the GameCube component cable

Re: Cloning the GameCube component cable

Re: Cloning the GameCube component cable

Re: Cloning the GameCube component cable

Re: Cloning the GameCube component cable

Re: Cloning the GameCube component cable

Re: Cloning the GameCube component cable

Re: Cloning the GameCube component cable

Re: Cloning the GameCube component cable

Re: Cloning the GameCube component cable

Re: Cloning the GameCube component cable

Re: Cloning the GameCube component cable

Re: Cloning the GameCube component cable

Re: Cloning the GameCube component cable

Re: Cloning the GameCube component cable

Re: Cloning the GameCube component cable

Re: Cloning the GameCube component cable

Re: Cloning the GameCube component cable

Re: Cloning the GameCube component cable