OSSC Pro

[Lelautre]

Hi,
Is it confirmed that the Pro will have a built-in Dejitter please? The release date will be announced soon?

[BuckoA51]

What do you mean by a dejitter? If you're referring to the NES/SNES mod, that was more an issue due to a quirk in the original OSSC hardware, so likely it won't even be needed this time around.

[McKie1]

Last post RE: this tangent we went on, but looks like someone has finally dropped a reasonably priced SCART to DE-15:

https://www.retroupgrades.co.uk/product ... a-adapter/

It's a shame that one is using LM1881 sync stripper instead of a more modern sync separator like ISL59885 which could generate H+V sync.

Could this be used to officially linetriple 480p? Or just unofficially at 2560? Usually 480p is at 720x480 rather than 640x480 at least through component input.

Majority of 4:3 480p games are 640x480 which is easily integer multiplied to 1920x1440. Different widths can be supported by tweaking sampling or alternatively polyphase scaling can be just used for X & Y which is usually better fit for 3D games anyway.

Possibly a weird question but would it be possible to have multi-channel analogue audio inputs via the gpio?

It could then be combined with either the component or rgbhv inputs.

One could design an expansion card with analog audio inputs and appropiate ADC(s), but only 1 out 4 I2S data signals is routed from FPGA to HDMI TX (rest are RX->TX directy) due to IO pin limitations. It means that non-bitstream multichannel audio can only be used with HDMI sources, but I don't see many use cases for analog multichannel inputs aside perhaps retro PCs. Basic stereo sound can be still copied to back channels (5.1 / 7.1 matrixes) with all sources.

Thank you Marqs for the feedback.

My specific connection is probably unusual but was planning on connecting our Hi-Vision Laserdisc player from the muse box with the rgbhv (d-sub) and the 5.0 multi-channel audio. Otherwise was going to just do as you suggested and only use the two front channels.

Had to ask

Thank you again for an amazing project. Don't laugh but with our system we sadly need four of these

Now which organ to sell. lol

[fernan1234]

Thank you marqs for all the great info and replies here. I would like to ask about 1080i processing on the OSSC Pro.

I believe you have mentioned that 1080i will be supported as a scaled output, and I assume it will also be supported as an input. I am wondering if the OSSC Pro can support a similar presentation of HD interlaced video as some professional monitors like Sony's, which essentially perform the same trick that the OSSC does already for SD interlace sources with a progressive output using bob combined with scanlines, which is both faster than other deinterlacing and more CRT-like in appearance. This is how Sony describes it in advertising material:



There is a pretty large amount of video content from broadcast and blurays of film, TV, music, animation, and various other content that is native 1080i and, albeit subjectively, is best represented in its original interlaced appearance, which is why Sony continues to advertise it even on its latest broadcast monitor. Enabling this feature on the OSSC Pro would bring its advantages to commercial TV sets and monitors that do not have it built in like Sony's pro monitors (and are significantly less expensive). The output signal would be 1080p and thus not subject to additional I/P conversion (and lag) on the display side.

[Fudoh]

Do you have any reson to believe that alternating scanlines for 1080i input signals won't be available, when they have been available on the original OSSC for SD signals for years?

[marqs]

On the topic of multichannel input, I don't remember seeing specifics about the TOSLINK jack--is it an input or an output?

It's an input as shown in the OP block diagram.

Hi,
Is it confirmed that the Pro will have a built-in Dejitter please? The release date will be announced soon?

The release date will be announced once HW is final and we've found a manufacturer that meets our quality/cost requirements. Assuming you're referring to snes_dejitter, it's not something you can build into downstream processor, but the video frontend in OSSC Pro is much more resilient to irregular sync such as SNES is producing in 240p mode. There are some details and test results in this thread.

Thank you marqs for all the great info and replies here. I have a couple of questions regarding 1080i input and output on the OSSC Pro.

I believe you have mentioned that 1080i will be supported as a scaled output, and I assume it will also be supported as an input. I am wondering if the OSSC Pro can support a similar presentation of HD interlaced video as some professional monitors like Sony's, which essentially perform the same trick that the OSSC does already for SD interlace sources with bob combined with scanlines, which is both faster than other deinterlacing and more CRT-like in appearance. This is how Sony describes it in advertising material:

