OSSC vs Uzebox Omega

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #66626
    danboid
    Participant

      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/Omega

      https://uzebox.org/wiki/Video_Modes

      • This topic was modified 9 months, 1 week ago by danboid.
      #66636
      marqs
      Participant

        Uzebox 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.

        #66638
        danboid
        Participant

          Thanks 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.

          #66656
          danboid
          Participant

            Jubatian 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.
            #66671
            marqs
            Participant

              The 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.

              #66672
              danboid
              Participant

                I 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.

                #66752
                marqs
                Participant

                  Would be interesting to know if older 0.xx firmware revisions have the same issue since they have less custom sync processing.

                  #66757
                  danboid
                  Participant

                    I 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?

                    #66758
                    marqs
                    Participant

                      Just try 0.90a. Not sure if the old sync path will work if you have v1.8 board, though.

                    Viewing 9 posts - 1 through 9 (of 9 total)
                    • You must be logged in to reply to this topic.