When we think of retrocomputing, it’s very often the computers themselves that get all the glory. There’s nothing wrong with this of course- the computers of the late 70’s and 80’s were incredible machines that were chock full of hacks in their own right. But some of the most interesting hacks of the day happened not in the computers, but rather in their peripherals. A devotee of such periphery is [Michael Steil], who was driven to compile years of research, knowledge, and hard data into The Ultimate Commodore 1541 Drive Talk which you can view below the break.
In the talk, [Michael] covers the physical disk composition and construction, the disk drives, controller hardware, and the evolution thereof. The bit-by-bit breakdown of the tracks, sectors, and header information on the disks themselves is fascinating, as is the discussion of various copy protection techniques used by vendors to prevent piracy at a time when sneakernet was in full swing.
The descent into the circuitry of the controller reveals a venerable 6502 CPU which powered many vintage computers. Further discussion divulges the secrets for getting higher performance from the 1541 drive using innovations that are as recent as 2013.
A computer historian and archaeologist, [Michael] discusses how using modified vintage hardware is sometimes enough to save your old floppy collection. He also shows how modern interfaces that read disks all the way down to the magnetic flux level can be used to reconstruct missing data.
[Michael] masterfully lays bare the complexity, engineering, and hackery that went into storing less than 200kb of data. Whether you’re a Commodore enthusiast or not, your appreciation for the 32GB USB stick collecting dust on your desk is bound to grow!
We’ve covered [Michael]’s exploits before, and you may wish to check out the Ultimate Apollo Guidance Computer Talk or the Ultimate Gameboy Talk. Do you have your own favorite retrocomputer hacks and insights to share? Be sure to let us know via the Tip Line!
Fantastic!
Using small ‘b’ for bits is not uncommon – for example in memory datasheets ( like this one https://www.onsemi.com/pdf/datasheet/le25u40cmc-d.pdf , or this one https://www.micron.com/-/media/client/global/documents/products/data-sheet/nand-flash/20-series/2gb_nand_m29b.pdf )
After rather too many years, the thing I came to realise about correcting someone is: Did I understand them without having to work much harder than I would have done with that correction in place? If so – am I assuming nobody else is as smart as me, or just trying to show everyone that I’m smarter than the person I’m correcting?
+1
Fantastic talk, horrible drive. I still can’t believe why they shipped the original model without a light barrier, added one in 1541c, just to be removed in the 1541-ii again. What’s worse, the 1541-ii had the the predecessor’s firmware, so the presence of a light barrier had to faked in hardware. And then there was the buggy serial interface (multiple bugs) with its 300-400 baud that was slower than the datasettes on other platforms.. and even if you had a proper 1571 and you fixed the serial connection in your C64 (using 1571 “fast busmode” trough connecting SRQ and DATA of the CIA1 with pin 4 and pin 5 on user port), you would loose datasette support ? Also, speed loaders (JiffyDOS etc). They would replace the datasette routines, to save space in ROM.. Great. So you could nolonger use the datasettes you already had or which your friends gave to you. Anyway, nothing against the C64 itself. It’s just the IEC drive interface that felt like an epic fail, I think.
I was thinking of Commodore and its 1541 series.. The Ultimate 1541 is a different beast, of course. My bad.
Thing is, why would you want to use the tape when you had a floppy? Even back in its heyday, SpeedDOS and off you go. Everything released on tape was released on disk also. And if you really needed that tape, turn off the speeder.
I have had the real 8 inch floppy without a cover. IBM System23 with the Brady Operating System!
I’ll accept this kibbi mibbi BS the minute someone invents a computer that operates on base 10.
Until then a KB is 1024 bytes
IBM 650.
Nope, sorry. The IBM 650 used bi-quinary.
I remember how upon purchasing a 1541 I felt like I had just joined the modern world.
My ZX81 of course lacked a HD, and my C64 started out with a 1530 “Datassette”
The only thing I disliked was the fact various disk formats (Apple, IBM, etc.) were incompatible. No working on a C64 at home and them bringing the file to work.
great talk!
The blog he mentions https://www.pagetable.com is also great too, it contains lot’s of info presented in a very useful way., certainly worth a visit and scroll through the huge amount of articles.
The C64 dumb design fault of some data lines and the resulting very lame 1541 should´ve been the very end of the C64.
But mysterious – the market produces “Speed Loaders” and many other “Kernel Expansions Cartridres” who forces the glorious Leader of Home Computers.
Btw:
1987 i´d a very big experience in Hardware Extensions and sold my entire C64/C128 Collection due to a employment in a “serious” Company to buy my an AT 16Bit Computer with 5 MB HD as Development Device.
But my alcoholic Mom stole the entire Money and declared:
“You´re my son, and i´ve the right to take your Money ´cause i raised you!”
Never she´d do that but every day (99%) in my youth she was drunken beated me, called me a sh*th*le etc.
That last day, i was 16, i left home…
Sounds like you got out just in time.
Wondering if anyone ever made a Frankenstein’s monster by mapping actual 1541 I/O devices into an actual C64 bus. It was only a couple of 6526 chips (or were they 6522s? Idk, about the same) and a bit of ROM in the 1541. Fiddle around with some ROM patching, and boom, GCR off the rust directly into the 64’s main memory. Of course, that pesky VIC-II comes and steals the bus once every character row, which would blow the 1541 bit banging to, well, bits – so it’d have to use that wretched ‘disable the VIC’ thing..
The best you can do is to connect drive mechanism directly to one of CIAs (or you can split I/O space and add a VIA or CIA#3). C64 would handle head position, read data and do GCR decoding.
Unfortunately it doesn’t have much sense. The fastest fastloaders (like the one from Action Replay) do GCR decoding on the fly, *during* transmission over serial bus.