OSSC Pro

The place for all discussion on gaming hardware
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: OSSC Pro

Post by marqs »

fernan1234 wrote:Maybe he means 1080i output? That certainly would be useful for HD CRTs as well as multisync pro monitors, maybe even also some old HD LCDs and plasmas.
It should be able to output any mode up to ~180MHz pixel clock.
digitron wrote:Late to the party here "a small add-on PCB compatible with a couple Terasic FPGA dev boards (DE10-Nano, DE2-115) is in works and available soon." Has this been made available yet? Thanks
PCB files for v1.2 are available and code has been integrated to DE10-Nano, but things are still quite much in progress. There will be at least one updated PCB revision that aims to improve signal integrity at 1080p and higher (although DE10-Nano GPIO might be the bottleneck since these issues are not present on the actual Pro prototype). Code hasn't also been ported to DE2-115 yet while documentation is non-existent so you might still want to wait before jumping into building/testing the board.
6t8k wrote:Beyond that, it'd be interesting to know whether this could even include the HDMI input. The ADV7611 HDMI RX has audio extraction support, but I think we don't know yet whether A) there will be a dedicated DAC (probably not) or B) the 3.5mm audio output jack is connected to the Cyclone V in such a way that a suitable DAC could be implemented in the FPGA. It's safe to say at this point that it could be done by an extension module connected via GPIO -- but depending on the way the built-in 3.5mm audio output jack is connected, that extension module would have to bring its own audio jack, which would be a little wasteful. Maybe marqs can chime in on that a bit.
AV1 audio operates just like on the original model aside for digital control of the swtich. All audio - digitized from analog inputs by PCM1863, direct I2S/SPDIF stream from ADV7611 or SPDIF via optical - goes to FPGA which does muxing/processing and outputs the formatted stream to HDMI TX. In order to convert audio from any source to analog, one would need to design a extension GPIO module including DAC + RCA connectors.
User avatar
Speedy
Posts: 95
Joined: Sun Jan 20, 2019 4:31 pm
Location: Seattle

Re: OSSC Pro

Post by Speedy »

fernan1234 wrote:Maybe he means 1080i output? That certainly would be useful for HD CRTs as well as multisync pro monitors, maybe even also some old HD LCDs and plasmas.
Yes, I did mean output to 1080i and for the exact reason you state. There are so many HD CRTs out there that people can pick up for free these days. It'll be amazing if the OSSC Pro can output (scale everything to) 1080i60 with minimal lag.
User avatar
digitron
Posts: 172
Joined: Wed Apr 10, 2019 1:16 am
Location: California, USA

Re: OSSC Pro

Post by digitron »

marqs wrote:
fernan1234 wrote:Maybe he means 1080i output? That certainly would be useful for HD CRTs as well as multisync pro monitors, maybe even also some old HD LCDs and plasmas.
It should be able to output any mode up to ~180MHz pixel clock.
digitron wrote:Late to the party here "a small add-on PCB compatible with a couple Terasic FPGA dev boards (DE10-Nano, DE2-115) is in works and available soon." Has this been made available yet? Thanks
PCB files for v1.2 are available and code has been integrated to DE10-Nano, but things are still quite much in progress. There will be at least one updated PCB revision that aims to improve signal integrity at 1080p and higher (although DE10-Nano GPIO might be the bottleneck since these issues are not present on the actual Pro prototype). Code hasn't also been ported to DE2-115 yet while documentation is non-existent so you might still want to wait before jumping into building/testing the board.
6t8k wrote:Beyond that, it'd be interesting to know whether this could even include the HDMI input. The ADV7611 HDMI RX has audio extraction support, but I think we don't know yet whether A) there will be a dedicated DAC (probably not) or B) the 3.5mm audio output jack is connected to the Cyclone V in such a way that a suitable DAC could be implemented in the FPGA. It's safe to say at this point that it could be done by an extension module connected via GPIO -- but depending on the way the built-in 3.5mm audio output jack is connected, that extension module would have to bring its own audio jack, which would be a little wasteful. Maybe marqs can chime in on that a bit.
AV1 audio operates just like on the original model aside for digital control of the swtich. All audio - digitized from analog inputs by PCM1863, direct I2S/SPDIF stream from ADV7611 or SPDIF via optical - goes to FPGA which does muxing/processing and outputs the formatted stream to HDMI TX. In order to convert audio from any source to analog, one would need to design a extension GPIO module including DAC + RCA connectors.
Thanks for the update Marqs! :)

