This tune: https://csdb.dk/release/?id=165909
Sounds correct in Vice 3.1, but incorrect in Vice 3.2. The same vicerc file is used. In 3.2, two frames of white noise is heard at the attack of every note.
This probably affects many other tunes as well.
My playroutine makes use of double hard-restart. This means that the envelope counters are reset during two frames (ADSR=0000, normal hard-restart), and then the counter is deliberately allowed to escape by switching to a slow rate for a sufficient number of cycles, before switching back to the desired attack rate (which is 0 or 1 in these instruments). On real hardware (and in Vice 3.1), this delays the note onset by a further 1.67 frames, so I can play a very brief burst of white noise in the remaining 0.33 frames. If the counter overflow doesn't work as expected, the white noise plays for the full two frames.
Both versions of Vice were built from source, specifying only --enable-cpuhistory.
would you please look here: https://sourceforge.net/projects/vice-emu/files/old-versions/
and try to find the revision that broke it? that would help a lot
rereading what you wrote... it must have been r34721 that broke it? can you provide a small test case?
Last edit: gpz 2018-07-03
I can confirm that it happened in r34721. It sounds fine in r34720.
I have created and attached a small test program.
Thank you for the test! It seems that commenting out line 381 in envelope.h (where state is set to FREEZED) fixes the problem. Not sure why though, probably because rate_period isn't updated on registers write during FREEZE state, will check later.
Confirmed! All envelope tests work now, patch attached.
applied in r35199 - thanks for the patch!
please retest :)
leandro: i noticed that SID/envelope/testADSRDelayBug.prg fails randomly on subsequent runs... cant tell atm if that is because of a bug in the test, or a bug in the emulation - maybe you want to have a look
edit: that one was easy. fixed it. cheers :)
i guess we can close this?
Last edit: gpz 2018-07-08
"i guess we can close this?" ? :)
yeah? :)
Great to see this fixed, for me the bug manifested as an unwanted sharp HR, when I intentionally wanted a full or "ugly" first frame of sound :)
no comlaints... closing :)