OSSC (DIY video digitizer & scandoubler)

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 (DIY video digitizer & scandoubler)

Post by marqs »

nmalinoski wrote:Xyga wrote:
Whatever, how do you figure how to make non-HDMI 2.1 specced devices support HDMI 2.1 features like VRR ? is that possible ? (do you have to redesign from scratch or not)

For me this new HDMI smells like juicy licence and newer machines that can technically carry it, it's for manufacturers who can afford it, I'm not sure marqs could add that to the OSSC without a significant price increase, and I mean significant.

Where the OSSC is concerned, I'm not sure it could be done without a board revision that includes an HDMI-2.1-compliant TX chip; and, even then, you'd need an HDMI-2.1-compliant display, and probably HDMI-2.1-compliant equipment in between (switchers, AVR, etc.).

An upgrade is not always necessary, however; my understanding of the PS4 is that its HDMI TX chip was only compliant to the 1.4 spec, but was later updated to 2.0b compliance with a firmware update.
HDMI 2.1's new gaming-related features (VRR, QMS, QFT) cannot be used with a fixed-function 1.4 TX chip I'm afraid. There are no dedicated v2.0/v2.1 TX chips either as far as I know. It's not that surprising considering how challenging/inpractical it'd be to hook a video controller (FPGA in OSSC's case) using a parallel RGB bus running 4K@60 bandwidth to a HDMI TX chip on PCB. HDMI 2.x thus is generally driven by a GPU/SoC/FPGA directly, so taking advantage of it becomes an issue of finding / developing suitable IP. QMS would definitely be nice, but othervise VRR feature itself has little use for retro games. That's assuming a given VRR-capable display can process VRR refresh rate range from non-VRR sources without framerate conversion. Do we have any early indicators (Freesync/G-sync displays included) that indicate otherwise?
Xyga wrote:Again; only as an option, what don't you get about switchable ? it would be kind of like the XRGB-3 and its two modes.

Many people would be happy when dealing with a display that won't do beyond 2x, to be able to unlock the other modes at the cost of maybe just 1 frame.

Plus think about the other potentials like full deinterlacing, smooth modes switching as mentioned, rotation, etc.

win-win
There's also a third option between pure linedoubling and frame rate conversion (buffering). That involves synthesizing the exact source frame time at a given output resolution which requires very accurate clock generation. It's not trivial - especially if source details are not known beforehand - but still possible and proven to work by cps2_digiav and a few other projects. It doesn't allow smooth mode switching, but maximizes compatibility at minimal latency overhead (some tens of scanlines at most).
User avatar
Xyga
Posts: 7181
Joined: Tue Nov 05, 2013 8:22 pm
Location: block

Re: OSSC (DIY video digitizer & scandoubler)

Post by Xyga »

marqs wrote:but othervise VRR feature itself has little use for retro games. That's assuming a given VRR-capable display can process VRR refresh rate range from non-VRR sources without framerate conversion. Do we have any early indicators (Freesync/G-sync displays included) that indicate otherwise?
Variable refresh is the best thing for retrogaming at least when it comes to emulation, I don't know all the science behind but FreeSync/GSync manage to do this smooth as butter and without additional lag in most cases.
Then ViewSonic monitors aren't branded with vrr tech but can run anything 50~75Hz without conversion, assuming your pc/drivers are set up for running anything within the set range of course (what I'm doing with GroovyMAME & Emudriver). With external real sources like consoles and pcb's, it's sort of strange because it doesn't show anything like running @55Hz (it does with emulation) but the behaviour and compatibility are beyond expectations too.
marqs wrote:There's also a third option between pure linedoubling and frame rate conversion (buffering). That involves synthesizing the exact source frame time at a given output resolution which requires very accurate clock generation. It's not trivial - especially if source details are not known beforehand - but still possible and proven to work by cps2_digiav and a few other projects. It doesn't allow smooth mode switching, but maximizes compatibility at minimal latency overhead (some tens of scanlines at most).
Indeed you've mentioned that some time ago, sounds great but challenging.
Strikers1945guy wrote:"Do we....eat chicken balls?!"
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: OSSC (DIY video digitizer & scandoubler)

