4mat wrote:

or type this into your hex editor:

7C 00 05 A2 29 3F A8 E5 A1 45 A2 05 A2 29 7F 99 00 D4 99 D7 CF 50 EB

Can I type this straight into memory with a monitor? At which address? (I'm a noob). There's a specific address where executables can be put, right? Or I can SYS it. Hmm..

Yes, if you skip the first two bytes (which are the file header) and put it into memory at $7c , then jump to $7c (or SYS 124) and it'll run.  Just tried that in Vice.  (I can't figure out how to type a bunch of hex bytes into Vice's monitor so used fill for each address )

If you type the whole thing into a hex editor and save that as a binary it'll autorun with LOAD "FILENAME",8,1

One thing to note is while the structure of the demo remains intact the audio & visuals change slightly depending on how long the c64 has been powered up before it's run.  In the video it's within the first 'second' of a boot-up, unfortunately this is beyond my control as there's no room to reset the timer values before the demo activates.  (putting code at $7c only gives you about 23 bytes to play with)

or type this into your hex editor:

7C 00 05 A2 29 3F A8 E5 A1 45 A2 05 A2 29 7F 99 00 D4 99 D7 CF 50 EB

Can I type this straight into memory with a monitor? At which address? (I'm a noob). There's a specific address where executables can be put, right? Or I can SYS it. Hmm..

My girlfriend: "how can you enjoy that? It's annoying."

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

With such a small source code it seems like this is as much a discovery as a creation? (I don't mean that disparagingly!)  Can you explain a bit about what is actually happening to produce this result?

I'd been trying some small music drivers that use the Commodore64's realtime clock to keep rhythm, rather than the
standard way of having an interrupt with a countdown for tempo.   While the output isn't particularly pleasant here's
a little 23 byte demo that messes with those registers and then outputs the data to the VIC-II and SID to make a
little glitch fest.  It ends after 9 minutes, I presume because the VIC-II eventually gets fed some bogus data. 
(I had to keep moving the visuals offset around to stop it crashing much earlier in the run)

Download the binary or type this into your hex editor:

7C 00 05 A2 29 3F A8 E5 A1 45 A2 05 A2 29 7F 99 00 D4 99 D7 CF 50 EB