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.)

35 thoughts on “The story of FCopy for the C-64”

  1. Some times reverse Engineering encourage a person to discover something. Newton wants to prove Einstein theory wrong but discover a newton laws……..

  2. Ok, I have to make a confession … more than 25 years late:

    I’ve reverse-engineered TT’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.

    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, intellectual property matters wasn’t exactly something a kid like me was overly concerned with.

    Later on, when everyone was soldering parallel-transfer cables to their 1541, I wrote “15 second copy”. Yes, it copied a full 35 track disk in 15 seconds! There was only one down-side: this was only the time for the copy — you had to swap the floppies 7 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 async by adjusting for the slightly different CPU frequencies and with only a minimum number of handshakes.

    The raw GCR took up more space (684*325 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 this meant they had to skip (at least) every other sector and read every track multiple times. But my program was able to read/write at the full 300rpm, i.e. 5 tracks per second plus stepper time, which boils down to ~7.5 x 2 seconds for read and write. Yep, you had to swap the floppies every 2 seconds …

    Ok, so I spread the program. For free. Only to see it coming back in various mutations, with the original credits ripped out, decorated with multiple intros, different groups pretending they wrote it. The only thing they left alone were the copy routines, because I don’t think anyone was able to decipher how it really worked. 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. Umm, 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. ;-) ]

  3. >>>In the end, FCopy and its optimized successors were probably the most-popular software ever on the C-64 in the 80s.

    ha ha, good one. prove it or stfu.

    there was tons of really great software for the C-64 so this statement is bull sh*t.

  4. Oh man holy nerdism. Great story. What a crazy time it was back then. Every new computer release was like a revelation in new speed, memory, storage capabilities, and graphics. My first computer was a TRS-80 Model 1.
    The original unit is one of the first 10,000 manufactured and is still able to boot today. I booted NEWDOS 80 on it just about 9 month ago or so. That machine had an 8 bit Z-80 microprocessor and 4k bytes of ram in it’s first conception. There was a cassette drive for Data transfer. POWER CHEESE!! You would start the tape. Pause it when you heard the tone. Issue the ‘load’ command at the READY> Prompt and and press play, and watch the asterisk blink in the upper corner of the screen.
    The first version of the computer was released with regular non silver bearing solder on the buss connectors. We got the expansion interface unit less than a year after getting the main 4k system. We had purchased some ram IC’s at the Rochester, NY Hamfest and decked out the KB unit to the full 16k ram. Then we got the fully loaded ram in the expansion interface and had our full blown 48k ram unit.
    Soon after that we found out that the ribbon cable connecting the expansion interface to the main KB unit was flakey. Turns out the non silver bearing solder was oxidizing enough to blow the data link on the connection to the expansion interface over the ribbon.
    Radio Shack’s official recommendation for this was to use a pencil eraser to clean off the buss connectors!!! HAHAHAHA!!! After hearing that, and seeing the time period between failures being about every two weeks, my father made the decision to fix the problem.
    At our kitchen table, to my Mothers great chagrin, we completely disassembled the expansion interface unit and KB unit and thoroughly solder wicked off all the crap solder from every buss connector pin on both units and resoldered them with silver bearing solder. THIS SOLVED THE PROBLEM PERMANENTLY We never saw it again.
    We were still using the tape drive at the point. I was running stuff like Microsoft Adventure Series. These were text based adventures. You would start with something coming across the split screen saying something like “You are strapped in a surgical chair. Your hands and legs are bound tight. Around you are….blah blah blah…” So you would then tell it to do something like, “Untie your hands”. The computer would respond back with “You manage to untie your hands…” and it went on and on and on and on hehhehe. They were great geek crack. Loved it.
    So these cassette tapes they gave you to load up the program with really sucked bad. You would get half way through a load and the blinking asterisk would turn to a question mark and you had to start over. It was POWERLAME FROM HELL! So I decided that it would be good practice to clean and demagnetize the heads before trying to load a program from tape. That worked out rather well and loads became a lot more reliable.
    I then decided it would be a good idea to make a copy of the original cassette before playing it the first time. This way if the tape failed you would be able to make another copy of it….or so I thought.
    The record levels were SO LOW on them though it was rough getting a good copy I found. The degradation of the already poor signal was too much for the signal to noise ratio to make for a good data tape after copying.
    Then I got a little more sophisticated about it. Mind you I was 10 years old at this point and it was early 1978. I didn’t know too much about recording. I questioned my brother Joe a bit about his cassette deck. I noticed it had a lot of switches and it had second tape drive in it. It was a Sanyo Dual Cassette Half Speed deck with Metal tape and Dolby A and B capability.
    After describing the trouble to my Brother, we had the idea of making a half speed recording of the original program cassette, to a Metal tape, and boosting the record level, and driving it into Dolby B for pre-emphasis. Then we played back the Metal tape, also at half speed, and made a nice hot cassette on normal bias tape and we flipped the Dolby OFF on playback of the Metal master for the 1/2 speed dup. This gave us an extra bump on the high frequency end as well.
    Those half speed duplicated program cassettes loaded perfectly EVERY time. Never had to clean the heads again on that tape drive ever again to get a good load. It works fabulous. So well in fact that I WAS BOOTLEGGING MICROSOFT SOFTWARE ALL THE WAY BACK IN 1978!!! WEEEEEEE!!!
    I would hang out at the Radio Shack Computer Center on Seneca Street in West Seneca, N.Y. and give the software to friends of mine that used to hang out there and geek out. It was great man. What a fantastic time that was.
    We took that computer up to a very sophisticated level of performance in the end. We started using the Floppy Disk interface a while after I started doing the tape copies. We had one drive and were running TRS-DOS 1.1 written by none other than BILL GATES HIMSELF!! No wonder it was so horribly buggy. TRS-DOS 1.0 and 1.1 were Microsoft products. TRS-DOS 1.2 and beyond were Tandy products and were much better. TRS-DOS 1.2 and 1.3 really never got much of a chance though because 1.0 and 1.1 sucked so bad that people gave up on it and jumped shit on TRS-DOS over to NEWDOS. NEWDOS was a lot like unix. They took a lot from the posix shell. It was a very nice operating system.
    After that we got the “Percom Data Doubler” This was a floppy disk interface replacement for the expansion interface. It took the floppy disk subsystem from 35 tracks single sided 10 sectors per track to 40 tracks double sided and 18 sectors per track. This was a DRASTIC increase in speed, storage, and overall disk performance.
    My Father picked up a Kit from a company called Escomm. They had a conversion kit for the IBM Selectric type writer. It was a standard solenoid kit that was used previously for RTTY (telletype). Escomm had a kit that allowed you to construct a parallel port interface box that connected to the solenoid kit in the Selectric and allowed you to use it as a printer on the parallel port of the TRS-80 Expansion interface!!!
    IT WORKED RAD MAN!!!! It was fast! Loved it. I did all my papers for school on an IBM Selectric Script ball in 1979!!! My teachers were like “Who did this paper for you?? You cannot have your older siblings do this for you. We need these HANDWRITTEN*^~!()#^%$!*()@%)@#*(&%@
    I was like WHAT?!?!?!?!?!?!??!? I actually had to get notes from my parents that I did in fact do these papers using Electric Pencil word processing software and an IBM Selectric converted for parallel port use on a TRS-80 computing system. My teachers were like, “Whatever kid. We are going to talk to your parents about this!!” It was the twilight zone I swear.
    After that time my Brother started getting into the C-64 and then the Amiga. I got into the C-64 and the Amiga as well. Great computing platforms for the time.
    Glad to have caught this thread. Hopefully I have found some geeks that appreciate this stuff. I would very much like to make a computer museum. I think it would be a gas!!
    Someone actually wrote Defenders for the TRS-80 is you can believe it. It was a major machine code hack of the 128 x 48 graphics interface on the machine. Believe it or not, if you sort of allowed your eyes to blur a bit and sat at the right distance from the monitor, it was actually fluid motion on that piece of crap computer. What a miracle to be able to program a game of that sophistication on such a minimalistic computer and graphic interface. It actually was quite playable. I couldn’t believe it.
    The other thing I could not believe is how good those 1/2 speed Metal Cassettes of stuff like the Shiefield Labs Direct Master Recordings of stuff like Dark Side of the Moon and other titles sounded next to a CD. When you duped one of those records half speed, to Metal tape, at say, +6 to +8 db into the red zone, and drove that into Dolby B, it sounded absolutely incredible. We had a CD player in late 1980. I think the very first one on the market. Not sure. But there was positively a case to be made that the Metal tape done up half speed and boosted into Dolby B sounded BETTER then the CD’s Ah the 70’s and 80’s What wonderful times. The shuttle test missions like the first piggyback flights of the model and the first unmanned test launches and stuff were happening back then. Hope you guys enjoyed this. I sure enjoyed writing it.

    John Margarone
    TCP/IP Systems
    3906 Seneca Street
    West Seneca, N.Y. 14224
    716-608-8304 – TCP/IP Systems Storefront.
    admin@nationmedia.net

  5. CORRECTION:

    NON-ORBITAL test flights of the Shuttle. Not Unmanned. My bad. I am referring to the piggy back rides when they blew the explosive bolts and allowed the Astronauts to glider pilot the orbiter to a landing for testing purposes. CAN YOU BELIEVE THEY CANCELED THAT SPACE PROGRAM? CAN YOU BELIEVE IT??? God lets hope our next President sees their way fit to re-launch it. EESHK. Ahhh the 70’s and 80’s…..Magic times!

  6. Wow Enlightenment. What a bitter blogger you are. How about naming some of those great C-64 titles?? Comon quick. I am timing you. How long will it take you to goggle some……..

  7. I wrote the GT4 cartridge for the C-64 that was published by Pro-Line Software (also the publisher of WordPro 64 and SpellPro 64 which I also wrote).

    Lots of memories here … such as making sure that you did async transfer of bits using both the data and the CLK lines of the serial cable, and making sure that your code was aware of the scan line for the VIC chip since it would take control of the address bus every 8 scan lines to fetch the next 40 bytes of data that it would need from shared memory. That would play havoc with async 2-bit transfers.

    The 1541 drive would write data using an interleave pattern such that successive logical sectors would appear on opposite sides of the disk. So the max rate of data that you could get off the disk was 300 rpm / 60 * 2 * 254 = 2540 bytes per second. Or about the speed of a 28.8Kbps modem :) The GT4 cartridge was about 5x faster than the default 1541 drive since the software GCR decode took such a long time that the drive would always miss the interleave. The 2040/4040 drives would use hardware GCR decode so they always hit the interleave.

    Fun memories. Thanks for the trip down memory lane!

  8. Thanks for the memories. The old C64 is still at my parents place, but hasn’t been booted in 20 years.

    Is the original code available? It would be fun to have a look at the details.

  9. Very cool! The VIC-20, followed by the C-64, were my introduction to computers, back in the early 1980’s. I’m pretty sure my friend and I used FCopy, during our weekly “backup” sessions. Thanks for the software, and thanks for the story!

  10. TO: Mike Pall
    Wow! Doing GCR encodes on C64 in async manner while the drive switches track, what an infinitely cool idea! I would enormously boost my turbo save routine (that only managed interleave 3) I have written back then.
    I’m seriously excited 20 years after :)!

  11. BTW, I loved the way that the C64 was as bare metal as one can get with all the non-hampered optimization opportunities.

  12. @Mike Pall: Speaking of those multiple passes, I had a version of “15 second copy” that worked with the 1764 REU. At one of the copy parties so common back in the day, someone asked me to copy a disk for him. 15 seconds later I asked for a blank disk, which I then returned to him another 15 seconds later.

    To this day I still remember how he just stared at the disk, completely baffled. “That’s it?1=”. “That’s it!”, I replied and patted the REU. :)

    • I’m the guy who , shall we say, “adopted” and “improved” the 15-sec-copy for REU usage.
      Yes, you can read a disk in 8 sec and write it back to disk as many times as you want in another 8 secs. That became pretty much standard….

  13. As a kid with c64, I probably “backed up” over 10,000 games (the c64 had a massive collection) in my day. I remember fcopy well and of course the numerous variants. I was simply in love with game collecting and in retrospect spent far more time collecting than playing.

    All of that effort, which led me to starting a BBS on a 300 baud modem, gave me the tools I needed to start one of the first Web design companies, Blue Diesel, back in 1994. At the time there was no way I would have realized that collecting games would be some impactful in my life later on.

    I know that what you were doing was simply a hack to make something work at the time, but wanted you to know that the butterfly effect of that got a young kid to get more involved in his computer than he ever would have. The result of that was a set of skills that allowed him to build companies employing hundreds of people.

  14. @DS: Err, no, please reread. It didn’t do a full GCR decode. It only decoded a partial checksum from a parallel 5 byte XOR of the raw GCR.

    @Jan: REU was after I left the C64. If it’s a modification of my code, then it should have taken 7.5 seconds to read and 7.5 seconds to write. :-)

    I’ve just tried my old version in an emulator. Heck, using the menus to swap the virtual disks feels slower than swapping physical disks … we had quite some practice doing it quickly with four hands.

    I’ve just sent a longer article about 15 second copy to Michael for publication. With a screen shot! And code snippets, too!

  15. My story may not compare to the Fcopy program by any means (although I recall using that program on C64 back then) but here it is anyway :)

    I was still living in Tunisia in the early eighties. I recall at the time my first computer, an MSX generation one with a Z80 processor, 64K or ram, pathetic graphics to be honest, did go through all of the issues with cassette tapes, duplication, cleaning, etc just trying to get things to work.

    The biggest challenge we had was that hardware costs was very expensive compared to the cost of living. At any case, I had an MSX printer with a 500 pages manual or so written in English. I only spoke Arabic And French only at the time so the book made it safely to my book archives and just stayed there.

    All worked well until I eventually transitioned from the MSX to the Amiga 500 computer. That was heaven on earth per say until I tried to print.

    The MSX printer drivers were not available under the Amiga platform of course. I could print basic text as ASCII printing worked somehow fairly well but that was it.

    I recall spending full days and nights deciphering the printer manual to get a hang on the programming logic, concepts etc while having my trusty English to French dictionary at hand. I was not a programmer by any means and this was my first foray into it. Not sure how to explain it but the concepts made just perfect sense as I was reading my newly acquired assembly book, I had already a Basic book that came bundled with the MSX computer that I have already read end to end and fully mastered the concepts it carried.

    One thing I never managed to properly grasp is why the printer manual focused on examples based on a gun factory business and all images where for guns, ammunition, etc … I just thought that this was an odd choice for a printer manual.

    At any case, I had to make the printer receive the image into an 8×8 buffer. that is the space normally allocated for one letter. The process was to take the first 8 lines of the image, loop through it using 8 pixels at a time, fill the buffer with the 8×8 image content, print it and keep looping through the end of the line then carriage return.

    I made an unexpected mistake of initially programming the logic in Basic. Basic had all the necessary tools to call the printers assembly routines using poke to write, peek to read, etc …

    It was a magical moment when the printer started printing graphics. I chose for a test the image of a pharaoh, Tutankhamun who had an image that came bundled with a leading printing software at the time, I think it was called Deluxe Paint IV.

    It did print alright, spending three to four hours to print a full page. As far as I was concerned, it did print ! That moment, or few hours actually while the printer was inching its way through the process was glorious, I unfortunately had no one who cared about this enough to share the moment with, oh well :)

    I spent that summer translating that driver into assembly and then make it into an actual driver that the Amiga OS would leverage and shared it with the local community at the time as that printer was commonly available back then over there. That was a saga by itself as I had no documentation and the Internet was not born yet.

    I managed to track someone traveling to Germany and paid him for his trouble to track and buy for me few Amiga OS books. The books were in German, … there goes more money for another dictionary … German is not the easiest language to learn as I found out :)

  16. Fcopy was pretty much the basis for all elite group forms of duplicators. It was elite according to the groups. They just didn’t want anyone to know they had not come up with it. So all the programs that Enlightenment talks about all started out with Fcopy and all that was done was they were dressed up for that groups release. I was in that scene for a long time and even in the Amiga scene afterwards and saw pretty much the same repeated. TT did us well with Fcopy. Thanks for the great program.

  17. @Karim: Great story. Kind of like I felt when I started disassembling the 1541 ROMs without any background info.
    @Phil: Sorry, I have nothing left of those times, neither disks nor hardware.
    @Freejack: Thanks.

  18. When I was a teenager I also hacked the C64.
    I used to work for a company that developed an IEEE488 based LAN for C64’s and PET computers, allowing them to share one 8050 or 8250 floppy drive among multiple computers. The PET could do this via an updated EPROM only (maybe that was even not requierd – I forgot), but the C64 required a special IEEE488 with a ROM.

    Anyhow, the 1541 serial protocol was loosely based on the IEEE488 from the PET computers. We had hard copied of the C64 ROM disassembly and later we also got a hard copy of the 8050/8250 ROM source and finally even the C128 and 1571 original source code, where I learned of it’s unique structure (dual 65xx processors running on opposite clock phases, and sharing a small RAM).

    One of the most interesting commands in the CBM DOS, was a relatively unknown command, “&”. You could send a command like &0:XXX,U” (if IIRC), which would take a file XXX of type USR, load it inside the drive’s RAM and execute it there!

    I must admit that at one point I worked very hard on craking one of the major C64 apps that relied on heavy copy protection code that ran inside the drive. At the end , after I failed to easily crack it, but after inspecting the protection code, I ended up crafting a special crack program that simply created the unique error track that the application expected. I coded this using a very small application that ran inside the 1541 using the mechanism above.
    To copy the app all you needed was to copy it as=is and ignore the error, and run the USR file once using
    Open1,8,15,”&0:crack”

  19. I also wrote a copy program, but for tape. That must have been before or shortly after I got a floppy drive. I called it “Koppie Thee”, a Dutch pun on Copy-T (meaning, informally, “cup of tea”). The user was recommended to drink a cup of tea while copying was in progress.
    Of course I used the ubiquitous TurboTape routines, but you could also load/save the usual slow tape format, and to/from the disk drive. I think my program allowed the largest size file to be copied of all tape copiers I had seen (there weren’t many anyway), around 56 or 58K or so (out of 64K).
    I used a modification of TurboTape where during the phase where it scans for a program header, it shows the bits from the tape in the border colour. Since the screen was turned “off”, that was the whole screen. From the various patterns you’d get, you could easily learn to see if the tape was positioned right, or if you were in the middle of a program already.
    Many cracked games, normally loaded from floppies, worked fine if you could manage to copy them to tape in the first place, and many were too large to use the simple LOAD, then SAVE method.
    For two-part programs (with a loader and the main program), it would sometimes be necessary to use a specially modified TurboTape, located extremely high in memory at $FD00, which simply intercepted disk load requests and loaded from tape anyway.

  20. @udif would that company have been one by the name of BMB Compuscience? I was the designer of the IEEE488 networking module for the C64 and later incarnation that was IEEE488 only by the name G-Link. The PETs did not need any special software to work on the network like the C64.
    One of the developers on our team “played” extensively with code running in the disk drives for a product by the name “Orwell” (yes 1984 reference). It was for the education market to allow teachers to monitor computers on the network and push software and screens snapshots to the slaves.
    The C64 was instrumental in changing many aspects of the PC market. The sound chip (SID) was the first commercial chip to mix analog and digital technologies in one package. The designers later went on to make significant contribution to the music synthesizer market.
    I do remember my hacked SuperPET with 2 MB ram, yes 2MB which at the time was a lot both by price and real estate as the memory board was the same size as either of the two processor boards in the computer.

  21. I used to have something like FCopy I think. I had 2 1541’s hooked together with a parallel cord. It made things much quicker, that’s for sure.

  22. I’m 26 now and used to have a commodore 64 when I was little I still think nothing beats it to this day, I’m seriously considering buying another as using things like emulators or playing classic games on the xbox just isn’t the same.

  23. @Derek: That was FCopy III, most probably. Three of us worked together for weeks to write the best copy and crack protection. Naturally, _every_ hacker wanted to crack it once it was out, but it still took about 2 weeks until one managed it, with tricks (and modified hardware) we hadn’t thought about. But 2 weeks was still an incredible long time for a crack that everyone tried to achieve.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.