OSSC (DIY video digitizer & scandoubler)

[KekGs]

Hello all.

Long time user of OSSC, but after a while I decided to jump onto the pure analog capture.
A while back, I pulled out the OSSC and got updated that we can mod our OSSC for a Line 6x, I did the mod and updated to latest firmware which was a success!

When I try to do Line 5x and use optimal timings I get a very distored picture, Can't remember that it was like that ever?
https://ibb.co/SR7XvSB

It's a PS2 NTSC Console running a 320x240p game (Final fantasy IX) in this case, Retrogaming Cables from UK (SCART) into the OSSC, and then from OSSC into a Magewell USB HDMI Capture.
Whenever I do a Generic 4:3, the image is "perfect" and stable, but as soon as I pick 320x240p optimal timings, I get this image.

Can someone explain this to me? I really hope I didn't mess up the mod cause it works great on my SNES with Optimal timings for 256x224.
Would love to hear what you experts have to say.
The OSSC was bought from VGP and I believe it's the 1.6 model.

Thanks!

Do you know if the capture card is supposed to support pixel clocks beyond 165MHz?

Hi Marqs

Thanks a lot for replying to my question. I don't really know those technical stuff, The capture I use is a : https://www.magewell.com/tech-specs/usb ... hdmi-gen-2

Input Features
165M HDMI receiver, max input 2048x1080 60fps 4:4:4
Custom EDID
Input RGB/YUV 4:4:4 8/10/12-bit, YUY 4:2:2 12-bit
Up to 8-channel 24-bit HDMI-embedded audio at 192kHz
HDMI interfaces: HDMI 1.4a

Process and Capture Features
Video processing pipeline up to 160M pixels/s
Capture videos up to 2048x2160, frame rates up to 120fps. Outputs include (actual capture frame rate can be limited by the USB bandwidth and internal working frequency.):
1920x1080p 23.98/24/25/29.97/30/50/59.94/60/75
1280x720p 23.98/24/25/29.97/30/50/59.94/60/100/119.88/120
720x576p25
720x480p30
Support for YUY2/UYVY/RGB24/RGB32
Support video cropping, up/down scaling, de-interlacing, aspect ratio conversion, color format conversion, frame rate conversion, flip and mirror
Up to 2-channel IEC60958 audio streams

This is the information that I see on their website..

I took a screenshot of the Magewell Capture program and this is the information I receive about the capture:

https://ibb.co/HKYSq78

I don't know if this helps you to answer your question, but if you want me to do something, just reply

Thanks once again!

[marqs]

The capture I use is a : https://www.magewell.com/tech-specs/usb ... hdmi-gen-2

Input Features
165M HDMI receiver, max input 2048x1080 60fps 4:4:4
...

This is the information that I see on their website..

I took a screenshot of the Magewell Capture program and this is the information I receive about the capture:

https://ibb.co/HKYSq78

