gc-forever - Gamecube/Wii Forums

megalomaniac wrote:

andre104623 wrote:Just remember I think that there will never be a plug-and-play version so your going to have to solder something.

....pfffft
you underestimate the power of the MEGA

YEAHHHHHHHHH

Mega, can you tease us some more? Will it be HDMI audio and video in a single cable? Would be awesome.

lev11 wrote:Blimey @andre104623 looks like you have been unlucky!
My GC-video DVI on my standard PAL gamecube has worked on all the following:

Samsung TV
Panasonic TV
LG TV
Benq monitor (via HDMI -> DVI cable)
Marantz AV amp
2 x different unbranded cheapo PC monitors

Basically everything I can access with a HDMI input has worked, though some don't like 240p just adding linedouble + with or without scanlines sorts that.

Well lucky you. I'm not buying a new TV this year so maybe next year

Wait a minute PAL gamecube. So your mostly using 576p and 576i correct? So my problem is I can't get a picture from HDMI I'm guessing it because my TV won't read 480i and 480p though HDMI.

No mostly in 480i, or 480p (if booted via swiss), or 240p for gameboy player, as I always select 60Hz mode. PAL games let you choose between 50hz (576i) and 60Hz (480i).

Have you tried KNJN's HDMI.XC3S200.bit, its a free download when you buy the board? That would let you test the FPGA on your TV independantly of your gamecube or wiring, it still works in place as long as you powerup the gamecube for the 5v. I had to test mine when updating between v1 and v1.1 as I had trouble flashing it. At least you'd know whether or not it was the board that had the issue then.

I think it maybe a problem with true NTSC gamecubes, so we have

unseen / happy_bunny / lev11 with pal gamecubes it all works lovely on are TV

then we have

andre104623 with a NTSC gamecube and it only works a PC monitor.

has anyone else in north america tried unseens code on there true NTSC gamecube ?

That doesn't make sense. The only difference between a pal and an NTSC cube is the video encode which isn't involved in the chain when using the digital port.

... Weird... maybe there's a timing difference somewhere on the signal?

I'll be able to try it this week on a ntsc if I can get through the wiring.

Unseen, have you seen Extrems' Gameboy Interface: viewtopic.php?f=37&t=2782 ?
GCVideo reports the ultra low latency version (59.7276Hz) as 288p@50Hz, but my TV sees it as 240p60Hz.

lev11 wrote:Unseen, have you seen Extrems' Gameboy Interface: viewtopic.php?f=37&t=2782 ?
GCVideo reports the ultra low latency version (59.7276Hz) as 288p@50Hz, but my TV sees it as 240p60Hz.

I haven't tested that one yet.

If GCVideo claims it is 288p@50, then the flags sent by the Gamecube identify it as a progressive PAL mode with 15kHz horizontal rate. I suspect Extrems modifies the video mode parameters quite a bit to match the Gameboy's frame rate as well as possible, in which case the blanking regeneration in GCVideo may get confused a bit.

@unseen Is there any benefit to update my 1.1 DVI to the 1.2?

andre104623 wrote:@unseen Is there any benefit to update my 1.1 DVI to the 1.2?

The only difference is better compatibility with some third-party controllers, specifically a certain NES-to-Gamecube adapter. If the OSD works with your current controller, there won't be any difference.

Unseen wrote:

andre104623 wrote:@unseen Is there any benefit to update my 1.1 DVI to the 1.2?

The only difference is better compatibility with some third-party controllers, specifically a certain NES-to-Gamecube adapter. If the OSD works with your current controller, there won't be any difference.

Ok thank you. I use a wavebird and the OSD works everytime

I have got GC audio over HDMI working.
[youtube]https://www.youtube.com/watch?v=9G0SDgQcE2Q[/youtube]

When you see the GC screen, you see the GC image through composite. After that I switch to HDMI. The screen then turns yellow. That is because, I wanted to give it a quick try, so I only connected the I2S signals to my FPGA. So I am outputing my own image currently, which is just a yellow image.

Currently it does not use any code from GCVideo. What it basically is, is just a module that outputs a fixed HDMI image, which also has I2S inputs for audio. It outputs 32KHz audio at the moment, but I think that should not be too hard to change to 48KHz. Only thing I am not sure about is whether the I2S clock and the video clock are derived from the same input clock. If that is not the case, then we need to make the CTS factor variable, I think. Other option is to drop an audio sample every now and then (will rarely happen, can not be noticed at all).

