Colecovision and Sound Bios

[bfg.gamepassion]

Hi, can someone explain me how the Colecovision sound data work.

 

Especially the "VOLUME SWEPT NOTE". In attached file there is the structure of this music note.

 

Byte 1 : Ok, we choose the channel and tell the bios we will play a "VOLUME SWEPT NOTE"

Byte 2 : Ok, first part of the frequency

Byte 3 : Ok, Base volume and last 2 bits of the frequency

Byte 4 : Length of note : Ok, number of ticks this note will play

 

Byte 5 : Step size + Number of Step

 

Seems ok for me, but

 

Byte 6 : Step length + first step length

 

Is my theory exact :

 

Byte 3 : Start volume = 0xF (silent)

Byte 4 : The note will play for 15 ticks

Byte 5 : Step size = 2 Number of step = 4 So, the volume will do : 0xF(first volume)-->0xD-->0xB-->0x9-->0x7 (4 step after first volume)

Byte 6 : Step length = 3 first step length = 3

 

So with the byte 6 we will have :

 

Ticks 1 : 0xF

Ticks 2 : 0xF

Ticks 3 : 0xF

Ticks 4 : 0xD

Ticks 5 : 0xD

Ticks 6 : 0xD

Ticks 7 : 0xB

Ticks 8 : 0xB

Ticks 9 : 0xB

Ticks 10 : 0x9

Ticks 11 : 0x9

Ticks 12 : 0x9

Ticks 13 : 0x7

Ticks 14 : 0x7

Ticks 15 : 0x7

 

Is my theory exact ?

[Pixelboy]

I think you should contact Daniel Bienvenu directly for an answer to your question. Don't bother sending him a PM on AtariAge though, he doesn't drop by here very often anymore. You should contact him by e-mail.

[Tony Cruise]

Please do post the answers here though, as this is something I am struggling with as well.

[tabachanker2]

Hi, can someone explain me how the Colecovision sound data work.

 

Especially the "VOLUME SWEPT NOTE". In attached file there is the structure of this music note.

 

Is my theory exact ?

 

Hi, here's what I've written in my personal notes about the attenuator sweepings :

• You got the description of the first four bytes OK .
  
• The 5th byte: Attenuator modifier: xxxxyyyy
  
  • xxxx = Value to add to current attenuation. To decrease volume, use positive(0x1 to 0x7) numbers (more attenuation). To increase volume, use negative(0xF to 0x8) numbers (less attenuation).
    
  • yyyy = Amount of attenuator modifications. Note: This value is decremented before modifications. Also, attenuator modifications stop as soon as it turns 0. So, a value of 0x1 here means NO MODIFICATIONS while 0x0 means 15 modifications.
    

  [*]The 6th byte: Step length between attenuator modifications: xxxxyyyy

  • xxxx = Step length resetter. BIOS use this value to replace 1st step length "yyyy" as soon as it turns 0.
    
  • yyyy = Step length. The value here is used as the 1st step. Note: This value is decremented before modifications. Also, a modification will occur as soon as it turns 0. If you call 0x1f61 (play sounds) before 0x1ff4 (update sounds), as you should, this won't be a problem. But if you flip the 2 calls, an initial value of 0x1 here would mean NO DELAY while 0x0 would mean a delay of 15.
    

So in your example:

• Byte 3 : Start attenuation = 0xF (silent)
  
• Byte 4 : The note will play for 15 ticks
  
• Byte 5 : Step size = 2 ; Number of steps = 4
  
• Byte 6 : Step length resetter = 3 ; Step length = 3
  

Ticks 1 :

Call 1f61: Attenuator = 0xF

Call 1ff4: Step length - 1 = 2: Nothing special occurs

 

Ticks 2 :

Call 1f61: Attenuator = 0xF

Call 1ff4: Step length - 1 = 1: Nothing special occurs

 

Ticks 3 :

Call 1f61: Attenuator = 0xF

Call 1ff4: Step length - 1 = 0: Step length is reset with "step length resetter".

Number of steps - 1 = 3: Continue attenuation modifications

Attenuator = 0xF + step size (and 0x0F) = 0x01 (only calculated in RAM, used at next call 1f61)

 

Oops! There's a problem here! Your step size should be negative(bit3=1) to increase volume. And if I remember well, the BIOS doesn't check limits. It does the modification than only mask the result with "0x0F".

So here's the revised example (with more details) :

• Byte 3 : Start attenuation = 0xF (silent)
  
• Byte 4 : The note will play for 15 ticks
  
• Byte 5 : Step size = 0xE ; Number of steps = 4
  
• Byte 6 : Step length resetter = 3 ; Step length = 3
  

Ticks 1 :

Call 1f61: Attenuator = 0xF

Call 1ff4: Step length - 1 = 2: Nothing special occurs

 

Ticks 2 :

Call 1f61: Attenuator = 0xF

Call 1ff4: Step length - 1 = 1: Nothing special occurs

 

Ticks 3 :

Call 1f61: Attenuator = 0xF

Call 1ff4: Step length - 1 = 0: Step length is reset with "step length resetter".

Number of steps - 1 = 3: Continue attenuation modifications

Attenuator = 0xF + step size (and 0x0F) = 0x0D (only calculated in RAM, used at next call 1f61)

 

Ticks 4 :

Call 1f61: Attenuator = 0xD

