Gameboy Advance RGB NTSC

[kamiboy]

I actually have a component cable, and pretty much all my systems are NTSC, the Cube not being an exception. Thing is I want to use this on a TV without component input, so I have to go with S-video. Don't want to mess with messy transcoder setups either, even though I have them available.

The maker of GBI never gave an explanation on the mising colours in S-video issue did he? Mind asking him again in that thread of his? I am not a member there.

[BazookaBen]

The maker of GBI never gave an explanation on the mising colours in S-video issue did he?

He did. The weird GBA frequency breaks the chroma encoding process on the video chip.

EDIT: Or maybe he meant the decoding chip in the TV

[Einzelherz]

Here is the set of files/tools that I used to produce the ISO (including GBI):

https://dl.dropboxusercontent.com/u/484 ... 0151014.7z

I deleted the ~1GB video file from the disc folder that I had stuck in there to pad the ISO.

Just to be clear, I can make a bootable disc with the ULL version of GBI that should work fine over S-Video?

[bobrocks95]

According to Guspaz yes, but I don't see how. Why would it magically work for that version and then not work for any earlier or later versions, especially if the problem is due to the odd refresh rate?

[Guspaz]

I don't know what to say, it works fine for me... Do you guys need a video of the thing working to believe it?

I've got a Gamecube (NTSC, with digital port) running GBI ULL via a XenoGC mod chip and DVD-R. It's connected to a PVM-14L2 via S-Video, which works fine with colour. The PVM's S-Video output is run directly to the Epson PowerLite 8345 projector. Both the PVM and the Epson projector work perfectly fine, with colour.

This was the first and only version of GBI I ever bothered to try, so it's simply worked fine for me.

EDIT: Here: https://www.youtube.com/watch?v=pQJwNCLRmQM

It was too dark behind the PVM to really see the s-video cable actually plugged in, so that kind of ruins my proof. I said in the video that you can see that the PVM is on the S-Video input, but only realized after that that doesn't prove anything: LINE A has both composite and s-video inputs. However, you can clearly see when I turn off the gamecube that the projector is on s-video input.

[BazookaBen]

Maybe certain revisions of the Gamecube have a more capable encoding chip? This is interesting.

Is your Gamecube a launch model or something? Mine is from late 2002 and is definitely in black and white over s-video.

[Guspaz]

No idea, I got it on eBay a few months back, because my SGB does't do GBC or GBA games. It's early enough to have the digital port.

[Spacemonkey]

Tried it out on a US Gamecube with XenoGC, connected to a PVM monitor via S-video it works fine in color.

I burned a DVD-R with the latest ULL version (2016-01-03) My Gamecube has the Digital port.

Looks pretty good, there is however some nasty screen tearing? on certain games, pretty noticeable on Yoshi's Island.

[Guspaz]

IIRC the screen tearing is specific to the ULL version (because it has no framebuffer), and it comes from the slight difference between the GBA refresh rate (59.7275 Hz) and the GameCube running GBI (59.7276 Hz). It should basically be luck of the draw how long it takes before tearing is visible, because it needs to basically drift far enough out of sync to notice it. The author reports that it typically takes 2 hours before he sees tearing, but it seems to be display-dependent. I don't know the technical reasoning as to why the gamecube can only run very close but not quite exactly at the same refresh rate.

You can try the LL version: at the cost of 1-2 frames of lag, it's got a framebuffer, and so should not be affected by tearing.

If I had to guess how it solved the problem, it runs at roughly 0.1 Hz faster than the GBA, so probably it starts by buffering 2 full frames, and then it presents ~0.1 Hz faster than the GBP is drawing frames to the buffers, so the second frame buffer is very slowly emptying, and every ~10 seconds (~600 frames) the second framebuffer is completely empty, so it draws the first framebuffer twice (duplicate frame) while using the extra time to buffer an extra full frame from the GBA. But this is a complete guess: I'm thinking, this is how it could solve the problem, I've no idea how it actually works.

EDIT: The GBI author's take on why chroma appears to be missing on S-Video: "It is there, you just can't decode it, due to the longer horizontal period breaking things." So quite likely, it's entirely dependent on the display, with some displays (such as my PVM and my Epson projector) decoding it fine, and other displays refusing to decode it.

I did notice that if I turn on the Gamecube while the PVM is on a different input, wait for GBI to boot the game, and then switch inputs to S-Video, it takes about half a second for the colour to pop in. But after that, switching inputs does not reproduce the effect (instant colour). It also doesn't happen if I start out on S-Video, wait for GBI to boot, then switch back and forth. Only if I turn on the cube while the PVM is on a different input.

