Subject: Re: [stella] 2600 Sound, that time of year.. From: "Andy Mucho" <andy@xxxxxxxxxxxxxxxxxxxx> Date: Sat, 2 Aug 2003 10:07:54 +0100 |
Paul Slocum wrote: > > I assume doing 2 voices also reduces the number of cycles required in the > kernal, which would help. yup, at the moment each to synthesise each voice is dead quick(ish) well as things go it's quick.. This code lives in the zeropage, and where needed either rts's for a normal display line, or jumps directly through a modified jump to the current sequencer event.. (I'm typing this all in by hand and memory right now (as I did on the bankswitch example, which I'm sure won't even work) , since my computer with the 2600 code on isn't here, but I'll be with it later on), so forgive any glaring typos.. It's basically this for the PWM type voice.. ;; ;; Voice 0 ;; clc V0_COUNT_LO = *+1 lda #$00 V0_RATE_LO = *+1 adc #$00 sta V0_COUNT_LO V0_COUNT_HI = *+1 lda #$00 V0_RATE_HI = *+1 adc #$00 sta V0_COUNT_HI V0_PULSEWIDTH = *+1 cmp #$80 lda #0 rol tay ;; ;; Voice 1 ;; V1_COUNT_LO = *+1 lda #$00 V1_RATE_LO = *+1 adc #$00 sta V1_COUNT_LO V1_COUNT_HI = *+1 lda #$00 V1_RATE_HI = *+1 adc #$00 sta V1_COUNT_HI V1_PULSEWIDTH = *+1 cmp #$80 tya rol tay ;; ;; Voice 2 ;; V2_COUNT_LO = *+1 lda #$00 V2_RATE_LO = *+1 adc #$00 sta V2_COUNT_LO V2_COUNT_HI = *+1 lda #$00 V2_RATE_HI = *+1 adc #$00 sta V2_COUNT_HI V2_PULSEWIDTH = *+1 cmp #$80 tya rol ;; So at this point we bnow have voice outputs 0-2 in bits 0-2 ;; except they're backwards because of the cmp,rol method ;; D0 = Voice 3 ;; D1 = Voice 2 ;; D2 = Voice 0 ;; ;; Which now just leaves us with.. ;; tay lda AUDVLUT,y sta AUDV0 ;; __ __ __ ;; __ __ V3 ;; __ V2 __ ;; __ V2 V3 ;; V1 __ __ ;; V1 __ V3 ;; V1 V2 __ ;; V1 V2 V3 ;; AUDVLUT: .byte 0,6,5,11,4,10,9,15 I actually regenerate AUDVLUT every frame based upon the 3 channels output levels, which pitfall2 fixed at 6,5,4 You can use any levels as long as they sum to 15, or you could make it whatever you want, there's bound to loads of cool noise laden effects by overdriving the thing :) Which is as near as dammit ot how pitfall2 works, except it gets the DPC to do 99% of it.. I onyl selected this method after getting disheartened with other more interesint wavetable based methods, which I though were worse than they were because of the emulator problems, but then started to focus on making the sequencer work with this simple setup before bolting back in a more compelx wavetable system, with proper levels, waveshapers (for filtery effects) and sample sounds, both fixed ptich (for speed, minaly drums etc..) and variable pitch, with sample loops etc.. Consider this a testvbed to get the sequencer running.. If I can get the sequencer running within the alloted time, the world is my oyster :) If anyone has any optimisations to this it'd be cool, but I can't see anymore cycles in this.. Clearly you can lose the CMP #$80 is you aren't interested in having a pulse width control, but it does break up the sameness of the voices, and a bit of pulse width modulation does stop it sound to static.. Anyway, that's the basis of the voices at the moment :) Not very interesting, but a nice simple statrting block to the sequencer.. > > Maybe you could aim for reducing the number of cycles and RAM at the > expense of ROM. ROM is much easier to come by. I will do once I get everything in place.. > Instead of using an event data style, my own music driver just uses > patterns and a pattern list that specify the pitch, sound type, and volume > of both oscillators for every tick in the song. So there's no duration > data. This makes the driver very simple and efficient with RAM. It's a > bit less efficient as far as ROM space, but I can still fit the driver and > a complex 3-4 minute song in 2k. Maybe switching to a music data > representation like that would save some RAM and cycles? I thought long and hard about that, but I'm personally not a fan of the MOD style of things. It strikes me as a bit lazy, but who knows what fate shall disk out to me, perhaps it'll be so hard making this blimmin sequencer work within these constraints that I'll give up and throw caution and ROM to the wind and go the MOD route.. Without a doubt it'll save me some time, but at the end of the day, I'd still have the same problem, which is breaking up *whatever* processing I do into little 40cycle chunks, be that a more complicated sequencer system, or the simpler mod style, though there'd be less events in the mod style, there'd still be multiple states per event, and I think that if I'm going to have to implement the horrible system of states I may as well use it to its max :) Well, you've got the basic code above, I'm sure you could bolt it into yours to do something interesting :) andym ---------------------------------------------------------------------------------------------- Archives (includes files) at http://www.biglist.com/lists/stella/archives/ Unsub & more at http://www.biglist.com/lists/stella/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [stella] 2600 Sound, that time , Paul Slocum | Thread | Re: [stella] 2600 Sound, that time , Andy Mucho |
Re: [stella] Bank-switching, Thomas Jentzsch | Date | Re: [stella] 2600 Sound, that time , Andy Mucho |
Month |