gc-forever - Gamecube/Wii Forums

meneerbeer wrote:That is too bad. Not sure what could be the issue. I will have to test it on more TVs anyways, but I only have access to two unfortunately.

Did you at least try 480p/576p? Those modes are most likely to be accepted by any TV.

If only I could get it to fit inside the Shuriken video, that would rule out a lot of the problems.. I still think it is possible to make something that fits inside it, but it requires a lot of work.

I will be gone untill the start of september by the way, so I won't be able to look at this at all coming days.

Thanks for trying out the code anyways.

It's fine I left the JTAG cable on the pluto so I can flash it easy next time I have found out that 1.1 also broke my TV compatibility so 1.3 is the reason that the pluto is working on my TV. I don't know why this is but something to look into

I made a little diagram for the sake of portables. Just a 5 minute wiring diagram using dirty portablizing tactics such as removing extra ground and voltage lines. I have yet to test it but it should work just fine. I excluded the csel and the 3 audio lines. Not sure if I needed csel though.

I'll be testing this later. Feel free to rip it apart.

EDIT:

Ok I added the CSEL Line so this should work with 12 wires, I'll update again after testing.



Images from here and blargamans rev C component cable mod.

http://forums.modretro.com/viewtopic.php?f=36&t=13251

I am pretty sure you need csel.

Does that 54 MHz via mean we would be able to use it on any GameCube, even on one without a digital video port?

bentomo wrote:Not sure if I needed csel though.

You only need it if you want to get a video signal from the board. ;)

(unrelated: Did I mention that preparing software for a release is a tedious and annoying process?)

meneerbeer wrote:I am pretty sure you need csel.

Does that 54 MHz via mean we would be able to use it on any GameCube, even on one without a digital video port?

Yes.

Unseen wrote:

bentomo wrote:Not sure if I needed csel though.

(unrelated: Did I mention that preparing software for a release is a tedious and annoying process?)

Cool, does that mean you have your own implementation of audio over hdmi working? Is it the microcode version?

meneerbeer wrote:Cool, does that mean you have your own implementation of audio over hdmi working?

Yes - it still needs a bit of cleanup (removing commented-out old code, fixing copyright headers etc), but I hope it'll be release-ready this weekend.

Unseen wrote:

meneerbeer wrote:Cool, does that mean you have your own implementation of audio over hdmi working?

Yes - it still needs a bit of cleanup (removing commented-out old code, fixing copyright headers etc), but I hope it'll be release-ready this weekend.

Awesome, I had no idea you were this far! I probably would not have bothered adding it myself in that case, allthough I did learn a little from it. I will be able to give it a try in September. Really curious if your version will work for Andre.

I have a small suggestion for a feature. There seem to be multiple VIC codes 480p (and also 480i, 576p etc.). One is for 4:3 the other is for 16:9. My TV will stretch the image to 16:9 if the 16:9 one is selected. Perhaps you can make that selectable through the OSD.

meneerbeer wrote:Awesome, I had no idea you were this far!

I didn't expect it to work that soon! When I finally added the audio data from the cube into the packets, I turned my TV's volume down and expected to hear screeching or other sounds indicating problems, but instead I got the Mario Kart DD intro music on the first try. Usually I need a few rounds of debugging/simulation.

I have a small suggestion for a feature. There seem to be multiple VIC codes 480p (and also 480i, 576p etc.). One is for 4:3 the other is for 16:9. My TV will stretch the image to 16:9 if the 16:9 one is selected. Perhaps you can make that selectable through the OSD. :P

Sure, 24 instead of 12 sets of infoframes (6 resolutions, full+limited RGB range) should still fit. The current ones are all set to 4:3, but a 16:9 option will be useful for a Wii version.

