Thankyou. Going into a little more detail: With the kernal system running (the default on bootup) the c64 has a realtime clock
active. It uses the zeropage addresses $a0-$a2 for minutes, seconds, and... not quite milliseconds. They call it a 'jiffy clock' which
translates to it being 50fps for PAL and 60fps for NTSC. Anyway, as the system is still enabled those addresses are counting up at a regular rate. My code then takes the values in $a1 and $a2, does some bit shifting and subtracting and then uses the results twice. Once for the Y index so I can offset to other parts of the VIC-II and SID chips, and then the second time for what value to put in the chips for that loop. There is no timing inside the demo itself so things are running as fast as the CPU can do them. (which is why the sound is quite 'bubbly' sounding)
; assembled to address $007c in the zeropage of memory. This is a known trick to allow tiny programs to
; execute by loading them with LOAD"FILENAME",device,1
* = $7c
; OR accumulator with the millisecond register.
ora $a2
; AND it to be a value between 0 and 63, then tranfer to the Y index.
; We don't want too much range for the SID/VIC addresses to write to.
and #$3f
tay
; More messing with the accumulator value, limiting the range to 0-127.
; This will be the value that gets written to the other chips and gives us
; enough values to keep the display and audio interesting. (though no
; noise waveform as that would require $81)
sbc $a1
eor $a2
ora $a2
and #$7f
; Write to SID chip.
sta $d400,y
; Write to VIC chip. By rights the address should be $d000 , however
; because some written values end up crashing the demo or freezing it
; I offset back to a reasonably "safe" area. This overlaps from the end of the
; ram bank at $c000.
sta $cfd7,y
; As the overflow flag is always clear I can use this to loop back. The other
; branch types always resolve and a JMP command costs another byte.
bvc $7c
I agree, the workflow for the demo was much more discovery than a direct creation. I
called the demo 'Wallflower' because it's almost like a dance, the sprite blocks begin
clustered around the sides of the screen and then interact with each other as the
environment changes, with the ORA & EOR sequences in the code forming and dissolving
relationships between the different blocks in turn.
)