Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in 
CSDb User Forums


Forums > C64 Coding > resetting the SID
2011-07-02 23:32
ThunderBlade

Registered: Jan 2002
Posts: 64
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?
2011-07-03 01:27
Soren

Registered: Dec 2001
Posts: 546
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. :-)
2011-07-03 06:32
iAN CooG

Registered: May 2002
Posts: 2932
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 =)
2011-07-03 07:14
Hermit
Account closed

Registered: May 2008
Posts: 206
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.
2011-07-03 08:59
Conrad

Registered: Nov 2006
Posts: 774
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.
2011-07-03 18:41
ThunderBlade

Registered: Jan 2002
Posts: 64
Thank you for the hints, yes it's different play routines. I will try the suggested solutions.
2011-07-03 18:49
Frantic

Registered: Mar 2003
Posts: 1561
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.)

2011-07-03 19:57
iAN CooG

Registered: May 2002
Posts: 2932
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 =)
2011-07-03 20:09
j0x

Registered: Mar 2004
Posts: 213
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?
2011-07-03 20:28
Frantic

Registered: Mar 2003
Posts: 1561
j0x: I thought just the same.. I think Ian got something wrong here..
2011-07-03 20:28
iAN CooG

Registered: May 2002
Posts: 2932
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 =)
2011-07-03 20:46
iAN CooG

Registered: May 2002
Posts: 2932
another example
/MUSICIANS/S/Simon_Laszlo/So_Hard.sid
change the lda #$1f sta $d418 to $0f like it was before and hear.
2011-07-03 20:49
Frantic

Registered: Mar 2003
Posts: 1561
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.
2011-07-03 21:02
iAN CooG

Registered: May 2002
Posts: 2932
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 =)
2011-07-03 23:07
SIDWAVE
Account closed

Registered: Apr 2002
Posts: 2238
ldx #$1d
lda #0
.sta $d400,x
dex
bpl .
rts
2011-07-04 06:45
j0x

Registered: Mar 2004
Posts: 213
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... :(
2011-07-04 07:36
Frantic

Registered: Mar 2003
Posts: 1561
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.
2011-07-05 20:53
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 ?
2011-07-05 20:59
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.
2011-07-05 21:04
Soren

Registered: Dec 2001
Posts: 546
SIDwave: what if you don't want to start the tune with hard restart? ;-)
2011-07-05 21:07
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.
2011-07-05 21:40
Devia

Registered: Oct 2004
Posts: 401
Quoting Frantic
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.)


Quoting iAN CooG
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 =)


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 Frantic
Probably 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

2011-07-06 07:59
j0x

Registered: Mar 2004
Posts: 213
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.
2011-07-06 08:10
ThunderBlade

Registered: Jan 2002
Posts: 64
This is a great discussion. Very helpful indeed, thank you all!
2011-07-06 08:11
JackAsser

Registered: Jun 2002
Posts: 1867
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	:-

2011-07-06 19:04
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?



2011-07-06 21:16
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"?

2011-07-06 21:33
Soren

Registered: Dec 2001
Posts: 546
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. :-)

2011-07-07 20:24
Frantic

Registered: Mar 2003
Posts: 1561
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.
2011-07-07 22:05
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/

2011-07-09 08:26
ChristopherJam

Registered: Aug 2004
Posts: 1191
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.
2011-07-09 22:23
Groepaz

Registered: Dec 2001
Posts: 10163
you should definately post that kind of stuff on the vice bugtracker. yes resid is maintained :)
2011-07-12 19:02
ChristopherJam

Registered: Aug 2004
Posts: 1191
Thanks Groepaz, I'll shrink my test code a little and get on it.
2011-07-12 20:07
Frantic

Registered: Mar 2003
Posts: 1561
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. :)
2011-07-13 12:14
ChristopherJam

Registered: Aug 2004
Posts: 1191
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 :)
2021-06-01 15:48
Bacchus

Registered: Jan 2002
Posts: 132
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
2021-06-01 16:01
Groepaz

Registered: Dec 2001
Posts: 10163
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)
2021-06-01 19:30
Frantic

Registered: Mar 2003
Posts: 1561
@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.
2021-06-01 20:25
TheRyk

Registered: Mar 2009
Posts: 1189
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.
2021-06-01 21:01
Groepaz

Registered: Dec 2001
Posts: 10163
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.
2021-06-01 23:18
Frantic

Registered: Mar 2003
Posts: 1561
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. :)
2021-06-02 07:28
Fred

Registered: Feb 2003
Posts: 267
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.
2021-06-02 13:15
Groepaz

Registered: Dec 2001
Posts: 10163
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)
2021-06-02 22:00
Fred

Registered: Feb 2003
Posts: 267
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.
2021-06-02 22:24
Groepaz

Registered: Dec 2001
Posts: 10163
Of course, doing it "properly" would probably take twice as much code... at least :)
2021-06-03 07:06
Flavioweb

Registered: Nov 2011
Posts: 427
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...
2021-06-03 12:38
Groepaz

Registered: Dec 2001
Posts: 10163
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.
2021-06-03 12:49
Flavioweb

Registered: Nov 2011
Posts: 427
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.
2021-06-03 13:56
Groepaz

Registered: Dec 2001
Posts: 10163
You lost it - both would reset the SID the same way, just the code to do it would be different.
2021-06-03 14:12
TheRyk

Registered: Mar 2009
Posts: 1189
Quoting Flavioweb
some 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.
2021-06-03 18:47
iAN CooG

Registered: May 2002
Posts: 2932
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.
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
csabanw
TheRyk/MYD!
Hammerfist/Desire
Brittle/Dentifrice
zscs
hedning/G★P
Mythus/Delysid
Knight Rider/Excess
Luca/FIRE
A3/AFL
Xiny6581/Dees Produc..
psych858o/MSL/Elysiu..
Guests online: 70
Top Demos
1 Edge of Disgrace  (9.6)
2 Coma Light 13  (9.6)
3 Bromance  (9.6)
4 Uncensored  (9.6)
5 Memento Mori  (9.5)
6 Comaland 100%  (9.5)
7 Unboxed  (9.5)
8 Lunatico  (9.5)
9 Wonderland XII  (9.5)
10 Christmas Megademo  (9.5)
Top onefile Demos
1 Copper Booze  (9.6)
2 Daah, Those Acid Pil..  (9.5)
3 Dawnfall V1.1  (9.5)
4 Cityscape 2730  (9.5)
5 To Norah  (9.5)
6 Lovecats  (9.5)
7 Elite Code Mechanics  (9.4)
8 Barry Boomer - Trapp..  (9.4)
9 Offering  (9.4)
10 Tribute to Ben - Las..  (9.4)
Top Groups
1 Booze Design  (9.4)
2 Performers  (9.4)
3 Oxyron  (9.3)
4 Fossil  (9.3)
5 Crest  (9.2)
Top Swappers
1 Derbyshire Ram  (10)
2 Jerry  (9.8)
3 Acidchild  (9.7)
4 Starlight  (9.6)
5 Violator  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2021
Page generated in: 0.098 sec.