Forum Replies Created
If you use 512×240 optim preset, horizontal multiplication with line5x is only 3x, see here.August 21, 2019 at 10:41 PM in reply to: The Return of the Bad audio quality through SCART from Genesis – OSSC 1.6 #27635
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?
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.
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.
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.
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.
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.
Should be 18351f8. No need to update if you haven’t had issues with the board.
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.
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.August 15, 2019 at 12:12 AM in reply to: The Return of the Bad audio quality through SCART from Genesis – OSSC 1.6 #27457
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.August 13, 2019 at 11:38 PM in reply to: The Return of the Bad audio quality through SCART from Genesis – OSSC 1.6 #27436
Can you update to this test firmware and report the numbers displayed when you press INFO on remote?
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.
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.