OSSC v1.xx series beta firmware

[agnosticNinja]

Hi @marqs, I am wondering if there is any need for me to mod my OSSC rev. 1.6 to install the latest firmware 1.xx. It might be risky, and I don’t want to solder without a strong reason. The main motivation is to minimize the number of converters and make an ultimate device that supports both game consoles and a VCR player. I know that OSSC is not too good when it comes to VCR compatibility, but maybe some sync bugs were addressed and fixed in 1.xx (as I read in what has changed).

An old thread about VCR compatibility: https://videogameperfection.com/forums/topic/vcr-compatibility/

So far, I have 2 significant issues:

1) OSSC loses sync and drops audio/video frequently when getting input from the VCR. If newer firmware has some solution, it’s nice to know.

2) VCR has European SCART output, but not RGB, so I use a SCART to S-video/RCAs adapter and an OSSC add-on board like this to get a proper signal: https://videogameperfection.com/forums/topic/ossc-av-s-video-transcoder-add-on-worthy-upgrade-or-scam/. Since it’s a popular solution, maybe someone else had the same issue. Unfortunately, the colors of S-video output are not bright enough compared to CVBS (which shouldn’t be the case, I expected to see an image with better quality). Is it an issue with the add-on board itself or something related to Lumacode, which can be accessed only in 1.xx firmware? I’ll try to connect the add-on board with OSSC using component cables, not SCART, maybe it will help.

Thank you in advance.

Update: I tried my setup on RetroScaler2x, it has similar issues with sync, but at least getting the image from S-video works properly, and the colors are correct. If OSSC is still not compatible with VCRs, I’ll leave it as it is (so far I am happy with 1.6 and 0.90 firmware features) and will have to deal with an additional S-video to HDMI converter for VCR.

• This reply was modified 3 months, 2 weeks ago by agnosticNinja.
• This reply was modified 3 months, 2 weeks ago by agnosticNinja.
• This reply was modified 3 months, 2 weeks ago by agnosticNinja.
• This reply was modified 3 months, 2 weeks ago by agnosticNinja.

[Morpheus_79]

Afaik the video output of almost all VCRs has a very (VERY!) unstable sync signal. CRT TVs can cope with it easily – but it’s a big problem for all ADCs. It’s a technical issue and a result of the way VCRs work. There are minimal speed fluctuations for the motor… worn VHS tapes are more stretched in the areas that have been watched more frequently -> all this causes an unstable sync signal, which gets even worse for Longplay-Recordings.

I remember the later days of VHS-Capturing: there were recommendations for using VHS/DVR combo player/recorder, because some had an integrated TBC:

https://en.wikipedia.org/wiki/Time_base_correction

For VHS without a TBC it’s kind of a gamble on how stable the digital output from an ADC looks: it may be okay for one tape… but with another tape you have lots of flickering caused by lost sync.

[polipyc]

Hey, quick question. I love the addition of shadow masks to the firmware. I noticed there are a lot of unused remote buttons. Would it be possible to code a quick on/off toggle for shadow masks?

[kosekmi]

In general shadow masks are used to simulate various CRT structures and there are built-in presets for different CRTs (and next fw will support importing custom presets like these).

Looking forward to this feature! Any chance Shadow mask strength will also make it?

Edit: if this is any indication it probably will 🙂 how stable is the branch? I’d like to try it, but never compiled OSSC firmware before.

• This reply was modified 3 months ago by kosekmi.
• This reply was modified 3 months ago by kosekmi.

[marqs]

Hey, quick question. I love the addition of shadow masks to the firmware. I noticed there are a lot of unused remote buttons. Would it be possible to code a quick on/off toggle for shadow masks?

I suppose shmask selection and strength could be mapped to rev/fwd and vol+/-, respectively.

Edit: if this is any indication it probably will 🙂 how stable is the branch? I’d like to try it, but never compiled OSSC firmware before.

It’s relatively stable but documentation on compilation is not up to date. The dev branches are recommended only to people who have USB Blaster in case something goes wrong.

[kosekmi]

Thanks, I’ll wait for the release then. Nice idea putting shmask options on the remote!

