OSSC for PCBs
NewHome › Forums › OSSC, OSSC Pro and DExx-vd isl › OSSC – Discussion and support › OSSC for PCBs
- This topic has 50 replies, 5 voices, and was last updated September 10, 2019 at 10:33 PM by Harrumph.
-
AuthorPosts
-
August 15, 2019 at 12:57 PM #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?
August 15, 2019 at 5:04 PM #27468Can 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).
August 15, 2019 at 5:36 PM #27469How 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?
August 15, 2019 at 7:00 PM #27471For 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.
August 15, 2019 at 7:57 PM #27472How 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?
August 15, 2019 at 10:23 PM #27473If 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.
August 16, 2019 at 7:28 PM #27488Thanks 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.
August 17, 2019 at 11:24 AM #27494Or maybe there’s a data repository of optimal settings for various PCBs? I’d be a contributor there if I can figure this out.
August 18, 2019 at 3:58 PM #27525I 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?
August 18, 2019 at 6:03 PM #27530For 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.
August 18, 2019 at 8:35 PM #27535If 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?
August 18, 2019 at 8:51 PM #27537It’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.
August 18, 2019 at 11:34 PM #27538It 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?
August 19, 2019 at 7:46 AM #27539For 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.
August 19, 2019 at 11:59 AM #27543I’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?
-
AuthorPosts
- You must be logged in to reply to this topic.