DAC output problem [solved]

[Stef]

Hi

I've been rewritting my simple PCM Z80 driver.
Now it plays signed 8 bits sample (unlike my previous version which was using unsigned) and it's more stable with the output rate.
It support panning and output rate from 8 Khz up to 32 Khz.

I got it perfectly working in all emulators i tested (Fusion, Regen, Gens...) but for some obscures reasons it doesn't work as expected on real hardware.
It's not due to the "busy" flag, i made some tests and this didn't made any changes.

So what i got on real hardware is very very quiet sound : i can barely heard the sample but at a very low level.
If i made a record of the output and highly amplify it i obtain a very noisy sound but we can recognize the played song.

How can we obtain that sort of result O_o ????
It sounds like i was sending 2 bits data instead of 8 bits one...

I could post the code but i don't think someone would spent time in understand it and trying to figure what is going wrong here.
All my others drivers are working correctly and i don't see anything strange in what i'm doing with this one...
So to start with an idea, did someone already experienced that very weird thing (very quiet DAC output) or something similar ?

Thanks for any help, i'm quite of a bit desperate

[Chilly Willy]

Does it sound louder at lower rates on real hardware? Perhaps over a certain rate on real hardware, you get "out of sync" with the output stage of the YM2612 and that causes the low volume and noise.

I noticed on my own PCM drivers that 22kHz audio sounds quieter than 11kHz, which sounds quieter than 8kHz.

[TmEE co.(TM)]

This something I have not encountered myself... It would be very interesting to debug it if I had time

[Eke]

Could you post a test ROM ? I also suspect this is a timing issue.

[Stef]

Does it sound louder at lower rates on real hardware? Perhaps over a certain rate on real hardware, you get "out of sync" with the output stage of the YM2612 and that causes the low volume and noise.

I noticed on my own PCM drivers that 22kHz audio sounds quieter than 11kHz, which sounds quieter than 8kHz.

Afaik no, i tried with all possible driver output rate (8 Khz, 11 Khz, 16 Khz, 22 Khz or 32 Khz) and it sound always as quiet.

Could you post a test ROM ? I also suspect this is a timing issue.

I will post a test rom right after i am back to home.
I can also post source if that help...
I don't think it's a timing issue as i tried to add port 0 bit 7 checking before sending data to DAC but that didn't made any changes. Also the output rate is respected, only the volume is very low.

[Stef]

I directly released a new SGDK version to make stuff available :
http://code.google.com/p/sgdk/downloads/list

You can grab source of the faultly driver in
src/z80_drv1.s80

and the test rom is available in
sample/sound/out/rom.bin

If someone is interested...

[Chilly Willy]

Err - the sample rom doesn't work on real hardware. I'm testing on a CDX with a NeoMyth. I get a partial display compared to Gens/GS - I get < > and below it part of the rom header text, not the text that should show. It also doesn't respond to the joypad.

[Stef]

Err - the sample rom doesn't work on real hardware. I'm testing on a CDX with a NeoMyth. I get a partial display compared to Gens/GS - I get < > and below it part of the rom header text, not the text that should show. It also doesn't respond to the joypad.

O_o ??? i'm just testing it on my Sega CDX (bios v2.21) with an everdrive and it worked nicely except the DAC problem i'm experiencing... unfortunately i can't test with my usual MD1 as my shitty LCD doesn't accept the MD1 video signal.

[Chilly Willy]

Err - the sample rom doesn't work on real hardware. I'm testing on a CDX with a NeoMyth. I get a partial display compared to Gens/GS - I get < > and below it part of the rom header text, not the text that should show. It also doesn't respond to the joypad.

O_o ??? i'm just testing it on my Sega CDX (bios v2.21) with an everdrive and it worked nicely except the DAC problem i'm experiencing... unfortunately i can't test with my usual MD1 as my shitty LCD doesn't accept the MD1 video signal.

I noticed some Everdrive support in the SDK... maybe you're doing something Everdrive specific that keeps it from working on other flash cards.

Odd - it works on my Model 2/CD/32X, just not the CDX. Everything else I've tested works on the CDX. The bios is 2.21 as well. I changed the Neo Myth without change in behavior.

Works on my Nomad... so what's the difference... HA! Found it - your joystick code goes bananas when there's a mouse plugged in.

Okay, now that I can run it, let's do some checking...

[Chilly Willy]

I don't see anything in the driver, so I'm guessing it's the example... specifically line 495 of main.c:

Code: Select all

            const u16 pan = params_value[driver_ind][1]->value;

My guess is that's the index into the list of pans, not the actual pan value. So you're passing 0 to 2 instead of 0x40, 0x80, or 0xC0. So your pan is turning off the channel instead of setting the pan.

[Eke]

I've noticed that the first driver (single channel PCM) does not work in my emulator. After some investigations, I found out you were writing $B6 to FM port #2 after setting $2B as register address in port #0 and before writing PCM data into port #1 . This is done at Z80 PC= $025A.

However, according to Nemesis notes, the address register is shared:

