Re: [stella] 2600 Sound, that time of year..

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
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
;;    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
    cmp #$80
;;    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
    cmp #$80

;;    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..
    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 :)


Archives (includes files) at
Unsub & more at

Current Thread