| |
ThunderBlade
Registered: Jan 2002
Posts: 75 |
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?
|
|
| |
Soren
Registered: Dec 2001
Posts: 547 |
Different musics, different music routines, possibly?
resetting oscillators (testbit in waveform register)should have to do with parts of this issue. I bet the oscillators start running as soon as they are NOT reset.
d404,09 = gate on and reset oscillator.
So d404,0 possibly lets the oscillator running, even though no waveform is really played, but the phase is not reset.
Also ADSR might give some problems.
There are people that know far much more than me about this, so lets wait and see. :-) |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
It happened very often to me to reset the SID between an intro and a game by writing first $ff then $00 to every sidregs, else the game tune would sound w/o a voice or with one continuous BEEP. There are a shitload of intros out there that don't take the problem of properly reset the SID into account =) |
| |
Hermit
Registered: May 2008
Posts: 208 |
I don't know whether it's the same issue, but I remember, when I was coding SRA Music Collection, and wanted to fade out tunes, some of the tunes played ugly after fading out the previous in the list.
I had to remove the fade-out function. Whatever I did, didn't help. Maybe this $ff then $00 would have been the solution to start every tune correctly, not depending on previous tune.
Now in my player I'm trying with $08 to every register at init/startup, as I saw in some tunes at RakBit project. An ancient way possibly, but simple, and resets the oscillators.
Anyway. That's why I like SID, it's soo analog, if it was a living creature not a chip, which always has new aspects to discover.
|
| |
Conrad
Registered: Nov 2006
Posts: 833 |
Quote: It happened very often to me to reset the SID between an intro and a game by writing first $ff then $00 to every sidregs, else the game tune would sound w/o a voice or with one continuous BEEP. There are a shitload of intros out there that don't take the problem of properly reset the SID into account =)
Yeah, the older intros used the kernal routines to reset the VIC, but didn't necessarily reset the sid registers either. You could definitely tell with those lame frozen "cracks" some groups did. ;)
One thing I know is that you can reset the noise generator by set waveform $91, and then a frame later, reset with $09, as Jeff mentioned. Works wonders with tunes that use phase effects with the noise waveform. |
| |
ThunderBlade
Registered: Jan 2002
Posts: 75 |
Thank you for the hints, yes it's different play routines. I will try the suggested solutions. |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
I haven't really experimented with, or thought closely about, how to reset the sid in the best possible way, but...
Filter regs, frequency regs, and pulse width regs should simply be set to 00.
I would first set ADSR regs to 00, then set the control registers to $08 to set gate off and turn oscillators off (what Jeff suggested, sort of). Then you should preferably wait for a while (2-3 frames should be completely safe) to make sure that the internal ADSR counters are reset properly.
...and finally, if everything is silent when you try to play your tune, just set global sid volume to $0f before initializing the tune. (The tune init routine really should take care of this itself though, so I guess you won't ever need that.)
|
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
or even $1f as probably is best for most tunes, happened also that some tunes lacked a proper init (yes there are) and setting $0f would make the tune play with one voice muted =) |
| |
j0x
Registered: Mar 2004
Posts: 215 |
ian: Am I somehow misunderstanding your post? To me, $0f should be the correct value. Adding $10 just enables the low-pass filter. Are you mixing up bits 3 and 7 here? |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
j0x: I thought just the same.. I think Ian got something wrong here.. |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
jox: no, many tunes with muted voices were fixed by setting $1f instead of $0f. I've done quite a bunch of them in the lastest HVSC updates.
one of the many examples
# from iAN CooG: Restored $d418 setting, bassline now it's audible.
/update/fix/MUSICIANS/C/Coolrock/Commercial_Music_3.sid
/MUSICIANS/C/Coolrock/
if you remove the sta $d418 like it was before, sidplay defaults to lda #$0f sta $d418 before jmping to the init. and the bassline is not audible anymore. there were plenty, just check the hvsc updates =) |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
another example
/MUSICIANS/S/Simon_Laszlo/So_Hard.sid
change the lda #$1f sta $d418 to $0f like it was before and hear. |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Probably enabling the filter for some voice(s) but not selecting any filter type results in silence then.. I guess. Never tried that I think. At least not that I can remember. ...but then this it is not necessarily correct to select low pass filter. It could just as well have been some other type of filter in the original tune, even though low pass filter is probably most common.
|
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
search for a9 1f 8d 18 d4: 10489 sid files found
search for a9 0f 8d 18 d4: 3987 sid files found
not so uncommon, and i don't want to search for DMC tunes that set d418 in an indirect way =) |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
ldx #$1d
lda #0
.sta $d400,x
dex
bpl .
rts
|
| |
j0x
Registered: Mar 2004
Posts: 215 |
Quote:
Probably enabling the filter for some voice(s) but not selecting any filter type results in silence then.. I guess.
Sounds like Frantic is probably on the right track. If this is true, is it only true for SID emulation?
Sorry for side-tracking the thread slightly, btw... :( |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Sidwave: Sorry if I am rude now, but I have to say that that was quite a crappy answer to his question. To begin with, $d41d is not a valid SID register at all, and there is no need to write anything to the registers $d419-$d41c which are purely output registers. ...and the whole thread began on the assumption that something more than just writing zeroes to the SID would be relevant.
j0x: I think it may very well be true on the real hardware too, but I don't have it right here where I am at the moment, so I can't tell for sure. |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
ok Frantic,
i didnt make a sidplayer yet, but what i think will work is:
clear d418, and do a hard restart with no sound, then set filter type.
now the sid will have a filter type when the first note is played, and the ADSR will be reset.
i have a sound like that in SDI:
waveform:
09 00
.01 00
ff .
it resets the sid (as of what i know),
and my filters begin at the correct spot.
this any help ? |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
this positively works 100% (on 6581 R4 AR anyway), its from a tune i made, i used it many times:
ADSR: 0002
HARD RESTART
FILTER type: 1F (lowpass, max resonance)
WAVEFORM:
01 .
FF .
just a 1.
work every time. |
| |
Soren
Registered: Dec 2001
Posts: 547 |
SIDwave: what if you don't want to start the tune with hard restart? ;-) |
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
/MUSICIANS/H/Harries_Jan/Equations.sid
Jeff, its just a sid reset that works, that what he asked. |
| |
Devia
Registered: Oct 2004
Posts: 401 |
Quoting FranticFilter regs, frequency regs, and pulse width regs should simply be set to 00.
I would first set ADSR regs to 00, then set the control registers to $08 to set gate off and turn oscillators off (what Jeff suggested, sort of). Then you should preferably wait for a while (2-3 frames should be completely safe) to make sure that the internal ADSR counters are reset properly.
...and finally, if everything is silent when you try to play your tune, just set global sid volume to $0f before initializing the tune. (The tune init routine really should take care of this itself though, so I guess you won't ever need that.)
Quoting iAN CooGor even $1f as probably is best for most tunes, happened also that some tunes lacked a proper init (yes there are) and setting $0f would make the tune play with one voice muted =)
sooo.. to recap, the issues may be ADSR related and related to "incomplete" music init routines, right?
And based on at least 10489 tunes having hardcoded low-pass filter somewhere in the code, the assumption is that an incomplete music init routine is best supported by a preconfigured low-pass filter, right?
Since KERNAL sets $d418 to $00, I'm curious as to what has initialized $d418 to something other than that in the original code? ..or maybe they are just bad (incomplete) rips?
That aside,
Quoting FranticProbably enabling the filter for some voice(s) but not selecting any filter type results in silence then.. I guess.
You guessed right.
So to sum up: A SID reset routine would have to look something like this:
SIDRST:
ldx #$18
lda #$00
: sta $d400,x
dex
bpl :-
lda #$08
sta $d404
sta $d40b
sta $d412
ldx #$03
lda #$ff
: cmp $d012
bne :-
dex
bpl :-
lda #$00
sta $d404
sta $d40b
sta $d412
lda #WhateverValueUThinkIsMosLikelyToMakeSenseIfWhateverYouJumpToNextDoesntSetI tItself
sta $d418
rts
|
| |
j0x
Registered: Mar 2004
Posts: 215 |
Devia:
Quote:
You guessed right
Did you check on real hardware?
And, fwiw, your delay loop probably doesn't do what it's intended to. It may make a number of "dex"'s while $d012 equals $ff.
|
| |
ThunderBlade
Registered: Jan 2002
Posts: 75 |
This is a great discussion. Very helpful indeed, thank you all! |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Devia:
Quote:
You guessed right
Did you check on real hardware?
And, fwiw, your delay loop probably doesn't do what it's intended to. It may make a number of "dex"'s while $d012 equals $ff.
Indeed that wait will fail. Patch to:
ldx #$03
: bit $d011
bpl *-3
bit $d011
bmi *-3
dex
bpl :-
|
| |
Devia
Registered: Oct 2004
Posts: 401 |
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: 401 |
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
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: 1627 |
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: 401 |
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: 1378 |
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: 11111 |
you should definately post that kind of stuff on the vice bugtracker. yes resid is maintained :) |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Thanks Groepaz, I'll shrink my test code a little and get on it. |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
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: 1378 |
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 :) |
| |
Bacchus
Registered: Jan 2002
Posts: 154 |
Picking up this thread, can we agree this piece of code is the utter and complete SID init? It's basically the above but also optimised to minimise memory footprint.
sidinit:
lda #$00
ldx #$18 //00
!: sta $d400,x
dex
bpl !-
lda #$08
jsr sidset
ldx #$03
!: bit $d011
bpl *-3
bit $d011
bmi *-3
dex
bpl !-
lda #$00
sidset: sta $d404
sta $d40b
sta $d412
rts
/Bacchus |
| |
chatGPZ
Registered: Dec 2001
Posts: 11111 |
For broken music players you want $1f in $d418. Also to really reset the noise lfsr, you gotta wait kindof long with testbit set (but thats probably not required for most things) |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
@gpz: What constitutes a "broken music player" in this context, and why enable the lo pass filter? Looks strange to me, but I guess I am missing something obvious here. |
| |
TheRyk
Registered: Mar 2009
Posts: 2069 |
I also tend to leave $D418 alone, normally, because older .SID files (done with ancient trackers, that's what gpz means I guess) can't deal with $d418 muted and (re-)setting $d418 ain't essential anyway, when $D400-$d417 are restted, unless you wanna do some good old $d418 samples on 6581 :)
For sure, it all depends on what you're aiming at. Most possible "universality" or 2020 modern approach that makes most sense. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11111 |
Frantic: see ians comment above (#8). It seems to work best :) There are a bunch of old players that dont init "enough", and with those $1f in $d418 is often what seems right. |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Ah.. haha.. thanks gpz. Amusing to see that I was involved in the discussion you refer to in those old posts too, and even kind of asked the same question. Memory is short I suppose. At least mine. :) |
| |
Fred
Registered: Feb 2003
Posts: 284 |
Quote: Picking up this thread, can we agree this piece of code is the utter and complete SID init? It's basically the above but also optimised to minimise memory footprint.
sidinit:
lda #$00
ldx #$18 //00
!: sta $d400,x
dex
bpl !-
lda #$08
jsr sidset
ldx #$03
!: bit $d011
bpl *-3
bit $d011
bmi *-3
dex
bpl !-
lda #$00
sidset: sta $d404
sta $d40b
sta $d412
rts
/Bacchus
For tunes like:
/MUSICIANS/T/Tel_Jeroen/Cybernoid.sid
/MUSICIANS/B/Bjerregaard_Johannes/Stormlord_V2.sid
the mentioned SID reset is not enough. If you restart those tunes and perform the reset it will not always play the same. To fix it you have to write #$ff first to every SID register, then #$08 and then #$00 and have some time between writing those values.
For the Sidplayer in the Ultimate devices I wrote this:
lda #$ff
resetSidLoop ldx #$17
- sta $d400,x
dex
bpl -
tax
bpl +
lda #$08
bpl resetSidLoop
+
- bit $d011
bpl -
- bit $d011
bmi -
eor #$08
beq resetSidLoop
lda #$0f
sta $d418
Note that it doesn't write #$1f to $d418. I don't think there are SIDs in HVSC anymore that require this. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11111 |
Quote:To fix it you have to write #$ff first to every SID register, then #$08 and then #$00 and have some time between writing those values.
Effectively you are doing what i said - reset the noise lfsr :) (you dont actually need to write $ff or $08 to _all_ registers) |
| |
Fred
Registered: Feb 2003
Posts: 284 |
Quote: Quote:To fix it you have to write #$ff first to every SID register, then #$08 and then #$00 and have some time between writing those values.
Effectively you are doing what i said - reset the noise lfsr :) (you dont actually need to write $ff or $08 to _all_ registers)
True, not needed for all registers but it's doesn't matter if you do so for the noise lfsr. This way I could optimize the code in size. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11111 |
Of course, doing it "properly" would probably take twice as much code... at least :) |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
But... what does "proper" really mean?
Reset Sid as it is on machine power up, or what?
I guess after power up all internal regs are set to $FF except $D418 that kernal put at $00 during startup... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11111 |
by "properly" i was referring to clean "by the book" code that only writes exactly the values needed only to the registers that require it. |
| |
Flavioweb
Registered: Nov 2011
Posts: 447 |
Quote: by "properly" i was referring to clean "by the book" code that only writes exactly the values needed only to the registers that require it.
Ok.
But musicians out there start composing from an "after power up" state and not from a "by the book" Sid setup.
Some examples have been given, including "Cybernoid", so i guess the goal is "how to make play already made tunes same way, everywhere".
Maybe a "by the book" setup make "power up setup" tunes sound different.
Anyway, if is it, this mean that some tunes out there have no proper self Sid Setup code. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11111 |
You lost it - both would reset the SID the same way, just the code to do it would be different. |
| |
TheRyk
Registered: Mar 2009
Posts: 2069 |
Quoting Flaviowebsome tunes out there have no proper self Sid Setup code.
varies a lot of course.
As you can already seen by nowadays
LDA #$SUBTUNE No.
JSR $INIT
being perfectly fine for Goattracker, whereas
TAX
TAY
before the JSR $INIT makes it more universal as older players expect X and/or Y regs set.
Slightly offtopic of course, so what has this to do with anything? Well, it's an example why not to rely on .SID-file immanent Init routine doing the I/O init job for you, especially if tunes are done with older or exotic trackers. |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
TheRyk: that is the tune init, to init its internal counters, especially to restart playing it from pattern 0, and doesn't have anything to do with SID chip regs init. Also not all inits require A, X or Y, some just require some value stored in some address, it only depends on the tracker used.
Then, the tune init isn't even guaranteed to set all SID chip regs correctly and could rely on a SID chip just as it is at power up. There are TOO MANY sid files and each is made in its own special way =)
The typical problem is on cracks, or multipart demos made with different single parts linked together. After an intro played some music, then the next part sounds weird/wrong/not at all.
Reiniting manually the sid registers before starting the next tune is the only way. |