There is a pretty large amount of video content from broadcast and blurays of film, TV, music, animation, and various other content that is native 1080i and, albeit subjectively, is best represented in its original interlaced appearance, which is why Sony continues to advertise it even on its latest broadcast monitor. Enabling this feature on the OSSC Pro would bring its advantages to commercial TV sets and monitors that do not have it built in like Sony's pro monitors (and are significantly less expensive).

Both 1080i input and output will be supported. I've actually run some tests with Intel VIP IP suite recently, using its Deinterlacer II block in motion adaptive mode for 480i/576i and 1080i. The quality is pretty good and latency is just a few scanlines (operates using data from past frames), but it consumes quite a lot of FPGA resources. The IP is not open or free either, so in a long run I'd prefer something custom but nevertheless VIP could be a quick way to implement most scaler mode functions. The bob+scanlines method would be naturally supported as the classic model already implements it (for 1080i too).

[fernan1234]

Do you have any reson to believe that alternating scanlines for 1080i input signals won't be available, when they have been available on the original OSSC for SD signals for years?

I guess it is likely they will be, but they are not on the OSSC, which only passes through 1080i without processing it as suggested. I imagine that the OSSC Pro hardware will be capable of this for HD signals, but don't know if marqs has already planned to implement it.

...And just as I was typing that, marqs just confirmed it.

The bob+scanlines method would be naturally supported as the classic model already implements it (for 1080i too).

Thank you for your response and for this confirmation! Great news for those of us who really value this feature and thus far depended on Sony's professional displays for it (I have never encountered any other video processor or display that can do this for HD signals).

edit: just got it that the OSSC classic does it too. Guess I just missed it somehow! The Pro's HDMI input will make it much more accessible and practical for digital sources.

[u1su3su2]

Last post RE: this tangent we went on, but looks like someone has finally dropped a reasonably priced SCART to DE-15:

https://www.retroupgrades.co.uk/product ... a-adapter/

It's a shame that one is using LM1881 sync stripper instead of a more modern sync separator like ISL59885 which could generate H+V sync

Sorry for the plug here, but I just released an open-source project that might be helpful to you (although you need a passive SCART to DIN8 cable also): viewtopic.php?f=6&t=68150

It supports RGBHV.

[marqs]

Sorry for the plug here, but I just released an open-source project that might be helpful to you (although you need a passive SCART to DIN8 cable also): viewtopic.php?f=6&t=68150

It supports RGBHV.

It might be a good idea to buffer CSYNC_IN since sources like MD have open-collector driver with limited strength. Then you could have separate CSYNC_TTL (5V) and CSYNC_75 (video-level sync) outputs. For OSSC Pro specifically, CSYNC_75 could be additionally routed via a solder jumper to DE-15 pin 4, although that might not be necessary as you seem to have the option to route TTL CSYNC to pin 13.

[u1su3su2]

Sorry for the plug here, but I just released an open-source project that might be helpful to you (although you need a passive SCART to DIN8 cable also): viewtopic.php?f=6&t=68150

It supports RGBHV.

It might be a good idea to buffer CSYNC_IN since sources like MD have open-collector driver with limited strength. Then you could have separate CSYNC_TTL (5V) and CSYNC_75 (video-level sync) outputs. For OSSC Pro specifically, CSYNC_75 could be additionally routed via a solder jumper to DE-15 pin 4, although that might not be necessary as you seem to have the option to route TTL CSYNC to pin 13.

Thanks for looking at it. To make sure that I'm not missing anything: a MD would be connected via J1 and in the normal mode of operation, (JP1 closed at 1-2 and JP2 open - https://github.com/semi-simple/backporch#outputs), CSYNC_75 should be buffered via U1. Perhaps the fact that JP2 is "supposed" to be open is unexpected, since it's not the normal mode of operation. I'm relying on sync strippers being pretty tolerant with TTL input levels (i.e. it doesn't need to be caped at 2.5V), and there is little point in setting up a proper "transmission line" termination, since as you point out, the MD doesn't even have a 75 Ohm resistor inside the console - and this part is supposed to be very short anyways -.

In general, I'm thinking of a design using buffering instead of having different input ports (J1 and J2) depending on whether or not I can expect 75 Ohm resistors inside the console and TTL sync or not. This should allow removing the large coupling caps as well.. Is that the kind of improvement that you are suggesting?

