03732: mouser: AY-3-8910 initialisation not correct

ID	Category [?]	Severity [?]	Reproducibility	Date Submitted	Last Update
03732	Sound	Minor	Always	Feb 13, 2010, 19:54	May 14, 2010, 19:29

Tester	M.A.S.H.	View Status	Public	Platform	MAME (Self-compiled)
Assigned To	couriersud	Resolution	Open	OS	Windows XP (32-bit)
Status [?]	Assigned			Driver	upl/mouser.cpp
Version	0.136u2	Fixed in Version		Build	Normal
		Fixed in Git Commit		Github Pull Request #

Summary	03732: mouser: AY-3-8910 initialisation not correct
Description	Since the AY-3-8910 rewrite in MAME 0.124u4 you must reset Mouser to hear the correct start music. Or the music plays correct, but after a reset it plays wrong and you must reset the game again. Listen to the attached wave files. I think the AY-3-8910 registers must be set or reseted in the emulation.
Steps To Reproduce
Additional Information
Github Commit

Flags
Regression Version	0.124u4
Affected Sets / Systems	mouser

Attached Files	Mouser-136u2.mp3 (540,864 bytes) Feb 13, 2010, 19:54
Attached Files	Mouser-136u2-After_Reset.mp3 (533,376 bytes) Feb 13, 2010, 19:55

No.06117 couriersud Developer May 14, 2010, 19:29	Copy of an email I wrote on this issue: This issue is not related to initialization as the title suggest. The observations result from aliasing. What is happening: Both channels A and B get the same register values written. The intention obviously is that both channels add up their outputs. At times this happens, at other times the channels are phase shifted, leading to nasty aliasing effects. There are two possible reasons: a) AY8910 itself. Currently, the tone clock generation is running continously. If the channels in the past played at different frequencies, even setting them to the same frequency most likely will result in a phase shift. b) stream_update: If a register is changed, stream_update is called. If this happens at the "wrong time", this may introduce a phase shift as well. Example: Period register channel A is written. No update. Now channel B is written. Update occurs before register channel B is written ==> Channel A's counter may reset to 0 one sample before channel B's counter on a switch to shorter frequencies. a) should be observed in the wild as well. Does anybody here has more details? The issue vanishes, if the channel counter and state are reset when the channel period register is written. I searched all information available (datasheets, web sites) I know about but something like this is not documented. However it would probably make sense from a design view. Again, any feedback or information would be greatly appreciated. I was also not able to find a patent describing the AY8910. Any information would be appreciated.

No.06117

couriersud

Developer

May 14, 2010, 19:29

Copy of an email I wrote on this issue:

This issue is not related to initialization as the title suggest. The observations result
from aliasing.
What is happening: Both channels A and B get the same register values
written. The intention obviously is that both channels add up their
outputs. At times this happens, at other times the channels are phase
shifted, leading to nasty aliasing effects. There are two possible
reasons:

a) AY8910 itself. Currently, the tone clock generation is running
continously. If the channels in the past played at different
frequencies, even setting them to the same frequency most likely will
result in a phase shift.

b) stream_update: If a register is changed, stream_update is called. If
this happens at the "wrong time", this may introduce a phase shift as
well. Example: Period register channel A is written. No update. Now
channel B is written. Update occurs before register channel B is written
==> Channel A's counter may reset to 0 one sample before channel B's
counter on a switch to shorter frequencies.

a) should be observed in the wild as well. Does anybody here has more
details?

The issue vanishes, if the channel counter and state are reset when the
channel period register is written. I searched all information available
(datasheets, web sites) I know about but something like this is not
documented. However it would probably make sense from a design view.
Again, any feedback or information would be greatly appreciated.

I was also not able to find a patent describing the AY8910. Any
information would be appreciated.