Would any of you notch punch holders be willing to let me borrow it? They're rather difficult to find for purchase, and I'm not comfortable with my motor skills with scissors, but I've got about 75 disks that need a second notch. Near Seattle, WA, USA. Can compensate with dollars or happy to share some of the disks (made in the bay area, addressed to an east coast computer builder but appatently never sent).
this was the first thing i did when i bought a 10-pack of new floppies (i used scissors). still remember that sweet box fresh smell from opening a new box of floppies
Very interesting, I love these deep-dives into the beloved 8-bit machines of the (my) past.
Meta: I was going to say something fun/snarky about the humor in a retro-computing page using Python 2.x code, but the page is from (2019) which I guess could be noted in the title. Very cool, it's interesting how the disk format itself is defined by software, and of course how Commodore cheapened out by replacing the mechanism manufacturer's (Shugart) controller with a design of their own.
Must have been fun (?) to work at Shugart and have a customer replace your controller with their own solution, saving money, and also getting better capacity out of the drive. That sounds like something that would be kind of annoying to explain to other customers. :)
>how Commodore cheapened out by replacing the mechanism manufacturer's (Shugart) controller with a design of their own.
I'm not sure it was wise, but "cheapened out" doesn't seem right either. The C64 disk drives have their own 1MHZ 6502 CPU inside them, so they have roughly the same amount of CPU as the C64 itself.
Commodore had bought out MOS by this point and manufactured 6502 chips themselves, so the drive CPU was "free" in a sense.
Also it's worth noting that the Commodore DOS talked about in the article was implemented and ran entirely on the drive, not the host computer. Commodore computers only understood a simple serial protocol and DOS commands like rename, delete or format disk were just sent as text commands on the serial command channel, which were interpreted and run by drive itself.
The computers had no concept of a filesystem at all: displaying the disk directory involved a hack where the drive would construct a fake BASIC program and stream it to the computer when a special filename "$" was loaded. That's why displaying the disk directory on a Commodore computer would clobber any BASIC program in RAM. A common blunder was to list the directory before saving and losing your work.
While the disk drives were smart, the tape drives were dumb. Tape drives came first and were designed along side the computer architecture starting with the PET. The disks were an add on later once disk drives caught on as the home computer medium of choice. The computers actually had a significant amount of precious ROM space dedicated to tape drive operation which was completely wasted in the later C64 timeline when most users were using disks exclusively. Some later ROM replacements like the excellent JiffyDOS system repurposed the tape code in their ROMs to provide a built in fast loader and DOS wedge (a whole other rabbit hole).
I still remember having my mind blown at a Pirates of Puget Sound party in the 80s where there were banks of 1541 drives connected in pairs happily copying disks with no C64 connected to the drives. Just insert two disks and it would copy from A to B. That was when I realized the 1541 drives weren't just drives, they were computers themselves.
> Must have been fun (?) to work at Shugart and have a customer replace your controller with their own solution, saving money, and also getting better capacity out of the drive. That sounds like something that would be kind of annoying to explain to other customers. :)
Apple did the same thing. The difference between the Disk II and the various Commodore drives is instructive of the two companies' engineering philosophies.
> Also, they got more capacity, but did they also get at least the same speed and reliability?
1541 was horribly slow because the marketing people wanted it to be backwards compatible with VIC-20, and the serial protocol used by the VIC-20 was very slow because of a timing bug found at the last minute. It was possible to multiply the default speed by an order of magnitude or more using custom firmware, but stock software was almost slower than using a cassette tape.
Compatibility with the shift register in the VIC-20 CIA was a part of it, but Commodore had a “fix” that was removed from the board during a revision that would have resulted in fast serial transfers from the 1541 on a C-64.
Finding primary sources while on my phone is difficult, but there’s some discussion here that would probably point you to a primary source. (Bill Herd and other have spoken about it in panels at various VCF gatherings.)
Ooh, I didn't know this detail. Thanks. It sounds terrifying:
> It also had something to do with a board screw hole. Iirc, the pcb already had a screwhole where the traces should be. Robert Russell was the engineer who designed those IEC traces and so when he found out about it, he was pretty much upset, but it was too late, they already modified thousands of boards.
There was a trimmer potentiometer one could adjust until errors would occur and then turn back just a little that would result in a speed increase. It may have been the motor speed I can't remember.
Regarding reliability, I doubt it was due to the controller, but where I lived the drive needed a fan blowing on it to keep it from overheating. But my parents didn’t run the ac much…. Fun times…
In high school, my friend used his dad’s drill press to drill a hole in cheap 720KB floppies to make the computer recognize them as 1.44MB instead. The disks worked perfectly at the higher density, making you wonder whether these were identical to the more expensive units…
All 3.5" floppy drives shipped with the Commodore Amigas were capable of using 84 tracks in total, though AmigaDOS and AmigaOS' low-level libraries limit themselves to just 80 tracks. Some games and other software made use of extra tracks (usually 81 or 82) for both copy protection schemes and to squeeze in a bit more data per disk, without any known reliability issues.
I remember there was a freeware file system for AmigaDOS that could store 920 KB on a floppy without using more tracks.
The regular AmigaDOS file system stored 880 KB, Macintosh 800 KB and MS-DOS 720 KB.
I remember there was one utility for MSDOS as well. The name escapes me :(
Those sorts of utils kinda worked on usually if you were on your own computer. But if you really pushed them and the tried to go over to a friends house with one good luck...
As mentioned in the comments in the linked article, it appears to be possible to improve capacity by an additional 9 percent with a more efficient GCR encoding.
https://csdb.dk/forums/?roomid=11&topicid=94092
I never ran into that, having repurposed several hundreds of DD floppies for HD use. But the opposite situation was common with many different brands of both 3.5" and 5.25" discs: HD floppies that were problematic to write to using a DD drive, because of different thickness and composition of the magnetic layer.