Thanks for your help!

[marqs]

Thanks for looking at it. To make sure that I'm not missing anything: a MD would be connected via J1 and in the normal mode of operation, (JP1 closed at 1-2 and JP2 open - https://github.com/semi-simple/backporch#outputs), CSYNC_75 should be buffered via U1. Perhaps the fact that JP2 is "supposed" to be open is unexpected, since it's not the normal mode of operation. I'm relying on sync strippers being pretty tolerant with TTL input levels (i.e. it doesn't need to be caped at 2.5V), and there is little point in setting up a proper "transmission line" termination, since as you point out, the MD doesn't even have a 75 Ohm resistor inside the console - and this part is supposed to be very short anyways -.

In general, I'm thinking of a design using buffering instead of having different input ports (J1 and J2) depending on whether or not I can expect 75 Ohm resistors inside the console and TTL sync or not. This should allow removing the large coupling caps as well.. Is that the kind of improvement that you are suggesting?

Thanks for your help!

My concern mainly are cases where CSYNC_IN via J1 ends up driving 75ohm termination (display connected to J2 or JP2 shorted). You should assume CSYNC_IN is weakly driven (e.g. MD) and logic high anywhere between 2V and 5V (e.g. 2.5V with SNES). I'd replace R6, C10 and C11 with a TTL schmitt trigger buffer (e.g. SN74HCT14 A>Y>A>Y) which should be proper load for CSYNC_IN input. That also solves another problem of the current design: in U1 bypass mode (JP1 2-3 shorted), AC-coupled c-sync goes to DE-15 pin 13.

[u1su3su2]

My concern mainly are cases where CSYNC_IN via J1 ends up driving 75ohm termination (display connected to J2 or JP2 shorted). You should assume CSYNC_IN is weakly driven (e.g. MD) and logic high anywhere between 2V and 5V (e.g. 2.5V with SNES). I'd replace R6, C10 and C11 with a TTL schmitt trigger buffer (e.g. SN74HCT14 A>Y>A>Y) which should be proper load for CSYNC_IN input. That also solves another problem of the current design: in U1 bypass mode (JP1 2-3 shorted), AC-coupled c-sync goes to DE-15 pin 13.

Thanks! Your suggestion makes a lot of sense to me for the U1 bypass mode (where JP1 2-3) is shorted and I'll look into it.

For the JP1 (1-2) closed mode (normal mode), wouldn't R7 alleviate your concerns? C10 and C11 should take care of any positive voltage offsets (like the SNES has) and with display connected to J2, the source (say a MD on J1) "sees" ~620 Ohm. This should be to spec (and is how all existing SCART cables are built, to my knowledge). Please let me know if there is something I'm missing!

Your solution is of course still better, so I'll consider that even when U1 is used. I'm not a big fan of the common practice of relying on an extra resistor (R7 here) to reduce the voltage "seen" by the display.

[marqs]

For the JP1 (1-2) closed mode (normal mode), wouldn't R7 alleviate your concerns? C10 and C11 should take care of any positive voltage offsets (like the SNES has) and with display connected to J2, the source (say a MD on J1) "sees" ~620 Ohm. This should be to spec (and is how all existing SCART cables are built, to my knowledge). Please let me know if there is something I'm missing!

AC coupling via C10-11 isn't mandatory, but it can be done for video-level sync (CSYNC_75 in your schematics). It has both benefits and downsides. While R7 prevents excessive voltage when connected to video-level inputs, I'm afraid 620ohm is still too low value for sources that expect high-impedance input. A few years ago I recall testing hooking MD csync via 470ohm in series to 75ohm termination, and the resulting sync amplitude was way too low. Addition of AC coupling cap resolved that (no static current), but I'd consider it as a workaround. Leading sync edges in this configuration were not very sharp compared to cvbs, take a look at some comparison pictures here.

Your solution is of course still better, so I'll consider that even when U1 is used. I'm not a big fan of the common practice of relying on an extra resistor (R7 here) to reduce the voltage "seen" by the display.

R7 or a proper 75ohm driver would still be needed with SN74HCT14.

It's probably better to continue this discussion on its dedicated thread.

