this is really cool

I bet it gives interesting values after loading some software beforehand.

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)

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

Brings a tear to my eye, beautiful.

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

23 bytes. Astounding as usual 4mat. Just awesome.

Like like!

That is indeed quite awesome

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.

Haha that is so cool. 23 BYTES. Awesome.

Wow... the way this evolves is fascinating!

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?

Bonus for posting the demo's code in its entirety.

inspiring!

Excellent!!!! Music sounds a bit skrju-ey. Would loading an image immediately before running this code be COOL or NOT COOL (broken)?

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