ay-3-8910 question
category: general [glöplog]
so on Apple II / Mockingboard AY-3-8910 I am getting glitchy audio, and it seems to be a problem with the chip itself, so I thought I'd ask here in case there are any AY-3-8910 experts lurking.
On the emulators, if you update the TONE registers, it takes effect immediately, even if the new value is lower than the old one. (the greater than is the key here)
if ( tonea_count >= tonea) { tonea_count=0; toggle_aout(); }
what I am seeing, is if you reduce the TONEA but have bad luck and the internal count is higher than the new value, instead of being reset, the counter keeps counting until it wraps around the 12-bit counter leading to a glitch in the audio. Almost as if the case was
if (tonea_count==tonea)
instead. This makes the music played sound choppy and glitchy.
Has anyone noticed this? It might be worse on Apple II because we run the AY chips at 1MHz (instead of 1.7MHz or 2MHz on the spectrum or atari) so the glitches are easier to hit and last twice as long.
On the emulators, if you update the TONE registers, it takes effect immediately, even if the new value is lower than the old one. (the greater than is the key here)
if ( tonea_count >= tonea) { tonea_count=0; toggle_aout(); }
what I am seeing, is if you reduce the TONEA but have bad luck and the internal count is higher than the new value, instead of being reset, the counter keeps counting until it wraps around the 12-bit counter leading to a glitch in the audio. Almost as if the case was
if (tonea_count==tonea)
instead. This makes the music played sound choppy and glitchy.
Has anyone noticed this? It might be worse on Apple II because we run the AY chips at 1MHz (instead of 1.7MHz or 2MHz on the spectrum or atari) so the glitches are easier to hit and last twice as long.
I suspect glithcy audio issue is probably not realted with counter reset but rather by the fact that low and high parts of tone counter registers are independent, so when you're rapidly toggling between i.e. 0x100 and 0x0FF waveform switch can occur between register updates (so i.e low byte updated, then counter is reset while high byte still contains from old value, resulting in glitch).
and yes, AY doesn't reset counter when writing to and load new value after terminal count. This does also apply to envelope generator, though it also have a waveform regiter (R13), whiting to it triggers instant counter reload and waveform change.
hope this would be helpful :)
and yes, AY doesn't reset counter when writing to and load new value after terminal count. This does also apply to envelope generator, though it also have a waveform regiter (R13), whiting to it triggers instant counter reload and waveform change.
hope this would be helpful :)
yes, this is a different (though possibly related) issue than the high/low byte issue as I see it when just writing the low 8-bits (for example $80 to $51).
I'm going to have to set up more tests to prove I'm not just imagining things. It's mostly it seems unlikely that this issue would be around for 40 years and I'd be the first to notice it.
I'm going to have to set up more tests to prove I'm not just imagining things. It's mostly it seems unlikely that this issue would be around for 40 years and I'd be the first to notice it.
Using == instead of >= would not be surprising, that's much cheaper/simpler to implement.
Writing only to the low byte might be your problem, I'd say something could be triggered only when writing the high byte of the tone register to reset the counter?
Also, Amstrad CPC has been running the AY3 at 1MHz for 35 years, so that's not your problem.
Writing only to the low byte might be your problem, I'd say something could be triggered only when writing the high byte of the tone register to reset the counter?
Also, Amstrad CPC has been running the AY3 at 1MHz for 35 years, so that's not your problem.
Quote:
Using == instead of >= would not be surprising, that's much cheaper/simpler to implement.
Writing only to the low byte might be your problem, I'd say something could be triggered only when writing the high byte of the tone register to reset the counter?
fwiw, these were my two first instincts as well.
Interesting! I guess one way to test this theory would be a routine something like this:
If the counter is using >= logic, it will reset on every iteration, so you'll get a 1KHz tone (I think?)
If the counter is using == logic, then it will only hit the reset <1% of the time; the rest of the time it'll continue counting up to 255, and you'll end up with a (slightly glitchy) 245Hz tone.
Code:
loop:
set ay register 0 to 1
wait for 16 AY clock cycles (the tone counter is updated at 1/16 of the AY clock speed, and presumably it's only being checked once per update)
set ay register 0 to 255
wait for 1000 AY clock cycles
If the counter is using >= logic, it will reset on every iteration, so you'll get a 1KHz tone (I think?)
If the counter is using == logic, then it will only hit the reset <1% of the time; the rest of the time it'll continue counting up to 255, and you'll end up with a (slightly glitchy) 245Hz tone.
after a lot of trouble I think I have figured out what was causing this. And it was in the data sheet the whole time.
The data sheet says when you write a value to the AY-3-8910 you can only hold the write signal for a max of 10,000ns (10us). On a 1MHz Apple II this is only about 10 cycles.
My code was holding it for 12 cycles for various reasons. I've modified the code to only take 8 cycles instead and now the sound is a lot better. Now to go and fix all of my demos that use this code :|
The data sheet says when you write a value to the AY-3-8910 you can only hold the write signal for a max of 10,000ns (10us). On a 1MHz Apple II this is only about 10 cycles.
My code was holding it for 12 cycles for various reasons. I've modified the code to only take 8 cycles instead and now the sound is a lot better. Now to go and fix all of my demos that use this code :|
Using == instead of >= would be very surprising, coming as a huge design mistake for a sound processor.
The AY has a lot of limitations, but not this one fortunately.
The AY has a lot of limitations, but not this one fortunately.
I was willing to call the case closed, when suddenly somebody e-mailed me to say they were seeing the same symptoms I was describing earlier, and asking if my "fix" here was just changing time timing enough to avoid the race condition.
In both our cases we are using late-model AY-3-8913s sourced from China. Is it possible they are counterfeit? I really wish I had some de-capping skills so I could open it up and see.
In both our cases we are using late-model AY-3-8913s sourced from China. Is it possible they are counterfeit? I really wish I had some de-capping skills so I could open it up and see.
feels a bit of a far reach to blame china cheap parts for it, but curious on how the investigation will unfold