[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.

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.

OK going back to this old post, yesterday I thought of what could be an excellent use case for 480i as an output mode for 240p: rotation/tate of 240p games on SD CRTs.

480i should offer enough vertical space to fit the game's original horizontal resolution after rotation, and SD CRT users would only need an appropriate DAC to get a rotated 15khz signal.

Does this make sense, or am I missing something obvious as to why this wouldn't work? Would be a great way to not need to tate CRTs or keep an extra around just for tate games.

[energizerfellow‌]

Both 1080i input and output will be supported. [...] The bob+scanlines method would be naturally supported as the classic model already implements it (for 1080i too).

I think there's some confusion here on what's being asked. They aren't asking about bob de-interlacing + scanlines, they're asking about what's effectively a "raw" 1080i field in a 1080p progressive frame container with no de-interlacing processing at all.

The top field will start from the top with a video line, then a blank line, then a video, line, etc. in the progressive output frame. The lower incoming field will have a blank scan line at the very top, then a video line, blank, etc. Think bob+scanline, but the output scanline moves up/down one line depending on the incoming field and there's no video line duplication/multiplier.

As mentioned, I don't know of any displays on the market that do this other than the current-gen Sony PVM/BVM panels.

[Joelepain]

Yes that's what he has told you.
marqs answer may be a little confusing (bob+scanline could mean something else) but what you asked is already implemented in the current OSSC.

[fernan1234]

 
Yes that's what he has told you.
marqs answer may be a little confusing (bob+scanline could mean something else) but what you asked is already implemented in the current OSSC.

I was a bit confused at first but I also take it that they are the same thing. I can't say for sure what exactly the flat panel Sony PVM/BVMs do for their interlaced modes, but what else could it be other than what the OSSC already does?

BTW1, I never realized the OSSC classic can do this since there are so few analogue sources that can do 1080i, and all of them AFAIK (e.g.: handful of games on PS2, XBox) require YPbPr rather than RGB for it. So very few sources could take advantage of it. But now with an HDMI input on the Pro a whole new world is opened up for a lot of digital backups of originally interlaced HD content that has been backed up as progressive. The Pro will make it very convenient to "re-interlace" such progressive backups into their original appearance.

As mentioned, I don't know of any displays on the market that do this other than the current-gen Sony PVM/BVM panels.

BTW2, it's not just the current-gen panels. Sony has been doing this with the pro monitors going all the way back to the L-series in 2007-2008 (first pro LCDs after the last pro CRTs, the A-series). In fact those may make this interlace effect look a bit better as they use 120hz panels (pretty novel for the time I'd say), compared to the 60Hz panels in the OLEDs. The current-gen dual layer LCD (HX-310) may be 120Hz, though I've never seen the refresh rate listed in the specs sheet for it. Either way, it looks great @ 60Hz too (which is also ideal for 60fps and 30fps content, as well as their 1/1.001 equivalents).

[anexanhume]

BTW, what are the 540p timings - same as 1080i but without interlace?

540p is 960x540. As Downy said, it's similar to the 240p trick used by NES, etc...

Slight nitpick: If we’re talking digital interfaces (hdmi/dvi etc) it’s likely that devices will be picky about the pixel clock, so it will probably need to be 1920x540 to maintain the expected 74.25MHz.

I believe the total resolution including blanking would be 2200x563.

I wonder if it would be possible to highjack the passthrough control and force non-1080i analog signals straight through to the tube?

[Leewrigley]

One of the features I'm most excited for is the deinterlacing of 480i content (ps2 etc). Do you think we could get some short clips as a preview of the new deinterlacing and even any new upscaling features of 480p etc. Looking for some demo so I can get more hyped for what we will get ! Even if it's still a work in progress I know I would still appreciate a sneak peak.

[marqs]

One of the features I'm most excited for is the deinterlacing of 480i content (ps2 etc). Do you think we could get some short clips as a preview of the new deinterlacing and even any new upscaling features of 480p etc. Looking for some demo so I can get more hyped for what we will get ! Even if it's still a work in progress I know I would still appreciate a sneak peak.

Here are a few clips I took a week ago with the motion adaptive deinterlacer.

[Shinianess]

One of the features I'm most excited for is the deinterlacing of 480i content (ps2 etc). Do you think we could get some short clips as a preview of the new deinterlacing and even any new upscaling features of 480p etc. Looking for some demo so I can get more hyped for what we will get ! Even if it's still a work in progress I know I would still appreciate a sneak peak.

