Freespin: C64 demo running on 1541 floppy drive | Hacker News Reader

Freespin: C64 demo running on 1541 floppy drive

quiss.org

174 pointsmatthiaskramm30 comments

The processor in the 1541 was identical to the c64… 6502. (Or 6510C)

The serial link between them was notoriously slow. I studied them extensively as a teenager, and had reams of disassembly printed out in fanfold dot matrix, with my own scribbles. This is how I learned 80% of my computing skill set.

The signaling between the drive and computer used a clock line and a data line. When reading from the drive, the drive would set the data bit then invert the clock. The CPU would be polling the clock line, and when it changed, it would read the data bit. There wasn’t any fancy hardware like DMA. It was basically two cpus connected to get her with a couple of I/O pins.

I can’t remember where I saw it, but there was an extremely fast driver going around, and sure enough I disassembled it to find out what they were doing.

Before each 256-byte sector was transferred there was a loop which synchronized the cpus in the drive and host computer, down the the clock cycle. Then they used both clock line and data line to blast all the data, two bits at a time down the lines. The cpus didn’t wait for any clock to change, they just read the data as fast as possible. Wrapped with a bit of error detection to top it off.. in the end it was about a 10x speedup with the same hardware…. Which at the time was totally mind blowing

> in the end it was about a 10x speedup

10x speedup is what every disk Turbo was doing back in the day, with ActionReplay6 topping off at 5KB/s

https://www.c64-wiki.com/wiki/Comparison_of_fast_loaders standard C64+1541:

    SAVE/LOAD: 374/407 bytes/sec
    SEQ write/read: 349/395 bytes/sec
    Data transfer: 455 bytes/sec

http://tech.guitarsite.de/fastloader.html

Real state of the art is pushed by Krill using technique you describe, and is capable of 20x:

https://csdb.dk/release/?id=189130

Article about one aspect of modern fastloaders - decoding GCR on the fly: https://www.linusakesson.net/programming/gcr-decoding/index....

Krill’s 50x loader (requires nonstandard format that’s still copiable by normal copiers): https://csdb.dk/release/?id=197710

Thanks for the info. I had remembered something like a 17x number but that just seemed like my mind was misremembering.

As someone younger... how did a teenager in that time period possibly get that level of technical introduction to things at that level?

I wasn’t bad with programming BASIC, but the true epiphany came when I went on vacation to Spain (very common for UK kids). I took the programmers reference manual which not only had info about BASIC, which I already understood, but it included info on all the 6502 opcodes and all the c64 registers. It really took me a long time to understand what this was. It would have been much easier to have a mentor to help me through this… it was a reference, not a tutorial.

But at some point, it clicked, and I started writing out the assembly… there was a register to control the screen background color… so I just blasted 0 into that register to make it black. In what was probably my greatest ever fear of engineering, I then hand-assembled my two-line assembly into 5 bytes of machine code. But I had to wait until I got back from vacation to try it.

It worked… it changed the background color, but it crashed the machine… I had forgotten to add ‘return from subroutine’, after that it worked, and that was the beginning of my journey.

I regret not spending more on proper tooling early on. But all the good assemblers were cross-assemblers that ran on pc’s.

There’s was also a really good book by Raeto Collin West that went into more details, and that’s where I got some of the drive register info. There is a command you can send to the printer to dump its memory, so that’s what I did. (To get it’s ROM to see what it’s drivers are doing)

The printer was critical to being able to read through the assembly and annotate it. You learn how to read ASCII in your head, etc.

Actually, unless you lived in a big city or near a university getting any level of programming books was tough...

However, assembly was more common back then and really wasn't consider a 'black art'. It was just what you did. Also, 8 bits were a lot simpler to program (flat address space, no protected mode, etc) - at most, you might have to deal with some bank switching..

Even hobbyist mags like Compute! would run articles on assembly - and DDJ would have that fancy 'C' stuff too!

To add to the "simplicity" aspect, I'd add: They were tiny.

You could read the entire OS ("KERNAL") and BASIC disassembly start to finish (there were books listing them, with comments added). You could systematically test what changing registers would do - I remember pestering my parents at work by calling them to let them hear what sounds I managed to make by randomly POKE'ing things into the sound registers just to experiment.

And of course the manuals. While I agree with you books were hard to get, the C64 manual was fantastic.

Do you have any links to books with the annotated disassemblies of the kernal/BASIC interpreter?

To GGP: you should get an 8-bit computer and play around a bit, some things may blow your mind. I first played around with a C64 in around 7th grade, after I'd already learned some programming on PCs, and I learned a lot.

not a book, but....

https://github.com/mist64/c64rom

Or even more interesting, the original sources from CBM:

https://github.com/mist64/cbmsrc