It's specced to 165MHz and the output is slightly over it. I've bumped into some ADI HDMI receivers that seem to artificially limit their support just around the spec maximum (perhaps they use same silicon than higher-grade variants and don't want customers paying less to get full performance). The snippet from capture SW implies you're using H. samplerate of 429 while at least PS1 320col should use 426.625. Reducing samplerate also reduces output pixel clock frequency so it's worth a try.

[Obleon]

With 1440p available for 6x 240p sources. Would it be possible to add 1440p 3x 480p as well for 4:3 sources?

Technically it is possible, and perhaps 16:9 mode (2560x1440@60) as well. The HDMI transmitter is specced to 225MHz TMDS clock which is quite on par with 4:3 480p x3 while 16:9 mode would run at 'overclocked' 295MHz. For reference, the 165MHz transmitter on DE10-Nano is able to drive ~250MHz, and 300MHz transmitter in OSSC Pro reaches ~410MHz, at least in room temperature.

However, as I've mentioned in VGP forums, there's some obstables for adding any new features. My focus will on Pro on the upcoming months so I've summarized below what would need to be done in order to implement the feature if someone wants to have a try:

1. Reduction of SW image size by 1-2kB (either by tighter optimization or by removal of existing features)
2. Addition of new generic 480p sampling presets (960x480 and 1280x480) for respective Linex3 modes
3. Addition of related functionality (menu options, scanconverter configs etc.)
4. Addition of a new PLL configuration (50MHz -> 150MHz)

Is 360 x4 for 1440p gbi and 480p x3 1440p still possible?

Also thanks for the great support made an acount just to to say thank you.

[jd213]

Is there a BOM for version 1.8? I'm getting a 404 error for the one linked on the wiki and don't see it elsewhere on github:
https://github.com/marqs85/ossc_pcb/raw ... m_full.xls

Or if anyone is selling a kit, that would probably be easier.

[KekGs]

The capture I use is a : https://www.magewell.com/tech-specs/usb ... hdmi-gen-2

Input Features
165M HDMI receiver, max input 2048x1080 60fps 4:4:4
...

This is the information that I see on their website..

I took a screenshot of the Magewell Capture program and this is the information I receive about the capture:

https://ibb.co/HKYSq78

It's specced to 165MHz and the output is slightly over it. I've bumped into some ADI HDMI receivers that seem to artificially limit their support just around the spec maximum (perhaps they use same silicon than higher-grade variants and don't want customers paying less to get full performance). The snippet from capture SW implies you're using H. samplerate of 429 while at least PS1 320col should use 426.625. Reducing samplerate also reduces output pixel clock frequency so it's worth a try.

Hi again Marqs.

Thanks for replying to me and trying to help me, you are correct that PS1 games should be at 426.625. But I have also learnt during my analog captures that playing a PS1 game on a PS2 console doesn't use the same samplerate as a PS1 console, hence why we use 429 with a PS2 Console. But nonetheless, I tried setting it the value of 426, still the same output. But when I lowered it down to 419 which isn't the correct nor optimal setting, I got a picture without any janky stuff like my image, and when I bumped it up to 420, the capture went all janky once again. I swapped to 256x240 optim. , 384x240 optim. and 512x240 and the capture works flawlessly.. Shouldn't it be worse cause due to it being "higher" resolutions than 320x240 optim.?

I don't have the knowledge but if you say the output is slightly over it on the 320x240 optimal timings, then in theory it shouldn't work in the other higher resolutions but it does strangely :/
Now it's more of a curious question than actual question

Once again, thanks for help and thanks for making an awesome product.

Cheers

[NightSprinter]

Have you tried using the "h samplerate fractional" setting? I know I had to set it, to make the 256x240 optimized timings work correctly.

[marqs]

I swapped to 256x240 optim. , 384x240 optim. and 512x240 and the capture works flawlessly.. Shouldn't it be worse cause due to it being "higher" resolutions than 320x240 optim.?

I don't have the knowledge but if you say the output is slightly over it on the 320x240 optimal timings, then in theory it shouldn't work in the other higher resolutions but it does strangely :/
Now it's more of a curious question than actual question

Optimized modes have different horizontal oversampling ratios, and in this case 320col results to highest actual H.total (you can compare total scan sizes reported by your capture card). You can calculate that 419*5*263*5*59.85Hz=164.9MHz while 420 already results slighly above 165MHz pixel clock. It thus seems that the capture card has hard limit on 165MHz so should try line4x instead.

[RocketBelt]

A recent example is a tweak to reduce ADC sampling jitter which was half-accidentally found during Lumacode development. Wish that would have been available already years ago, but better late than never.

Thanks for another update.
Regarding the ‘sampling jitter on optimized modes’ fix. Does it require the hardware mod to work? Or would it be possible for a developer to backport the fix to the 0.xx firmware series for the unmodded pre-1.8 hardware versions?
I’m probably not going to mod my DVI-D board.

[marqs]

A recent example is a tweak to reduce ADC sampling jitter which was half-accidentally found during Lumacode development. Wish that would have been available already years ago, but better late than never.

Thanks for another update.
Regarding the ‘sampling jitter on optimized modes’ fix. Does it require the hardware mod to work? Or would it be possible for a developer to backport the fix to the 0.xx firmware series for the unmodded pre-1.8 hardware versions?
I’m probably not going to mod my DVI-D board.

It doesn't require any hw modification as it's just a ADC setting. Based on some recent reports increased PLL bandwidth causes compatibiliy issues with certain displays which calls for release of another fw that has an option to revert to original settings.

[jd213]

Is there a BOM for version 1.8? I'm getting a 404 error for the one linked on the wiki and don't see it elsewhere on github:
https://github.com/marqs85/ossc_pcb/raw ... m_full.xls

Found the link: https://github.com/marqs85/ossc_pcb/raw ... m_full.xls

[Serif]

I know official updates are pretty much 'done', but I'm curious if anyone is working on a firmware branch to get 3x 480p, which is feasible according to a previous post by marqs.

I get most of the attention is now towards the higher end scalers, but I find the base OSSC to be very cost effective for my needs. Getting 1440p from my Wii's 240p looks great on my set, and I run it in 4:3 mode anyway, so 3x 480p 4:3 would be sufficient. I like the idea of squeezing as much as possible from this hardware.

Thank you for all the great work on this device.

[marqs]

I know official updates are pretty much 'done', but I'm curious if anyone is working on a firmware branch to get 3x 480p, which is feasible according to a previous post by marqs.

I get most of the attention is now towards the higher end scalers, but I find the base OSSC to be very cost effective for my needs. Getting 1440p from my Wii's 240p looks great on my set, and I run it in 4:3 mode anyway, so 3x 480p 4:3 would be sufficient. I like the idea of squeezing as much as possible from this hardware.

Thank you for all the great work on this device.

The problem with 3x 480p is that it can be only done with pixel repetition due to high pixel clock frequency (3x3x27MHz = 243MHz). That means horizontal sampling will end up being 1.5x the optimal, thus only generic sampling mode is possible. I'm not sure if / how much attractiveness that'd take away of it, though.

[Serif]

I know official updates are pretty much 'done', but I'm curious if anyone is working on a firmware branch to get 3x 480p, which is feasible according to a previous post by marqs.

I get most of the attention is now towards the higher end scalers, but I find the base OSSC to be very cost effective for my needs. Getting 1440p from my Wii's 240p looks great on my set, and I run it in 4:3 mode anyway, so 3x 480p 4:3 would be sufficient. I like the idea of squeezing as much as possible from this hardware.

Thank you for all the great work on this device.

The problem with 3x 480p is that it can be only done with pixel repetition due to high pixel clock frequency (3x3x27MHz = 243MHz). That means horizontal sampling will end up being 1.5x the optimal, thus only generic sampling mode is possible. I'm not sure if / how much attractiveness that'd take away of it, though.

Thanks for the explanation, is pixel repetition how 240p 6x to 1440p was achieved? Or was that a different process?

4K sets, at least my LG CX, scale 1440p very well. The 240p 6x mode on my TV looks the best of all the modes I've tried. Feeding the scaler on my TV as high a resolution as possible seems ideal.

Thank you again for all of the work you've done on this project, even running now with firmware 1.10 and HLG HDR, 480p 2x looks fantastic.

[Serif]

Just tried the v1.11 firmware with 480p 3x and it looks great I wish the later model Wiis didn't have that 480p bug (that the bugfix doesn't correct), as it throws off the sharp image ever so slightly. Feels nice to get the most out of this scaler.

[NightSprinter]

What would be a suitable capture card (internal or external) that wouldn't be extremely-slow on resolution switching wjth the OSSC? I'd like to hook it up via either splitter or passthrough, and use a second display for live-view. Especially for my PS1, Saturn, and Commodore Amigas.

[kitty666cats]

What would be a suitable capture card (internal or external) that wouldn't be extremely-slow on resolution switching wjth the OSSC? I'd like to hook it up via either splitter or passthrough, and use a second display for live-view. Especially for my PS1, Saturn, and Commodore Amigas.

If you chain a GBS Control before the OSSC you shouldn’t get *any* dropouts on resolution switching. From there you could get a super-cheap capture card.

It’d even be easier putting GBS-C on 1080p and just using the OSSC as passthrough, since it isn’t an odd faux-1080p like the OSSC’s. It’s a 960p in a 1080p frame but with video timings a capture card should take zero issue with.

…but this is only really worth it if you already *have* an OSSC

[marqs]

Firmware 1.12 has been released:

* Extend Lumacode support to Atari GTIA & VCS (latter still untested)
* Fixed HDR infoframe repetition
* Reduced default ADC PLL BW for better display compatibility
* Added Full VSYNC bypass option for MDA cards

There will be a longer pause until next release due to required infrastructure changes (no more space left after hammering in features for past 10 years).

[NightSprinter]

What would be a suitable capture card (internal or external) that wouldn't be extremely-slow on resolution switching wjth the OSSC? I'd like to hook it up via either splitter or passthrough, and use a second display for live-view. Especially for my PS1, Saturn, and Commodore Amigas.

If you chain a GBS Control before the OSSC you shouldn’t get *any* dropouts on resolution switching. From there you could get a super-cheap capture card.

It’d even be easier putting GBS-C on 1080p and just using the OSSC as passthrough, since it isn’t an odd faux-1080p like the OSSC’s. It’s a 960p in a 1080p frame but with video timings a capture card should take zero issue with.

…but this is only really worth it if you already *have* an OSSC

I already do. Have a Kaico one with HDMI out, and an older one with DVI-D and the audio board. I asked, mostly due to owning an Amiga 2000 and 1200, Sega Saturn, PS1, and DOS machine due to those having games that switch resolutions fairly often.

[bobrocks95]

Firmware 1.12 has been released:

* Extend Lumacode support to Atari GTIA & VCS (latter still untested)
* Fixed HDR infoframe repetition
* Reduced default ADC PLL BW for better display compatibility
* Added Full VSYNC bypass option for MDA cards

There will be a longer pause until next release due to required infrastructure changes (no more space left after hammering in features for past 10 years).

Thought this was the Pro thread and was a bit surprised if the FPGA was already full!

Hoping RetroTinks can start supporting Lumacode, sounds like I might pull out my old OSSC and give NES a shot though, if that's supported now.