I might share a little quirk I discovered a few days ago, while I was working through a list of random tests unrelated to the envelope generator. I was running a test to check whether parts 1 and 2 had a separate address register, IE, whether you could write one address to $A00000 and another to $A00002, then write to each data port, and have the two writes go to two different register addresses in each part. What I found was that not only do parts 1 and 2 not have a separate address register, they don't even have a separate data port.

It turns out that writing to an address register stores both the written address, and the part number of the address register you wrote to. You can then write to either the data port at $A00001, or the data port at $A00003, and the write will go to the register number you wrote, within the part of the address register you wrote to. This means you can, for example, write an address to $A00000, then write the data to $A00003, and the data will in fact be written to the part 1 register block, not the part 2 register block.

The simpler implementation would seem to be only storing the 8-bit address data that was written, and use the data port that received the write to determine which part to write to, but it isn't implemented this way. Writing to the address register stores 9 bits of data, indicating both the target register address, and the part number. I don't think any emulator does this correctly right now.

By emulating this, this breaks all PCM writes after setting address in Port 2, since they go to the wrong registers.

I didn't test your ROM on my MD2 yet but it's very likely this depends o n the chip revision if this driver works on your CDX. Or maybe Nemesis was wrong ?

[Stef]

I don't see anything in the driver, so I'm guessing it's the example... specifically line 495 of main.c:

Code: Select all

            const u16 pan = params_value[driver_ind][1]->value;

My guess is that's the index into the list of pans, not the actual pan value. So you're passing 0 to 2 instead of 0x40, 0x80, or 0xC0. So your pan is turning off the channel instead of setting the pan.

I remember it's the first stuff i tested, as i was modifying pan in this driver and not in other i tried to comment the pan section code and it didn't made any differences.

If you look into the code params_value is a [][] pointer to param_def.
So you can use it to retrieve what param is selected for a specific command (for example PAN) and for a specific driver (for example Z80_DRIVER_PCM).

As i'm testing the driver->id i could directly use params_value[1][1] instead of params_value[driver_ind][1] as driver_ind should be equal to 1 anyway here.
But then params_value[driver_ind][1]->value is equals to the value of these params :
{"center ", AUDIO_PAN_CENTER}
{"left ", AUDIO_PAN_LEFT}
{"right ", AUDIO_PAN_RIGHT}
depending the selected param so the value should be ok.

[Stef]

I've noticed that the first driver (single channel PCM) does not work in my emulator. After some investigations, I found out you were writing $B6 to FM port #2 after setting $2B as register address in port #0 and before writing PCM data into port #1 . This is done at Z80 PC= $025A.

However, according to Nemesis notes, the address register is shared:

I might share a little quirk I discovered a few days ago, while I was working through a list of random tests unrelated to the envelope generator. I was running a test to check whether parts 1 and 2 had a separate address register, IE, whether you could write one address to $A00000 and another to $A00002, then write to each data port, and have the two writes go to two different register addresses in each part. What I found was that not only do parts 1 and 2 not have a separate address register, they don't even have a separate data port.

It turns out that writing to an address register stores both the written address, and the part number of the address register you wrote to. You can then write to either the data port at $A00001, or the data port at $A00003, and the write will go to the register number you wrote, within the part of the address register you wrote to. This means you can, for example, write an address to $A00000, then write the data to $A00003, and the data will in fact be written to the part 1 register block, not the part 2 register block.

The simpler implementation would seem to be only storing the 8-bit address data that was written, and use the data port that received the write to determine which part to write to, but it isn't implemented this way. Writing to the address register stores 9 bits of data, indicating both the target register address, and the part number. I don't think any emulator does this correctly right now.

By emulating this, this breaks all PCM writes after setting address in Port 2, since they go to the wrong registers.

I didn't test your ROM on my MD2 yet but it's very likely this depends o n the chip revision if this driver works on your CDX. Or maybe Nemesis was wrong ?

I just saw your message after i wrote mine...
Well that make sense ! i remember now about this feature but totally forgot it ! I tested my rom in your emulator (Regen), i used the last D (debug) version and the driver was correctly working on it. Where can i grab your version which seems to be more advanced that mine ?

[Eke]

I'm not Regen's author, AamirM is
The emulator I'm talking about is Genesis Plux Gx which is a port of Genesis Plus on Wii/Gamecube. I made a Win32 backport that uses SDL for quick testing. You can grab it on the download page of genplus-gx googlecodebut it's very limited and sort of buggy (SDL audio go crazy if you try to grab or move the window), I don't know if it is really useful for ROM debugging

[Stef]

I'm not Regen's author, AamirM is
The emulator I'm talking about is Genesis Plux Gx which is a port of Genesis Plus on Wii/Gamecube. I made a Win32 backport that uses SDL for quick testing. You can grab it on the download page of genplus-gx googlecodebut it's very limited and sort of buggy (SDL audio go crazy if you try to grab or move the window), I don't know if it is really useful for ROM debugging

Oh sorry
I don't know why i always though you were the author of Regen. My mistake... I don't know at which point your emulator is accurate but in this particular case it would save me a lot of time It's always very difficult to fix bugs you have only on plain hardware only and not in emulators as there is very few way to do debug on hardware when emulator have almost time many debug capabilities