OSSC vs Uzebox Omega
NewHome › Forums › OSSC, OSSC Pro and DExx-vd isl › OSSC – Discussion and support › OSSC vs Uzebox Omega
Tagged: Uzebox Omega sync
- This topic has 8 replies, 2 voices, and was last updated August 6, 2025 at 6:59 PM by
marqs.
-
AuthorPosts
-
July 21, 2025 at 9:00 PM #66626
I got a Mcbazel OSSC 1.7 today. It came with firmware 1.08 but I’ve updated it to v1.12. I was having the same issue I am now with the old firmware.
I’m hoping I’ll be able to get it fully working with my super obscure Uzebox Omega open source 8 bit console that uses RGB SCART.
I think I’ve tested pretty much all of the video output settings and several other options but non of them provide a stable AV signal for video mode 3 games that use
lots of sound or music.The Uzebox bootloader displays fine via OSSC and so do video mode 74 games (like Flight of a dragon, Output and Stormforce) with sound, work fine, I can run Uzemod to play Amiga mod files fine and I can also run video Mode 3 programs that barely use sound like my Uzebox Stopwatch app fine, its only mode 3 with lots of sound that don’t work
with the OSSC and the Omega eg Donkey Kong, IKD title screen etc.Most Uzebox games uze mode 3 rather than m74 unfortunately. I’ve tried using RCA audio on the Omega v1.4 which should cut out audio via the SCART but that doesn’t help with the Mode 3 OSSC sync issue.
When I have my Omega connected to my OSSC, the LCD says:
AV1_RGBS 262-p
15.73Khz 60.04Hz
Approx every 5 to 30 seconds, the green LED to the right of the LED panel turns off and the video and audio drop out for a second before the LED comes back on along with the audio and video.
This console works fine with my RGB SCART TVs as well as two other SCART to HDMI converters I’ve tried it with.
I would appreciate any tips anyone might have to try and get more
stable AV when using it with the OSSC.Thanks v.much for any advice anyone can offer!
https://uzebox.org/wiki/Video_Modes
-
This topic was modified 9 months, 1 week ago by
danboid.
July 22, 2025 at 2:01 PM #66636Uzebox video timings are SW-generated so perhaps they are not fully consistent across lines/frames, potentially causing PLL locking issues (indicated by the LED turning off). Either that or noise on the sync line. You could try adjusting “Analog Sync Vth” and/or setting “ADC PLL BW” to ultra low under sync options.
July 22, 2025 at 3:30 PM #66638Thanks for your reply Matt!
I’ve had some success with IKD by increasing the hsync tolerance from 0.92 to around 1.5 and setting ADC PLL BW to Ultra low both seemed to help IKD but I haven’t found settings that give me uninterrupted play for Donkey Kong yet.
July 23, 2025 at 4:12 PM #66656Jubatian wrote the bootloader for the Uzebox and he’s also written some of the most capable video modes for the Uzebox. He owns an OSSC and pretty much every version of the Uzebox. He had this to say:
Hi Dan,
Similar experiences here with the OSSC, usually it works, sometimes a
little intermittent, I couldn’t much see any relation with what was
running (as long as it had good signal as far as cuzebox reports).But with me there is also that my Scart cables are crap :p
Rambling ON:
There isn’t anything special with Flight of a Dragon, maybe the only
thing is that Mode 74’s pixel clock is equivalent to an NTSC C64’s
(Multicolour mode), if possibly the OSSC might be trying to figure out
some common pixel clock.Uzebox’s most common modes (Mode 3) use 6 clocks / pixel, which I think
wasn’t ever used in any 80’s machine or console. Would feel it very
unlikely to be an issue as I don’t see much point in trying to figure
out some pixel clock, but there might be a very remote possibility that
it might be less liked.(The NES is a bit bonkers, its pixels are around equivalent to 5.33
Uzebox clocks wide, and in general it just isn’t even using clocks which
would be suited for standard NTSC. Even the colorburst is wonky. Yet, it
is a thing, and the OSSC should be supporting an RGB modded NES with its
nonstandard timing)Rambling OFF.
What I could think of might be clock stability, some ATmegas like less
running with a nearly 50% overclock (driving a crystal they weren’t
designed for – here also how well the components around the oscillator
are soldered might possibly matter).No better idea, sorry!
Jubatian
-
This reply was modified 9 months, 1 week ago by
danboid.
July 25, 2025 at 10:53 AM #66671The exact source dot clock is irrelevant for stability, but line length has to be consistent due to line-locking behaviour. Can you still test it in 240p passthru mode and report if the green LED keeps turning off? If so, then there might be a mode detection problem instead of PLL locking issue.
July 25, 2025 at 12:47 PM #66672I have tried Output options -> 240p/288p proc -> Passthru as well as Output options -> Passthru mode -> 256×240 optim and Output options -> Passthru mode -> Normal and Output options -> Passthru mode -> High samplerate amongst several other output options and the green LED keeps turning off every few seconds in all cases.
August 5, 2025 at 10:02 PM #66752Would be interesting to know if older 0.xx firmware revisions have the same issue since they have less custom sync processing.
August 6, 2025 at 6:02 PM #66757I could give that a go. I have found OSSC fw versions 0.26, 0.27, 0.28 and 0.81 over at
http://www.infocult.com/m/ossc/fw/
Which version would you recommend I try? Which firmware version added the additional sync processing?
August 6, 2025 at 6:59 PM #66758Just try 0.90a. Not sure if the old sync path will work if you have v1.8 board, though.
-
This topic was modified 9 months, 1 week ago by
-
AuthorPosts
- You must be logged in to reply to this topic.
