Dramatic bad DAC output quality !

[Stef]

Well, i just completed my new Z80 driver. As the Shiru's driver it's a 4 PCM channels players, the only but major difference is that it can play 8 bits PCM sample as the driver does saturation if needed. Initially i wanted a stable 16 Khz playback and to be sure to get on the hardware i used pessimist timing in cycles count. Finally the driver plays at ~18300 Hz on emulators and ~17600 Hz on hardware. I just doesn't understand how count Z80 cycles :-/ I read somewhere we should use (M cycles * 4) instead of T States based on an instructions flow (<> single instruction). This logic is just too pessimist and wrong...

Anyway, i got the driver working on emulator, cool
Then tested it on hardware, it worked on the first shoot, nice
But .... the quality is *imo*, just innaceptable ! I don't understand what happen but the playback quality can become insane depending the sample you're playing. It's very noticeable on "high level" voices !

Here's a picture where we can see what i'm sending to the DAC (top) and what i'm getting (bottom). Record has be done from the MegaCD2 audio output but honestly it was as bad than conventional MD2 ouput :-/



How it can be that different ??? the sample is not only shifted and noised, it's really distorted in severals parts ! I noticed differences can be more or less important depending the sample. As i said before "high frequency" voices are very impacted.

You can test it with this test rom.
You start playback with A button, at some point you can heard a woman voice. Try with Fusion emulator (Gens has some saturation problem) then listen on hardware (if you have the possibility to do it). I would love to have feedback from people with a modified MD (tmEE's crystal sound mod), i want to know if it improves stuff or not. Thanks
I probably sound as "naive" but i always though the bad voices quality was du to DMA during Z80 operation. I'm just realising DMA wasn't responsible, the major problem is DAC, it takes your sample and crushs it !

[Sik]

I love how accurate emulators are, I tested five of them and there was no match between them in the output at all o_O So bad I can't test on the real hardware, but I would want to see a more zoomed version of the samples, I want to make sure it isn't just that the program skips the samples between pixels and gives inaccurate waveforms hence (this happens more often than you may think).

[HardWareMan]

I read somewhere we should use (M cycles * 4) instead of T States based on an instructions flow (<> single instruction). This logic is just too pessimist and wrong...

Usually, M-cycle is 4 clocks length and memory R/W-cycle is 3 clocks (of course with 0 wait states). So, 1 byte move opcode with REG-REG will 4 clocks and REG-(HL) - 7 clocks. So, most length of opcodes you can compute by its effects step by step. Don't forget: preffix are always 4 clocks (its M-cycle before opcode - another M-cycle).
For example, RET opcode: M-cycle C9h, memory read ADRL from stack, memory read ADRH from stack. So, 4+3+3=10 clocks (with 0 wait states).

[tomaitheous]

The only thing I can think of is the response time of the YM chip for the DAC write. I've read that two fast of writes to the DAC will be ignored. Some external chips have a way of slightly delaying a processor when it writes to a port (not sure of the 68k has something similar to /RDY). It's possible that on the higher frequency writes, you're getting "misses" on misaligned writes. Dunno. Try doing a two sample square wave(a series of FF and 00) at higher frequencies and see what it looks like.

[TmEE co.(TM)]

The sample rate being lower issue is because the Z80 accesses ROM when 68K isn't and Z80 has no priority for accessing ROM... but for distortion, I'll hear it...

I'll test the ROM ASAP and tell you my results and ideas.

EDIT : That distortion is caused by one thing called leakage, value written to DAC will go silence in a short period of time... on emulator it doesn't happen that's why speech sounds better... on real HW instrument like cymbals sound a bit better because of this.

[AamirM]

Hi,

TmEE, Can you find out that period in which it goes to silence?

EDIT: BTW, Regen runs it at 17900 Hz which is pretty close.

stay safe,

AamirM

[Stef]

I love how accurate emulators are, I tested five of them and there was no match between them in the output at all o_O So bad I can't test on the real hardware, but I would want to see a more zoomed version of the samples, I want to make sure it isn't just that the program skips the samples between pixels and gives inaccurate waveforms hence (this happens more often than you may think).

Of course the difference isn't only du to pixel alignment of waveform, when you listen sample on emulator then on real hardware it's *very* noticeable !

Usually, M-cycle is 4 clocks length and memory R/W-cycle is 3 clocks (of course with 0 wait states). So, 1 byte move opcode with REG-REG will 4 clocks and REG-(HL) - 7 clocks. So, most length of opcodes you can compute by its effects step by step. Don't forget: preffix are always 4 clocks (its M-cycle before opcode - another M-cycle).
For example, RET opcode: M-cycle C9h, memory read ADRL from stack, memory read ADRH from stack. So, 4+3+3=10 clocks (with 0 wait states).

Thanks HardwareMan for yours explanations, i guess i'll have to recalculate entirely all my routine cycles :p
So the "z80-documented.pdf" document was correct about T States infos.

The only thing I can think of is the response time of the YM chip for the DAC write. I've read that two fast of writes to the DAC will be ignored. Some external chips have a way of slightly delaying a processor when it writes to a port (not sure of the 68k has something similar to /RDY). It's possible that on the higher frequency writes, you're getting "misses" on misaligned writes. Dunno. Try doing a two sample square wave(a series of FF and 00) at higher frequencies and see what it looks like.

In fact i'm writing to the YM2612 port 18000 times per second which is "theorically" far from his limit (~55000 times per second). There is a busy flag on YM2612 but i don't waste time to read it as i don't have enough free time for that. Your square sample is a good idea, nice way to see how the DAC got it.

The sample rate being lower issue is because the Z80 accesses ROM when 68K isn't and Z80 has no priority for accessing ROM... but for distortion, I'll hear it...

I'll test the ROM ASAP and tell you my results and ideas.

EDIT : That distortion is caused by one thing called leakage, value written to DAC will go silence in a short period of time... on emulator it doesn't happen that's why speech sounds better... on real HW instrument like cymbals sound a bit better because of this.

Yep i though about the 68000 BUS being sometime busy can distorde sound but not in that range ! Futhermore it looks like some particular frequencies are more impacted than others.
About your silent period after a write to the DAC, do you have more information about it ? If it's really the reason of the poor quality... weird, i'm feeling really disapointed. I always though the bad speech quality in genesis games were only due to the Z80 interruption at each frame for DMA stuff and controllers read, but it is not !

EDIT: BTW, Regen runs it at 17900 Hz which is pretty close.

When only 1 sample is played hardware is close to 17900 Hz, the more channel are played, the lower the rate is because of more wait state on 68000 BUS access. You can also notice a FPS drop (which mean the 68000 is slowed down by the multiples Z80 BUS steals).
Tested on a NTSC genesis :
No sample = 788 FPS
1 sample = 767 FPS
2 samples = 754 FPS
no tested more as my demo doesn't permit it :p

On a PAL system the FPS stays to 0 because of a bug in my library.

[Sik]

I love how accurate emulators are, I tested five of them and there was no match between them in the output at all o_O So bad I can't test on the real hardware, but I would want to see a more zoomed version of the samples, I want to make sure it isn't just that the program skips the samples between pixels and gives inaccurate waveforms hence (this happens more often than you may think).

Of course the difference isn't only du to pixel alignment of waveform, when you listen sample on emulator then on real hardware it's *very* noticeable !

Yes, except I didn't do the comparsion with the real hardware (because I can't) but between emulators, and the results were a disaster, I didn't find a single match, and I only listened, I didn't analyze the waveform...