Eager to build & test once you feel it's ready. Cheers!
User avatar
6t8k
Posts: 496
Joined: Wed Aug 14, 2019 2:44 pm

Re: OSSC Pro

Post by 6t8k »

Thanks for clarifying!
User avatar
Lawfer
Posts: 2283
Joined: Fri Dec 01, 2006 3:30 am

Re: OSSC Pro

Post by Lawfer »

marqs wrote:
fernan1234 wrote:Maybe he means 1080i output? That certainly would be useful for HD CRTs as well as multisync pro monitors, maybe even also some old HD LCDs and plasmas.
It should be able to output any mode up to ~180MHz pixel clock.
digitron wrote:Late to the party here "a small add-on PCB compatible with a couple Terasic FPGA dev boards (DE10-Nano, DE2-115) is in works and available soon." Has this been made available yet? Thanks
PCB files for v1.2 are available and code has been integrated to DE10-Nano, but things are still quite much in progress. There will be at least one updated PCB revision that aims to improve signal integrity at 1080p and higher (although DE10-Nano GPIO might be the bottleneck since these issues are not present on the actual Pro prototype). Code hasn't also been ported to DE2-115 yet while documentation is non-existent so you might still want to wait before jumping into building/testing the board.
6t8k wrote:Beyond that, it'd be interesting to know whether this could even include the HDMI input. The ADV7611 HDMI RX has audio extraction support, but I think we don't know yet whether A) there will be a dedicated DAC (probably not) or B) the 3.5mm audio output jack is connected to the Cyclone V in such a way that a suitable DAC could be implemented in the FPGA. It's safe to say at this point that it could be done by an extension module connected via GPIO -- but depending on the way the built-in 3.5mm audio output jack is connected, that extension module would have to bring its own audio jack, which would be a little wasteful. Maybe marqs can chime in on that a bit.
AV1 audio operates just like on the original model aside for digital control of the swtich. All audio - digitized from analog inputs by PCM1863, direct I2S/SPDIF stream from ADV7611 or SPDIF via optical - goes to FPGA which does muxing/processing and outputs the formatted stream to HDMI TX. In order to convert audio from any source to analog, one would need to design a extension GPIO module including DAC + RCA connectors.
Can you input at the same time 1 HDMI for video and 1 analog for audio and get 1 digital output?
nmalinoski
Posts: 1974
Joined: Wed Jul 19, 2017 1:52 pm

Re: OSSC Pro

Post by nmalinoski »

Lawfer wrote:Can you input at the same time 1 HDMI for video and 1 analog for audio and get 1 digital output?
My AVR does this, albeit only if the HDMI stream excludes audio. Would definitely be interesting/nice to configure/customize inputs by selecting a pair of video input and audio input, and I think that would be necessary anyway for assigning the TOSLINK I/O as an input to one of the video inputs.
dandiego
Posts: 11
Joined: Sat May 07, 2016 1:42 pm

Re: OSSC Pro

Post by dandiego »

nmalinoski wrote:
Lawfer wrote:Can you input at the same time 1 HDMI for video and 1 analog for audio and get 1 digital output?
My AVR does this, albeit only if the HDMI stream excludes audio. Would definitely be interesting/nice to configure/customize inputs by selecting a pair of video input and audio input, and I think that would be necessary anyway for assigning the TOSLINK I/O as an input to one of the video inputs.
What AVR do you have?
nmalinoski
Posts: 1974
Joined: Wed Jul 19, 2017 1:52 pm

Re: OSSC Pro

Post by nmalinoski »

dandiego wrote:
nmalinoski wrote:
Lawfer wrote:Can you input at the same time 1 HDMI for video and 1 analog for audio and get 1 digital output?
My AVR does this, albeit only if the HDMI stream excludes audio. Would definitely be interesting/nice to configure/customize inputs by selecting a pair of video input and audio input, and I think that would be necessary anyway for assigning the TOSLINK I/O as an input to one of the video inputs.
What AVR do you have?
It's an Onkyo TX-NR555. It basically has a set of profiles with user-friendly labels on the physical buttons on the front and remote (BD/DVD, CBL/SAT, STRMBOX, GAME, PC, etc.) to which you can configure specific HDMI and/or a component or composite input for video, and then a specific TOSLINK and/or stereo RCA input for audio; so you can, for example, assign HDMI 1, COMPONENT 1, OPTICAL 1, and AUDIO 1 to the BD/DVD profile, which would configure that input to use HDMI 1 and fallback to COMPONENT 1 for video and use HDMI 1 for audio and fallback to OPTICAL 1 then AUDIO 1 for audio.