[Unseen]

It should basically be luck of the draw how long it takes before tearing is visible, because it needs to basically drift far enough out of sync to notice it. The author reports that it typically takes 2 hours before he sees tearing, but it seems to be display-dependent.

It probably depends on the tolerances of the crystals in your Gamecube and Gameboy Player - and on their temperatures, because the frequency of a crystal changes slightly with temperature.

I don't know the technical reasoning as to why the gamecube can only run very close but not quite exactly at the same refresh rate.

The Gamecube uses a master clock frequency of 54.000 MHz from which everything else is derived, the GBA uses 4.194304 MHz (2^22 Hz). I don't know enough details about the "internal" side of the Cube's video chip, but I believe it can use only two different pixel frequencies (13.5MHz for 15kHz modes and 27MHz for 31kHz modes) and it is unlikely that you can adjust the image parameters (pixels per line, lines per field) in fractions of a pixel. A standard 15kHz picture has roughly 225000 pixels per frame(*) in total including blanking, so if you want a constant number of pixels per frame (you do, otherwise your display compatibility suffers) the adjustments you can make aren't fine enough to exactly match the GBA's frequency.

(*) or per field, but I'll assume 240p instead of 480i

[kamiboy]

Well then, I am glad I waited on burning an older version of ULL since it seems that it would have changed nothing. I guess I'll just burn a copy of the latest LL for use with the displays that cannot handle the odd ULL s-video timing.

Maybe one frame lag won't be such an issue.

[bobrocks95]

Okay, so the solution is basically have a PVM or another display where it happens to work?

Maybe one frame lag won't be such an issue.

On a CRT it sure won't be.

[Guspaz]

Unfortunately, that would seem to be the case. It's basically, of all displays, some subset of them support the weird ULL framerate (at all), and of those, some subset of them can decode the colour signal at that weird framerate. Maybe we could try to make a list of which devices support it and which don't. It's also possible that an s-video to component converter might solve the problem, if it was able to decode things, but that sounds expensive/convoluted.