[Stef]

I love how accurate emulators are, I tested five of them and there was no match between them in the output at all o_O So bad I can't test on the real hardware, but I would want to see a more zoomed version of the samples, I want to make sure it isn't just that the program skips the samples between pixels and gives inaccurate waveforms hence (this happens more often than you may think).

Of course the difference isn't only du to pixel alignment of waveform, when you listen sample on emulator then on real hardware it's *very* noticeable !

Yes, except I didn't do the comparsion with the real hardware (because I can't) but between emulators, and the results were a disaster, I didn't find a single match, and I only listened, I didn't analyze the waveform...

You can grab the original sample and MD2 sample here

It's pure raw sample, use 8 bits signed at 17700 Hz for PC sample (cmp_pc) and 8 bits signed at 18000 Hz for md2 one (md2_megacd).
The difference permit to have correct samples alignement as the genesis output rate was lower than expected.

[tomaitheous]

That distortion is caused by one thing called leakage, value written to DAC will go silence in a short period of time... on emulator it doesn't happen that's why speech sounds better... on real HW instrument like cymbals sound a bit better because of this.

I take it you're referring to "return to zero". The rate of decay back to zero depends on the capacitance and resistance setup. But- that only effects the "squareness" of a sample, not the peak(or initial write) which he seems to be missing in some sample areas in stef's pics.

Here's a visual of return to zero on a *really* low hz sine wave (that's also low res).


Stef: What if you use the 68k to output the sample directly to the DAC? That would eliminate the possibility that it's the z80 being stalled by the 68k(tight loops or VDP and whatnot).

Edit: I talked with Charles and he said that you need to poll the busy flag before writing to the YM's DAC or you will eventually get missed writes. Maybe someone can verify this?

