shmups.system11.org

Any examples?
If you've discovered some special sauce to make the Xbox play ball, then I'm definitely interested. Through my testing though, I'm 99% sure I'm getting the accurate output.

In my experience, the Wii's 480i output isn't actually horrible. It's the 480p output where more issues start to come into play, though it's obviously a lot easier to see those objectively with the test suite.

Is 480i output bad all around, or does quality differ depending on board revision? I recall there being some discussion about earlier boards with Conexant encoders having good YPbPr output but bad RGB output, and the 1.6 boards with the Xcalibur encoders having good RGB output but bad YPbPr output.

So which board revisions are people testing with?

I always inclined to jump in onto the comments, but I have to admit, I have not seen an Xbox running on an interlaced CRT in almost a decade. I don't remember it to be bad though.


me neither, it was mentioned here only recently:
viewtopic.php?p=1366729#p1366729


you're right. The big UNLEASH letters look crip. I was looking at the menu text before (e.g. LAUNCH DISC) and here it looks like the sampling is off (the H looks clear on the right, but way different on the left).

revision 1.3, HD Pack, Good Component Cable, 480i/p YPbPr, looks good.

1.1, but have also had a friend with a 1.6 try. Both with good component cables, good 480p, bad 480i.
I've also tried my 1.1 with RGB SCART and had exactly the same issue, so it's not specific to the YPbPr output. Plus, if it was, 480p would be just as bad.




Awesome, I'll give that a look. Ty!

You said it's the "same" as GC, but does that mean 660 active, or is it the full 720?

Apologies, I wasn't super clear.
The original Xbox actually outputs to all 720 pixels, so you just need to apply the 10:11 ratio without any cropping.
That results in 655x480

Genius!

I've wanted to do something similar so I can cleanly integrate the OSSC near the head of my HDMI switching chain instead of forcing it to the tail. But I have zero circuit design ability.

If you have any helpful links I'd sure appreciate them. If not, I'm sure having the name "load switch" will get me further in google than I've gotten before.

Can't the OSSC only fit in one spot in the chain? I have mine after the SCART switches, outputting HDMI to the series of splitters/switches/amazingness from your thread. Not sure why you'd even need it elsewhere.

But I do agree with the load switch; it's worth a try I think assuming It can activate from any inlet. I hope he posts a link!

I'm referring to my HDMI chain.

Since I want every console to be fully autoswitched. I'm forced to leave the OSSC on.

When the OSSC is on, any automatic HDMI switch I've tried treats it as an active source. So I have to put it in the lowest priority port.

However, my head switch has to be fully OSSC and 4K60RGB compatible. So far this limits me to the Vorke HD41. Which only has 4 ports. And since I have 9 HDMI devices to hook up. I have to daisy chain at least 1 additional switch.

And every HDMI switch I've tried has the same port priority problem as the OSSC. I can't chain to anything but the lowest priority port. Which means I have to chain in serial and not parallel. And also means the OSSC is the last device on the last switch. Which means they all have to be 100% OSSC compatible. And any resolution switches of the OSSC have to sync on 3 switches instead of 1. Causing roughly 2 additional seconds of black screen per mode switch.

If the OSSC were invisible to the HDMI switch whenever an analog input wasn't present. Then I could move the OSSC to the head switch. And use a much less compatible switch with more ports as my chained switch. And reduce black screen on mode change.

It would be a HUGE win for auto switching.

FYI, I think I mentioned it in your other thread but the Smartooo switcher is a 5x1 and it works perfectly with the OSSC. That would be just enough to get all 9 devices with only 2 switchers. Just FYI Doesn't solve the autoswitching issue, though. I just leave my OSSC off when not in use to get around it.

My goal was a fully-auto-switched setup as well, but I made one compromise in that I have power for all of my retro stuff (Currently the OSSC, component switcher, RGB decoder, and any console that goes through the OSSC) running to a CyberPower CPS1215RMS PDU. When I want to play one of these consoles, I flip the power switch on the PDU, which brings up the video processors, and then I just power on whichever console I want to use. When I'm done, power off the console, then flip the switch on the PDU.

Having to toggle power certainly isn't fully automatic, but a 2-step process (push this button, then that button) is still far simpler to operate than anything involving a matrix switcher; and I'm pretty sure I don't play my old consoles as much as most people in the retro community (I mainly use them for parties), so being able to just kill the power for my entire retro setup means I save a tiny bit on my power bill.

I also think I have a far simpler setup than some people on here; I haven't really needed to expand past the inputs I have on my AVR plus the Vorke HD41Pro. This lets me get away with hooking up my OSSC to port 4 on the Vorke, with my N64, Switch, and Steam Link on the other three ports without conflict from the OSSC; but, if I needed to, I could put the OSSC chain anywhere on my HDMI switchers, since it would normally be powered off.

I also made the power concession. I run my stuff through an APC LE1200 as recommended by db electronics that's always on to provide protection against power damage. That splits off to a charging shelf that's always on. It also branches off to a Furman PL-8C power conditioner for the entire rest of my gaming rack. And I turn the PL-8C off when the rack is not in use. Retro, new, and everything in between is completely disconnected from AC most of the time.

When I say auto-switching. I'm mostly referring to a setup that can be remembered by my wife and young kids. Which right now is:
1. Speak the words "Alexa, turn on a game"
2. Power on the PL-8C master switch.
3. Turn on the thing you want to play.

As soon as I throw a "if this, then this. If that, then that" curveball in there, it all falls apart.

I was wondering auto switches you use for your OSSC sources?

