The most fragile things in the universe (next to C64 PLA chips) are C64 GEOS boot disks. Because of its copy-protection, the “Graphic Environment Operating System” had to be booted from the original disk every time. The disk failed so often that the box came with a second “backup” boot disk.
If a disk failed, it could be sent in for a replacement. I happened to come across a stack of 50 broken original disks of the German GEOS 2.0 disk set that were sent in for replacement. Let’s analyze what went wrong with these disks!
GEOS Disks Basics
The GEOS boot disks are copy protected. Because overwriting a sector is not guaranteed to hit the exact same location as the original sector data, the Commodore disk format specifies two gaps around the sector data:
These gaps don’t normally carry useful information, but GEOS boot disks are mastered with all gaps filled with a signature of all $55 and $67 bytes on all tracks. During boot, GEOS checks that on track 21, all gap data is exclusively $55 of $67 bytes.
An unmodified 1541 disk drive cannot reproduce this: The 1541 cannot write a whole track in one go, because it cannot receive the data from the computer fast enough, and because it doesn’t have enough RAM to store a whole track.
When writing a track in mulitple passes, the 1541 has to write some sectors in one pass, and some other sectors in another pass – the only legal junction points for continuing to write are the sectors – which destroys either the signature before or after it, since after all, there is no way to start writing at an exact byte location.
A naive block copy onto a new disk will not have the signature and booting will fail. But even tools that are meant to defeat some copy protection schemes by copying some of the extended properties of a disk will fail to copy a GEOS disk1.
As a side effect of the way the copy protection works, writing a sector will also destroy the signature. The “System” and “Backup” boot disks contain the signature on all sectors on both sides, but only track 21 is ever checked. It is safe to write all sectors on other tracks, even though it would destroy these signatures. With broken GEOS disks, it is easy to see which sectors have ever been written by the user, and it is possible to correlate this with the errors on disk.
In addition, GEOS used the concept of serial numbers for protection. On first boot, the “System” disk picks a 16 bit random number, and stores it on both the “Backup” and the “System” disks. Some applications also remember the serial number on first start, and fail on subsequent starts if the serial number is different.
Overview
My set of sent-in GEOS disks consists of 50 disks total:
- 21x Disk 1/4: System
- 18x Disk 2/4: Backup
- 7x Disk 3/4: GeoSpell
- 4x Disk 4/4: Drivers
Here are the original .NBZ dumps (and for convenience also .G64 files): geos_broken.zip (32 MB)
Let’s look just at the System and Backup disks for now. If either boot disk was broken, both had to be sent in. So we should expect some of the System disks and most of the Backup disks working, which turns out to be the case:
| Disk | Boots | Disk Errors | User Error |
|---|---|---|---|
| System | 8 | 9 | 4 |
| Backup | 11 | 6 | 1 |
While three quarters of the failures are due to read errors, one quarter of the broken disks seem caused by user error.
User Error
In this article, let’s look at the user error ones. The read errors will be covered in a separate article.
Disk 21: Overwritten Sector
A single overwritten sector breaks this disk. Track 21, sector 3 is overwriten with garbage. This sector is not just part of the GEOS KERNAL, but also part of the copy protection, so the broken signature will make the protection check trip during boot.
It is unclear what caused this. The sector could have been written by the user, or by some malfunctioning program. The disk is fine otherwise and does not have any read errors.
Disk 12: Block Copy Restore
This disk probably stopped booting at some point, so the user decided to copy the disk over itself to get rid of some errors. Every sector of the disk has been re-formatted and rewritten, but contains the original data. All signatures are broken.
Interestingly, physical tracks 3 to 10 are occupied by data that claims to be logical tracks 1 to 8. And there are lots of secors that are not written at their corrrect places, overwriting surorunding data. The user might have used some copying tool with advanced functionality that messed up some things.
Disk 2: File Copy Restore
The next disk doesn’t boot for a similar reason: All signatures are missing, even the ID is different, and the boot and GEOS KERNAL files are missing.
The user probably encountered and error and decided to fix the boot disk. The GEOS disk copy program refuses to copy from or to the system disk, so the user might have decided to format the disk and do a file copy of the files from the backup disk.
The format of course removed all signatures. In addition, the GEOS file copier won’t copy the boot programs, so they ended up with a disk that contained everything but the actual OS core.
Disk 6: Incorrect Target of Block Copy
The user of the next disk probably mixed up their disks during a disk copy – and copied a disk full of copy programs onto it (“TURBOCOPY V1.0” and “DATA-BECKER ULTRA-COPY”). Ultra-Copy has an option to do a non-formatting block copy of only allocated sectors, which is what happened here, because the signature of 99 unchanged sectors is still intact.
The user then soft-formatted the disk, i.e. cleared the filesystem index.
Disk 39: Erased
The final disk in this category, this time a “Backup” disk, has also been erased. This user actually used this boot disk disk for data – maybe even on purpose, because… who needs backups? The disk contains a printer driver and an (erased) GeoWrite document (something about hospitals; without any personally identifying information).
Conclusion
Most disks that were made unbootable by the user seem to have been attempts to actually fix a presumably broken the boot disk.
In the second part, we will look at the read errors that makes GEOS disks unbootable.
-
The copy protection scheme was ultimately defeated by writing a sector with the correct gaps but no data onto track 21, which could be done in one pass, and moving the data that was originally there onto some other track.↩
It’s been over 30 years, but I definitely was able to create a Geos disk on a 1541.
It required running code in the 1541 itself, but it was a very short routine, and I created a USR file that was easily runnable on the drive. IIRC the syntax for runnung those was :
Open 1,8,5,”&0:FILENAME.USR”
So all you had to do was copy the GEOS disk, copy the single sector USR file, and then run it as above.
Did you ever had a look at GeoMakeBoot?