shmups.system11.org

I was just looking at the GCDual jumper instructions here:-
http://www.dansprojects.com/GCDual_Jumpers.html
and noticed this:-

I'm guessing this means the GCDual has TTL level CSYNC as standard, not 75ohm?
Rather than having to remove a surface mount resistor from the mainboard would it not be possible to have a jumper to select between TTL or 75ohm CSYNC output?

Also, looking at the jumper pads I just wondered if you ever considered a jumper layout like this:-

It just seems more straight forward to have each corner correspond to one of the four MULTI OUT pins.

Let him get a board out to us before you start suggesting revisions for simplicity.
We've waited long enough :p

I don’t plan on selling the GCMax, maybe somebody else will start making them. BAC will be selling something at some point

Those are some good ideas, however changing the qsb would only add sync to chroma. I have no idea why anybody would use sync on chroma. So I doubt I’ll change it; just so I don’t have to update docs or rewire the board. But I like the idea.

I’ve already had some other people mention a sync jumper, and it’s been added to my next revison. The DAC I’m using is obsolete and mouser just dried up. The new board will have an analog devices DAC and a sync jumper.

I’ve started working my way down the preorder list. So it’s happening.

hey citrus3000psi, thanks for keeping us updated on the project. so as I understand it the multi-out will have RGB after the mod. I'm assuming that it won't be compatible with current SNES RGB sync on luma cables (right?) also, assuming one has the correct custom cable will the analog output still be compatible with the various modes on the OSSC? (for instance will 240p line5x still work with GBA interface?)

It was stated earlier but if you add a resistor to the board you can run component free scart lines.

ah, I was reading a little bit about that in his FAQ I just wanted to make sure I fully understood. so you're saying YUV/component over scart will be the default/best analog option? (as long as one is using the properly constructed cable with the added resistor, I'll probably have to have someone make one as I can't solder worth beans)

I'll be mostly using the 480p HDMI output with my upscaler (or a newer television when I buy one), but for some 240p material it would be nice to use the ossc line multiplication function. also, have you tested any of the other optional video modes from Swiss with the mod? like 960i or 1080i? I would imagine some of those would look great on an HD CRT monitor.

I apologise for any confusion I may have caused using the word "component".
I was referring to the components inside a csync or composite sync multiout scart lead. Capacitors resistors ect

Quality picture depends on the receiving device.
I have sets here that are great for component but have poor RGB and vice versa.

Such a versatile bit of kit that I just cannot wait to get my hands on.

Ill primarily be using this for the Game boy player untill Benvenn has completed his GBA VGA RGB out modkit at which point I'll probably consolize a GBA

oh that's okay, thanks for clearing that up. (it is kind of confusing when we have a video standard named "component" lol, that's why these days I usually say YUV/Component to distinguish. or sometimes YPbPr/ Component) I saw video of that GBA VGA RGB prototype it looks really interesting but I'm not sure if it has any advantages over the GameCube+GBI+OSSC combo, as the quality is great and it's pretty much input latency free. (but I do like the idea of VGA output for easy hook up to a PC CRT)

I just got the EON adapter and I must say, it sure is nice. It's very nicely done and looks like an actual product that a larger company would produce. This thing plugs in nice and snug and is very nicely 3D printed. Picture quality is of course amazing and sharper, in my opinion, than my Gamecube component cables. It's so nice just plugging this in and using a single HDMi cable, versus the component cable clutter. 10/10 on this thing from me!

Nice. Can't wait for a review on this.

I actually did a quick video on my channel, nothing too special because there are a few other youtube videos up where people went into a little more depth, but mine covers the basics.

https://youtu.be/UAB_yMzv044

Thanks for the kind words! Just letting you know though the plug is not 3D printed. It is custom tooled and injection molded.

Again thanks for the props!

Well, I'll be damned. It looks fantastic either way!

I just installed my GCDual last week and wanted to make a quick note for people planning to use it for extrems' GameBoy Interface.

When I first tried it out I was missing a giant column of pixels spanning roughly 1/3 of the middle of the screen. Swiss worked fine and super mario sunshine ran fine. I was using a version of GBI from ~April of 2017. Updating to the latest version of GBI fixed the issue.

I searched really quick to see if anyone else had come across this issue but my searches turned up nothing. So hopefully this isn't redundant information.