[Sik]

You can grab the original sample and MD2 sample here

Now is when I want one of those sound editors working :/ (gosh, I've just noticed I have lots of drawing programs installed of all kinds and that I never use o_o').

Edit: I talked with Charles and he said that you need to poll the busy flag before writing to the YM's DAC or you will eventually get missed writes. Maybe someone can verify this?

Stupid question, is there any chance that the YM2612 registers may stop working until the status register is polled to check for the busy flag? I don't think so (otherwise Tiido's engine wouldn't work properly), but just in case.

Anyways, that waveform shouldn't hurt more than PWM. PWM waveforms are way more distorted >_>

[tomaitheous]

PWM waveforms are way more distorted >_>

PWM relies on a filter and a really fast frequency output. Some CD players supposedly use it. Both of the GBA's channels are actually PWM (even though it takes a binary value for a sample). The PWM unit outputs 1bit waveforms at 16mhz.

[HardWareMan]

I will try to explain some HW "features" of YM2612. As I told, I done some research work with analog part of YM2612 on one russian forum (wich is already dead). You can do this to, using a good oscillograph. YM2612 using time-multiplexed channel mixing. It use 6 "slots" on every cycle. It looks like this:
...(1)-(2)-(3)-(4)-(5)-(6)-(1)-(2)-(3)-(4)-(5)-(6)-(1)-(2)...
Every "(n)" (where n - number of channel) is an analog equivalent of amplitude of single channel. And "-" is gaps, wich 1/2 of Ucc of analog part. And cycle frequency is about of 20kHz. Then goes active Low Frequency filter (on operation amplifier), wich cut off all below about 18-20kHz. But big difference of amplitude between gaps and maximum channel amplitude create strong harmonic frequences, wich depend from amplitude and frequency of every channel. Now, you can imagine, what happens when you using all 6 channels with FM... By the way, becouse only 6 "slots" in output DAC of YM2612, internal "DAC" can be only replace one of FM channel number 6. "DAC" - becouse it is simple register, sets output DAC of YM2612.

I believe that engineers has an strong reason when projected YM2612 to do this terrible analog part (against of 6 separate DACs). Sorry, but now I can not put photos waveforms from oscillograph.

So, using 18kHz samplerate you get big aliasing.
BTW Becouse every channel has that small cycle duty high frequences sounds much better, then in emulators.

[TmEE co.(TM)]

here's a sample : http://www.hot.ee/tmeeco3/DACTEST.WAV

First I wrote 128 to DAC then wait in a delay looop and then write (128 and delay not in WAV) 255, and it goes to silence in about 160ms
Recorded form my MD2... I have no idea what MD1 does... I didn't check.
That small noise is VDP activity noise, there's no way to get rid of it, unless you cut PSG form the mixer (which is custom in my MD2, no filters or anything, just great sound output).

[Stef]

I will try to explain some HW "features" of YM2612. As I told, I done some research work with analog part of YM2612 on one russian forum (wich is already dead). You can do this to, using a good oscillograph. YM2612 using time-multiplexed channel mixing. It use 6 "slots" on every cycle. It looks like this:
...(1)-(2)-(3)-(4)-(5)-(6)-(1)-(2)-(3)-(4)-(5)-(6)-(1)-(2)...
Every "(n)" (where n - number of channel) is an analog equivalent of amplitude of single channel. And "-" is gaps, wich 1/2 of Ucc of analog part. And cycle frequency is about of 20kHz. Then goes active Low Frequency filter (on operation amplifier), wich cut off all below about 18-20kHz. But big difference of amplitude between gaps and maximum channel amplitude create strong harmonic frequences, wich depend from amplitude and frequency of every channel. Now, you can imagine, what happens when you using all 6 channels with FM... By the way, becouse only 6 "slots" in output DAC of YM2612, internal "DAC" can be only replace one of FM channel number 6. "DAC" - becouse it is simple register, sets output DAC of YM2612.

I believe that engineers has an strong reason when projected YM2612 to do this terrible analog part (against of 6 separate DACs). Sorry, but now I can not put photos waveforms from oscillograph.

So, using 18kHz samplerate you get big aliasing.
BTW Becouse every channel has that small cycle duty high frequences sounds much better, then in emulators.

I'm a bit septic ot maybe i doesn't understand what you mean.
You said the frequency cycle is ~20Khz, i always though it was ~55 Khz. If it's really 22 Khz then a record at 96 Khz would be revelant about the multiplexed sample. If only the DAC is active then we should obtain something like that (96 Khz) :

_____/\______/\______/\__

but i never observed that type of waveform. I'll do some tests with different samples at different rate.