(I'm pretty sure only one HDMI input can be assigned to a given profile at a time (so you can't have two profiles using the same HDMI input), but you can have the same of any of the other video or audio inputs as fallbacks, so you could, for example, have all of the profiles fall back on COMPONENT 1 and AUDIO 1.)

My biggest problem trying to use TOSLINK-capable consoles with the regular OSSC (TOSLINK from component switch routed around OSSC directly to my AVR) has been that, when TX Mode on the OSSC is set to HDMI, it always adds audio to the HDMI stream, even if nothing is playing over any of its inputs, which means my AVR sees that [logically empty] audio stream and uses that instead of falling back on TOSLINK, which actually has the audio stream I want; so I need to have a separate profile on the OSSC that changes TX Mode to DVI, which kills the embedded audio, and allows my AVR to see and use the audio from its TOSLINK input.

Since the OSSC Pro is a new product from scratch, I think it might be a good opportunity to reexamine the existing profile system and potentially redesign it. If the OSSC Pro inherits profile system from the regular OSSC, then I think that would mean tight pairing between video and audio inputs (for example, the component and adjacent stereo RCA/TRS jack(s) will always be part of AV2), but there'd still be the exception of the TOSLINK input, and I don't think it's been made clear how that would work--if it would just blanketly override whatever analog audio is coming in over any currently-selected input, or if it would be preferred on a per-profile basis, or what.

Personally, assuming everything is planned to be as close to the original OSSC, at least to start with, I think having it preferred on a per-profile basis or paired with a specific input would be fine for me, because I only use digital audio from YPbPr component sources, but I think that would cause headaches for anyone that uses TOSLINK from more than one type of input.

If the profile system is up for redesign, I think I would like to pitch something akin to what my AVR uses--a logical profile that can be configured with whichever pairing of inputs would be needed for a given console, however it's connected in a given person's setup.

For example, if Profile 1 is for a PlayStation connected (whether or not through a switch) to the SCART input, Profile 1 could be configured to use the SCART input for both audio and video, possibly indicate the initial format as RGBS, plus any other tweaks that may be necessary; and, when you select Profile 1, the Pro would switch to SCART for AV, using RGBS and whatever other settings are needed specifically for your PlayStation.

Another example: A profile for a BIOS-modded Xbox could be set up to use the component input for video, using RGsB instead of YPbPr, and TOSLINK for audio (with a fallback on the RCA input).

A third: If you have a Genesis 1 or Neo Geo AVS with only mono on the AV output but stereo from the front panel, and your SCART cable doesn't have one of those TRS extensions to grab stereo from the front of the console, you could set up this console's profile to use video from the SCART input, but then use one of the TRS jacks for audio, connected to the console with a regular male-to-male TRS cable.
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: OSSC Pro

Post by marqs »

The most straightforward solution would perhaps be an option for each physical input (AV1-4) that allows selecting audio source from all possible options with perhaps the most obscure combinations removed (e.g. SCART audio with HDMI video).

Speaking of combinations, below is table for planned (most already implemented) adaptive line multiplication output modes. Together with the pure LM modes (identical to oriiginal OSSC), they should cover a good amount of common output resolutions which are suitable for frame sizes resulting from line multiplication.

R= 240p proc & 288p proc & 480i proc & 576i proc & 480p proc & 576p proc R= 720x480 [Line2x] & 720x576 [Line2x] & 720x240 [240p restore] & 720x288 [288p restore] & 720x240 [line drop] & 720x288 [line drop] R= 1280x720 [Line3x] & 1920x1080i [Line4x] & 1280x1024 [Line4x] & 1920x1080i [Line4x] & 1280x1024 [Line2x] & 1920x1080i [Line2x] R= 1280x1024 [Line4x] & 1920x1080 [Line4x] & 1920x1080i [Line4x] & 1920x1080 [Line4x] & 1920x1080i [Line2x] & 1920x1080 [Line2x] R= 1920x1080i [Line4x] & 1920x1440 [Line5x] & 1920x1080 [Line4x] & & 1920x1080 [Line2x] & R= 1920x1080 [Line4x] & & 1920x1440 [Line6x] & & 1920x1440 [Line3x] & R= 1920x1080 [Line5x] & & & & & R= 1600x1200 [Line5x] & & & & & R= 1920x1200 [Line5x] & & & & & R= 1920x1440 [Line6x] & & & & &
fernan1234
Posts: 2175
Joined: Mon Aug 14, 2017 8:34 pm