Post by marqs »

Xyga wrote:
marqs wrote:but othervise VRR feature itself has little use for retro games. That's assuming a given VRR-capable display can process VRR refresh rate range from non-VRR sources without framerate conversion. Do we have any early indicators (Freesync/G-sync displays included) that indicate otherwise?
Variable refresh is the best thing for retrogaming at least when it comes to emulation, I don't know all the science behind but FreeSync/GSync manage to do this smooth as butter and without additional lag in most cases.
Yes, but that has more to do with emulators typically not being able to drive video output directly, but instead getting limited by OS refresh rate / mode pool. VRR is very nice way of getting around that limitation even though that disables any motion blur reduction / strobing techniques displays could offer (although many do not support / properly implement ~60Hz rate), so it's a tradeoff between motion smoothness and motion resolution.
User avatar
Xyga
Posts: 7181
Joined: Tue Nov 05, 2013 8:22 pm
Location: block

Re: OSSC (DIY video digitizer & scandoubler)

Post by Xyga »

I tend to value accuracy over comfort, though the goal is to have both in the end. :p

BTW it's funny but to layman your third option sounds like it shares DNA with the sort of work they've been doing for GroovyMAME lately: http://forum.arcadecontrols.com/index.p ... 399.0.html, and that I believe will be of use for a potential future implementation of beam racing.
Strikers1945guy wrote:"Do we....eat chicken balls?!"
paulb_nl
Posts: 340
Joined: Sat Feb 20, 2016 5:05 pm

Re: OSSC (DIY video digitizer & scandoubler)

Post by paulb_nl »

BazookaBen wrote:In this scenario I don't think you even need a framebuffer to make the TV run in VRR mode. Because the OSSC just needs to trick the TV into switching to that mode, then provide a static refresh rate as it normally does.

The benefits of the OSSC running in VRR mode would be 1)The TV would be flexible with the strange refresh rates because it's not looking for NTSC/ATSC/VESA modes and 2)TV's and monitors tend to have much less input lag in VRR mode.

Basically, the TV would gladly accept the frames as they come in because they're within the Freesync range, it has no way of knowing if they're buffered beforehand.

...right?
With a device like the OSSC a framebuffer is required to use VRR/Adaptive sync. Adaptive sync works by having a fixed pixel clock and instead varying blanking time.

As an example a display that supports adaptive sync up to 120Hz will need a 120Hz pixel clock and display every frame in 8ms and then wait for the next frame. If you let the display wait for 8 ms you get 60Hz. So in this case the OSSC would have to buffer around half a frame before it can output that to the display. This is also what current 120Hz displays do internally with 60Hz content.

The supported video modes / pixel clock with or without adaptive sync are in the EDID data of the display so you can't just send any weird video mode to a display with adaptive sync like you can't without adaptive sync.
User avatar
Xyga
Posts: 7181
Joined: Tue Nov 05, 2013 8:22 pm
Location: block

Re: OSSC (DIY video digitizer & scandoubler)

Post by Xyga »

TBC the kind of buffer people had in mind was a dumb fixed 1 frame, not one specifically dedicated to adaptive sync (hence the 'barbaric'), two different case uses and effects I believe.
The supported video modes / pixel clock with or without adaptive sync are in the EDID data of the display so you can't just send any weird video mode to a display with adaptive sync like you can't without adaptive sync.
ViewSonic don't play by everyone's EDID traditions then.
Strikers1945guy wrote:"Do we....eat chicken balls?!"
User avatar
Fudoh
Posts: 13015
Joined: Mon Mar 06, 2006 3:29 am
Location: Germany
Contact:

Re: OSSC (DIY video digitizer & scandoubler)

Post by Fudoh »

The info stored in the EDID is merely a recommendation for the sourc to know which timings are definitely compatible - possibly to choose a working timing for boot up. It has of course nothing to do with what you can or can't send to the display or what the display can or can't display IN ADDITION to what's stored in the EDID. You're free to ignore the EDID completely.
User avatar
Xyga
Posts: 7181
Joined: Tue Nov 05, 2013 8:22 pm
Location: block

