Viewing 15 posts - 16 through 30 (of 51 total)
  • Author
  • #27550

    I think Marqs have given you most of the info already but just to add to it (and maybe clarify).

    There are a bunch of dotclocks listed here (including various arcade boards):

    Using the formula Marqs posted ( dots_per_line = dotclk/(lines*refresh_rate) ), you can easily punch in a number from the table with the total lines and v.refresh you get from the OSSC display (since you own the PCBs).
    You can probably narrow down the plausible dot clock already from following the lineage of various manufacturers (i.e. some dotclocks are more likely used than others).

    The other way he mentioned ( /0.75) is perfectly fine as a rule of thumb, but clearly MVS is an exception (and there are many others). If you check other boards using the same 6 MHz dotclock in the link, you see that Konamis GX board does follows the rule of thumb: 288/0.75 = 384.

    One additional way (as Marqs hinted at) would be to use a scope and check the total vs active video line length, and then apply the ratio to the known horizontal resolution which can surely be checked in MAME documentation (i.e. the “0.75” term gets replaced by the ratio of the active video length divided by total line length (as measured in microseconds)).


    Thanks for the link. I have a few boards I should be able to find the right samplerate for from that table. I’ll report back.

    Of course there are a lot of boards that don’t seem to fall into any of the categories in the table and it sounds like an oscilloscope is the right way to handle those. With the right scope is the clock easy to measure and will it be measurable on all boards?


    I’ve made some progress. Thanks to the dot clock info on this table:


    I was able to get Battle Garegga dialed in:

    Line5x mode 512×240 optim.
    Sampling phase 202 deg
    H. samplerate 432
    H. backporch 46
    H. synclength 41
    H. active 450
    V. backporch 18

    It’s a little low of center on the screen but I can’t get it to shift any higher. Maybe that’s how it appeared in arcades?

    Also I was finally able to nail down Espgaluda:

    Line5x mode 512×240 optim.
    Sampling phase 292 deg
    H. samplerate 640
    H. synclength 80
    H. backporch 46
    H. active 450
    V. backporch 13

    It turns out it’s a PGM board even though it’s not a cartridge so I used this line:

    68HC000FN20 – Motorola 68000 processor, clocked at 20.000MHz (PLCC68)

    from here:


    to test dividing 20MHz by a few different integers that made sense until I came up with:

    ( ( 20000000 ) / 2 ) / ( 263 × 59.34 ) = 640.76194

    To figure out the sampling phase I’ve been testing for an upper and lower boundary where the pixels will start to flicker or appear out of place, and then I average those two numbers. It actually seems to work really well.

    I’ve been using the table here:

    Fine-tuning of sampling rate in optimized modes

    and the Horizontal multiplication factors here:


    to try and optimize H. s.rate adj but so far anything but zero looks worse even if it’s closer to the calculated exact samplerate.


    Nice that you are making progress 🙂
    I suppose you made a typo for Battle Garegga, it has to be h.active 320, and 320×240 optim mode?

    Also I wonder why you set h.active of Espgaluda to 450, MAME doc says it is 448?


    Thanks for the feedback.

    I just double-checked and in Espgaluda changing h.active from 450 to 448 definitely wipes 2 lines off the top of the image.

    I tested Garegga in 320×240 optim with h.samplerate 432 and the image is completely scrambled. It looks perfect in 512×240 optim. What about the board makes you think 320×240 would be better than 512×240? I don’t have a good understanding of the difference in this context.

    6750000 / ( 263 × 59.37 ) = 432.295

    I’d like to do Raiden next. Is there a way to eliminate any of these frequencies or do I need to test with each of them:

    XTALs: 20MHz, 14.31818MHz, 12MHz
    CPUs: 2 x Sony CXQ70116P-10 (NEC V30 @ 10MHz), Z80A



    I assumed so because what you posted is an invalid mode (active > samplerate ! )
    Samplerate = active + frontporch + sync + backporch
    This relation should not be violated. I have no idea how the OSSC treats the signal with those parameters.

    The reason I guess your display does not accept the 320×240 optim, might have to do with it’s upper limit for pixelclock, or other incompatibility. For example my TV does not accept total samplerate over 2150-ish. In 5x mode this limits 320 optim mode to 430 samplerate (5×430 = 2150), and it is unstable even before that.
    However, in 512 optim mode, it’s only multiplied 3x horizontally in 5x mode, 2x in others. (See the table in optimal timing wiki page) So you will have much lower total samplerate.
    So try with lower line multiplication mode.

    Also, from the MAME documentation for toaplan2 board:
    /* video hardware */
    SCREEN(config, m_screen, SCREEN_TYPE_RASTER);
    m_screen->set_raw(27_MHz_XTAL/4, 432, 0, 320, 262, 0, 240);

    320 signifies active h.video (the others dotclock, dots per line, total lines, active lines, everything you needed 😉 )

    Edit: regarding raiden, the 14.3 and 12 mhz clocks are only for audio. The video area seems to be 256×240, so that would indicate a dotclock below 10mhz. 5 or 6.67 perhaps?


    @videogameperfectionrocks: Keep up the useful work you’re doing here!

    As you go through tuning the OSSC for your PCBs, please share (here in this thread or elsewhere) the OSSC-reported line counts and frame rates of the various boards, as well as the optimized sample rates you discover. The MAME drivers are often incomplete or imprecise when it comes to those parameters (e.g., many drivers just assume an exact 60Hz output). I’m sure these measurements will aid the community in many ways for years.


    Battle Garegga does in fact work with h.active 320 and 320×240 optim if I switch from 5x to 4x. Why is Generic 4:3 mode able to do 5x if optim mode can’t? I prefer the look of 5x in Generic 4:3 vs 4x in 320×240 optim.

    I noticed that 4x in 320×240 optim fills every single pixel on my screen. How is that possible since 320 * 4 = 1280 and 240 * 4 = 920 and my screen is 1600×1200?

    There are black bars above and below the image in 5x in Generic 4:3. Why is that happening since 320 * 5 = 1600 and 240 * 5 = 1200 and my screen is 1600×1200?

    If Espgaluda is 450×240, why do I get larger black bars above and below the image than I do on the sides in both 512×240 optim and Generic 4:3?

    BTW I’m planning to start a new thread once I have the procedure figured out and I’ll keep editing the first post there to record as many of these as I can.


    There are black bars above and below the image in 5x in Generic 4:3. Why is that happening since 320 * 5 = 1600 and 240 * 5 = 1200 and my screen is 1600×1200?

    Do you have Output Opts > Line5x Format set to 1600×1200? It defaults to 1920×1080, which results in cropping of the top and bottom of the image.

    If you still have black bars on the top and bottom, I would make sure Post Proc > Vertical Mask is set to 0.


    I have Line5x Format 1600×1200 and Vertical Mask 0 and Horizontal Mask 0. I get black bars above and below Battle Garegga (320×240) in Generic 4:3 and above and below Espgaluda (450×240) in Generic 4:3 and in 512×240 optim. Nothing looks cropped.


    Regarding black areas, Battle Garegga seems a bit of a mystery, but with Espgaluda it would be expected because MAME doc claims it’s a 224 vertical game.
    You can check this by reducing v.active to 224 (and increase v.backporch to compensate).

    The difference between x4 and x5 you described sounds like some difference in how your display scales different resolutions.

    And regarding generic 4:3, in lx5 mode this uses 2046 as default samplerate. So it is less than 320 optim in x5.
    2046 is the same as 256 optim mode at default (341*6). Actually this is a bit too wide, if you want same aspect as x3 and x4 modes, reduce samplerate to 1950.


    My monitor seems to have much lower lag when I send it 1600×1200 (native res) even when it’s set to 1:1. Because of that I should stick with 5x and it sounds like I won’t be able to use an optim mode with some boards since my monitor can’t handle a samplerate over about 2110.

    Why do even small samplerate changes greatly affect the image in optim mode but hardly at all in Generic mode? For example, in Garegga in optim mode I can’t use the correct samplerate of 432 since 432 * 5 = 2160 and my monitor stops working after about 2110, and if I lower the samplerate to something my monitor can handle it looks bad, but in Generic mode it looks great with default 2046 or 2110 or with other samplerates.

    At this point I’m planning to use 5x for low lag and Generic 4:3 mode for monitor compatibility. Should I just set the samplerate as close to the real samplerate * 5 as possible without going over 2110?

    Is there a great LCD monitor for this? I have the Dell 2007FP and I was loving it because it’s 4:3, looks fantastic (IPS panel), and is very low lag at native res, but I’m disappointed it can’t handle a samplerate over 2110.


    I do my best to explain the difference in this post:

    OSSC General Help w/Pixel Perfection

    In general, it is no use changing samplerate per game in generic mode. The image is oversampled as is. Just stick with 1950 if you want the most correct aspect ratio in x5.


    How did you come up with 1950 for samplerate on all boards in 5x and Generic mode?

    In that post you mentioned that it is no use setting sample phase in Generic mode either. Does Espgaluda look slightly better at 292 degrees than it does at default 180 degrees or am I fooling myself?

    Are there monitors out there that can handle any sample rate a ~240 lines board can throw out or are some boards never usable in optim mode at 5x? For example Espagluda would be 640 * 5 = 3200 samplerate.


    If you use 512×240 optim preset, horizontal multiplication with line5x is only 3x, see here.

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