At least one of my TVs seems to think that "Aspect: Auto" means "always scale to 16:9" though. =(

Unseen wrote:

meneerbeer wrote:Awesome, I had no idea you were this far!

I didn't expect it to work that soon! When I finally added the audio data from the cube into the packets, I turned my TV's volume down and expected to hear screeching or other sounds indicating problems, but instead I got the Mario Kart DD intro music on the first try. Usually I need a few rounds of debugging/simulation.

Cool, really looking forward to seeing how you implemented it. The microcode stuff should make it a lot more straightforward how it is expected to look when synthesized.

Sure, 24 instead of 12 sets of infoframes (6 resolutions, full+limited RGB range) should still fit. The current ones are all set to 4:3, but a 16:9 option will be useful for a Wii version.

Is a Wii version still a thing? Last time I thought you said soldering to the DAC was kind of a challenge. For the GC version 16:9 is useful as well, for people that want their TV to stretch the image anyways. I am still unsure which one of the two I like most.

At least one of my TVs seems to think that "Aspect: Auto" means "always scale to 16:9" though. =(

My TV thinks it is supposed to always perform a zoom in on 1080p sources.

Don't forget wide-screen hacks and the (very) small amount of games that actually support it natively (Star Wars Clone Wars seems to always be wide-screen).

meneerbeer wrote:Cool, really looking forward to seeing how you implemented it. The microcode stuff should make it a lot more straightforward how it is expected to look when synthesized.

I haven't been completely successful in keeping the complexity down - dvid.vhd has grown to about 550 lines, not counting the ECC and TERC submodules or the two ROMs (microcode and static infoframes). Moving the "signal twiddling" to microcode was a really good idea though, finding and fixing bugs in a linear table is much easier than the first attempt which used pixel counts and multiple state machines.

Is a Wii version still a thing? Last time I thought you said soldering to the DAC was kind of a challenge.

It is when/if I have the patience to actually attempt to solder that. =) The signals are also available on vias close to the encoder chip, so an option would be to solder only to every second chip pin and use the vias for the other half of the connections.

Ok I updated the diagram and I have a GC-video lite wired up at home, I'm hopefully going to successfully program it tonight and wire it into a cube tonight.

Unseen wrote:At least one of my TVs seems to think that "Aspect: Auto" means "always scale to 16:9" though. =(

My video scaler does get it right and even adds a little animation when the aspect ratio changes: Video

So I've only used the Xilinx project environment before so I got as far as the .jed file is missing when I click program. I tried lattice diamond and lattice programmer. Advice?


EDIT: So I figured out how to recompile the entire project through diamond. However when I start programming "Failed in function READ_ID" comes up and says to check the log. I just want to make sure I've got this wired correctly.

I've got the board wired up to a 3v supply where vcc on the jtag is the pin in the square and going down from there I have TMS, TCK, TDI, TDO, then GND. I'm using the Lattice chinese jtag clone to program it. I hand soldered all of the passives but I reflowed the fpga and control ic so those look pretty solid.

What direction should I start looking in?

the kicad render on the first page agrees with how you have your board wired for the jtag header. I think i may have read somewhere in this thread about the knock off programmers not really working, but I could be wrong about that. It was ages since I have read this entire thread and I am not up to the challenge right now. You could always look to the data sheet of the fpga and start there.

I don't know off hand, don't have one, but that is where I would start.

Yea the wiring all looks good, I can't get it much better with hand tools honestly.

When I click on device view it looks like it's detecting the x02, so I think my programmer is fine, but I'm not sure if that is what it means.

Cable detects seems to work fine so I'm guessing the programmer is working fine. Here's the log I'm getting in lattice programmer and lattice diamond.

I can't tell what log it's actually asking me to check. All of the things that say log just tell me to check the log, so I'm guessing this is a log inside the software that unseen wrote then I can't find.

Will anyone be offering a cloned cable for sale? I will take one!

Sent from my SAMSUNG-SM-N910A using Tapatalk

bentomo wrote:Cable detects seems to work fine so I'm guessing the programmer is working fine. Here's the log I'm getting in lattice programmer and lattice diamond.

I think I've seen similar messages from the Lattice tools when I had a short on one of the JTAG pins. Unfortunately I can't test it myself right now because I don't have the hardware at hand.

I can't tell what log it's actually asking me to check. All of the things that say log just tell me to check the log, so I'm guessing this is a log inside the software that unseen wrote then I can't find.

I'm pretty sure this refers to some log written by the Lattice tools - nothing I wrote for GCVideo creates any log files.

New release: GCVideo-DVI 2.0

New features:

• Enhanced DVI mode
• Option to disable the output temporarily when the video mode switches, this may help some displays to recognize mode switches in non-enhanced DVI mode

Because new settings were introduced, the new release won't recognized a configuration stored by previous GCVideo-DVI releases which means that your settings will be reset to the defaults. Just reconfigure everything to your liking and hit "Store settings" once and then you'll get your favored options and OSD colors right from power-on once more.

There are currently three clips on Youtube that were recorded with an almost-2.0-version (the third one shows the menu from the release):

• Switching enhanced DVI mode on and off
• The Health and Safety screen from Twilight Princess, overlaid with a bit of signal information from a Triax HMX Analyzer (sucks, don't buy it)
• Aspect ratio switching via the GCVideo-OSD - needs a TV that correctly interprets the information from the video signal

(I really hope I won't need to do another release after this...)

Is there gonna be a VGA output option?

Sent from my SAMSUNG-SM-N910A using Tapatalk

XC-3730C wrote:Is there gonna be a VGA output option?

GCVideo Lite can be set to output RGB via a jumper and has H+V sync signals available, so you could wire a VGA connector to it. Support for 15kHz video modes (480i/576i) on VGA inputs tends to be a bit rare though, so you may not get a picture until the game switches to 480p.

So this is what perfection looks like.... Really amazing what you have done unseen, can't wait to try this out.

However, on your ''health and safety screen'' link, I noticed some tearing on the upper side of the picture. Is that youtube's doing, or maybe the capture device?

Lastly, will there be a video/guide, maybe by someone else, on how to order one and flash it (where, what files, how etc.) and maybe install one for the less tech-savvy among us?

tesla246 wrote:However, on your ''health and safety screen'' link, I noticed some tearing on the upper side of the picture. Is that youtube's doing, or maybe the capture device?

I think it's Youtube - I don't see any tearing in the original capture file (uploaded here for now), although I'm not sure how sensitive I'm to that. If you can also see tearing in the file, it's either the Elgato Game Capture or directly from the cube, with just two lines of video that can be buffered there isn't much chance to introduce tearing in the FPGA.

Lastly, will there be a video/guide, maybe by someone else, on how to order one and flash it (where, what files, how etc.) and maybe install one for the less tech-savvy among us?

I still hope that someone else will do that =)

Unseen wrote: I think it's Youtube - I don't see any tearing in the original capture file (uploaded here for now), although I'm not sure how sensitive I'm to that. If you can also see tearing in the file, it's either the Elgato Game Capture or directly from the cube, with just two lines of video that can be buffered there isn't much chance to introduce tearing in the FPGA.

Hmmm, its still there, but definitely less noticeable. The tearing is partciularly visible on the youtube video between 1:30 and 1;47 (look at the the rocks/mountains on the upper side of the screen against the light background, when the camera pans horizontally). Might be the cube or the capture device.

Unseen wrote:I still hope that someone else will do that =)

*fingers crossed*