Re: OSSC (DIY video digitizer & scandoubler)

Post by Xyga »

Yet almost every display on earth is limited to exactly the same that's stored in the EDID (save for 480)
I don't explain how the viewsonics work, not with a giant library, but it's arguably better than free/gsync the way it is, so I hope there'll be a hardware/software explanation some day so the same technique could maybe be exploitable elsewhere.
Strikers1945guy wrote:"Do we....eat chicken balls?!"
User avatar
orange808
Posts: 3196
Joined: Sat Aug 20, 2016 5:43 am

Re: OSSC (DIY video digitizer & scandoubler)

Post by orange808 »

Windows exposes the ability to manipulate the video output timing. The issue for emu devs is the end users and their lousy gear. In most cases, devs prefer to err on the side of caution--versus enduring rants from ignorant users that can't understand why their displays won't support a video mode.

I hate the idea of variable refresh rates as a crutch for shitty display internal video processing. The refresh rate isn't actually going to vary, so I shouldn't need to make motion clarity sacrifices to see the content.

There's one exception: The Atari 2600 is the console that really needs adapative refresh. That's the only one.
We apologise for the inconvenience
paulb_nl
Posts: 340
Joined: Sat Feb 20, 2016 5:05 pm

Re: OSSC (DIY video digitizer & scandoubler)

Post by paulb_nl »

Xyga wrote:Yet almost every display on earth is limited to exactly the same that's stored in the EDID (save for 480)
Most TVs yes but monitors seem to be very compatible with the OSSC output are they not?

My Samsung SyncMaster 2494HM supports everything the OSSC throws at it. I guess it lives up to its name. :D
User avatar
Xyga
Posts: 7181
Joined: Tue Nov 05, 2013 8:22 pm
Location: block

Re: OSSC (DIY video digitizer & scandoubler)

Post by Xyga »

