Re: Cloning the GameCube component cable
Posted: Wed Aug 17, 2016 5:48 am
I've checked. NES is 256x232, main menu is 608x448 and the rest is 640x480.
Gamecube/Wii support & news forums
http://www.gc-forever.com/forums/
FANTASTIC. You have no idea how excited I am about this. Project M will look amazing. Noob question: will the Pluto work for Wii as nicely as for GC? Also, is there a Paddata-via for the OSD again, or will it rely on the new IR compatibility?Unseen wrote:GCVideo-DVI 2.2, now with:Oh, and no - I don't have any videos or screenshots available and I can't make them any time soon because my Dev-Wii is a wiring mess and the board is currently on the Cube for the final "did I break anything"-checks.
- Infrared remote support (alternative to Pad)
- Wii support (don't even think about it unless you found that soldering the Paddata-Via on the Cube was really easy)
Yes, but I don't think you'll be able to fit it in the Wii's case. Also, you need to flash either the Wii or the GC bitstream to it, so using the same Pluto for both Wii and GC isn't really an option.Guilt wrote:Noob question: will the Pluto work for Wii as nicely as for GC?
There are some nice test pads for it, so if your Wii has Gamecube ports you do not need IR.Also, is there a Paddata-via for the OSD again, or will it rely on the new IR compatibility?
Someone else is already working on a solution for the Dreamcast, so I probably won't do my own unless I don't like what he offers.Now make it Dreamcast compatible.
Oh boy is that the trick. I just finished reassembling my Wii and if there's a way to stick a Pluto in there I have NO idea where it's gonna go.Unseen wrote: Yes, but I don't think you'll be able to fit it in the Wii's case. Also, you need to flash either the Wii or the GC bitstream to it, so using the same Pluto for both Wii and GC isn't really an option.
Is OzOne still working on that? I wonder if that's almost release worthy yet...Someone else is already working on a solution for the Dreamcast, so I probably won't do my own unless I don't like what he offers.
I still find it a pain compared to the Gamecube... and I still have no idea where that tiny foam block goes that fell out when I took out the board.Guilt wrote:Oh boy is that the trick. I just finished reassembling my Wii and if there's a way to stick a Pluto in there I have NO idea where it's gonna go.
As far as I know he does, he posted an update not that long ago on Assemblergames.Is OzOne still working on that? I wonder if that's almost release worthy yet...
Oh, tented vias (covered with solder mask) - annoying. A fiberglass eraser will probably be helpful if you want to solder to these vias, IMHO it's much easier to remove solder mask in a very controlled way with these compared to other scratching implements.Here's a picture of my NTSC Wii from like a few months after the NA launch.
Based on the other components around it and the way the pins are connected I think it would be a reasonable guess that the pinout is the same for AVE-RVL and AVE-RVL A. Your markings on the vias also look reasonable to me.I've taken these images to try and follow the traces and see if I can figure out which vias go to which pins, but I'm nervous that my chip's pinout might be different.
If it doesn't have "wii" in the file name, it does not work on the Wii. I haven't built bitstreams with Wii support for the shuriken variants because I didn't have their schematics available to check which pins could be used for the IR remote and its config button.ghostavel wrote:will the gc-dvi 2.2 on the shuriken v2 work on the wii? i would like to test it out this weekend if it does.
I can easily add Wii-builds for the shuriken, but I need to find a bit of time to locate their schematics first.ghostavel wrote:got exited as i have a couple of assembled shurikens...
is it something that will be available in the future or is the pluto ii my only option for the wii?
I'm not really the right person for that either, but after reassembling my Wii to get a better view on its internals I would guess that it might be a viable option? In testing, I usually had only the heat sink screwed onto my bare board with no fan and the system didn't seem to mind, at least in the main menu.Guilt wrote:My thoughts are, if the heatsink's fins are already partially removed in a stock Wii, and much of it isn't even behind the fan, then how much will it really hurt if I take off a 8th to a 5th of the volume and stuff a Pluto in there? Will it overheat? I sure don't understand enough of the science to say, and I don't know if you do either.
Any chance this idea works for the current Shuriken V3 board? I am late to this game, but I would like to build a V3 with case. However I really want to have a full working GCVideo DVI with OSD working.andre104623 wrote:If the shuriken video had the XC3S200A instead of the XC3S50A it would be perfect. I really liked the OSD with ability to use scanlinesUnseen wrote:Just replace the chip, they're almost pin compatible with each other and on the Shuriken Video board the differences do not matter.
If I find a reason to release an update, I will. Currently I have no plans to do so though, except for the IR remote pins for the Shuriken boards.Xaranar wrote:Hey Unseen, purely out of interest, are you going to keep releasing updated versions of the GCVideo firmware, even after the release of Mega's plug and play version, despite their lack of means to update like us with Pluto boards can?
Never. To do this properly, GCVideo would need to check the EDID data from the display to determine if it supports non-RGB formats and that is too much of a pain to implement and probably won't fit in the remaining space either.Extrems wrote:When's Y'CbCr passthrough over HDMI?
Just because it is specified in HDMI 1.0 does not mean that every device with an HDMI input is required to support it.Extrems wrote:It's part of the HDMI 1.0 specification, is checking the EDID really necessary?
Even if I would implement YCbCr outout, it would be 444 and not 422. The current code is not able to handle reduced-resolution chroma in most of the modules, for example the OSD and fixing that would be a major undertaking.Extrems wrote:What if I want to upscale chroma using jinc or bilateral filtering, or the super-resolution algorithm of the year?
There are correct matrix coefficients and wrong matrix coefficients. Why do you want to use wrong ones?What if I want to use different matrix coefficients?
422-to-444 by repetition instead of filtering? It looks a tiny bit worse, but you need to look very closely to see it, even with test patterns.Can you at least add an unfiltered option?
Do you even use a capture device that puts the color samples in the correct location?It'd reduce loss with Y'CbCr 4:2:2 capture devices
So what if I want to output YCgCo, or something wacky like xvYCC?Unseen wrote:There are correct matrix coefficients and wrong matrix coefficients. Why do you want to use wrong ones?
Install Xilinx ISE and implement them yourself?Extrems wrote:So what if I want to output YCgCo, or something wacky like xvYCC?
I've checked and it's indeed using left, oh well.Unseen wrote:Do you even use a capture device that puts the color samples in the correct location?