Re: OSSC Pro

Post by fernan1234 »

Will it be possible to add 480i and 576i as output modes for 480p and 576p inputs? This would let the OSSC Pro (paired with a DAC) also work for SD/multisync CRTs with many digital or PC sources, and would replace the use of devices like Extron VSCs.

Also, this one will be seen as crazy by many, but how about 720x480i as an output mode for 240p inputs? That's what crappy processors typically do and hence something everyone wants to avoid, but if done correctly it can have interesting experimental uses.
User avatar
Konsolkongen
Posts: 2310
Joined: Fri May 16, 2008 8:28 pm
Location: Denmark

Re: OSSC Pro

Post by Konsolkongen »

marqs > It will be possible to do 480i > 240p > Line2,3,4,5,6 right? :)
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: OSSC Pro

Post by marqs »

fernan1234 wrote:Will it be possible to add 480i and 576i as output modes for 480p and 576p inputs? This would let the OSSC Pro (paired with a DAC) also work for SD/multisync CRTs with many digital or PC sources, and would replace the use of devices like Extron VSCs.

Also, this one will be seen as crazy by many, but how about 720x480i as an output mode for 240p inputs? That's what crappy processors typically do and hence something everyone wants to avoid, but if done correctly it can have interesting experimental uses.
Both can be implemented easily if needed. I didn't think there'd be practial use cases especially for the latter so I'm a bit surprised to hear a request this soon.
Konsolkongen wrote:marqs > It will be possible to do 480i > 240p > Line2,3,4,5,6 right? :)
Yes, there's a separate "LM deinterlace mode" option with "Bob" and "Noninterlace restore" values.
User avatar
Fudoh
Posts: 13015
Joined: Mon Mar 06, 2006 3:29 am
Location: Germany
Contact:

Re: OSSC Pro

Post by Fudoh »

but how about 720x480i as an output mode for 240p inputs?
https://youtu.be/OVUwHv43HqM?t=172

'nuff said.
H6rdc0re
Posts: 224
Joined: Tue Jan 17, 2017 8:22 pm

Re: OSSC Pro

Post by H6rdc0re »

marqs wrote:The most straightforward solution would perhaps be an option for each physical input (AV1-4) that allows selecting audio source from all possible options with perhaps the most obscure combinations removed (e.g. SCART audio with HDMI video).

Speaking of combinations, below is table for planned (most already implemented) adaptive line multiplication output modes. Together with the pure LM modes (identical to oriiginal OSSC), they should cover a good amount of common output resolutions which are suitable for frame sizes resulting from line multiplication.

R= 240p proc & 288p proc & 480i proc & 576i proc & 480p proc & 576p proc R= 720x480 [Line2x] & 720x576 [Line2x] & 720x240 [240p restore] & 720x288 [288p restore] & 720x240 [line drop] & 720x288 [line drop] R= 1280x720 [Line3x] & 1920x1080i [Line4x] & 1280x1024 [Line4x] & 1920x1080i [Line4x] & 1280x1024 [Line2x] & 1920x1080i [Line2x] R= 1280x1024 [Line4x] & 1920x1080 [Line4x] & 1920x1080i [Line4x] & 1920x1080 [Line4x] & 1920x1080i [Line2x] & 1920x1080 [Line2x] R= 1920x1080i [Line4x] & 1920x1440 [Line5x] & 1920x1080 [Line4x] & & 1920x1080 [Line2x] & R= 1920x1080 [Line4x] & & 1920x1440 [Line6x] & & 1920x1440 [Line3x] & R= 1920x1080 [Line5x] & & & & & R= 1600x1200 [Line5x] & & & & & R= 1920x1200 [Line5x] & & & & & R= 1920x1440 [Line6x] & & & & &
With 256x240p input will you do 7x horizontal multiplication on Line6x so 1792x1440? 6x horizontal multiplication will be too skinny and otherwise you'll have to scale non-integer.
User avatar
Konsolkongen
Posts: 2310
Joined: Fri May 16, 2008 8:28 pm
Location: Denmark