If you have component and RGB on different AC ON OSSC. do you still switch using the OSSC remote? Last time I tried auto switch mode on OSSC it would work for one day or certain consoles and I would have find my remote.

There’s where my auto switching into OSSC got stuck. I haven’t tried feeding all signals through av3 but o don’t want to because of a different filter on av3.

Working from the head (the thing the connects to displays/OSSC) of my chain to the many tails...

1. A gscartsw 3.4 with lpf switch mod (lpf disabled). This one mostly handles native RGBS 15khz consoles that I play the most.
2. The newest gscartsw 5.2 connected to port 8 of #1 so HD signals pass through. With sync regen enabled. This one fixes sync issues for non-csync consoles as well as the Garo.
3. A gscartsw_lite connected to #1. With sync regen disabled. This extends the port count of native RGBS 15khz
4. An old model garo with Guspaz's recommended mods. Connected to #2. This brings component signals into the chain.
5. A gcompsw connected to #4 to bring component signals into the chain
6. A kenzei connected to #2 to bring RGBHV into the chain.
7. A retrotink 2x with hdmi->vga adaptor plugged into #6. This is not auto switched and it makes me sad
8. A no-name svideo/composite to RGsB transcoder from eBay connected to #2. It looks terrible but it plays well with auto switching.
9. A gcompsw connected to #7 or #8 depending on whether I want fully auto switched with terrible quality or non-auto switched with acceptable quality. With adapters to convert svideo in/out to YPb rca as necessary. This brings composite and svideo into the chain.
10. An rf to composite transcoder connected to #9

So everything terminates as RGBS at #1


And if there were a descent composite/svideo to rgb/ypbpr transcoder I'd be happier

I should be converting to scart instead of RGBHV.

That still doesn’t solve my sync issues with my Taito F3 requiring a av3 OSSC filter though.

I like solving most of my problems though so I gonna work towards it.

Thanks for clarifying.

You must be one of the lucky ones that has a good sync signal on your pvm with F3.

I don't use my F3 much. But I definitely had issues the last time i tried. I think i got thr best results with HAS vga adapter board and a kenzei. Can't clearly remember though.

This is essentially what I have, +/- a few differences, but it's fairly similar. I finally found a way to power the OSSC through a USB port on the TV, though it activates whenever the TV turns on, not only when I want to play a game. Realistically, I'm not too concerned with powering the OSSC on demand any more, you still have to turn on the console, right? And find the game to play, controllers, etc.

Does anyone have a build of the new merge with the samplerate fine tune option?

Anybody know if serial (rs232) control was ever discussed for the OSSC?

It would be great in a home automation environment to be able to control the OSSC without needing IR (and seeing the LCD screen)

I asked for it about a year ago on the OSSC Feature Requests subforum on VGP. According to marqs, UART is available via the JTAG port, but, at the time, the soft CPU upgrade had not yet occurred, and there was no available code space for that functionality.

Since then, the soft CPU upgrade has been completed, and more new functionality has started to trickle in. Hopefully serial remote control is still on marqs's radar.

Thanks for the information ... I've posted a reply in that thread you linked to as well. Hopefully marqs will consider it.

Hey guys. Sorry for the absence. Had a business trip to go on so I couldn't get to the forums. Having issues getting files out of Eagle, but do have screenshots in case someone is able to reproduce the schematic and layout in Eagle.

Fair warning: I am NOT an electronics engineer so this layout on the PCB might be horrific. LOL. A more competent circuit board designer will likely be able to create a much better designed switch. I just know that this works.

It's a dual output load switch. When I first designed it, I had to have two HDMI devices powered on for my TV to recognize the signal (OSSC and HDMI passthrough on a cheap SCART-To-HDMI Adapter). The problem is that BOTH had that habit of making my autoswitcher think it should switch to that input. Now, I don't need that passthrough due to a new TV setup which is fully compatible with the OSSC. So I only have one plugged in at a time. This could be simplified a bit in order to reduce it down to a single input, single enable, and single output load switch.

Schematic:


Top Image of Traces


Bottom Image of Traces

Firmware v0.83 is now officially released:

* Scanline updates and fixes
** Overlay pattern customization feature
** Fixed non-alternating mode with line4x interlace sources
** Added half-interval option for pre-linedoubled sources

* Adv. timing option updates
** Sampling phase made mode-specific
** Horizontal samplerate fine-tune option for optimized modes

* Video and audio TX parameters tweaked
** Set optimal video clock level
** Disable audio copyright flag
** YCbCr444 TX mode added

* Auto YPbPr CSC option added
* Fixed profile load not reading data from last mode presets
* Enabled 35MHz video LPF for 720p & 1080i in auto mode

Appreciate the hard work, man.

Do you have this issue with the release 0.83 firmware?

The updated wiki documentation states:



What is the % operator in this context?

Edit: it must be “modulo”, right?

I just flashed the new fw and I still see the small artifacts. I recorded another small video switching from 5x to 4x and back to 5x scaling mode on my Japanese Megadrive with the final fw. I can also see it in an NTSC SNES (with the dejitter board) but it's less prevalent.

It seems your OSSC is not quite reaching the required clock speed at LineX5. Try this firmware: https://drive.google.com/file/d/18I72UHxe8TNrGLOM5cEtu_vtLDhL1myZ/view?usp=sharing

That sounds like a timing (setup) violation which could occur with a combination of maximum pixel clock and slow individual chip (FPGA). Even a small touch in RTL can significantly change the Quartus fitter results, so the release builds are basically ran with ~20 different fitter seeds to get an image which should meet timing requirements for all chip & environment combinations. I just recompiled the image with another fitter seed (link), maybe you have better luck with (or with the one paulb_nl just made ).