Oh! I should probably mention - Assembly was one of only 2 languages you were sure would be supported: you got ROM Basic, and an assembler. Later, you might get Forth,C,Pascal,Logo... especially if you could afford the 'big' CP/M or Apple ][ machines...Though those probably didn't have the ROM basic.

how did a teenager in that time period possibly get that level of technical introduction to things at that level?

Commodore published very detailed documentation for its computers, including schematics. You could buy these in most large book stores.

There was also lots of information available through local user groups, BBSes, BBS networks, and online services like GEnie, Delphi, The Source, and CompuServe.

Many local computer stores had regular meetings of their customers where people would exchange programs and information.

Youth shouldn't stop you, I walked into computer shops all day during my youth and I ended up with a job. This was early 00's, so Internet was there, and knowing a bit of HTML and how to reinstall windows was really all that's needed but -

Nowadays it's even easier with FB and such, just ask, and keep asking until you're satisfied.

Back then, it was the same, 80's, ask, community clubs, mailing lists, etc -

We're in tech, we communicate with one another, ask the right question and you'll get the right answer, even if it's questionable. ;)

There were magazines, and manuals were not too hard to find. (These things had real technical manuals, with lots of internals described)

My personal experience as a kid is more oriented towards the Amiga, but I suspect it was quite similar.

One fun fact, the place I grew up was a minority language region, so specialized magazines/books were only available in the dominant language of the country which was not yet part of my of my school curriculum.

I ended up reading most of that stuff in German having absolutely no idea what that meant; a double puzzle to solve.

Oh, I'm very curious, what language is that? Sorbian? Romansh?

Italian in southern Switzerland. Big enough so you can grow up listening and speaking it 100% of the time with little and no exposure to german/french, not big enough for newspaper/magazine distribution network to care about it (I'm pretty sure some fashon and general culture magazines were imported from italy, but not the Amazing Computing magazine...)

(Yes, I could have gone a few dozen kilometers cross the border to Italy to buy some, but I was a kid and my parents didn't indulge me further with this "toy")

Haha, we mostly didn't. I knew, roughly, what I wanted: assembly documentation, and a modem to find and talk to the people who knew. But I didn't have any of those things, and to be honest, it probably wouldn't have helped much if I had. The cracking/demo scene wasn't exactly friendly and accessible. Things are different today, with stars like LFT being very generous with explanations of how the magic is done.

>"Freespin is a Commodore 1541 demo, released in 2021. It runs on the Commodore floppy drive. It is is the first demo on this device. [Without the C64 attached!]

[...]

Freespin generates sound/music using the floppy drive mechanic (in particular, the stepper motor responsible for moving the head to the right track).

Video is generated through the [1541's] serial bus."

PDS: Absolutely amazing!

I have never seen this done before!

"How freespin bit bangs the video signal"

http://www.quiss.org/freespin/raster.html

Floppy drive music is pretty impressive, see also Floppotron: https://www.youtube.com/c/Pawe%C5%82Zadro%C5%BCniak

(they've got some non-floppy devices like scanners too)

This! is! hacking! Making something new, out of the technology you have at your hands. Probably he did not even had to use any JavaScript.

it would be fun to try to fit a JavaScript interpreter into that.

I did write a very small once but far from fitting in 2k ram

This is crazy.

Yeah, I watched the whole video straight through with my mouth wide open. What in the heck!

Same here. I'd consider myself pretty jaded about C64 demo effects. I've seen many impressive ones over the years, but it's extremely rare to see one this original, that isn't "just" a stepwise refinement of known effects but a massive leap.

At the same time it's a massive "d'oh" moment given the technique of having the CPU generate the video signal on 8-bit computers is much older than the C64, and running code on the 1541 is also well established.

[same approach on the C64 itself to do multi-monitor effects, anyone? Wire up the user port, tape and/or serial port.... Resolution would suffer, of course - but it'd be fun to see attempts...]

Given how heavily people have hacked it, both in terms of software and hardware it's amazing that it's been overlooked (and impressive to think of it). Then to get the idea, and not just leave it at a proof of concept but producing something this high quality...

> If needed, the 100 Ω resistor can be harvested out of the C64. (E.g. the not strictly necessary R14 AUD IN pulldown.) As such, this demo runs on stock C64 hardware and doesn't need any extra components.

This is wonderful.

I used to connect the line-out from my CD player to my Commodore 1702 monitor's RCA luma jack (I think) to make a primitive visualization that changed with the music, but this is amazing.

Very impressive. I wonder if the burst mode of the 1571 would be useful at all

Yes. The 6502 processor in the 1571 could run at 2 MHz (as opposed to 1 MHz in the 1541) so it has the potential to generate higher fidelity video and audio.

The 1571 also has a 6526 with a working hardware shift register in it, which is connected to the serial bus. Should allow for higher bitrates out than the CPU alone could support.

Reply on news.ycombinator.com