Re: OSSC Pro

Post by Konsolkongen »

marqs wrote:
Konsolkongen wrote:marqs > It will be possible to do 480i > 240p > Line2,3,4,5,6 right? :)
Yes, there's a separate "LM deinterlace mode" option with "Bob" and "Noninterlace restore" values.
Excellent! There’s a lot of terrible 480i releases of arcade games on the PS2 I would love to play :)
fernan1234
Posts: 2175
Joined: Mon Aug 14, 2017 8:34 pm

Re: OSSC Pro

Post by fernan1234 »

Fudoh wrote:
but how about 720x480i as an output mode for 240p inputs?
https://youtu.be/OVUwHv43HqM?t=172

'nuff said.

:lol: I did say it's crazy and for experiments! But yes that can be thrown in there just because, if there's room. If not, obviously no loss.

31khz -> 15khz does make a lot more sense and has real use cases though. It's one of the main reasons for currently using Extron VSC 500/700 or some of their scalers with SD outputs.
User avatar
Fudoh
Posts: 13015
Joined: Mon Mar 06, 2006 3:29 am
Location: Germany
Contact:

Re: OSSC Pro

Post by Fudoh »

But yes that can be thrown in there just because, if there's room. If not, obviously no loss.
I wouldn't object either, I can simply see that in the long run it's very limited use case.
fernan1234
Posts: 2175
Joined: Mon Aug 14, 2017 8:34 pm

Re: OSSC Pro

Post by fernan1234 »

Fudoh wrote:I wouldn't object either, I can simply see that in the long run it's very limited use case.
For what it's worth, N64 VC titles have very good results with 240p to 480i conversion. I think there may be some sources that actually benefit from it, like the N64's particular style of 3D graphics, but obviously as we all know well 2D sprite graphics for example look worse. Again, it might enable interesting experiments. Might look good for some 3D Saturn games also.
User avatar
6t8k
Posts: 496
Joined: Wed Aug 14, 2019 2:44 pm

Re: OSSC Pro

Post by 6t8k »

Would somebody be able to roughly describe how the new adaptive line multiplication feature is going to work under the hood? As marqs explained earlier, I take it that it combines the advantages of both a) an adjusted clock, and by extension, -framerate to avoid tearing/stuttering (drawback: game runs at slightly different speed), and b) leaving the clock be while accepting tearing/stuttering due to different target framerate (non-framelocked operation). Personally I'm familiar with these trade-offs due to Analogue's devices. I assume the solution has nothing to do with Variable Refresh Rate (VRR) technologies? Is it that lines are subtly inserted/dropped on-the-fly?


And, another idea for an extension module. I think having an open-software, open-schematics capture card just like the OSSC would be really convenient and meaningful, and wouldn't this be the opportunity to let the idea come to life? Receiving the pixel data over GPIO, one would then "merely" have to suitably encapsulate the data for USB, Thunderbolt or what have you, and send it down the line (or am I by any chance making it simpler than it is? I think it's not much more than that!). The device could seamlessly benefit from the Pro's scaling and further video processing capabilities. When the Pro is digitizing an analog source, one would be able to view the stream with minimal lag via the built-in HDMI out port, just like normal. When the Pro is, on the other hand, accepting a digital source via the built-in HDMI in port, the HDMI out port could act as a passthrough - I'm thinking this should work even while a modified stream is delivered to the capture card at the same time. Different from other capture cards, one could then also cater for maximum compatibility with sources, as the device would be tailor-made for use with the Pro.

A message to all the dear and able PCB designers out there: I ardently hope to eventually see a device like this, we in agreement? :mrgreen: Otherwise I'd see no alternative to setting my own hand to it, necessity is the mother of invention. ;) ;)
whatamansion
Posts: 24
Joined: Thu May 07, 2020 6:33 am

Re: OSSC Pro

Post by whatamansion »

Will the new adaptive mode fix the jittery sync issue on SNES and NES where you won't need the dejitter mods anymore for most tv sets?
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: OSSC Pro

