Can't wait to sink my teeth into this when released. I know it's still quite early but any idea on the price range?

Quick estimation based on the released information:Bassa-Bassa wrote:Will you be able to double native 720p graphics and then add scanlines for 1440p displays with this?
Those are not just filters, but shaders. Like on the MiSTer, I imagine shaders cannot be possible due to the lack of a GPU. However a combination of hybrid scanlines, vertical+horizontal, and perhaps other tricks could get kinda close to a similar effect.MysticSynergy wrote:Also, will this OSSC Pro offer the ability to use scanline filters like the ones seen on RetroArch such as CRT-Royale, Royale-Kurozumi or CRT-Geom?
Thanks for the answer, even if I'm sad now. Still surprising, that nobody in 2020 seems to care about native 720p (2D) visuals given that 720p displays are old and low quality, specially latency-wise.Unseen wrote:Quick estimation based on the released information:Bassa-Bassa wrote:Will you be able to double native 720p graphics and then add scanlines for 1440p displays with this?
- 2560 x 1440 at 60Hz needs a 235MHz pixel clock
- the ADV7513 HDMI transmitter of the OSSC Pro is limited to a 165MHz TMDS clock and officially only supports HDMI 1.4
- 24 bit RGB uses the same TMDS clock frequency as the pixel clock -> won't work
- YCbCr 4:2:2 in HDMI 1.4 also uses the same TMDS clock as the pixel clock
- YCbCr 4:2:0 with 8 bits per component uses half the pixel clock for the TMDS clock -> within the limit, but 4:2:0 is an HDMI 2.0 feature and from a quick glance at the datasheet it is not clear if the ADV7513 could be convinced to output it
- also, scanlines and 4:2:0 don't mex very well in my experience
Whenever I see this I think of the ZisWorks monitor kit and wonder why it no one else has been able to pull it off.Unseen wrote:
- 2560 x 1440 at 60Hz needs a 235MHz pixel clock
I actually didn't know that. Thanks for pointing this out.YCbCr 4:2:2 in HDMI 1.4 also uses the same TMDS clock as the pixel clock
The basic idea is easy: They use DisplayPort instead of HDMI and an FPGA with integrated gigabit transceivers so they don't need an external receiver chip. Using DisplayPort has a few advantages here, among them the rather important detail that the signal levels that the FPGA transceivers can work with are directly compatible with DisplayPort while they would need external level translation to receive (or transmit) HDMI. DisplayPort is also a bit easier to work with for high resolutions because it is packet-based and does not require all (up to four) lanes to be perfectly in sync - HDMI requires that the three lanes (originally R/G/B) are time-aligned to within half a pixel or so.strayan wrote:Whenever I see this I think of the ZisWorks monitor kit and wonder why it no one else has been able to pull it off.Unseen wrote:
- 2560 x 1440 at 60Hz needs a 235MHz pixel clock
I also thought that there must be a packed 8-bit variant, but it seems that was completely left out - it's always 12 bits per component.Fudoh wrote:I actually didn't know that. Thanks for pointing this out.YCbCr 4:2:2 in HDMI 1.4 also uses the same TMDS clock as the pixel clock
Excellent! Thank youFudoh wrote:The RAD handles it faster on your display, because the RAD normalizes the output refresh rate, while the OSSC keeps the original refresh rate (which differs between the 240p and 480i outputs from a single system).
By adjusting the frame buffer as far as possible the Pro should be able to handle 240p to 480i back without any glitching. The buffer can basically make it perform like a seamless switcher.
Ah - Thank you. That's what I meant to say, shader instead of filter.fernan1234 wrote:Those are not just filters, but shaders. Like on the MiSTer, I imagine shaders cannot be possible due to the lack of a GPU. However a combination of hybrid scanlines, vertical+horizontal, and perhaps other tricks could get kinda close to a similar effect.MysticSynergy wrote:Also, will this OSSC Pro offer the ability to use scanline filters like the ones seen on RetroArch such as CRT-Royale, Royale-Kurozumi or CRT-Geom?
Hmm of course completely fair and I'm sure it will come along soon enough, but I'd argue your phrasing in that post does happen to make it sound like a confirmed/planned feature for launch.BuckoA51 wrote:Please everyone remember downscaling, mister like functionality etc are possible, but will depend on people actually developing the code for them. Saying that the community usually steps up with these sorts of things.Also Matt's post on VGP confirmed downscaling support which I've seen asked about a lot.
That got me thinking.Fudoh wrote:What I like most about the integrated deinterlacing feature is that it's really the first device where this is open to enhancements. Everything so far was either fixed in silicon (ASICs like the ABT102 or traditional ICs like the Marvell) or manufacturers were/are hiding their altgorithms as best as they could/can (DVDO or Lumagen).
Here we can actually see the algorithm behind the deinterlacing and this lets us change the balance between weaving and doubling based on different conditions or requirements. The Marvell's deinterlacing (used in the FM) is still unbelievably good, but with good captures from selected sequences, it shouldn't be too hard to recreate the algorithms at work here.
I like this, would cover everything then!2x20 pin GPIO connector for future expansion possibilities such as:
* composite & s-video input module
Wouldn't cover RF. Not that most people would actually use RF, but I think the compatibility would be useful for some, particularly the early, early, RF-only consoles, which some people may not be willing to mod.Greg2600 wrote:I like this, would cover everything then!2x20 pin GPIO connector for future expansion possibilities such as:
* composite & s-video input module
If you're not willing to mod a console then playing it is also probably a bad idea. Keep it in the box forever if you care that much about its value. Otherwise you might as well have the best experience you can out of it.nmalinoski wrote:Wouldn't cover RF. Not that most people would actually use RF, but I think the compatibility would be useful for some, particularly the early, early, RF-only consoles, which some people may not be willing to mod.Greg2600 wrote:I like this, would cover everything then!2x20 pin GPIO connector for future expansion possibilities such as:
* composite & s-video input module
Just remember that it creates persistence blur. There's almost always a trade off.Josh128 wrote:Excuse my ignorance on the technicalities of converting 240p60 15KHz to 240p120 31KHz, but from my understanding its being done on the MISTer project.
For me, the ability to convert the output of an NES or other classic 240p system to 31KHz and retain the same scanline look is essentially the "Holy Grail" of retrogaming. In theory it would render all PVMs and BVMs obsolete overnight as pretty much any run of the mill 31KHz+ SVGA CRT can trounce both of those in resolution, OSD adjustments, and clarity.
First off, will this be technically possible on the OSSC Pro? If not, why is it that it can be achieved on MISTer and what would actually be needed to accomplish it (conversion of an actual console output) for a classic system? Such a feature, if implemented properly, would mean an insta-buy for me.
https://www.reddit.com/r/crtgaming/comm ... 240p120hz/
https://videogameperfection.com/forums/ ... frequency/
I don't think that's quite what MiSTer does. If you're referring to the direct video out via HDMI feature, I think it changes the pixel clock in a way that an HDMI to VGA can pass as the original system's analogue output. The Analogue consoles do something like that for the DAC. It's not doing the 240p120 trick that can be done from PCs running emulators. And for the latter you need to use BFI to get rid of image doubling in motion.Josh128 wrote:First off, will this be technically possible on the OSSC Pro? If not, why is it that it can be achieved on MISTer and what would actually be needed to accomplish it (conversion of an actual console output) for a classic system? Such a feature, if implemented properly, would mean an insta-buy for me.
This is an evil that will affect all sample-and-hold panels (all LCDs and OLEDs), and will be a problem with the OSSC Pro and any other device because the problem lies on the display tech, though the commonly available BFI can help at the cost of brightness. If only more consumer sets finally implemented the rolling scan that Sony pro monitors use since almost 10 years ago.orange808 wrote:Just remember that it creates persistence blur. There's almost always a trade off.
Resolution is only one aspect; you have to take into account framerate and sync stability--simply windowboxing is not going to grant universal compatibility. If the sync rate is too far off of what the connected display will accept, you'll need to use something like framerate conversion to bring it to something an even 50/60Hz (+-1%); and that introduces its own problems, like judder and dropped frames.neorichieb1971 wrote:Question:
If you have a pro and your set it up for a 240/480/960 in a 1080p frame won't that give you 100% compatibility/results without further tinkering? Essentially you would expect results like a Framemeister at the very least?
DVDO machines take care of that with a partial frame buffer and Bucko confirmed that the OSSC Pro will do the same. Probably four to six milliseinds of lag. ???nmalinoski wrote:Resolution is only one aspect; you have to take into account framerate and sync stability--simply windowboxing is not going to grant universal compatibility. If the sync rate is too far off of what the connected display will accept, you'll need to use something like framerate conversion to bring it to something an even 50/60Hz (+-1%); and that introduces its own problems, like judder and dropped frames.neorichieb1971 wrote:Question:
If you have a pro and your set it up for a 240/480/960 in a 1080p frame won't that give you 100% compatibility/results without further tinkering? Essentially you would expect results like a Framemeister at the very least?
I agree.fernan1234 wrote:This is an evil that will affect all sample-and-hold panels (all LCDs and OLEDs), and will be a problem with the OSSC Pro and any other device because the problem lies on the display tech, though the commonly available BFI can help at the cost of brightness. If only more consumer sets finally implemented the rolling scan that Sony pro monitors use since almost 10 years ago.orange808 wrote:Just remember that it creates persistence blur. There's almost always a trade off.
Not if its output via VGA to a CRT, which is what I was talking about. I suppose if it only does HDMI out, that the HDMI could be converted to 240p120 VGA to feed the CRT.orange808 wrote: Just remember that it creates persistence blur. There's almost always a trade off.
Just to clarify, I was speaking of outputting to a 31KHz CRT, not a sample and hold type digital display.fernan1234 wrote:I don't think that's quite what MiSTer does. If you're referring to the direct video out via HDMI feature, I think it changes the pixel clock in a way that an HDMI to VGA can pass as the original system's analogue output. The Analogue consoles do something like that for the DAC. It's not doing the 240p120 trick that can be done from PCs running emulators. And for the latter you need to use BFI to get rid of image doubling in motion.Josh128 wrote:First off, will this be technically possible on the OSSC Pro? If not, why is it that it can be achieved on MISTer and what would actually be needed to accomplish it (conversion of an actual console output) for a classic system? Such a feature, if implemented properly, would mean an insta-buy for me.
This is an evil that will affect all sample-and-hold panels (all LCDs and OLEDs), and will be a problem with the OSSC Pro and any other device because the problem lies on the display tech, though the commonly available BFI can help at the cost of brightness. If only more consumer sets finally implemented the rolling scan that Sony pro monitors use since almost 10 years ago.orange808 wrote:Just remember that it creates persistence blur. There's almost always a trade off.
Doubling the refresh rate induces both motion incoherency (2 strobes/scans per frame) and latency (half a frame at minimum) so it's not without tradeoffs. You can do motion interpolation to mitigate the former (remember the 100Hz CRT TVs) but that bumps the lag even more. That said, 240p 120+Hz output should be doable on the Pro model.Josh128 wrote:orange808 wrote:In any case, if theres some technical reason as to why this mode would induce blur on a CRT ( I dont believe it does with MISTer or Retroarch), the tradeoff would be worth it to me.
If you dont mind me asking, i'm kind of curious to know what the pros/cons were of each ADC chip?marqs wrote:Selection of the video ADC was a hard choice between ISL51002 and ADV7842 - I hope I made the right call this time. ISL51002 has its own quircks but so far it has operated way better than TVP7002.