| |
ThunderBlade
Registered: Jan 2002
Posts: 78 |
resetting the SID
Hi, not sure if this is an awkward question, but... what's the proper way to reset the SID?
When starting various musics, I sometimes, very rarely, notice they sound different like all the other times. It seems to depend which music I played previously!
Inbetween playing musics, currently I just fill $D400 - $D418 with a counting down loop (starting with $D418) with zeroes. Is there a recommended better way?
|
|
... 44 posts hidden. Click here to view all posts....
|
| |
Devia
Registered: Oct 2004
Posts: 403 |
hehe.. yeah, whatever ;-)
and yes, did test on real hardware (6581R4AR) - I didn't test THAT thoroughly, so if it's completely silent or just have some barely inaudible properties remains to be measured.
But surely some supergeek must have tested this at some point?
|
| |
Devia
Registered: Oct 2004
Posts: 403 |
Uhm.. interestingly enough, the SID output is more silent in that configuration (filter ON, but no filter type active) with gate ON than OFF... /me is puzzled
Also the volume click is waaaay louder when changing from F to 0 or 0 to F than any other transition...
sorry for going off topic, but could someone point me in a direction of some material describing what everyone is referring to as the "ADSR bug"?
|
| |
Soren
Account closed
Registered: Dec 2001
Posts: 547 |
Devia: It's just something about the envelope on the sid being slightly unstable. But it's a good feature, especially when it's still possible to stabilize it with hard restart.
Unstable makes melodies more lively, etc. :-)
|
| |
Frantic
Registered: Mar 2003
Posts: 1661 |
A good source for people who are interested in the ADSR instability is to check the reSID code. There are some explanations regarding internal counters of the sid in the code comments too. If you make the effort to go through the code, it makes the nature of the ADSR bug quite clear.
Basically, there is an internal counter in the ADSR generator that misses a certain criterion under some circumstances, which makes it continue count upwards until it wraps ($ffff->$0000) instead of switching to downwards counting at a certain point as it is supposed to. In the cases when the criterion is missed and the counting just continues upwards, then wrapping, and eventually hitting the stopping criterion, the counting takes longer time, and the result is audible as instable sound (i.e, sometimes a delay, sometimes not, and the length of the delay depends on the states of the counters in relation to the ADSR values that are set). Not sure if that made anything clearer? :)
The delay of 2-3 frames makes sure that the counting is finished no matter if the bug is triggered or not, i.e. the internal counters will have reached a known state. Just to make very clear though: The ADSR bug is not a "random" thing. It just appears that way from the viewpoint of the musician. ...if anyone thought otherwise.
There was also a little article on the ADSR bug in the HVSIDs... uh... some HVSIDS production with articles in it and a bunch of tunes. If I remember correctly, that article wasn't really very pedagogically written though, but I might be wrong. I think it was this one:
10 Years HVSC
People often also mix up, or rather blend, two different things when they talk about "hard restart": Resetting the oscillator on the one hand (just use the testbit: flip on and off and it is reset) and handling the ADSR bug on the other...
@Devia: I am with you when you characterize the lack of filter type init as a "bad rip" problem. Quite obviously, there was some sort of filter type init in the original code if the tune ever played correctly in the original production, just as you say. |
| |
Devia
Registered: Oct 2004
Posts: 403 |
Thanks for the info.. I do remember that article about hard restart.. just don't remember actually reading it ;-)
Seem to remember there was some info in the JCH Edit source pack too.. oh well, off to 5 days of beer, rain, beer and no toilets \o/
|
| |
ChristopherJam
Registered: Aug 2004
Posts: 1424 |
Speaking of the ADSR bug, while I second the recommendation of reading the reSID sources to get a good understanding of how it occurs (especially envelope.cpp), I've just been testing the behaviour of ENV3 and discovered that VICE/reSID starts the envelope off one cycle early.
Is anyone still actively maintaining this emulation combination?
If attack is zero and the envelope rate counter hasn't escaped, env3 becomes 1 between 4 and 12 cycles after writing a 1 to the gate.
lda#1
sta v3ctl
lda env3
ldx env3
ldy env3 ; should always be '1'. Under reSID+VICE is occasionally 2
let me know if you want the rest of the test harness.
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11523 |
you should definately post that kind of stuff on the vice bugtracker. yes resid is maintained :) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1424 |
Thanks Groepaz, I'll shrink my test code a little and get on it. |
| |
Frantic
Registered: Mar 2003
Posts: 1661 |
ChrisJam: Interesting. Even though your finding is related to ADSR envelope, could the "one cycle off" phenomenon possibly be related to the following (which is rather about the waveform oscillators than the ADSR envelope):
http://codebase64.org/doku.php?id=base:detecting_sid_type_-_saf..
?
If it is, then maybe you should take care to test whether the behavior is actually the same on 8580 as on 6581. I am not sure whether the "one cycle off" thing for waveform oscillators is emulated in resid now. (Apparently resid-fp does emulate it).
Nice to see you around btw. Still remember when you first turned up on one of the LCP parties and released that very nice demo with the escher zoomer etc. :) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1424 |
Hmm, good point about SID revisions - according to the test code you posted I've been testing on a 6581, though I should probably open up the c64 in question to double check (I only just retrieved it from my stash in the cupboard last week :)
VICE shows the same 'wrong' behaviour regardless of whether I set it to a ReSID-fp 6581 or a ReSID-fp 8580.
Glad Effluvious made an impression :) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 - Next |
