Menu

marqs

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 508 total)
  • Author
    Posts
  • in reply to: OSSC for PCBs #27637

    marqs
    Participant

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


    marqs
    Participant

    The strange thing is that there are no changes in audio code between 0.81 and 0.82. The problem seem to trigger only on certain boards, otherwise there would have certainly been more similar reports after 0.82 update. I noticed one issue on how audio infoframe is set but it has been there since audio support was introduced. As your audio ADC configuration was correct, I’m starting to wonder if IT6613 somehow ends up being set incorrectly. Could you download this firmware which dumps relevant register values (via INFO again) and post those here?

    in reply to: OSSC for PCBs #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.

    in reply to: OSSC for PCBs #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.

    in reply to: ossc hot during use #27536

    marqs
    Participant

    I suppose 5.15V on U7 pin 3 is typo (pin 1 and 3 are connected together), otherwise everything looks as should.

    0.4A at 5.15V is perfectly normal, so the problem might be that digitizer and FPGA bottom ground/thermal pads are not soldered properly on PCB. If that is the case, heat transfer from those chips is bad which can create hotspots and eventually cause instability when their temperature rises high enough. The way to fix that would be reflowing/resoldering the ground pads on the bottom of the ICs, but if you’ve bought from VGP, you should just RMA the board.

    in reply to: OSSC for PCBs #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.

    in reply to: Firmware version #27528

    marqs
    Participant

    Yes.

    in reply to: ossc hot during use #27477

    marqs
    Participant

    Those numbers sound OK, so assuming there is no overvoltage, the power consumption (and thus heat dissipation) of the board should be on normal range.

    in reply to: Firmware version #27474

    marqs
    Participant

    Should be 18351f8. No need to update if you haven’t had issues with the board.

    in reply to: OSSC for PCBs #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.

    in reply to: OSSC for PCBs #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.


    marqs
    Participant

    There was no changes except that debug print. It indicates that at least audio ADC has correct configuration, so the issue is elsewhere. I updated the image with increased I2C and system delays, you might want to re-download it and try if that makes a difference.


    marqs
    Participant

    Can you update to this test firmware and report the numbers displayed when you press INFO on remote?

    in reply to: Unusual OSSC issue #27435

    marqs
    Participant

    I’d double check connections of the replaced character LCD. If there is e.g. a short on I2C/SPI line then it could cause an issue like this.

    in reply to: Fine-tuning of sampling rate in optimized modes #27416

    marqs
    Participant

    The interface has been updated for upcoming fw, so samplerate will be set as XXX.YY (XXX is base and YY is fraction at 0.05 interval) and closest factor is calculated internally.

Viewing 15 posts - 1 through 15 (of 508 total)