I would love to try to get this to work with GCVideo, but I am a bit short on time and I would also need advice how to cleanly connect all the signals. At the moment I have removed the shielding underneath the motherboard (heatsink is now loose). Unfortunately my disc drive does not seem to work either, so I could not show a game.

andre104623 wrote:@unseen Is there any benefit to update my 1.1 DVI to the 1.2?

And for completeness: 1.3 only changes a single bit in the SPDIF data stream which stops some Realtek chip from muting the signal.

meneerbeer wrote:I have got GC audio over HDMI working.

Nice!

Only thing I am not sure about is whether the I2S clock and the video clock are derived from the same input clock.

They are, the audio sample rate is locked at 54MHz / 1124, so a possible CTS/N pair would be N = 6144, CTS = 26976.

Unseen wrote:

andre104623 wrote:@unseen Is there any benefit to update my 1.1 DVI to the 1.2?

And for completeness: 1.3 only changes a single bit in the SPDIF data stream which stops some Realtek chip from muting the signal.

meneerbeer wrote:I have got GC audio over HDMI working.

Nice!

Only thing I am not sure about is whether the I2S clock and the video clock are derived from the same input clock.

They are, the audio sample rate is locked at 54MHz / 1124, so a possible CTS/N pair would be N = 6144, CTS = 26976.

Are you currently working on audio support? I think it should be relatively easy to add. My code is modified from NeoGeoHDMI, although I am also porting it to VHDL currently, but I think it is good to first test if it even works. What I would propose is to make GCVideo output the decoded RGB + signals indicating what the HDMI state should be (active video, video/data preamble, data etc.) and feed this to a unit that converts the RGB video + i2s to HDMI. You can base the state on horizontal count and vertical count and I think you already have those counters implemented.

I am interested in how you hooked up your board to the GameCube. Did you remove your digital port? I am kind of leaning towards first making a PCB board that fits nicely in the console, because I hate messy wiring. Underneath the disc drive is plenty of space to fit a board, but getting the wires from the digital port to there seems a bit annoying..

meneerbeer wrote:Are you currently working on audio support?

Yes, although very slowly.

My code is modified from NeoGeoHDMI,

I know that code and it's one of the sources for my notes, but I don't use it directly for various reasons - one of them being that GCVideo needs a bit more flexibility because it can output six different video modes.

You can base the state on horizontal count and vertical count and I think you already have those counters implemented.

My current test bed is a bit closer to XAPP460 and just expects parallel RGB+Blanking+Syncs as input. Currently there is just one fixed aux packet that is triggered by VSync, but if I remember the timing correctly adding one or two data packets after every HSync should be no problem and that wouldn't require any counters at all. It's still quite broken though, I need to shuffle a few things around the state machine to ensure the timing works out.

I am interested in how you hooked up your board to the GameCube. Did you remove your digital port?

Yes, and I soldered short pieces of ribbon cables that are threaded through its opening to a .1 inch dual-row pinheader on the outside. I'm thinking about changing this to a 26-pin Sub-D connector (three-row version of the 15 pin "PC game port" one) because it seems that one of the connections has broken - again.

I am kind of leaning towards first making a PCB board that fits nicely in the console, because I hate messy wiring. Underneath the disc drive is plenty of space to fit a board, but getting the wires from the digital port to there seems a bit annoying..

The Pluto board that I am currently targeting should be small enough to fit into that space, but a cheaper alternative(*) with a sufficiently small form factor would be nice.

(*) Scarab Hardware has announced a board with the same XC3S200A FPGA, HDMI output and integrated JTAG adapter for 35 USD, but it appears that it is still not shipping. It's physically larger, so integrating it into the Gamecube would likely not be possible.

Unseen wrote: My current test bed is a bit closer to XAPP460 and just expects parallel RGB+Blanking+Syncs as input. Currently there is just one fixed aux packet that is triggered by VSync, but if I remember the timing correctly adding one or two data packets after every HSync should be no problem and that wouldn't require any counters at all. It's still quite broken though, I need to shuffle a few things around the state machine to ensure the timing works out.

I have seen XAPP460. I think that makes more sense for cleaner code. I guess you only need to recognize the beginning and ending of blanking area a certain number of samples ahead. I am a bit confused with what you mean with one AUX packet. Are you buffering all the audio and send it only when VSync is triggered? Because you can easily only send the audio data during the horizontal blanking.

Yes, and I soldered short pieces of ribbon cables that are threaded through its opening to a .1 inch dual-row pinheader on the outside. I'm thinking about changing this to a 26-pin Sub-D connector (three-row version of the 15 pin "PC game port" one) because it seems that one of the connections has broken - again.

