Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user eightbitswide ! (Registered 2024-12-24) You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > How to players and trackers usually deal with these modulation issues? --> Bit-scaling? (sid related, but not nescesarily, not a question related to the battlestar galactica music btw;-)
2006-07-19 22:37
stunt
Account closed

Registered: Jul 2006
Posts: 48
How to players and trackers usually deal with these modulation issues? --> Bit-scaling? (sid related, but not nescesarily, not a question related to the battlestar galactica music btw;-)

hi all!

I use the output of osc3(8bit) ($d41b) to modulate the pulsewidth osc1 (12bit) ($d402 & $d403), but now i still do that by just modulating OR the lobyte OR the hibyte register which gives very coarse results and also causes the modulation not to be active on the whole scale of the parameter.

I want to improve this situation so i came up with two strategies, and i'd like to hear your comments on them.

Ok. let's take a look at the situ:

The 8 lsbs reside in d402, the 4 msbs are bits 0,1,3 & 4 of $d403.

Ofcourse I want to spend as less time as possible doing the math.

Now I thought of two strategies:

Strategy 1: To modulate just the 8 most sig. bits of the 12bit word. That would mean to split the modulator byte in two and use the 4 most sig bits to modulate the 4 least sig bits of $d403, and to take the other 4 bits and use them to modulate the 4 most sig bits of $d402.

pros: prolly a time efficient solution
cons: coarse way of modulating: takes 16 steps at a time.

Strategy 2: to "bitscale" or strech up the 8bit modulator value up to a 12 bit value and modulate the 12 bits.

pros: more detailled modulation
cons: prolly lot of math and thus time consuming.

My question: what would be the most time efficient ways to implement both strategies, and which strategy would you guys advice me.

How do players and trackers usually deal with the 12bit wide pulsewidth modulation?

Ofcourse i also want to modulate the 16 bit pitch, the 11 bit filtercutoff and the 4 bit volume parameters.

so i'd like to see a solution for the stretching to all these.

so :

8 bit value modulates 4 bit value
8 bit value modulates 16 bit value
8 bit value modulates 12 bit value
8 bit value modulates 11 bit value

i can imagine dat streching up and down to 4 or 16 is less difficult and strechting up to 11 is the hardest to do. is my intuition right?

very interested to see your solutions to my problem.

And prolly my most important question:

How do players and trackers usually deal with these modulation issues?

Greetz,

Stunt
 
... 20 posts hidden. Click here to view all posts....
 
2006-07-26 09:47
stunt
Account closed

Registered: Jul 2006
Posts: 48
Quote: Sorry but there is beter approach:

When you use bit 7 as a sign you understand values of 0-127 as 0-127, and values of 128-255 as -128 to -1. So 255 is -1, 254 is -2 and so on.

You just do your math as usual (if its one byte long).

There are instructions that support that build into 6502.
There is N flag, standing for negative in status register.
So if bit 7 in acumulator is set the flag is set acordingly.
and there is BMI - Branch if MInus, and BPL - Branch if PLus conditional jumps to support that.

That way steps 2-3 becomes obsolete, and in step 5 you only need just add.

Sorry but i'm totaly green on sound programming so i dont understand fully those modulations and stuff. I dont really know if they are 8 or 16 bit, hence i wont be able to help much more. But if they are 8 bit it should be fairly easy.


Jetboy, there's never reason to say 'sorry' when you provide a better way to fix things. B/c i can only be happy with that. This kind of feedback is exactly what i'm looking for.

Can you give an example as to how i implement it?
(I never worked with n-flag before, just carry)

By the way, what i would like to have is, that 0-127 become -128 to -1, and 128-255 become 0-127, so that is slightly different than in your example.

As for the math, after this 'absolution' is done the value still needs to be divided/multiplied by the modulation-intensity value before it can be added subtracted to the pitch value.

And yes, apart from 8bit, the value needs to be added/subtracted to 16,12,11 and 4 bit values also.

Now the bitshifting-thing seems both a good solution for both easily applying the intensity as well as a solution for multiple 8bit+ modulation.

I wonder wether i can still use Laxity's code (see above in this thread) to do it.

I dont see how to do stuff but i will draw it, maybe that will make cloud go a away:

ok so let's take example of the pitch. It has two bytes:

7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0

and then there is the modulation byte

7 6 5 4 3 2 1 0.

So bit 7 of the modulation-byte determines negative or positie, and bit 6-0 determine modulation 128 values. So the the number that is added/subtracted to the pitch is 7 bit long.

