So, the Commodore floppy drives had a 6502 CPU and a little bit of RAM, which was often loaded with custom fast-load routines because by default it was infamously slow. No video chip, though.
Well, this mad scientist decided two output lines was a perfectly usable composite video output, using a resistor on one of the lines to generate h-sync and v-sync signals.
The C64 is used strictly to load a custom routine into the floppy drive and is then discarded. The floppy drive itself plays the ensuing demo, with the 6502 generating the video signal on the fly.
I very much recommend Matthias Kramm’s technical writeups too - here’s the explanation of the unique approach to encoding data on the floppy (which is compatible with distribution as a disk image): Freespin’s loader
Again, we’re not actually “decoding” GCR here. What we originally encoded in GCR is different from what we decode above. But the point is that we can control what is going to get decoded. We just have make through some hoops when generating a d64 disk image.
Actually, it turns out that leaking the carry from one adc to the next actually helps the encoder. It’s easier to find an encoding for a block with the leaking than without.
In the freespin demo, all this, together with timekeeping logic, is distilled into 254 bytes of loading code, which is resident at $0702.