This is why I hate development/breadboard setups. I will have a look at making a PCB. Only thing that sucks imo is getting the wires to the board then. I think part of the bottom shielding needs to be cut away if you want to solder the wires to the bottom of the digital port.

meneerbeer wrote:I guess you only need to recognize the beginning and ending of blanking area a certain number of samples ahead.

Yes, the output data must switch to 8 preamble pixels followed by 2 guardband pixels just before the active video area. Right now I do that just like the appnote using shift registers, but since everything is a bit space-constrained I plan modify the earlier video stages to provide an "early warning" version of the blanking signal instead.

I am a bit confused with what you mean with one AUX packet. Are you buffering all the audio and send it only when VSync is triggered?

Currently the encoder doesn't even have an audio input, the encoder needs to get the process of sending just a single aux packet with fixed data right before I start worrying about that. Triggering that single test packet using VSync is quite convenient for simulation and when it's implemented the video infoframe would probably get sent there too.

This is why I hate development/breadboard setups. I will have a look at making a PCB. Only thing that sucks imo is getting the wires to the board then. I think part of the bottom shielding needs to be cut away if you want to solder the wires to the bottom of the digital port.

A fixed internal installation would be too inflexible for development for me though, occasionally I still connect a logic analyzer to see what happens if the simulation cannot provide sufficient detail or I'm too lazy to construct another testbench for the current problem.

Unseen wrote: A fixed internal installation would be too inflexible for development for me though, occasionally I still connect a logic analyzer to see what happens if the simulation cannot provide sufficient detail or I'm too lazy to construct another testbench for the current problem.

I am not too familiar with Xilinx. What I like about Altera is the SignalTap logic analyzer. I almost never write a testbench anymore because of that. Also, the JTAG programmer is very cheap.

I think Xilinx has the option of an internal logic analyzer as well, but I guess you do not have a JTAG programmer? I also read it was not really that good.

I need to think about how to program my custom PCB. The JTAG programmer seems rather expensive. It is so expensive that I seriously considered to just make a board with an Altera FPGA, but they have bigger footprints, usually need 3 power levels and do not have TMDS outputs. Maybe I should just get the JTAG programmer.

I am thinking of making a board with an FPC connector and then also use a breakout board to go from the FPC cable to the digital video port connections. I think it should be possible to place the breakout board on the bottom of the shielding of the motherboard and then cut away part of the shielding to be able to access the bottom of the digital video port. Not sure which lengths the clock signal can take, but of course it is possible to shield it properly by putting ground signals around it.

meneerbeer wrote:I am not too familiar with Xilinx. What I like about Altera is the SignalTap logic analyzer. I almost never write a testbench anymore because of that. Also, the JTAG programmer is very cheap.

I think Xilinx has the option of an internal logic analyzer as well, but I guess you do not have a JTAG programmer? I also read it was not really that good.

Xilinx has ChipScope which is their equivalent to SignalTap and I think I even have a license for it. I don't think it would be very useful for me though because it needs quite a bit of block RAM to store the data and IIRC there are only three still left in the design. With a simulation, the only limit is the space on my hard drive and I'm not limited to synthesizable constructs - it's quite useful to see U/X signals propagating through the design to figure out where an initalisation is missing.

I need to think about how to program my custom PCB. The JTAG programmer seems rather expensive.

There are cheap chinese clones of the Xilinx USB programmer. If you want to avoid them, you could generate an SVF file with the Xilinx tools and play it using another JTAG programmer. Another option is xc3sprog, an open-source tool that can program various Xilinx FPGAs and supports a number of different JTAG interfaces, although I'm not sure if the Altera USB Blaster is among them.

Ah, it seems you can use the USB Blaster if you use UrJTAG. I have a Papilio One FPGA lying here (my only Xilinx board), so I can give it a try to see if I can get it to work. If it does, I will just use JTAG to program the SPI flash, I guess.

Very excited for this project!

I intend on using it for portables though so I have a question. Did anyone post the motherboard via locations for the digital port anywhere? Or will I have to trace them myself?

@LOCTronics, have you tried this with one of those 5" vga screens from aliexpress yet?

Bentomo; you're much better off wiring directly to the AVE-DOL chip instead of the vias.

@Bentomo, you should checl out the GC Sticky and click on Rev C component cable, if you click on it you'll see the pinout of
the NTSC AVE-DOL chip which Blargman found the pinout for.

Also, Unseen would be possible to create our own PCB without having to buy one from OshPark?
For example Pcb etching from a cnc machine, or a laser printer beacause of its toner?
It also seems like it would be possible to print out the design you created for a laser printer, is it printable?