Post by marqs »

6t8k wrote:Would somebody be able to roughly describe how the new adaptive line multiplication feature is going to work under the hood? As marqs explained earlier, I take it that it combines the advantages of both a) an adjusted clock, and by extension, -framerate to avoid tearing/stuttering (drawback: game runs at slightly different speed), and b) leaving the clock be while accepting tearing/stuttering due to different target framerate (non-framelocked operation). Personally I'm familiar with these trade-offs due to Analogue's devices. I assume the solution has nothing to do with Variable Refresh Rate (VRR) technologies? Is it that lines are subtly inserted/dropped on-the-fly?
Both pure and adaptive line multiply modes are framelocked i.e. output frames are generated at exactly same interval as input. The following equation of frame time thus applies: (H1*V1)/C1 = (H2*V2)/C2 where H1,V1,C1 are H/V totals and pixel clock frequency for source (actually the video ADC) while H2,V2,C2 are respective values for the HDMI output. In pure line multiplication, V2 is simply N*V1 where N=2,3,4,etc. so for the equation to hold, C2 must be N*C1 (assuming H1=H2). This kind of clock multiplication can be done with a basic PLL, but H2 and V2 end up being dictated by source which is why this method provides limited compatibility, especially with higher N. With adaptive line multiplication, H2 and V2 are selected to match standard VESA/CEA timings for maximal compatibility. Then the big challenge is to generate clock C2 with exact frequency of ((H2*V2)/(H1*V1))*C1 where H/V values are large integers. Aside from custom clock synthesis logic used in large video processing ASICs, there are 2 approaches for implementing such clock with off-shelf parts. One is to use an adjustable free-running clock source and build a SW/HW feedback loop around it to make it settle to (and track) target frequency, preferably glitch-free and with minimal jitter. The second option is to use PLL which kinda does this internally, and with high performance. PLLs with such high requirements for the fractional part are rare, but I was able to find a suitable one originally for cps2_digiav project, and the same one is now used with OSSC Pro.
whatamansion wrote:Will the new adaptive mode fix the jittery sync issue on SNES and NES where you won't need the dejitter mods anymore for most tv sets?
The video ADC is more stable than the one used in original OSSC so chances are that unmodified (S)NES consoles are more likely to work with larger number of displays. Still, the jitter issue is inherent to the console so the only guaranteed way is to mod them or run non-framelocked.
User avatar
Fudoh
Posts: 13015
Joined: Mon Mar 06, 2006 3:29 am
Location: Germany
Contact:

Re: OSSC Pro

Post by Fudoh »

Still, the jitter issue is inherent to the console so the only guaranteed way is to mod them or run non-framelocked.
will we be able to set the output refresh mode in scaler mode to match the original refresh rate as close as possible? Ideally the framerate could be read from in the input (as it would in the LM modes) and could be applied to the output on demand. I don't need it freely adjustable, but a free choice between "original framerate", 50, 60 and 59.94Hz would be nice.

I've used many processors with unlocked output over the years and some still offered custom output timings with fine enough settings to reduce the number of dropped or inserted frames to a level that makes it really hard to notice.
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: OSSC Pro

Post by marqs »

Fudoh wrote:
Still, the jitter issue is inherent to the console so the only guaranteed way is to mod them or run non-framelocked.
will we be able to set the output refresh mode in scaler mode to match the original refresh rate as close as possible? Ideally the framerate could be read from in the input (as it would in the LM modes) and could be applied to the output on demand. I don't need it freely adjustable, but a free choice between "original framerate", 50, 60 and 59.94Hz would be nice.

I've used many processors with unlocked output over the years and some still offered custom output timings with fine enough settings to reduce the number of dropped or inserted frames to a level that makes it really hard to notice.
Yes, the same clock generator / PLL chip is able to generate free-running frequencies with high granularity. The scaler mode can also naturally use framelocked clock which is the preferred method for jitter-free sources.
tongshadow
Posts: 613
Joined: Sat Jan 07, 2017 5:11 pm

Re: OSSC Pro

Post by tongshadow »

This machine is gonna be a huge success specially because of 480i> 240p conversion alone. Not that the other modes and features arent amazing by themselves, but 480i> 240p is something everyone wanted in a simple and easy way, and seeing it in a powerful and versatile hardware is outstanding.

