4 ms·
Freespin: C64 demo running on 1541 floppy drive
- peter_d_sherman 5y ago>"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! Related: "How freespin bit bangs the video signal" http://www.quiss.org/freespin/raster.html http://www.quiss.org/freespin/raster.html
- ac29 5y agoFloppy drive music is pretty impressive, see also Floppotron: https://www.youtube.com/c/Pawe%C5%82Zadro%C5%BCniak https://www.youtube.com/c/Pawe%C5%82Zadro%C5%BCniak (they've got some non-floppy devices like scanners too)
- jmull 5y agoThis is crazy.
- krallja 5y agoYeah, I watched the whole video straight through with my mouth wide open. What in the heck!
- vidarh 5y agoSame 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...
- ChrisGranger 5y agoI 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.
- LocalH 5y agoVery impressive. I wonder if the burst mode of the 1571 would be useful at all
- basementcat 5y agoYes. 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.
- herio 5y agoThe 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.
- stevep98 5y agoThe 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
- rasz 5y ago> 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 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 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 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.php https://www.linusakesson.net/programming/gcr-decoding/index....
- stevep98 5y agoThanks for the info. I had remembered something like a 17x number but that just seemed like my mind was misremembering.
- arsenkay 5y agoSuper impressive!!! This is SO much work! This brings back great memories from the past when I was installing Doom from, like 12 floppies.
- Tommek 5y agoThis! is! hacking! Making something new, out of the technology you have at your hands. Probably he did not even had to use any JavaScript.
- ithkuil 5y agoit 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
- a1369209993 5y ago> 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.