Otherwise I might think that the component cables might resolve that issue (with the understanding that the "plug-and-play" option may be more affordable than the official cables), but I think ULL defaults to 480i on the component cables, which is sort of the worst of both worlds: you get flicker on a 240p-capable display like a PVM, and you need to do something special to force it to 480p (via Swiss or launch parameters, which don't seem to be possible via the bootable DVD approach).

IIRC the author said the cube is forced into 480i mode as soon as it detects EDTV support (the component cable flag is set), so I think that means 240p over component is impossible?

[bobrocks95]

Plenty of people are using it in 240p with component cables. You may or may not have to add a setting in a configuration file for it, but it's certainly possible.

[Guspaz]

I was going based on this statement from the author: "480i suggests you're using a component cable. 240p isn't available when signalling EDTV capability."

Maybe that has changed since that was written?

Is there any way to set the configuration parameters for ISO use? As awesome as GBI is, documentation is pretty sparse.

My interpretation of what there is is that a file named foo.dcp will contain the config parameters for a file named foo.dol... Except the ISO mode uses gbi-ull.gci, not gbi-ull.dol. So if you specified bootldr.dcp, that would be the config parameters for the bootloader, rather than for GBI? Or will gbi-ull.dcp still work with gbi-ull.gci? Or is the *.dcp file strictly something read by a launcher like Swiss?

It would appear that GBI is not opensource, so it's not possible to modify things directly and recompile.

[bobrocks95]

I would have to say it's beyond me... I thought the LL and ULL versions worked at a fixed 240p resolution (or rather a 160p image in a 240p window) and that others weren't even options...

If you comb the GC-Forever thread I'm sure you'd find an answer, but experimenting to figure out the solution isn't very viable when you're using discs and end up with a coaster each time.

I don't have a component cable or I'd experiment with my SD Media Launcher until I was able to answer everyone's questions. The LL and ULL versions are certainly 240p over S-Video, but I can't say what happens with component- again, I just thought it was 240p...

[Guspaz]

I don't either, so it's a moot point right now: I've got working ULL 240p over S-Video, which seems to be the best option without spending the big bucks on a cable.

I'm hoping Unseen/BadAssConsole's plug-and-play solution enables an affordable component video (or at least RGB) cable/solution, if that happens and I get one of those, maybe I'll experiment a bit more.

[Gered]

I have the GC component cable and can confirm the ULL version (2016-01-03) is capable of outputting 240p over component (This is how I play it on my PVM). I boot gbi-ull.dol via Datel's SD Media Launcher. I just choose the dol file from it's menu, I don't go into Swiss first... I don't even have Swiss on my SD card. No config file of any sort on my SD card either. And yes, I am 100% sure it's running in 240p. There really is no mistaking it for 480i as I'm sure you can all agree.

EDIT: re-read the author's info from Guspaz's quote above. It works for me because I'm using a PVM (non EDTV).

[bobrocks95]

In the analog days though as far as I know you couldn't really poll the display for what resolutions it supports... I know a pin on the digital out is there to detect the component cable, which can be looked at in software, so I would assume that's what he's talking about...

Again, of course, can't confirm without a component cable. I really wish Badaddconsoles had designed a solution that would support both analog and HDMI... I want HDMI on my EDTV and component to my CRT for the Gameboy Player.

[Guspaz]

But he did... He talks about it in his teaser video:

https://www.youtube.com/watch?v=lj-yohDS6hY

He says there is both a digital and analog version, both have the same footprint of 35mm x 35mm. The plug and play version would seem to be a way to attach a digital connector and cable to the gcvideo and plug it directly into the port (hopefully with an overwrap around the board), so I presume it would work with both versions if they're producing two boards with a near-identical footprint for digital vs analog.

[BazookaBen]

Or you could always use an HD Fury. I've heard some models are compatible with 15hz signals. I haven't tested that myself yet.

[bobrocks95]

But he did... He talks about it in his teaser video:

https://www.youtube.com/watch?v=lj-yohDS6hY

He says there is both a digital and analog version, both have the same footprint of 35mm x 35mm. The plug and play version would seem to be a way to attach a digital connector and cable to the gcvideo and plug it directly into the port (hopefully with an overwrap around the board), so I presume it would work with both versions if they're producing two boards with a near-identical footprint for digital vs analog.

I meant a single board that outputs both; as it is now you will buy and install either an analog or a digital version. Same goes for the external version (presumably).

Or you could always use an HD Fury. I've heard some models are compatible with 15hz signals. I haven't tested that myself yet.

The cheapest HDMI to Component converter they have starts at $160... Might as well just buy a component cable, that's ridiculous. If that sounds like too much of an exaggeration, another one of his external cables will undoubtedly be much cheaper as well.

[Guspaz]

I've no idea how much the BadAssConsoles plug and play version will cost, but because it doesn't involve modding the GameCube, you could just buy both the HDMI and Component/RGB versions, and just switch the plug as needed.

[tacoguy64]

If that plug and play mod cost almost the same as component cables then may we are better off just buy the component cables for the system? I guess this mod is awesome for more modern tvs but for people on crts is this really worth it? The GC is known to have ok component output so maybe this thing will be better?

[Guspaz]

I expect that the BadAssConsoles stuff will be, at the very least, cheaper than the existing component cables. But I don't expect them to be cheap.

If I had to take a wild and random and uneducated stab in the dark, the component cables are $225-250 USD and my probably totally incorrect guess is that the BadAssConsoles solution will end up being $100-150 USD.

[bobrocks95]

Again why I said earlier I wish he'd make a version that included both HDMI and Component output.

[tacoguy64]

Yeah but i don't think adding component would be cheap. Probably make this thing cost more than the official cables. If he did make that then it would totally sell like hotcakes.

@guspaz, i can actually see a plug and play version going for cheaper than the installed versions but yeah i dont expect this to be below $150.

[bobrocks95]

The expensive parts are the FPGA and the digital port connector. There may be a software conflict between GCVideoDVI and regular GCVideo, but if that's worked out adding another standard connector at the opposite end isn't going to up the cost that much...

[Guspaz]

Oh, I expect the plug and play version to cost a decent amount more than the installed version. The plug-and-play version has everything the installed version does, plus the fabricated connector, some cabling, some sort of overwrap, etc.

The cost difference between DVI/HDMI and component video should be minimal: most of the expensive parts are the same.

[Unseen]

The expensive parts are the FPGA and the digital port connector.

A suitable DAC chip is about 1/3 to 1/2 the cost of the FPGA though.

There may be a software conflict between GCVideoDVI and regular GCVideo

There isn't, you'd just have to define ~28 additional output pins on the FPGA to carry the 24 bits of parallel RGB video data and a few control signals for the external DAC.

alternatively: Use just 4 pins and do Sigma-Delta-Modulation in the FPGA, but that requires external filtering of the analog video signals, otherwise it looks like this:

Even with filtering (assuming that a low-cost, low-board-space filter solution can be found), image quality will probably be reduced compared to a dedicated video DAC chip.