The struggle is over.
User avatar
orange808
Posts: 3196
Joined: Sat Aug 20, 2016 5:43 am

Re: OSSC Pro

Post by orange808 »

tongshadow wrote:This machine is gonna be a huge success specially because of 480i> 240p conversion alone. Not that the other modes and features arent amazing by themselves, but 480i> 240p is something everyone wanted in a simple and easy way, and seeing it in a powerful and versatile hardware is outstanding.

The struggle is over.
Be cautious with expectations for 480i. It won't work all the time. If the source is implementing a flicker filter (very common on 3do** and PS2), the results for "double strike" (manipulating the field offset) won't be great.

**(Yes, I do know about the 3do hardware mod. Thanks anyway, readers. I'm talking about the OSSC Pro.)

Of course, in the future, there will probably be a high quality interlacing option that will probably deliver pretty 240p, but that will come with a latency penalty.
We apologise for the inconvenience
User avatar
6t8k
Posts: 496
Joined: Wed Aug 14, 2019 2:44 pm

Re: OSSC Pro

Post by 6t8k »

marqs: Thank you for the detailed explanation. I assume the adaptive line multiplication is the same thing you were referring to as 'frame synchronization' back in the Toaplan V2 thread - I think I'm getting a much clearer understanding now.

T̶w̶o̶ One more question now results that I'm still in the dark about (sorry :)): when H2 and V2 are changed as compared to H1 and V1, I assume always multiplying them by the same factor each wouldn't really help, so are you varying Hblank and Vblank ratios instead? I guess what I'm getting at is: can the original aspect ratio be preserved?

Here's the other one I answered myself (I hope) for posterity:
Spoiler
• When deciding on suitable H2 and V2 to match standard VESA/CEA timings, the aim is then to adapt externally generated C2 to ideally match ((H2*V2)/(H1*V1))*C1 as you outlined. This then also c̶h̶a̶n̶g̶e̶s̶ ̶t̶h̶e̶ ̶f̶r̶a̶m̶e̶ ̶r̶a̶t̶e̶ (no, see below) F2 because F2 = C2/(H2*V2). You say, however, that operation is framelocked (output frames are generated at exactly same interval as input). From that follows that one has to buffer the frames, and either discard information or insert "padding", depending on the input/output combination. Isn't this just what for example Analogue's devices' 'Fully buffered' and 'Single buffer' modes do (your earlier explanation seemed to imply that existing implementations like these lack adaptive line multiplication)? I'm probably just stuck somewhere.

Edit: Perhaps I shouldn't be comparing this too much to Analogue's devices specifically, it's just the only thing I'm familiar with that does something like what you described, so it seemed natural.
Edit2: OK, I think I got it! C2 = ((H2*V2)/(H1*V1))*C1 just means F1 = F2, because C1/(H1*V1) = C2/(H2*V2) can be rewritten as the former. Looking at it now it makes intuitive sense "new pixels per old pixels, at old speed". Simplified:

Code: Select all

I   X/A = Y/B   (*)      | * B
II  Y = (B/A)*X (*)
---
I   Y = (X/A)*B (**)
II  Y = (B/A)*X (*)

(same due to commutative property)
I.e. theory shows a more compatible framelocked mode as compared to the non-Pro OSSC is possible by changing the resolution, and completely without stuttering/tearing. :)
The challenge is then to care for the two remaining parameters: C2, which has to be driven correctly, and latency, as you said.
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: OSSC Pro

Post by marqs »