Got in the EON GCHD and did some REAL testing of the PQ down to the pixel level. I have to say I'm disappointed it doesn't actually improve on the picture you get from component cables. The clarity at the pixel level seems to be inherent to something done inside the console before it even reaches the digital output port, otherwise devices like the EON GCHD should be able to get digitally perfect pixels. I'll let this comparison image taken from the GBI driver for GBA on the GBP explain itself:



Now it may look like component cables are superior in quality to the GCHD, but that's just the effect of using an OSSC to force per-pixel sampling. Even though such is the case, that still means official component cables and the ability to set the OSSC to optimal-time the image is quite simply still the best solution for PQ short of an emulator.

Remember the Gamecube is internally rendering in 4:2:2 YCbCr

Is it possible that's why the pixels aren't digitally perfect? Whatever the case may be, the OSSC's ability to force per-pixel sampling is actually making it look better than HDMI solutions at the moment.

This happen because chroma is downsampled as "x[-1] / 4 + x[0] / 2 + x[1] / 4", as per standards.
This simplifies upsampling to an averaging every second pixel.

I have plans to fix this for GCVideoX and similar things to the OSSC.

Interesting that the emulator doesn't have the "drop shadows," if that is what those are supposed to be.

They are not supposed to be there. It's the net result of the poor picture quality coming out of the Gamecube itself, and the per-pixel sampling is forcing an RGB value that is off because of the 'smearing' taking place in the video quality.

Here's a 480p 2x scale test using Wind Waker. Here the image quality is actually slightly more 'crisp' on the GCHD, so this is where it seems to shine. However, component into the OSSC is very close in quality. Difference is very slight:

Try putting the HDMI through a VGA adapter + OSSC and see how it compares.

I'd imagine the RGB out on the GCDual/GCVideo should be very close to component.

What sample aspect did you set for GBI, 1:1 or 11:10?

I'm using the gbisr-OSSC driver, which I believe uses 1:1.

Ah ok. I didn’t update to the new version yet so not familiar with how it works now. I’ll see if I get some time to try it tonight.

Something in the output has changed, I could not get pixel perfect image with the values used for previous GBI-LL (263p and 59.82Hz, 429 (1:1)) or GBI-ULL (261p and 59.72Hz, 394). 390 gave decent image, similar to GBI-LL with 11:10 sample ratio, but slightly worse if memory serves.

I didn't have time to edit the .cli files, there were some values in there that I don't understand what they do. And notably, the .dcp for the regular gbisr.dol is now missing the sample ratio option, not sure why that was removed (decrease complexity perhaps?). I can try editing those in at some point and see what happens.
Unfortunately, I don't have much time this week but hope I can look into this a bit more soon.

Extrems gave me these settings to use with the speedrun interface and make it look like the standard GameBoy Player.
If I ran the stock settings its way too bright and there is really bad shearing.

Anyway these settings worked a treat for me, hopefully it helps you figure out your settings.
I put them in a static CLI. I'm thinking maybe my dynamic settings are not taking effect because the brightness settings are the same for both.

These settings will replicate the Game Boy Player Start-up Disc:

The new "gbisr-ossc" runs at 261p and doesn't duplicate frames. The correct H. samplerate for it is 433 (running in 320x240 optimal mode).

That’s what I get when messing with video settings when too tired. I had gone over that number as well, but just failed to notice lol. Thanks FBX!

Got some insight tonight, hadn’t realised before that video setting = custom is what produces the 261p 59.72Hz video, or else I would have used that much sooner back with gbi-ll as well!

I added in the sample ratio option in the gbisr.dcp, and now I get the expected behaviour again from that, so all good. Although I’ll be using the gbisr-ossc from now on for simplicity, will keep the regular version on there if I ever feel like fiddling with some other settings later on.

Now the question remains, what does the v. filter and h. filter actually do? I didn’t notice any particular difference when removing those from the .cli file...

Check out the latest OSSC component input results from a new GBI build Extrems sent me:



Looks frikken schweet!! Current HDMI solutions for the Gamecube are incapable of this level of clarity on GBI playback of GBA games (or so I'm told anyway). Indeed when I tried the new driver on EON GCHD, it ended up looking completely smeared. Very interesting how it ends up improving the PQ on the OSSC, yet makes it worse on HDMI output.