Here are a few clips I took a week ago with the motion adaptive deinterlacer.

It is so exciting to see the clips. May I ask that if the DE10 nano add-on has the full function of the OSSC pro or is only a budget solution? My ps2 can't wait to go with it.

Appreciate your amazing work.

[Leewrigley]

One of the features I'm most excited for is the deinterlacing of 480i content (ps2 etc). Do you think we could get some short clips as a preview of the new deinterlacing and even any new upscaling features of 480p etc. Looking for some demo so I can get more hyped for what we will get ! Even if it's still a work in progress I know I would still appreciate a sneak peak.

Here are a few clips I took a week ago with the motion adaptive deinterlacer.

Thats awesome thanks for the preview, looks quite clean and much nicer than the bob-deinterlacer imo, how does this type of deinterlace work then, would the output still be 60fps or does it cut down to 30? not too knowledgable on how deinterlacing works exactly, im assuming that the resulting 480p image could then be doubled like a standard 480p signal.

[orange808]

One of the features I'm most excited for is the deinterlacing of 480i content (ps2 etc). Do you think we could get some short clips as a preview of the new deinterlacing and even any new upscaling features of 480p etc. Looking for some demo so I can get more hyped for what we will get ! Even if it's still a work in progress I know I would still appreciate a sneak peak.

Here are a few clips I took a week ago with the motion adaptive deinterlacer.

Thats awesome thanks for the preview, looks quite clean and much nicer than the bob-deinterlacer imo, how does this type of deinterlace work then, would the output still be 60fps or does it cut down to 30? not too knowledgable on how deinterlacing works exactly, im assuming that the resulting 480p image could then be doubled like a standard 480p signal.

https://www.intel.com/content/dam/alter ... ug_vip.pdf

Page 130
15.2.3

[vol.2]

Page 130
15.2.3

Are you saying that this won't use edge interpolation (15.2.4)?

[orange808]

Page 130
15.2.3

Are you saying that this won't use edge interpolation (15.2.4)?

It's possible. I'm not experienced with using this IP library and my FPGA experience is limited, so I couldn't share details about what features are available as low latency options (or how they are configured).

The description at 15.2.3 should give a good general outline of how motion adaptive bob and weave choices are made.

I'm sure marqs can elaborate.

[Shinianess]

One of the features I'm most excited for is the deinterlacing of 480i content (ps2 etc). Do you think we could get some short clips as a preview of the new deinterlacing and even any new upscaling features of 480p etc. Looking for some demo so I can get more hyped for what we will get ! Even if it's still a work in progress I know I would still appreciate a sneak peak.

Here are a few clips I took a week ago with the motion adaptive deinterlacer.

Amazing works. Thanks for your sharing. May I ask if the DE10-addon makes DE10 a fully or a partially functional OSSC pro?

[marqs]

Page 130
15.2.3

Are you saying that this won't use edge interpolation (15.2.4)?

It's possible. I'm not experienced with using this IP library and my FPGA experience is limited, so I couldn't share details about what features are available as low latency options (or how they are configured).

The description at 15.2.3 should give a good general outline of how motion adaptive bob and weave choices are made.

I'm sure marqs can elaborate.

The sobel edge interpolation mode is even more resource-hungry than the basic motion adaptive configuration. It'd consume almost half of FPGA logic, making it rather unfeasible.

[Fudoh]

If this is something that can be implemented without too much work, I'd be very VERY interested in an alternative firmware down the road just geared towards 480i. I'm pretty sure you'd be reaching a whole new customer base by making something like this available.

[orange808]

With the Retrotink5x looking to undersell the OSSC Pro, would it make sense to reconfigure?

Maybe raise the specs, target the high end, and build a proper video processor with video game features? I think that would bring in home theatre enthusiasts. I understand it would be expensive, but many of the people complaining about high Framemeister prices are still buying them. I would love a 4:4:4 DVDO iScan successor with better deinterlacing, low latency, rotation, and warp--even if it was only 1440p output.

[Joelepain]

If this alternative firmware is really feasible and the resources a real limit, I wonder if it will be interesting to chain two ossc pro. One only doing deinterlacing, the other doing the rest.
I'm sure there will be people interested by that and ok to pay the price, while still keeping the price of only one ossc "reasonable" for oher pepole.