@orange808: with VRR the display's refresh itself may not change but at least you're playing the game at its correct speed and smoothly, it's no accelerated nor choppy-stuttery and laggy conversion, which is horrendous for so many games and we've endured for like two decades in emulators on our flat panels ... but sacrificing the clarity ? you don't, it's the same as before (you just aren't satisfied with 60hz sample and hold but it's not the game's fault)
Because it doesn't allow combining with anti-motion-blur features yet doesn't mean you make a 'sacrifice'.
Anyway what blur reduction doesn't have serious drawbacks yet? none, or nothing really fit for retrogaming, we've discussed that so many times.
So I don't get the criticism against VRR and similar, for emulation at the very least it's better than any other thing available to improve the ever-difficult retro experience on flat panels. In any case I'm not in the camp of sacrificing accuracy for the sake of other experience improvement features.
And if you don't like the principle of VRR, try a ViewSonic :P :mrgreen:

PS: you know we can just build a belt/band-like thing rotating around the display, speed adjustable with a potentiometer and there: physical adjustable blur reduction. :p
Could probably shove an arduino and write something to sync it to MAME instead of adjusting manually.
paulb_nl wrote:Most TVs yes but monitors seem to be very compatible with the OSSC output are they not?

My Samsung SyncMaster 2494HM supports everything the OSSC throws at it. I guess it lives up to its name. :D
I wasn't thinking exclusively of the OSSC case but in general, like so few modes open and purposedly made tight/narrow-tolerance JUST BECAUSE. :evil:
(nb: older monitors seemed more open/tolerant compared to more modern products)

As for monitors, yes and no, you know you'll find more that can do 3x with alot of sources, maybe but 4x too, then TVs... but 5x, and especially 5x 1:1, are not at all a given.
No signal, forced letterboxing you can't disable, or forced scaling, out of - iirc - 3 tvs and 5 or 6 monitors I've tied the OSSC on, only the VX3211-mh ended up supporting everything. All were Full-HD save a 1200p.
Nothing's written. NUTHIN :x :mrgreen:
Strikers1945guy wrote:"Do we....eat chicken balls?!"
User avatar
NormalFish
Posts: 282
Joined: Tue May 26, 2015 3:35 pm

Re: OSSC (DIY video digitizer & scandoubler)

Post by NormalFish »

As far as monitors go, my old TN 1080p60 ASUS handles literally everything i can throw at it via the OSSC (and anything else), while my new MSI Optix VA 1080p144 is much more picky. Seems like it might come down to certain manufacturers/panels since afaik basically every ASUS panel takes everything.
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: OSSC (DIY video digitizer & scandoubler)

Post by marqs »

paulb_nl wrote:With a device like the OSSC a framebuffer is required to use VRR/Adaptive sync. Adaptive sync works by having a fixed pixel clock and instead varying blanking time.

As an example a display that supports adaptive sync up to 120Hz will need a 120Hz pixel clock and display every frame in 8ms and then wait for the next frame. If you let the display wait for 8 ms you get 60Hz. So in this case the OSSC would have to buffer around half a frame before it can output that to the display. This is also what current 120Hz displays do internally with 60Hz content.
A number of displays have selectable ranges (e.g. 35-90Hz and 56-144Hz on my FS2735), so using the lowest range could help keeping buffering at minimum. About 120Hz displays frame-doubling 60Hz content, are you referring to TVs? I think most monitors should be able to output 60Hz regardless of their native/highest refresh rate. I'm not that sure about TVs, but enabling BFI (which forces 120Hz output) on some models bumps latency by 8ms which indicates non-BFI mode outputs at 60Hz (or alternatively a dumb BFI implementation).
Xyga wrote:Because it doesn't allow combining with anti-motion-blur features yet doesn't mean you make a 'sacrifice'.
Anyway what blur reduction doesn't have serious drawbacks yet? none, or nothing really fit for retrogaming, we've discussed that so many times.
It's a sacrifice for people used to be playing on a CRT - not being able to take advantage of features inherently incompatible with VRR that could bring motion clarity to near CRT-level. It's indeed sad that most common implementations like BFI or single screenwide strobe have their drawbacks, but in theory there's nothing preventing CRT-like scanning on a flat panel as long as there's enough brightness to pump temporarily on a set of pixels/area (which shouldn't be an issue for HDR models).
User avatar
BazookaBen
Posts: 2077
Joined: Thu Apr 17, 2008 8:09 pm
Location: North Carolina

Re: OSSC (DIY video digitizer & scandoubler)

Post by BazookaBen »

Are there any monitors or TV's that can actually strobe at 60hz though? I think most strobe at 120hz, while some monitors can go down to 80hz
User avatar
orange808
Posts: 3196
Joined: Sat Aug 20, 2016 5:43 am

Re: OSSC (DIY video digitizer & scandoubler)

Post by orange808 »

BazookaBen wrote:Are there any monitors or TV's that can actually strobe at 60hz though? I think most strobe at 120hz, while some monitors can go down to 80hz
The BenQ/Zowie xl2720 does it. The 2420g does it as well.
We apologise for the inconvenience
User avatar
Xyga
Posts: 7181
Joined: Tue Nov 05, 2013 8:22 pm
Location: block

Re: OSSC (DIY video digitizer & scandoubler)

Post by Xyga »

Well I grew up playing on CRTs and still do, like most I've added some flat panels around 2007~10 and kept renewing them, got into the video processors thing too (oh inevitability...)
But also emulation, following closely, and in that field it's always been a hunt for a 'better' that had two meanings for two groups with diferent expectations.
Originally the ones seeking better accuracy were the majority, today it's the 'enhancers' largely leaning towards retroarch features and not giving a damn nor really understanding what difference it makes to have the games play as they should timings and delay-wise.
They eliminate even the delay the games originally feature, play with tearing, or force even games like MK or R-Type to play at fixed accelerated frates for benefiting blur reduction features. And, vanilla MAME users have been playing for 20 years with the same old crappy and laggy three options, vsync, triplebuffer, and the broken syncrefresh. Really, emulation with clunky and lossy options is the most common, but not my thing.
My point's simple, with games that are really close to 60Hz originally in many cases it's no big deal to force a fixed sync rate and benefit of some features, but for tons of games/sources that aren't - and theres damn tons of hardwares clocking near 54, 55, 56, 57, 58 - all sorts of things go wrong and it's not worth sacrificing 'playing right' for 'playing comfortable'.

We've seen that everything is possible, we could have both 'right' and 'smooth' on a flat panel, there's more than one proposed evolution of existing techs or innovations,
but where I'm presistently being a bitch with people is that I always put them before: here's our options, what we can actually have and use, not speculative whatvever, and here are the effects in practice in X or Y case scenario...
We have the possibility to play games at correct rates, correct delay, correct timings overall as far as our hard and soft configurations allow, but it's possible, whether on CRT or LCD.
This requires either buying CRTs, flat panels with the required compatibilities and tolerances we need, buying either proper GPU and display for freesync/gsync, or actually learn to use GroovyMAME w/ Emudriver and the stuff going on with it.
It's accessible, available, it works.
Yet since I've been into all this stuff, I have seen a lot of people complain emulation, flat panels scalers etc suck, then when the better working solutions finally appeared one after the other, it's like only 1 in 20 if not less actually put effort into experiencing them.
In place the flashier yet not fully-working and not without drawbacks solutions (eliminate even the legit delay, bandaids instead of acquiring appropriate hardware, expect emulators and stuff will do magic and disregard/ignore the nasty effect that represent a against accuracy you have to pay for using some still-'lossy' features) etc.

I mean in short what a waste of time, also a waste of all the efforts people have put into developing and designing devices and software or even share on forums, if at the end the right stuff we waited so long for is ignored and it's the lossy/incomplete solutions that are popular.
Personally I'll adopt the potential superior solutions when they become real and commonly available, and don't actually sacrifice accuracy.

To conclude with another redundancy for the sake of being clear: I was finding a bit incredible that the actually correct working things would be considered sacrifice in place of the incorrect ones /still with issues. Such an unfair reversal.
I like the OSSC like many do because it does what it does right. Concern of some reading about a frame buffer or such, that this original OSSC quality would be diminished, shows that I'm not the only one to value reliable and untainted perormance/results, some improvements as good as they sound aren't worth is they degrade the original noticeably, and better motion's no exception, currently our options in that area aren't satisfying-enough.

Time to stop that monotonous rant because the TL;DR gauge is reaching max level. :P
Last edited by Xyga on Wed May 01, 2019 10:44 pm, edited 2 times in total.
Strikers1945guy wrote:"Do we....eat chicken balls?!"
paulb_nl
Posts: 340
Joined: Sat Feb 20, 2016 5:05 pm

Re: OSSC (DIY video digitizer & scandoubler)

Post by paulb_nl »

marqs wrote: About 120Hz displays frame-doubling 60Hz content, are you referring to TVs? I think most monitors should be able to output 60Hz regardless of their native/highest refresh rate. .
Yea I was thinking about those TVs that have higher latency at the top than the bottom as you also described at the OSSC latency tester wiki. Indeed monitors should be able to output at 60Hz regardless of their max refresh rate.
User avatar
orange808
Posts: 3196
Joined: Sat Aug 20, 2016 5:43 am

Re: OSSC (DIY video digitizer & scandoubler)

Post by orange808 »

Requiring variable refresh to display a source with a fixed refresh rate isn't "correct".

Furthermore, VRR doesn't support CRTs. You literally can't get proper tear free SNES emulation on a CRT if you simply install Retroarch and start a game with an off the shelf Displayport to RGBHV dongle.

That's a sacrifice. It's not right or correct. When a game, that was designed and originally played on CRTs, won't work on a CRT display, you know something is wrong. :)

Using variable refresh to force compatibility with a fixed refresh source is a hack and a workaround. It's an option I would like to see, but I know it's actually a bullshit embarrassing hack.
We apologise for the inconvenience
User avatar
BazookaBen
Posts: 2077
Joined: Thu Apr 17, 2008 8:09 pm
Location: North Carolina

Re: OSSC (DIY video digitizer & scandoubler)

Post by BazookaBen »

orange808 wrote:Using variable refresh to force compatibility with a fixed refresh source is a hack and a workaround. It's an option I would like to see, but I know it's actually a bullshit embarrassing hack.
The reality though is that, for whatever reason, input lag is like 1/2 or even 1/3 in Freesync mode on Samsung's 2018 Quantum Dot TV's compared to their standard Game Mode. I imagine that's because minimal image processing is necessary to be compatible with VRR. I hope TV companies start to bring their standard "game mode" down to those levels, but they haven't in the past 15 years so I'm not sure they'll start now.
User avatar
Xyga
Posts: 7181
Joined: Tue Nov 05, 2013 8:22 pm
Location: block

Re: OSSC (DIY video digitizer & scandoubler)

Post by Xyga »

orange808 wrote:Requiring variable refresh to display a source with a fixed refresh rate isn't "correct".
It's not but what matters is that the game plays at the correct speed and smoothly and without tearing nor added lag.
That the screen itself still refreshes at 60z instead of like the 56 of the game running behind doesn't matter here, the result you get in practice is that your' playing in much more accurate conditions than with any alternative like forced sync to 60 or triple buffering, or nosync/tearing.
And again you can have a flat panel supporting all the original refresh rates natively like the ViewSonic case, do you know what difference it makes vs a VRR setup in practice? none.
orange808 wrote:Furthermore, VRR doesn't support CRTs.
Of course not, dunno where that came from (?)
orange808 wrote:You literally can't get proper tear free SNES emulation on a CRT if you simply install Retroarch and start a game with an off the shelf Displayport to RGBHV dongle.

That's a sacrifice. It's not right or correct. When a game, that was designed and originally played on CRTs, won't work on a CRT display, you know something is wrong. :)

Using variable refresh to force compatibility with a fixed refresh source is a hack and a workaround. It's an option I would like to see, but I know it's actually a bullshit embarrassing hack.
Wait wait wait, what? What is that crazy story you're telling here, sorry but why would you do that? if you want correct SNES emulation over a CRT w/out issues use a PC with an AMD gpu and CRT_Emudriver or someting like that. Actually I get that even on my ViewSonic lcd.
Maybe retroarch is a problem there, dunno, I don't use it and wouldn't consider it for a CRT anyway.
I can't picture what you have in mind nor what's your problem with VRR, it's not always perfect but as long as the output is playing correctly without nasty drawbacks why do you care how it works in the background to achieve that?
And if you want correct emulation on a CRT you need to prepare a setup that can do it, and it's got nothing to do with VRR.


@BazookaBen: lag varies with different models of displays featuring freesync or gsync, some work without adding any, some do, dunno the reason.
Strikers1945guy wrote:"Do we....eat chicken balls?!"
User avatar
orange808
Posts: 3196
Joined: Sat Aug 20, 2016 5:43 am

Re: OSSC (DIY video digitizer & scandoubler)

Post by orange808 »

The difference in practice is incompatibility with some displays and no options to battle persistence blur.

Furthermore, it's like using beach toy shovel and pail to eat my morning cereal. You can do it, but it's ridiculous.

My preference is natively outputting the right refresh from the beginning. If it doesn't work for some people, those people should buy a better display.
We apologise for the inconvenience
User avatar
Hoagtech
Posts: 939
Joined: Mon Apr 27, 2015 3:53 am
Location: Bellingham, WA

Re: OSSC (DIY video digitizer & scandoubler)

Post by Hoagtech »

I am having an issue with wavy lines at the top of my Taito F3 though OSSC.

Is there a setting to fix the sync?

It goes away when I connect to my LCD directly.

Image Image Image
Copyright 1987
User avatar
Fudoh
Posts: 13015
Joined: Mon Mar 06, 2006 3:29 am
Location: Germany
Contact:

Re: OSSC (DIY video digitizer & scandoubler)

Post by Fudoh »

The wiki mentions the Vsync threshold in regard to the F3 arcade boards. I don't have one, so I can't test it....
Powerman293
Posts: 5
Joined: Mon May 06, 2019 6:33 am

Re: OSSC (DIY video digitizer & scandoubler)

Post by Powerman293 »

Hey guys, I'm new here.

Anyways, I was wondering what secondary video processors work great with the highest res modes for the main resolutions (Line 5x for 240p and 4x for 480i and 2x for 480p)? I know the DVDOs have been recommended in the past, but those were before the line 5x update.
Powerman293
Posts: 5
Joined: Mon May 06, 2019 6:33 am

Re: OSSC (DIY video digitizer & scandoubler)

Post by Powerman293 »

With the highest possible output modes, what's the best secondary processor to use with something like Line 5x mode?
User avatar
Hoagtech
Posts: 939
Joined: Mon Apr 27, 2015 3:53 am
Location: Bellingham, WA

Re: OSSC (DIY video digitizer & scandoubler)

Post by Hoagtech »

Fudoh wrote:The wiki mentions the Vsync threshold in regard to the F3 arcade boards. I don't have one, so I can't test it....
Well thanks for suggesting. It didn't change the curvy.

Also this board only works on 4x 240p on OSSC on XC only for some reason and will not display on my LCD through OSSC unless it is connected directly with component.
Copyright 1987
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: OSSC (DIY video digitizer & scandoubler)

Post by marqs »

Hoagtech wrote:
Fudoh wrote:The wiki mentions the Vsync threshold in regard to the F3 arcade boards. I don't have one, so I can't test it....
Well thanks for suggesting. It didn't change the curvy.

Also this board only works on 4x 240p on OSSC on XC only for some reason and will not display on my LCD through OSSC unless it is connected directly with component.
F3 is a bit problematic for the digitizer chip due to the anomalities in sync. You might be able to get it stable by setting H-PLL pre and post coast to 4, but the only certain method is to additionally use AV3 (RGBS) input as mentioned in the wiki.
User avatar
Hoagtech
Posts: 939
Joined: Mon Apr 27, 2015 3:53 am
Location: Bellingham, WA

Re: OSSC (DIY video digitizer & scandoubler)

Post by Hoagtech »

marqs wrote:
Hoagtech wrote:
Fudoh wrote:The wiki mentions the Vsync threshold in regard to the F3 arcade boards. I don't have one, so I can't test it....
Well thanks for suggesting. It didn't change the curvy.

Also this board only works on 4x 240p on OSSC on XC only for some reason and will not display on my LCD through OSSC unless it is connected directly with component.
F3 is a bit problematic for the digitizer chip due to the anomalities in sync. You might be able to get it stable by setting H-PLL pre and post coast to 4, but the only certain method is to additionally use AV3 (RGBS) input as mentioned in the wiki.
Thanks marqs the coast settings fixed the image but caused a couple bouncing lines to generate below the center of the which wobbles the picture left and right.

It's hard to tell from the image but the "T" on insert coin and the spaceship is shifted off its alignment.

I am using component so I cant to my knowledge use AV3 unless there is a Component to dsub 15 interface changer that would allow me to.

I don't have an RGB cord for the gun, but there is an 8 pin mini din connector for RGB out.

Is there a way to buy a 8 pin to Dsub or would I need to fabricate that?

Image
Copyright 1987
User avatar
Fudoh
Posts: 13015
Joined: Mon Mar 06, 2006 3:29 am
Location: Germany
Contact:

Re: OSSC (DIY video digitizer & scandoubler)

Post by Fudoh »

I am using component so I cant to my knowledge use AV3 unless there is a Component to dsub 15 interface changer that would allow me to.
something like this? https://www.ebay.co.uk/itm/232837060229 (UK) or https://www.ebay.com/itm/310799037608 (US)
User avatar
Hoagtech
Posts: 939
Joined: Mon Apr 27, 2015 3:53 am
Location: Bellingham, WA

Re: OSSC (DIY video digitizer & scandoubler)

Post by Hoagtech »

Fudoh wrote:
I am using component so I cant to my knowledge use AV3 unless there is a Component to dsub 15 interface changer that would allow me to.
something like this? https://www.ebay.co.uk/itm/232837060229 (UK) or https://www.ebay.com/itm/310799037608 (US)
I bought it but I don't know if meets the csync on pin 13 requirement.

this was stated in the wiki: TTL-level csync to pin 13 of DE-15 connector

This went downhill fast. I reset games and got the scrambled flashing image and the my screen lost sync entirely (blue screen) and will not play any consoles either.

I didn't think I would need the reset wire mod for the multi.
Copyright 1987
Post Reply