6t8k wrote:I assume the adaptive line multiplication is the same thing you were referring to as 'frame synchronization' back in the Toaplan V2 thread - I think I'm getting a much clearer understanding now.
Actually what I meant by frame synchronization on the other thread is sampling being done using a free-running clock (which is immune to sync instability) and resulting frame data getting synchronized to source refresh rate, but not necessarily perfectly as with true line/framelock.
6t8k wrote:One more question now results that I'm still in the dark about (sorry :)): when H2 and V2 are changed as compared to H1 and V1, I assume always multiplying them by the same factor each wouldn't really help, so are you varying Hblank and Vblank ratios instead? I guess what I'm getting at is: can the original aspect ratio be preserved?
H/V are horizontal and vertical total including blanking. Resizing the visible area (let's call that X and Y) is done using integer scaling (Y factor indicated as LineYx in the table). The amount of buffering needed depends on V1-V2 and Y1-Y2 ratios. All the mode combinations shown on the previous table can be implemented with maximum of 40-line buffer.
Joelepain
Posts: 180
Joined: Wed Sep 12, 2012 7:40 pm

Re: OSSC Pro

Post by Joelepain »

Hi !
I have a little question about this project.
I know it will represent a niche usage but anyway.
With the new GCVideo option to output YCbCr 4:2:2 (so I suppose the RAW untouched data from the console) and the fact that the OSSC Pro will have some RAM (so the ability to store several frames), do you think it will be possible to use some kind of spatial and temporal reconstruction to achieve a better YCbCr 4:2:2 > RGB 4:4:4 conversion than what the GCVideo is able to achieve with its hardware limitations ?
And do you think it will be worth it in terms of efforts vs quality gained ?
User avatar
6t8k
Posts: 496
Joined: Wed Aug 14, 2019 2:44 pm

Re: OSSC Pro

Post by 6t8k »

marqs wrote:Actually what I meant by frame synchronization on the other thread is sampling being done using a free-running clock (which is immune to sync instability) and resulting frame data getting synchronized to source refresh rate, but not necessarily perfectly as with true line/framelock.
Ah yes, in this sense, the (S)NES jitter touched upon here is a similar issue. Somehow conflated the two. Thanks.
H/V are horizontal and vertical total including blanking. Resizing the visible area (let's call that X and Y) is done using integer scaling (Y factor indicated as LineYx in the table). The amount of buffering needed depends on V1-V2 and Y1-Y2 ratios. All the mode combinations shown on the previous table can be implemented with maximum of 40-line buffer.
OK, I believe an important puzzle piece for me to understand is that setting of [H2_total x V2_total] tuple is an independent step from scaling H1_active and V1_active up to H2_active and V2_active.

It's not like H1_active and V1_active are scaled to match the resolution chosen by the user: [H2_active x V2_active] tuple, picked from table above (which dictates [H2_total x V2_total]). Instead, V2_active is defined by V1_active * Y (where Y is the integer LineYx as chosen by the user), and H2_active is defined by H1_active * X (where X is an integer =Y usually, but not always, due to aspect correction). It's important to distinguish that all lines ∈ V1_active are expanded horizontally by multiplying sampling rate by X* and/or applying pixel repetition, whereas V2_active is then reached by copying all lines ∈ V1_active Y-1 times (neglecting that sync has to be adjusted etc; I'm only considering active pixels for illustration). The - I believe - important thing is then that resulting H2_active and V2_active are subsequently projected onto H2_total and V2_total, which is why output resolution becomes independent from source (ADC) resolution. Side-note: the implementation of the non-Pro OSSC's "Line5x format" setting must be tied to a (slightly?) different concept because the external clock generator is missing, right?

* Assumption: as opposed to LM/ALM modes, in scaler mode, the Pro does not have to do this and will be able to freely scale in both H and V dimensions.

Would this be about right?
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: OSSC Pro

Post by marqs »

Perhaps the below example for 240p -> 1920x1080 (Line4x) [Generic 4:3] gives some idea how the parameters are selected under the hood:
Spoiler
Input [1]:

H1_Total: H1_Active / 0.82 = 1560 (ADC sampling rate)
V1_Total: ~262 (source-dependant)
H1_Active: X2 = 1280
V1_Active: 240

Output [2]:

H2_Total: 2200 (CEA-spec)
V2_Total: 1125 (CEA-spec)
H2_Active: 1920 (CEA-spec)
V2_Active: 1080 (CEA-spec)
X2: (4/3)*Y2 = 1280
Y2: 4*V1_Active = 960
6t8k wrote:Side-note: the implementation of the non-Pro OSSC's "Line5x format" setting must be tied to a (slightly?) different concept because the external clock generator is missing, right?
That just adjusts vertical active-blanking ratio while total stays same.
6t8k wrote:Assumption: as opposed to LM/ALM modes, in scaler mode, the Pro does not have to do this and will be able to freely scale in both H and V dimensions.
Freeform scaling in just H dimension could be done in all modes (no additional buffering), but freeform vertical/combined scaling is not within the definition of line multiplication. The premise of line multiplication is to provide pixel/line accurate output with minimal delay while scaler mode can trade some of that for better size/aspect control.
Post Reply