Now how i see it in my head, there's an intensity-value that determines the 'dept' of modulation.

How i see it the modulation will look like this:

mod.dept:16 (=max.modulation)
7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0
^ ^ ^ ^ ^ ^ ^
6 5 4 3 2 1 0

mod.dept:15
7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0
  ^ ^ ^ ^ ^ ^ ^
  6 5 4 3 2 1 0

mod.dept:14
7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0
    ^ ^ ^ ^ ^ ^   ^
    6 5 4 3 2 1   0

[....]

mod.dept: 7
7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0
                    ^ ^ ^ ^ ^ ^ ^
                    6 5 4 3 2 1 0

[... ]
mod.dept: 1
7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0
                                ^ 
                                6 
mod.dept:0 (=modulation off)
7 6 5 4 3 2 1 0 | 7 6 5 4 3 2 1 0
 

----------
So let's take for example mod.dept 14 and see what will have to happen, to make things clear:
As you can see in my drawn example, the 7bit mod.value is splitted in two:
a 6 bitpart that modulates (add/subtr) the 6 lsbs of the pitch-hibyte, and a 1 bit part that modulates just the msb of the pitch-lobyte.

So laxity's approach is useful: just take two instances of the mod.value, and sfift one two bits left and add/subtract it with hibyte. Then take the other instance and shift it 7 times right, and add/subtract that with the lobyte.

And ofcourse, if lobyte exceeds $ff bit 1 of the hybite has to be set.
and if hybite passes zero then ofcourse bit 7 of lobyte has to ... ehm.. wel the adding/subtracting just have to make sense basically and hi and lobyte have to act as one big 16bit byte :D

How would i implement something like this?
I'm sure this kind of math has been needed lots and lots of times before.

Stunt
2006-07-26 10:38
stunt
Account closed

Registered: Jul 2006
Posts: 48
i suddenly came up with a better idea maybe:

why do all the stuff with the n-flag and signing?
why not subtract 128 of the pitchvalue first and then add the unchanged modulation value?


Stunt
2006-07-26 17:44
tlr

Registered: Sep 2003
Posts: 1790
Quote: i suddenly came up with a better idea maybe:

why do all the stuff with the n-flag and signing?
why not subtract 128 of the pitchvalue first and then add the unchanged modulation value?


Stunt


The you'd get $80 as the centervalue, but everyone would expect it to be a 2-complement signed value. (-128 to -1 is $80-$ff, 0 to 127 is $00-$7f)

2-complement is pretty much standard nowadays because it is what most CPU's use internally, and it is what is used in C/C++ and many other languages...
2006-07-26 20:28
stunt
Account closed

Registered: Jul 2006
Posts: 48
ok. i see. that's why it's useful for me to learn and understand 2-complement way.

But from an optimiser point-of-view,my way might save time and provide the same result?

Stunt
2006-07-26 20:35
tlr

Registered: Sep 2003
Posts: 1790
It is not necessary to make the editor display the same representation that is used in the actual player data.

If it saves time in the player, go for it, but make the editor present it as a 2-complement value if possible.
2006-07-26 21:25
stunt
Account closed

Registered: Jul 2006
Posts: 48
well the interface is very hardcore and now just shows 8 bits of osc3 flippin in binary and just aside that the value osc3 is modulating, and beside that the mod.dept (intensity). And you can see to which waveform osc3 is set. So that's as far as the visual interface goes. I'd rather spend my time on math then on visuals here :P

Anyhow, altough all you guys' insights were helpful, this pig ain't fully washed yet (is that a proper expression in english?)

Can you guys see why the last strategy (the 16bit solution that i presented visually) isn't correct?

I'm still thinkin gof a solution, will keep you guys updated.
Previous - 1 | 2 | 3 - Next
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
Cybortech/Graffity
Digger/Elysium
Alakran_64
Lead/House Designs
t0m3000/hf^boom!^ibx
Magic/Nah-Kolor
Guests online: 114
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 The Demo Coder  (9.6)
6 Edge of Disgrace  (9.6)
7 What Is The Matrix 2  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 Layers  (9.6)
2 Cubic Dream  (9.6)
3 Party Elk 2  (9.6)
4 Copper Booze  (9.6)
5 X-Mas Demo 2024  (9.5)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Triad  (9.3)
Top NTSC-Fixers
1 Pudwerx  (10)
2 Booze  (9.7)
3 Stormbringer  (9.7)
4 Fungus  (9.6)
5 Grim Reaper  (9.3)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.148 sec.