Call 1ff4: Step length - 1 = 2: Nothing special occurs

 

Ticks 5 :

Call 1f61: Attenuator = 0xD

Call 1ff4: Step length - 1 = 1: Nothing special occurs

 

Ticks 6 :

Call 1f61: Attenuator = 0xD

Call 1ff4: Step length - 1 = 0: Step length is reset with "step length resetter".

Number of steps - 1 = 2: Continue attenuation modifications

Attenuator = 0xD + step size (and 0x0F) = 0x0A (only calculated in RAM, used at next call 1f61)

 

Ticks 7 :

Call 1f61: Attenuator = 0xA

Call 1ff4: Step length - 1 = 2: Nothing special occurs

 

Ticks 8 :

Call 1f61: Attenuator = 0xA

Call 1ff4: Step length - 1 = 1: Nothing special occurs

 

Ticks 9 :

Call 1f61: Attenuator = 0xA

Call 1ff4: Step length - 1 = 0: Step length is reset with "step length resetter".

Number of steps - 1 = 1: Continue attenuation modifications

Attenuator = 0xA + step size (and 0x0F) = 0x09 (only calculated in RAM, used at next call 1f61)

 

Ticks 10 :

Call 1f61: Attenuator = 0x9

Call 1ff4: Step length - 1 = 2: Nothing special occurs

 

Ticks 11 :

Call 1f61: Attenuator = 0x9

Call 1ff4: Step length - 1 = 1: Nothing special occurs

 

Ticks 12 :

Call 1f61: Attenuator = 0x9

Call 1ff4: Step length - 1 = 0: Step length is reset with "step length resetter".

Number of steps - 1 = 0: Stop all attenuator modifications

 

Ticks 13 - 15 :

Call 1f61: Attenuator = 0x9

Call 1ff4: No more attenuation modifications

 

So, as you can see, the number of times attenuator got modified is actually "Number of steps - 1". The step lengths will be true (not length - 1) only if you call 0x1F61 before 0x1FF4 (in all Colecovision games I disassembled, they were called in this order somewhere in the NMI subroutine or just after waiting for it to occur).

Edited October 20, 2012 by tabachanker2

[bfg.gamepassion]

Thanks, thanks thanks !!!!!!

[ten-four]

I like when people can help each other.

 

Very detailed reply Steve.

[tabachanker2]

Thanks, thanks thanks !!!!!!

 

No problems! If you need help with something else, don't hesitate to ask!

 

Very detailed reply Steve.

It's the only way to go!

By being so thorough, I even corrected a mistake I made in my initial post!

I thought at first that the "first step length" would suffer the same fate as the "amount of steps" (actual length = -1). But after adding the proper order of BIOS subroutine calls (1F61, then 1FF4) to my post, I stood corrected!

[Pixelboy]

Salut Steve! Content de te voir!

 

I hope your presence on AA is a sign that Lode Runner is not too far from release! We've been waiting a long time to see the fruits of your labours, and I know that the final version will have significant differences with your original SG-1000 port.

[retroillucid]

I hope your presence on AA is a sign that Lode Runner is not too far from release!

 

It is

[tabachanker2]

Salut Steve! Content de te voir!

 

I hope your presence on AA is a sign that Lode Runner is not too far from release! We've been waiting a long time to see the fruits of your labours, and I know that the final version will have significant differences with your original SG-1000 port.

 

Salut Luc! Content également de te voir!

 

What? Lode Runner... never heard of that before... Am I supposed to be working on that?

Seriously though, I'm really eager to show the results of my work on that project. I've been working on this for so long!

 

I basically reprogrammed the whole game. There were a lot of things wrong with the original SG-1000 version: levels layout were 30x10 tiles instead of 28x16 tiles; the tiles themselves were 8 pixels wide x 16 pixels high instead of 8x10; the AI was all wrong... And the change I made I'm most happy about: all the original 150 levels will be included in the 32k ROM. It's incredible the things one can do with a little code optimizing (and a lot of data compression too...!)

 

Anyway, enough derailing of the thread! Thanks for still being interested in the game! Oh, and I'll try to be more present here from now on. I don't even know why I didn't do it before!

[Pixelboy]

Oh, and I'll try to be more present here from now on. I don't even know why I didn't do it before!

 

Probably because you didn't want people to bug you about ongoing or potential CV projects!

[ColecoDan]

Now I can stop saying who is the Steve you speak of Welcome back and as one of the few who has played your old version I can say I have had fun and am excited to see the new version.

[tabachanker2]

Probably because you didn't want people to bug you about ongoing or potential CV projects!

I don't know about that! I'm always fine with talking about my Colecovision projects. I think it has to do with the fact that I'm not always working 100% on my projects (more often "not working" unfortunately!) I have several interests in other fields (music especially) and I can be months without touching a single line of code.

 

Now I can stop saying who is the Steve you speak of Welcome back and as one of the few who has played your old version I can say I have had fun and am excited to see the new version.

Thanks for your support! I also like my old Lode Runner. It was my first SG-1000 conversion and I was really excited to produce (a very limited) amount of them on actual carts. But I grew up with the C=64 version and I always wanted to do something more similar to that. And when retroillucid told me he had an interest in rereleasing my Lode Runner conversion, I thought it was time to rework it more like the C=64 game.

[+nanochess]

I've found very helpful the explanation from tabachanker2.