The story of FCopy for the C-64
The story of FCopy for the C-64
by Thomas Tempelmann, reprinted with permission.
Back in the 80s, the Commodore C-64 had an intelligent floppy drive, the 1541, i.e. an external unit that had its own CPU and everything.
The C-64 would send commands to the drive which in turn would then execute them on its own, reading files, and such, then send the data to the C-64, all over a propriatory serial cable.
The manual for the 1541 mentioned, besides the commands for reading and writing files, that one would read and write to its internal memory space. Even more exciting was that one could download 6502 code into the drive’s memory and have it executed there.
This got me hooked and I wanted to play with that – execute code on the drive. Of course, there was no documention on what code could be executed there, and which functions it could use.
A friend of mine had written a disassembler in BASIC, and so I read out all its ROM contents, which was 16KB of 6502 CPU code, and tried to understand what it does. The OS on the drive was quite amazing and advanced IMO – it had a kind of task management, with commands being sent from the communication unit to the disk I/O task handler.
I learned enough to understand how to use the disk I/O commands to read/write sectors of the disk. Actually, having read the Apple ][‘s DOS 3.3 book which explained all of the workings of its disk format and algos in much detail, was a big help in understanding it all.
(I later learned that I could have also found reverse-eng’d info on the more 4032/4016 disk drives for the “business” Commodore models which worked quite much the same as the 1541, but that was not available to me as a rather disconnected hobby programmer at that time.)
Most importantly, I also learnt how the serial comms worked. I realized that the serial comms, using 4 lines, two for data, two for handshake, was programmed very inefficiently, all in software (though done properly, using classic serial handshaking).
Thus I managed to write a much faster comms routine, where I made fixed timing assumptions, using both the data and the handshake line for data transmission.
Now I was able to read and write sectors, and also transmit data faster than ever before.
Of course, it would have been great if one could simply load some code into the drive which speeds up the comms, and then use the normal commands to read a file, which in turn would use the faster comms. This was not possible, though, as the OS on the drive did not provide any hooks for that (mind that all of the OS was in ROM, unmodifiable).
Hence I was wondering how I could turn my exciting findings into a useful application.
Having been a programmer for a while already, dealing with data loss all the time (music tapes and floppy disks were not very realiable back then), I thought: Backup!
So I wrote a backup program which could duplicate a floppy disk in never-before seen speed: The first version did copy an entire 170 KB disk in only 8 minutes (yes, minutes), the second version did it even in about 4.5 minutes. Whereas the apps before mine took over 25 minutes. (Mind you, the Apple ][, which had its disk OS running on the Apple directly, with fast parallel data access, did this all in a minute or so).
And so FCopy for the C-64 was born.
It became soon extremely popular. Not as a backup program as I had intended it, but as the primary choice for anyone wanting to copy games and other software for their friends.
Turned out that a simplification in my code, which would simply skip unreadable sectors, writing a sector with a bad CRC to the copy, did circumvent most of the then-used copy protection schemes, making it possible to copy most formerly uncopyable disks.
I had tried to sell my app and sold it actually 70 times. When it got advertised in the magazines, claiming it would copy a disk in less than 5 minutes, customers would call and not believe it, “knowing better” that it can’t be done, yet giving it a try.
Not much later, others started to reverse engineer my app, and optimize it, making the comms even faster, leading to copy apps that did it even in 1.5 minutes. Faster was hardly possible, because, due to the limited amount of memory available on the 1541 and the C-64, you had to swap disks several times in the single disk drive to copy all 170 KB of its contents.
In the end, FCopy and its optimized successors were probably the most-popular software ever on the C-64 in the 80s. And even though it didn’t pay off financially for me, it still made me proud, and I learned a lot about reverse-engineering, futility of copy protection and how stardom feels. (Actually, Jim Butterfield, an editor for a C-64 magazine in Canada, told its readers my story, and soon he had a cheque for about 1000 CA$ for me – collected by the magazine from many grateful users sending 5$-cheques, which was a big bunch of money back then for me.)
The story of 15 Second Copy for the C-64
by Mike Pall, published with permission.
[This is a follow-up to Thomas Tempelmann’s Story of FCopy for the C-64.]
Ok, I have to make a confession … more than 25 years late:
I’ve reverse-engineered Thomas Tempelmann’s code, added various improvements and spread them around. I guess I’m at least partially responsible for the slew of fast-loaders, fast-copys etc. that circulated in the German C64 scene and beyond. Uh, oh …
I’ve only published AFLG (auto-fast-loader-generator) under my real name in the German “RUN” magazine. It owes quite a bit to TT’s original ideas. I guess I have to apologize to Thomas for not giving proper credit. But back then in the 80’s, intellectual property matters wasn’t exactly something a kid like me was overly concerned with.
Later on, everyone was soldering parallel-transfer cables to the VIA #1 of the 1541 and plugging them into the C64 userport. This provided extra bandwidth compared to the standard serial cable. It allowed much faster loading of programs with a tiny parallel loader (a file named “!”, that was prepended on all disks). Note that the commercial kits with cables, custom EPROMs and silly dongles followed only much later.
So I wrote “15 second copy”, which worked with a plain parallel cable. Yes, it copied a full 35 track disk in 15 seconds! There was only one down-side: this was only the time for reading/writing from and to disk — you had to swap the floppies seven times (!) and that usually took quite a bit more extra time! ;-)
It worked by transferring the “live” GCR-encoded data from the 1541’s disk head to the C64 and simultaneously doing a fast checksum. Part of the checksumming was done on the 1541, part was done on the C64. There simply weren’t enough cycles left on either side! Most of the transfer happened asynchronously by adjusting for the slightly different CPU frequencies and with only a minimum number of handshakes. This meant meticulous cycle counting and use of some odd tricks.
The raw GCR took up more space (684*324 bytes) in the C64 RAM, so that’s why it required 4 passes. Other copy programs fully decoded the GCR and required only 3 passes. But GCR decoding was rather time-consuming, so they had to skip some sectors and read every track multiple times. OTOH my program was able to read/write at the full 300rpm, i.e. 5 tracks per second plus stepper time, which boils down to 2x ~7.5 seconds for read and write. Yep, you had to swap the floppies every 2 seconds …
Ok, so I spread the program. For free. I even made a 40 track version, which took 17 seconds. Only to see these coming back in various mutations, with the original credits ripped out, decorated with multiple intros, different groups pretending they wrote it or cracked it (it was free, there was nothing to crack!). The only thing they left alone were the copy routines, probably because they were extremely fragile and hard to understand. So it was really easy to recognize my own code. Some of the commercial parallel-cable + ROM kits even bragged with “Backups in 15 seconds!”. These were blatant rip-offs: they basically changed the screen colors and added a check for their dongles. Duh.
Let’s just say this rather frustrating experience taught me a lot and that’s why I’m doing open source today.
So I shelved my plans to write an enhanced version which would try to compress the memory to reduce the number of passes. Ah, yes … I wrote quite a few packers, too … but I’ll save that story for another time.
I still have the disks with the source code somewhere in my basement. But I’m not so sure I’ll be able to read them anymore. They weren’t of high quality to begin with … and I’d have to find my homegrown toolchain, too. ;-)
But I took the time to reverse-engineer my own code from one of the copies that are floating around on the net. For better understanding on the C64/1541 handshake issues, refer to this article. If you’re wondering about the weird
bvc * loops: the 6502 CPU of the 1541 has an SO pin, which is triggered by a full shift register for the data from the disk head. This directly sets the overflow flag in the CPU and allows reading the contents from the shift register with very low latency.
Yes, there’s a lot more weird code in there. For the sake of brevity, here are only the inner loops of the I/O routines for the read, write and verify pass for the C64 and the 1541 side. Enjoy!
;--- 1541: Read --- ldy #$20 f_read: bvc * ; Wait for disk shift register to fill clv lda $1c01 ; Load data from disk sta $1801 ; Send byte to C64 via parallel cable inc $1800 ; Toggle serial pin eor $80 ; Compute checksum for 1st GCR byte in $80 sta $80 bvc * clv lda $1c01 ; Load data from disk sta $1801 ; Send byte to C64 via parallel cable dec $1800 ; Toggle serial pin eor $81 ; Compute checksum for 2nd GCR byte in $81 sta $81 ; ... ; Copy and checksum to $82 $83 $84 ; And another time for $80 $81 $82 $83 $84 with inverted toggles ; ... dey beq f_read_end jmp f_read f_read_end: ; Copy the remaining 4 bytes and checksum to $80 $81 $82 ; Lots of bit-shifting and xoring to indirectly verify ; the sector checksum from the 5 byte xor of the raw GCR data ;--- C64: Read --- ; Setup ($5d) and ($5f) to point to GCR buffer ldy #$00 c_read: bit $dd00 ; Wait for serial pin to toggle bpl *-3 lda $dd01 ; Read incoming data (from 1541) sta ($5d),y ; Store to buffer iny bit $dd00 ; Wait for serial pin to toggle bmi *-3 lda $dd01 ; Read incoming data (from 1541) sta ($5d),y ; Store to buffer iny bne c_read c_read2: bit $dd00 ; Wait for serial pin to toggle bpl *-3 lda $dd01 ; Read incoming data (from 1541) sta ($5d),y ; Store to buffer iny bit $dd00 ; Wait for serial pin to toggle bmi *-3 lda $dd01 ; Read incoming data (from 1541) sta ($5d),y ; Store to buffer iny cpy #$44 bne c_read2 ;--- C64: Write --- ; Setup ($5d) and ($5f) to point to GCR buffer ldy #$00 tya c_write: eor ($5d),y ; Load from buffer and compute checksum bit $dd00 ; Wait for serial pin to toggle bpl *-3 sta $dd01 ; Store xor'ed outgoing data (to 1541) iny eor ($5d),y ; Load from buffer and compute checksum bit $dd00 ; Wait for serial pin to toggle bmi *-3 sta $dd01 ; Store xor'ed outgoing data (to 1541) iny bne c_write c_write2: eor ($5f),y ; Load from buffer and compute checksum bit $dd00 ; Wait for serial pin to toggle bpl *-3 sta $dd01 ; Store xor'ed outgoing data (to 1541) iny eor ($5f),y ; Load from buffer and compute checksum bit $dd00 ; Wait for serial pin to toggle bmi *-3 sta $dd01 ; Store xor'ed outgoing data (to 1541) iny cpy #$44 bne c_write2 ldx $5b sta $0200,x ; Store checksum for verify pass inx stx $5b ;--- 1541: Write --- ldy #$a2 lda #$00 f_write: bvc * ; Wait for disk shift register to clear clv eor $1801 ; Xor with incoming data (from C64) sta $1c01 ; Write data to disk shift register dec $1800 ; Toggle serial pin lda $1801 ; Reload data to undo xor for next byte bvc * ; Wait for disk shift register to clear clv eor $1801 ; Xor with incoming data (from C64) sta $1c01 ; Write data to disk shift register inc $1800 ; Toggle serial pin lda $1801 ; Reload data to undo xor for next byte dey bne f_write ;--- 1541: Verify --- ; Get checksum computed by c_write on the C64 side ldy #$a2 f_verify: bvc * ; Wait for disk shift register to fill clv eor $1c01 ; Xor with data from disk bvc * ; Wait for disk shift register to fill clv eor $1c01 ; Xor with data from disk dey bne f_verify ; Verify is ok if checksum is zero
Comments
Post a Comment
Leave your comments.. Everything posted is the truth and it took decades to unravel.