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.

[marqs]

There are a few upcoming notable updates on the aging OSSC Classic HW. First is a dedicated downscaler firmware, VoidScaler, by e8root which should be quite interesting for CRT owners (more details on its own thread). Second one is next major mainline firmware release, 1.20, which will bring several UI/usability features from OSSC Pro and restore some features which were left out of v1.xx series fw. Due to major changes underneath with potentially resulting compatibility issues (especially with HW versions/variants where I've not been involved with), this firmware will be initially offered only as USB Blaster programmable file. Once it's proven that bricking is not a concern, an usual image will be released. Below is a list of things to come:

* full FAT32/exFAT support
* new shadow mask and Lumacode presets
* easy load/store of profiles, custom shadow masks and Lumacode palettes on SD
* improved profile compatibility across subsequent firmwares (similar to Pro)
* restoration of DIY Latency tester and Panasonic hack features
* OSD cursor color selection
* support for alternative FW stored on internal flash
* freed up RAM for future use, e.g. for implementing 2 additional line buffers to enable linear interpolation horizontally

[bobrocks95]

There are a few upcoming notable updates on the aging OSSC Classic HW. First is a dedicated downscaler firmware, VoidScaler, by e8root which should be quite interesting for CRT owners (more details on its own thread). Second one is next major mainline firmware release, 1.20, which will bring several UI/usability features from OSSC Pro and restore some features which were left out of v1.xx series fw. Due to major changes underneath with potentially resulting compatibility issues (especially with HW versions/variants where I've not been involved with), this firmware will be initially offered only as USB Blaster programmable file. Once it's proven that bricking is not a concern, an usual image will be released. Below is a list of things to come:

* full FAT32/exFAT support
* new shadow mask and Lumacode presets
* easy load/store of profiles, custom shadow masks and Lumacode palettes on SD
* improved profile compatibility across subsequent firmwares (similar to Pro)
* restoration of DIY Latency tester and Panasonic hack features
* OSD cursor color selection
* support for alternative FW stored on internal flash
* freed up RAM for future use, e.g. for implementing 2 additional line buffers to enable linear interpolation horizontally

Oooh, Lumacode palettes? I'm guessing I could load Mike Chi's new HDR NES palette with the illegal NTSC colors included? That would be amazing to see along with digital support.

[SuperSpongo]

Thank you for still supporting this hardware!
I still have to do the small hardware modification...

[marqs]

There are a few upcoming notable updates on the aging OSSC Classic HW. First is a dedicated downscaler firmware, VoidScaler, by e8root which should be quite interesting for CRT owners (more details on its own thread). Second one is next major mainline firmware release, 1.20, which will bring several UI/usability features from OSSC Pro and restore some features which were left out of v1.xx series fw. Due to major changes underneath with potentially resulting compatibility issues (especially with HW versions/variants where I've not been involved with), this firmware will be initially offered only as USB Blaster programmable file. Once it's proven that bricking is not a concern, an usual image will be released.

The USB Blaster programmable firmware can be now downloaded here. Any feedback can be reported either here or in the VGP thread.

[marqs]

Firmware v1.20 has been now officially released with changes listed above. It is strongly recommended to back up flash contents with USB Blaster if the board doesn’t have S25FL116K0XMFI041 or IS25LP016D-JBLE flash chip (U10) which have been included in DIY kits and boards sold by VGP.

From v1.20 onwards FAT32/exFAT formatted SD cards must be used and writing firmware / profiles in RAW mode to SD is more needed or supported. This is important to keep in mind when downgrading/upgrading after v1.20 installation (which still needs to be done the traditional way when updating from an older fw).

It’s also worth noting that no profiles or settings are carried over to v1.20, but starting from this version profile forwards compatibility is significantly improved. Due to this reason all IR remote controls except L336 pre-programmed with correct keycodes stop functioning out of the box, and have to be re-bound with OSSC as detailed in wiki. The online profile tool does not currently support generation of v1.20 compatible profiles, but might be updated to do so later.

This firmware and all future releases will be available from Github releases page.

With all this, OSSC Classic fw development is also transitioning into maintenance phase from my side. In practice this means 1-2 releases a year containing bug fixes or features which are easily portable from OSSC Pro, but no new functionality exclusive to OSSC Classic. However, this new release opens up door for alternative firmwares stored alongside the main one such as VoidScaler.

[ldeveraux]

Firmware v1.20 has been now officially released with changes listed above. It is strongly recommended to back up flash contents with USB Blaster if the board doesn’t have S25FL116K0XMFI041 or IS25LP016D-JBLE flash chip (U10) which have been included in DIY kits and boards sold by VGP.

From v1.20 onwards FAT32/exFAT formatted SD cards must be used and writing firmware / profiles in RAW mode to SD is more needed or supported. This is important to keep in mind when downgrading/upgrading after v1.20 installation (which still needs to be done the traditional way when updating from an older fw).

It’s also worth noting that no profiles or settings are carried over to v1.20, but starting from this version profile forwards compatibility is significantly improved. Due to this reason all IR remote controls except L336 pre-programmed with correct keycodes stop functioning out of the box, and have to be re-bound with OSSC as detailed in wiki. The online profile tool does not currently support generation of v1.20 compatible profiles, but might be updated to do so later.

This firmware and all future releases will be available from Github releases page.

With all this, OSSC Classic fw development is also transitioning into maintenance phase from my side. In practice this means 1-2 releases a year containing bug fixes or features which are easily portable from OSSC Pro, but no new functionality exclusive to OSSC Classic. However, this new release opens up door for alternative firmwares stored alongside the main one such as VoidScaler.

Thanks for the good work for those of us who never moved on to the Pro.

[SuperSpongo]

I finally got around to doing the hardware mod and now I'm all set with being able to install latest firmware.
I installed 1.20 and everything went smoothly.

When I try to save a profile to SD card, it gives me an error with Error Code -3 (iirc). Did I miss something?

Thank you for your continued support of this awesome product! Great things ahead with the introduction of "alternative fimware loading"

[marqs]

I finally got around to doing the hardware mod and now I'm all set with being able to install latest firmware.
I installed 1.20 and everything went smoothly.

When I try to save a profile to SD card, it gives me an error with Error Code -3 (iirc). Did I miss something?

Thank you for your continued support of this awesome product! Great things ahead with the introduction of "alternative fimware loading"

Did you format the card as FAT32 or exFAT after installing the fw?

[SuperSpongo]

No, I don't think so!
That should be the problem then Thanks, I'll try this on the weekend.

EDIT: That was indeed the problem!

Still amazed that I get such good use out of it again. I just bought a Grundig 480p capable CRT TV and put it through its paces with the OSSC in 2x line doubler mode and multiplication scanlines. I love it!

Also, I just bought one of those enclosures from Aliexpress. All this really breathes new life into the machine!

Spoiler

[nightz85]

Hey, I'm trying to get a second firmware to build but I'm not sure I'm doing the right thing. I changed the create_fw_img tool to write OSS2 instead of OSSC to the header and expected that to be the only change necessary. The generated file is correct but after installing it (ossc displays the (sec) on screen when installing it) nothing happens. Am I doing the right thing? Thanks

[marqs]

Hey, I'm trying to get a second firmware to build but I'm not sure I'm doing the right thing. I changed the create_fw_img tool to write OSS2 instead of OSSC to the header and expected that to be the only change necessary. The generated file is correct but after installing it (ossc displays the (sec) on screen when installing it) nothing happens. Am I doing the right thing? Thanks

Did you start it via "Launch 2nd FW" option after install?