[marqs]

The next major firmware release, 1.20, is now ready for beta testing. It brings several UI/usability features from OSSC Pro and restores features left out during v1.xx transition. Due to major changes underneath with potentially resulting compatibility issues (especially with HW versions/variants where I’ve not been involved with), the firmware will be initially offered only as USB Blaster programmable file (link). Once it’s proven that bricking is not a concern, an usual image will be released. Below is a list of user-visible updates:

* 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
* 480p/576p pillarbox option (for widescreen displays without AR control)
* freed up RAM for future use, e.g. for implementing 2 additional line buffers to enable linear interpolation horizontally

[polipyc]

Woah… I just wanted to appreciate how cool is this new changelog. Unfortunately I cannot test it due to not having usb blaster (who knows maybe I’ll grab cheap one from aliexpress). Anyway having new features and still free ram for future ones is wild. Thanks!

[ardarvin]

Sorry if this has been answered already, but I did the mod to my 1.6 board — when I upload the 1.12 firmware i get the test screen, but I just get a black screen when I switch to my input source (SNES through SCART). I used the only Line2x Output in case my screen couldn’t handle the new options. When I go back to FW 0.9 everything works as normal.  Maybe I messed up the mod? Looks pretty cleanly soldered to me.

UPDATE: Turns out I’m terrible at instructions and soldered to the wrong pin. In case this helps someone here’s a photo showing both sides in the same picture. Also, I used 30 gauge wrapping wire — nice and neat.

• This reply was modified 1 week, 6 days ago by ardarvin.
• This reply was modified 1 week, 6 days ago by ardarvin.

[MaRC]

I flashed my OSSC 1.7, which was converted to 1.8, and it seems to be working fine. I like the new built-in shadow masks, especially the JVC ones.

[Frucoboti]

Hi everyone,

I’ve been testing my Commodore 64 (PAL) connected through my OSSC, using the Lumacode mod output into AV2, and I’ve noticed something strange.

When I set the OSSC to Line5x (240p/288p) mode, I get a pixel-perfect and beautifully stable image, but there’s no audio output on my TV (a Samsung QN95B).

If I switch back to Line2x, audio works perfectly — same cables, same inputs, same setup — so the issue only appears in 5x mode.

I’m running the latest stable firmware, and I’ve also tried rolling back to a previous version, but the result is exactly the same — great picture, no sound.

Not sure if this could be related to how the TV handles HDMI audio when Line5x mode is active, or maybe something specific to the QN95B.

Any ideas or suggestions on how to troubleshoot this would be greatly appreciated.

Thanks!

[Zacabeb]

It’s likely that the TV sees the 5x signal as an arbitrary PC resolution and assumes it to be a DVI source with no audio. While audio can be transmitted in data islands over DVI the same way as in HDMI (they are after all based on the same protocol with different physical interfaces,) there is no formal standardization. So, whether a display accepts embedded audio with non-TV resolutions depends on the manufacturer and SoC used.

In 2x mode, the signal is close enough to regular 480p TV resolution to be accepted as such.

[marqs]

The same issue has been reported by multiple people but I’m not able to reproduce it on my setup. Maybe someone could generate a matching modeline (see below) from PC HDMI and check if that is able to produce sound when connected to the same monitor.

Modeline “C64PAL_lc_x5” 157.50 1920 1968 1992 2016 1080 1280 1295 1560 -hsync -vsync

[Frucoboti]

I have recorded a video when I can reproduce the issue. When H. Samplerate is 504.00 there is no sound, when playing an intro with music. If I go for 507.00 the sound appears. Then down again to something lower, 506, 505, 504.. the sound stops.
In my setup 504.00 is the right value, and sampling phase around 202 deg.

I have uploaded the video to retransfer, here: https://we.tl/t-p7pJiBBaz6

[xepher573]

marqs, I’ve been wondering about this for a while now: would it be possible to take a regular OSSC 1.8, desolder the RAM, add a similar RAM module but with higher capacity and rework the firmware to accept features such as motion adaptive deinterlacing? even if only at say, 2x

[Author]

Posts