PCM maximum Hz

[r57shell]

I just came up with one thing. When you update backdrop palette color to same color it was, it will make glitch pixel at screen, if not during VBLANK period.
So, idea is: may be quality of PCM at high rates worse because you update output level during its propogation to output signal.

Then, I suguest to somehow sync with YM2612 cycle, and try different delays after sync.

This is just idea for tests.

[TmEE co.(TM)]

YM and Z80 run off different clocks and any kind of syncing is hard to get and near impossible to maintain, especially when you read ROM area or do uncoordinated DMA.

[r57shell]

Timer A sync with YM2612? I think so.
I think set Timer A to 3FF to make about 55555 Hz period.
Then, in loop just spin around :S.

Code: Select all

spin:
bit	0,(HL) ; spin till Timer A overflows
jp	Z,spin
<some nops>
write DAC LEVEL

[TmEE co.(TM)]

The problem with that is that you are likely not gonna hit the timer as it overflows, only some times. YM accepts address writes every 17 cycles and up data writes every 83 cycles (those are YM or 68K cycles not Z80 ones). Those waits alone make things iffy...

[r57shell]

The problem with that is that you are likely not gonna hit the timer as it overflows, only some times.

I don't need exactly, just with some precision.

YM accepts address writes every 17 cycles and up data writes every 83 cycles (those are YM or 68K cycles not Z80 ones).

Why then not to do same thing from M68k?

I don't claim that 55555 Hz PCM reachable Just, it is intersting to get MAXIMUM :]

[TmEE co.(TM)]

From my tests the maximum PCM rate is half of YM sample rate, which in case of PAL machines is 54203424 / 7 / 144 / 2 ~ 26390.59 Hz

Going past that definitely results in missed writes.

[GManiac]

I'll say more, different consoles give you different results. You can get maximum rate from 18k to 28k. To calculate the real rate you need to read from YM2612 busy flag (I don't remember exactly), check YM is not busy and only then write next sample.

[r57shell]

So, no data corruption occurs, just YM2612 rejects access?
Then, if I do something like this:

Code: Select all

  ld A,0
loop:
  inc A
  ld (HL),A
  jp loop

YM2612 I will get something like: 1,3,7,8,10,13,14,16,18,21,22... and so on?

[TmEE co.(TM)]

Data seems to be rejected on PCM writes, but in case of FM parameters, particularly TL there seems to be corruption when writes happen too fast.

[r57shell]

Tested in emulators: http://elektropage.ru/r57shell/MAXPCM.7z
Gens 17000 Hz, RetroArch 40000 Hz with sync.
Without sync, much better.
I didn't know that 64 cycle for z80 very low to check timer.
There is no interupt by timer?
Argh, bored. I'll do some tests may be later, "NOT TODAY".

[Chilly Willy]

Yes, the timer generates ints, but unfortunately the INT line doesn't connect to the Z80. Polling means you'll be a dozen or more cycles off the actual time, which isn't much compared to the sample rate, but is FOREVER compared to the FM chip cycle timing for "synchronized" access.

[Stef]

It's just impossible to perfectly sync PCM rate as it seems to vary depending the system... On my 2 MD1 (1 pal and 1 jap) PCM rate seems to accept 32 Khz (at least i can clearly heard the difference between 26 Khz and 32 Khz).
It would be nice to have a test program which actually loop in waiting for busy flag and feeding the dac then we can read number of sent sample per second and somehow estimate the accepted PCM rate on each system

[GManiac]

It would be nice to have a test program which actually loop in waiting for busy flag and feeding the dac then we can read number of sent sample per second and somehow estimate the accepted PCM rate on each system

I'd already done this program, it's somewhere on my hard disk Comparing original wav length and real output length I could easily calculate its frequency.
If you want, you can send to DAC not real wave samples, but ladder like 0 1 2 3 ... 255 0 1 2... So it will be easy to check frequency with waiting for busy flag.
And sending to DAC something like 0 0 0 0 0 0 255 0 0 0 0 0 0 without waiting for busy flag we can see if values on some frequency are really rejected or not.

[Stef]

I'd already done this program, it's somewhere on my hard disk Comparing original wav length and real output length I could easily calculate its frequency.
If you want, you can send to DAC not real wave samples, but ladder like 0 1 2 3 ... 255 0 1 2... So it will be easy to check frequency with waiting for busy flag.
And sending to DAC something like 0 0 0 0 0 0 255 0 0 0 0 0 0 without waiting for busy flag we can see if values on some frequency are really rejected or not.

How much rate you measured ? Having a rom which directly directly the sample rate on screen would be convenient for fast testing I should think about it when i will have some free time for that

[TmEE co.(TM)]

When I wait for the busy bit I get roughly 33KHz rate on my machines, but sound is garbage compared to 26KHz playback without respecting busy bit.