Fitting 44% More Data on a C64/1541 Floppy Disk(pagetable.com)
pagetable.com
Fitting 44% More Data on a C64/1541 Floppy Disk
https://www.pagetable.com/?p=1107
10 comments
Back in de 80's, to double the data on a C64/1541 floppy disk, I used a hole punch to create a hole on the other side and flipped the disk.
I still have my disk puncher in a box. A nice niche product.
I thought this was a "niche/notch" pun but nope, completely different etymologies!
I, too, still have my notch punch. :)
I, too, still have my notch punch. :)
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).
(Email in profile)
(Email in profile)
If you can't find an official punch, I often used the Radio Shack nibbler tool to make this an easy job: https://a.co/d/hR2rKAp
If you can't find one take a look at:
https://retro8bitshop.com/?s=notcher&post_type=product
https://retro8bitshop.com/?s=notcher&post_type=product
They get HOW MUCH for that thing?!? And people pay that???
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
I replaced the write-protect sensor with a toggle switch.
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. :)
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.
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).
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.
But can it run Doom? I would not be surprised at all to find someone has found a way to double the C64’s processing power with it.
Here's a demo running on just the drive: https://cdm.link/2021/07/freespin-is-a-demo-made-for-the-com...
Hilarious!
The 6502 in the 1541 is somewhat hobbled having only 2k of RAM. Though you can solder a bigger SRAM on the board.
> 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.
Apple did the same thing. The difference between the Disk II and the various Commodore drives is instructive of the two companies' engineering philosophies.
I think tech progress was so fast at the time that customers were used to that. Commodore’s design was newer, so of course it was better.
Also, they got more capacity, but did they also get at least the same speed and reliability?
Also, they got more capacity, but did they also get at least the same speed and reliability?
> 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.
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.)
https://www.lemon64.com/forum/viewtopic.php?t=58317
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.)
https://www.lemon64.com/forum/viewtopic.php?t=58317
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.
> 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.
Wasn’t that the cassette head alignment?
Yeah, they are probably remembering the azimuth adjustment screw on a cassette player.
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…
Somewhat related is improving the speed of the drive by optimizing the GCR decoding: http://www.linusakesson.net/programming/gcr-decoding/index.p...
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…
Used to do the same thing myself. It worked! Until it didn’t and you lost data. Floppy roulette :)
[deleted]
Same vein for DOS:
https://en.wikipedia.org/wiki/IBM_Extended_Density_Format
https://en.wikipedia.org/wiki/2M_(DOS)
https://retrocomputing.stackexchange.com/questions/12768/wha...
I recall using an "extended" track to write hidden serial numbers to distribution disks. Not copy protection but phone support authentication.
https://en.wikipedia.org/wiki/IBM_Extended_Density_Format
https://en.wikipedia.org/wiki/2M_(DOS)
https://retrocomputing.stackexchange.com/questions/12768/wha...
I recall using an "extended" track to write hidden serial numbers to distribution disks. Not copy protection but phone support authentication.
An old "special format" DOS tool:
http://toastytech.com/files/nformat.html
http://toastytech.com/files/nformat.txt
More info about XDF (by IBM):
http://www.os2museum.com/wp/the-xdf-diskette-format/
http://toastytech.com/files/nformat.html
http://toastytech.com/files/nformat.txt
More info about XDF (by IBM):
http://www.os2museum.com/wp/the-xdf-diskette-format/
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...
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...
There were two of them. One was called DiskSpare, the other has escaped my memory. I don't know if either actually stuck to just 80 tracks.
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
On those hard plastic 3 ½" you could punch a hole an and format theme as 1.44mb. Roughly 10% of them could hold the data for more than few weeks.
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.
Yes! One of the PCs at my school had a 720 3.5” drive.
Another twist with that. Writing with in 720 mode from a normal PC drive worked most reliably if the diskette first was formatted in the 720 PC.
Another twist with that. Writing with in 720 mode from a normal PC drive worked most reliably if the diskette first was formatted in the 720 PC.
I tried that on the Acorn Archimedes.
It resulted in, after a couple of days, a lot of lost data. Luckily just games.
It resulted in, after a couple of days, a lot of lost data. Luckily just games.
You mean they could have fit Ultima 3 on 3 floppies instead of 4? I think of all of the swapping I had to do back then.
Didn't Apple do something similar with the floppy drives on early Macs?