Any examples?Lawfer wrote:On my setup Xbox 480i component is pretty good, better than Wii at least.
me neither, it was mentioned here only recently:Ooh, what anti-blur patch? I'm not familiar with that.
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).Interestingly, the custom dashboard that I've been using to test (since it has pure black and pure white) is really convenient, since the UNLEASH text and the big X don't have any of the Xbox's weird scaling going on.
revision 1.3, HD Pack, Good Component Cable, 480i/p YPbPr, looks good.nmalinoski wrote: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?
1.1, but have also had a friend with a 1.6 try. Both with good component cables, good 480p, bad 480i.nmalinoski wrote: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?
Awesome, I'll give that a look. Ty!Fudoh wrote:me neither, it was mentioned here only recently:Ooh, what anti-blur patch? I'm not familiar with that.
viewtopic.php?p=1366729#p1366729
You said it's the "same" as GC, but does that mean 660 active, or is it the full 720?Jademalo wrote:Original Xbox is the same, 858/720 with 10:11 PAR.SavagePencil wrote:Excellent, thank you for the GC values. Does anyone know the correct ones for the original Xbox?
Do be aware though, 480i from the original xbox is absolutely goddamn awful
Apologies, I wasn't super clear.SavagePencil wrote:You said it's the "same" as GC, but does that mean 660 active, or is it the full 720?
Genius!Jdurg wrote:I have my OSSC in my setup and always leave the power switch "On". The only issue with doing that is the OSSC constantly is outputting a signal and the auto-switches I have see this constant "On" state and will always move over to the OSSC input even when no device is connected.
Knowing that I wouldn't be able to include my OSSC in my setup the way I want it, I did come up with a solution.
It's been a while so I forget what the parts were, but I built a load switch that will activate when it receives a +5V signal. This +5V signal comes from my SNES on the SCART cable (I only have my SNES going through my OSSC since it's my only console with zero HDMI mods available for it). When I turn on my SNES, the +5V signal is sent from the OSSC pin (I soldered a wire there) into my load switch. That activates the load switch which then allows the DC power to pass through and power on the OSSC.
Everything works like a champ now and I don't have to flip that switch or anything. Just turn on my SNES and the OSSC comes on and works its magic.
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.DirkSwizzler wrote:Genius!Jdurg wrote:I have my OSSC in my setup and always leave the power switch "On". The only issue with doing that is the OSSC constantly is outputting a signal and the auto-switches I have see this constant "On" state and will always move over to the OSSC input even when no device is connected.
Knowing that I wouldn't be able to include my OSSC in my setup the way I want it, I did come up with a solution.
It's been a while so I forget what the parts were, but I built a load switch that will activate when it receives a +5V signal. This +5V signal comes from my SNES on the SCART cable (I only have my SNES going through my OSSC since it's my only console with zero HDMI mods available for it). When I turn on my SNES, the +5V signal is sent from the OSSC pin (I soldered a wire there) into my load switch. That activates the load switch which then allows the DC power to pass through and power on the OSSC.
Everything works like a champ now and I don't have to flip that switch or anything. Just turn on my SNES and the OSSC comes on and works its magic.
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.
I'm referring to my HDMI chain.ldeveraux wrote: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.DirkSwizzler wrote:Genius!Jdurg wrote:I have my OSSC in my setup and always leave the power switch "On". The only issue with doing that is the OSSC constantly is outputting a signal and the auto-switches I have see this constant "On" state and will always move over to the OSSC input even when no device is connected.
Knowing that I wouldn't be able to include my OSSC in my setup the way I want it, I did come up with a solution.
It's been a while so I forget what the parts were, but I built a load switch that will activate when it receives a +5V signal. This +5V signal comes from my SNES on the SCART cable (I only have my SNES going through my OSSC since it's my only console with zero HDMI mods available for it). When I turn on my SNES, the +5V signal is sent from the OSSC pin (I soldered a wire there) into my load switch. That activates the load switch which then allows the DC power to pass through and power on the OSSC.
Everything works like a champ now and I don't have to flip that switch or anything. Just turn on my SNES and the OSSC comes on and works its magic.
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.
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!
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 FYIDirkSwizzler wrote: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.
Doesn't solve the autoswitching issue, though. I just leave my OSSC off when not in use to get around it. 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.nmalinoski wrote: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.
I was wondering auto switches you use for your OSSC sources?DirkSwizzler wrote: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.nmalinoski wrote: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.
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.
Working from the head (the thing the connects to displays/OSSC) of my chain to the many tails...Hoagtech wrote: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.
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.Hoagtech wrote: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.
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.DirkSwizzler wrote:Working from the head (the thing the connects to displays/OSSC) of my chain to the many tails...Hoagtech wrote: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.
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 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.sofakng wrote: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)
Do you have this issue with the release 0.83 firmware?hugo19941994 wrote:When outputting with 5x scaling I can see some small artifacts (https://photos.app.goo.gl/8NxKsraUwy1xzhsx7).
If I use 4x scaling mode or firmware 0.82 they dissapear. Has anyone noticed this as well?
The updated wiki documentation states:marqs wrote: ** Horizontal samplerate fine-tune option for optimized modes
What is the % operator in this context?H. s.rate adj
Fine-tune fractional H.samplerate adjustment for optimized modes. Effective samplerate is (H.samplerate + (H. s.rate adj % H. mult factor) / H. mult factor)
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.paulb_nl wrote:Do you have this issue with the release 0.83 firmware?
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 madehugo19941994 wrote: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.
).
