The Commodore 1541 was built to do one job—to save and load data from 5.25″ diskettes. [Commodore History] decided to see whether the drive could be put to other purposes, though. Namely, operating as a standalone computer in its own right!
It might sound silly, but there’s a very obvious inspiration behind this hack. It’s all because the Commodore 1541 disk drive contains a MOS 6502 CPU, along with some RAM, ROM, and other necessary supporting hardware. As you might remember, that’s the very same CPU that powers the Commodore 64 itself, along with a wide range of other 1980s machines. With a bit of work, that CPU can indeed be made to act like a general purpose computer instead of a single-purpose disk controller.
[Commodore History] compares the 1541 to the Commodore VIC-20, noting that the disk drive has a very similar configuration, but less than half the RAM. The video then explains how the drive can be reconfigured to run like the even-simpler MOS Technology KIM-1 — a very primitive but well-known 8-bit machine. What’s wild is that this can be achieved with no hardware modifications. It’s not just a thought exercise, either. We get a full “Hello World!” example running in both BASIC and machine code to demonstrate that it really works.
Code is on GitHub for the curious. We’ve featured hacks with the chunky Commodore 1541 before, too.
Thanks to [Bruce] and [Stephen] for the tip!

I don’t know why, but I feel I have read about this hack 30years ago…
This! For example this Mandelbrot program from 1991 used the 1541 as co-processor:
https://www.c64-wiki.de/wiki/Mandelbrot-Construction-Set
Also most fast loaders worked by running custom software on the floppy drive.
Something similar, but different had existed for the Macintosh, Atari ST and Amiga.
There was werw Mandelbrot programs that used an DSP chip (DSP3210 etc).
https://www.applefritter.com/node/12965
https://www.atariuptodate.de/en/7997/frac
https://aminet.net/package/driver/other/dsp3210.lha
I once wrote some code that ran inside the 1541 disk drive, which pulsed the disk access LED to the music that was playing on the C64. The same code also pulsed an attached modem’s LED lights in sync with the music, so all 3 channels of the SID were represented by the 3 LEDs pulsing on and off to the music. This was about 35 years ago.
https://hackaday.com/2021/07/08/c64-demo-no-c64/
To quote that article:
Does running that demo just on the drive count as test for being a general purpose computer (the input being the eject lever)?
Well, what about using the floppy drive as a storage for this computer to run code from it? Did not see this idea mentioned in the video.
I remember reading a story where a business, some time in the ’80s IIRC, had one big computer with a printer, and the printer had a CPU that was actually faster than the one in the main computer and could be tricked into doing some general-purpose computing unmodified. So, they ported big number-crunching jobs that were previously run on the main computer to be run on the printer overnight when it wasn’t printing.
I’m not having any luck finding the story now, but an Apple LaserWriter would fit the bill for the printer…
It might be this one thedailywtf [dot] com/articles/The-Killing-Job but there are likely many others, too. I know that article spurred me to look at using PostScript in “imaginative” ways.
lik this: https://www.tinaja.com/post01.shtml
More than 40 years ago, we were using the TWO 6502s in the Commodore PET floppy drives (GPIB interface!) as coprocessors. It was kind of ridiculous that the disk drive had more compute horsepower than the desktop machine. And that GPIB bus was pretty quick. Expensive, I recall. I think that Commodore pair of disk drives was much more expensive than two Apple ][ drives.
And the Apples might have even been quicker. Though compiling “Hello World!” in C from a pair of floppies (and a ramdisk) still took a coffee break.
True. The many years older PET floppy drives 8050/8052 were more sophisticated than the VC-20/C64 drives 1541/1540.
They were full versions, with 4 KByte of RAM rather than 2 KByte.
And the two 6502 processors working together.
https://en.wikipedia.org/wiki/Commodore_4040
https://en.wikipedia.org/wiki/Commodore_8050
Unfortunately, the 1541 was weaker in performance than the older 1540, too.
https://en.wikipedia.org/wiki/Commodore_1540
I imagine that 6502 was there to offload the sort of work the Apple II made the main CPU do bit-banging disk I/O (i.e. the infamous RWTS subroutine) which precluded fast loaders for us Apple and Franklin Ace users…
The Apple ][ already could read/write as fast as the disk can spin, so the only thing a fastloader could do would be to enable extra processing while doing disk I/O.
Commodore needed a CPU in its peripherals to process the high-level commands from the serial bus into actual disk operations. DOS was built into the drive instead of into the host.
Are you saying that DOS was literally disk OS ?
Well, more like Drive OS in Commodore’s case.
What’s interesting is that the 1541 was a disk drive with a computer inside for $400 in 1982, while Apple was selling a disk drive with minimal internal electronics for $400, plus a very simple (8 small ICs) interface card for another $150 (in 1982). Goes to show that pricing isn’t (just) about the BOM, but rather about knowing your customer.
In 1983 C64 was $300, 1541 was $300, 180K Tandon TM100-1 PC floppy drive was $189.
There’s a RAM upgrade mod for the 1541..
The default configuration is too little to copy certain floppies, but such a RAM upgrade makes it possible.
Now, a complete track can be held in RAM.
Example of such a RAM expansion:
https://github.com/ytmytm/1541-RAMBOardII
One of the disk copy programs would let you load it in memory on the drive and disconnect your computer and run it as a standalone disk duplicator. I would attend COW (Commodore Owners Workshop?) meetings in San Bruno California and trade disks with people. That was the best way to mass copy stuff and still have your C64 running to test out other stuff!
Fasthack’em could do that.
This idea scales. The DEC VAX-11’s of the late 70’s used the PDP-11’s that just a years prior were DEC’s flagship workstations as embedded peripheral controllers.
Then the Cray’s of the 80’s did the same thing with VAX’s
At first glance, it would seem that it is obvious that a device with its own CPU could be used to compute, as evidenced by the examples of peripheral based demos and co-processing. I felt similarly, with the drive having its own executable RAM and even the idea that a Commodore 64 could have been used as the terminal (using I/O commands), obviating the need to replace ROM chips or build an IEC-RS232 terminal adapter. This starts to unravel with having only 2k of RAM, while the ROMs have 16k.
I think though that the key component with the term general purpose computer is interactivity, in the sense that this 1541 can be used as an interactive computer using the same methods that were historically used to interact with computers (namely a terminal), without further intervention.
It would be cool to see it still retain some disk capability, so that programs could be stored and retrieved from the disk itself.
Bravo on the fine hack!
i had a commodore 1571 (the c128’s drive) that i added 32k of RAM to so i could run more complex routines on it. i went looking for it in my mother’s attic after she died but couldn’t find it
I would love to see somebody work out similar make-it-a-general computer software for the 1571 and/or 1581 drives. I still own a 1571 and a 1581, so… It would be beyond my capabilities to work it out myself.
It’s not really news though. One could program a pair of 1541 (set to 8 and 9 obviously) to have a master/slave relationship. Then you could carefully disconnect IEC cable from the C64 and it’ll run independently making copy from master to slave drive.
This allowed me to make multiple copies of BASIC programs and a few ML programs that didn’t use copy protection trick. Put in a disk to be copied in 8, put in a blank disk in 9, when both drive lever is locked down, it starts and one can go work on 17-course meal, take a shower, take your cat to the vet for snippy balls, etc. It’ll be waiting when done and ready for the next disk
Hmmm I have a pet 8032, a printer and twin floppy disk drives knocking about…….
This just reminds me of the Cellular modem in android phone that the modem itself is also running android.
Drive music anyone? Slamming the read write head against the home position end stop to play tones…..
Commodore disk drive IS a computer because it has to connect to another computer. One that was terribly poorly designed from the start. That’s why they couldn’t make something much simpler and functional: they had to almost start from scratch because of the shoddy work they did initially. The Commodore 64 has very serious design flaws. That’s why it hardly sold in many parts of the world and was surpassed by the MSX.
The C64 uses a 6510, not a 6502. Just a technicality…
But can it run doom?
Some guy got doom running on a receipt printer, surely this would be better.
surely the receipt printer capable of running doom was from 1982 too?
I recall a hardware mod for the 1541 called Dolphin DOS which used to speed disk access up quite substantially (although the 1541 was so slower than a sloth anyway – I recall waiting ages and swopping floppies while using the Cbm Macro Assembler). I also remember a book called Inside the 1541 which had disassemblies for the 1541 “OS”.
All this garbage because Jack Tramiel didnt want to spend $5 on a floppy controller chip. Owning MOS meant $0.5 per 6502 thus everything at Commodore became hacks on top of other terrible hacks.
The idea of microcontrollers in your peripherals is actually a pretty nice idea, provided that they’re hanging on a decent bus and that low price isn’t the main objective. That’s where the fails begin.
Seven Cities of Gold ran a substantial portion of the world builder in the 1541. What isn’t discussed is the chronic overheating problems with the drive and the negative effect it had on the disc reliability. There was no good old days when the 1541 was involved…