OSSC for PCBs

Viewing 15 posts - 1 through 15 (of 51 total)
  • Author
    Posts
  • #27467

    I have a large collection of PCBs from the 90s that I play on a 1600×1200 LCD via the HAS supergun and OSSC at 5x. I used Blazing Star on the MVS to adjust h.samplerate to 1935 and h.backporch to 138 and that’s what I’ve been using with everything.

    Can I do more to dial in the image quality?

    What settings should I be looking to change when switching between PCBs to keep image quality as high as possible?

    Is there any way to verify that 1 pixel outputted from the PCB equals 1 pixel outputted from the display?

    #27468
    nmalinoski
    Participant

      Can I do more to dial in the image quality?

      Does it look good to you now, or is there a specific problem you’re trying to solve?

      Is there any way to verify that 1 pixel outputted from the PCB equals 1 pixel outputted from the display?

      I’m not sure this makes sense. Both arcade and console games can vary in horizontal resolution, but both are (generally) designed to be displayed at 4:3, and on a CRT, which can handle that variance because CRTs are not fixed-pixel displays; so, if you assume that one pixel from the PCB should equal one pixel on a fixed-pixel display, you’re likely to see games that look too skinny (low horizontal resolution) or too wide (high horizontal resolution).

      #27469

      How funny. I edited that at the same time you posted. I’ll edit it back to the original.

      No problem in particular I’m trying to solve regarding image quality.

      You’re right, I mean 1 pixel equals 5 pixels on the LCD. Can I verify that somehow?

      #27471
      marqs
      Participant

        For pixel-perfect sampling, you’d need to investigate each PCB or system to find exact pixel clock / number of dots per line. That could be done by analyzing the HW or studying info provided in MAME sources etc. You could also try to get the samplerate correct by trial and error if you find a suitable test screen (e.g. in PCB test menu) with pixel-level grid.

        #27472

        How do I convert from pixel clock / number of dots per line to h.samplerate and h.backporch (or others)?

        How can I come up with the best number for sampling phase?

        #27473
        marqs
        Participant

          If you know dot clock and read line count and refresh rate from OSSC, you’ll get dots per line by the following formula:

          dots_per_line = dotclk/(lines*refresh_rate)

          That gives your ideal H. samplerate, backporch/active values are secondary and only affect position and/or compatibility. Optimal sampling phase depends on various things and need to be adjusted per PCB.

          Dot clock is typically video clock divided by an integer, whereas video clock is usually derived from on-board oscillator / XTAL.

          #27488

          Thanks for this info. It turns out dotclk is not so easy to find online. Is there hardware I can buy to help determine optimal samplerate and sampling phase per PCB? I’d like to nail this if I can.

          #27494

          Or maybe there’s a data repository of optimal settings for various PCBs? I’d be a contributor there if I can figure this out.

          #27525

          I found this driver for Dangun Feveron and ESP Ra.De. which I have:

          https://github.com/mamedev/mame/blob/master/src/mame/drivers/cave.cpp

          I found these lines in there:

          m_maincpu->set_clock(32_MHz_XTAL / 2);

          m_maincpu->set_clock(28_MHz_XTAL / 2);

          Is one of these the dot clock or video clock?

          #27530
          marqs
          Participant

            For 240p systems, dot clock is typically below 10MHz, so first guess would be 32MHz/4 = 8MHz. Looking at some PCB pictures (like this), Cave 68000 boards actually seem to have 16MHz and 28MHz XTALs. The same MAME source file indicates games use 320 or 384 column resolutions. Perhaps the dot clock is 7MHz (28MHz/4) with 320-column games and 8MHz with 384-column games (dots per scanline could be 426/512). The first thing would be to check line counts and Hz from both 320/384 games and then guess further. Alternatively, if you have an oscilloscope, you could measure the clock that drives video DAC if there is a dedicated one on the board.

            #27535

            If the clock on a 240p system is typically an integer under 10MHz then there can’t be too many possibilities. Maybe the fastest way to get the samplerate figured out for each PCB is to test with each of (I’m guessing) 6 or so values and I think the correct one would be obvious in optim mode most of the time even without a grid pattern onscreen. Would that work well?

            Alternatively, can I physically test the clock on most 240p PCBs if I get an oscilloscope?

            #27537
            marqs
            Participant

              It’s usually not an integer, but a divided value from an oscillator frequency (which in this case just happens to be integer). If you want to get a good starting point for guessing optimal samplerate, start by dividing game horizontal resolution (from MAME db etc.) by 0.75.

              #27538

              It turns out the samplerate for MVS is 384:

              http://www.firebrandx.com/OSSC/OSSC%20-%20Neo%20Geo%20Optimal%20Timing.txt

              But 320 / 0.75 = 426.6 so how best to get from there to 384? Would I need to test everything between 426 and 384 to find it? As I’ve fiddled with samplerate I’ve noticed that there seem to be a predictable number of steps between “good looking” values. How can I determine that number of steps so I can test fewer values?

              #27539
              marqs
              Participant

                For MVS no additional adjustments (from 384) is needed. The formula was given for systems where (horizontal) resolution is known but samplerate is not, and obviously the value provided by it is not universal like the MVS example shows.

                #27543

                I’m sorry, I don’t think I was clear. I’m using MVS as an example and trying to figure out how to get from the suggested good starting point (dividing game horizontal resolution by 0.75):

                320 / 0.75 = 426.6

                to the optimal value. As you said the optimal value for MVS is known to be 384 but if it weren’t then how best to discover that optimal value from the starting point of 426? If there’s a good method for that then I can use it to discover the optimal value for boards where it is not already known. Testing a large number of samplerate values one-by-one both higher and lower than the good starting point is rather laborious and prone to error.

                I wonder if I can somehow reduce the number of values that need to be tested. As I’ve tried to discover the best samplerate on various boards by testing one-by-one I’ve noticed that the values that look pretty good are spaced a certain distance apart from each other. Maybe I can determine that distance based on the board’s attributes so I only need to test the values that will look pretty good and then choose the best one?

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