Copy-Q claimed to be the fastest, most reliable and easy to use copy program. Contained an intelligent nibbler. Seems pretty basic from the screen shot.
I have scanned the manual and it’s on the blog here:
DOWNLOAD: Copy-Q v1.1
DOWNLOAD: Copy-Q v2.0
DOWNLOAD: Copy-Q v3.0
It worked fantasticly well. You culd buy an original and he copied it perfectly during one year or more after copy-q release.
There were many versions of this program.
It was a favourite of mine with Fast Hack’em, Orange Copy, Turbo nibbler, Turbo copy and Kwik Load.
I used this exclusively until Copy II was released, and moved to Fast Hack ‘Em after that. As I recall, it had a dynamic track/sector screen which showed progress and errors for each sector during a copy.
I grew up in Minneapolis, looks like these guys were local.
Worked great until I tried to copy Beach Head 2.
Beach Head II used PirateBusters protection. Checks track 35 for $D7, $D7, then “$AA, $55”. This track has no sync signal. Copy II had parameters to copy it, Fast Hackem also.
Copy-Q worked well, but it was just part of my arsenal in the days. I often found it could copy disks that Fast Hack’em couldn’t handle. Fast Hack’em was always my first go at a disk, but Copy-Q handled most everything else.
copyQ and copyQ v2 differed quite a bit visually. the original was superior, imo, though not as fast. both were nibblers, but v1 detected unused sectors and didn’t store them unless they had errors. several protected titles could be copied in a single pass because of this. the visual display for v1 was a complete sector map (taking up the entire screen), and you got feedback about where it was, where and what had been read, and how much was left, all from the sector map.
Pingback: Copy-Q Manual - C64 Copy ProtectionC64 Copy Protection
I was a co-author of Copy-Q versions 1 and 2, and am familiar with many details of version 3. I wrote the code that ran inside the drive.
All versions executed code within the 1541 drive’s RAM. Version 1 already used this to actually format the target disk with the desired errors, blank sectors or zeroed sectors (there was a difference) on the fly. No other copier did that. After formatting, the data were subsequently written out. If the data fit entirely in RAM (as was very often the case) the user was asked if they wanted to make another copy. I understand this latter feature especially made it pretty popular at user groups. Obviously we used the RAM which was mapped under the ROM and I/O to maximize the buffer size. On version 1 could also edit the sector list to add or remove specific errors wherever you wanted on the disk. Some errors were track errors, others were for single sectors, and still others tended to affect groups of sectors. The trick was to get those latter errors affecting as few sectors as possible. Ours was the best prior to the advent of nibble copying on the C64. Version 1 was not a nibbler, it was just very good at handling and reproducing errors.
Version 2 was a true nibbler, but the limitations of RAM on the 1541 and the slow speed of the Commodore serial bus presented a challenge in getting an entire track of GCR (group coded recording) bytes back to the C64 host. I did it in two phases, with an initial scan looking for syncs and then subsequently seeking on each one of those and capturing a length of GCR, which was then sent back to the 64. Then I had a routine on the 64 crunch through all the snapshots, finding the overlaps and stitching it all back together. These were serious constraints, but we managed to get it working, and we copied Zaxxon which nobody else could do. That game had an extra sector on a specific track, with a duplicated sector number, that the game’s boot loader checked for by first reading a specific other sector; only then would the phantom sector would be visible due to timing. Copy-Q version 2 which was a true nibbler, copied this without any problem. However I was never quite satisfied with the compromises we had to make. The program was necessarily slow due to all the snapshots and slow I/O on the serial bus. It was not slow execution; all of our programs were written entirely in assembly. This was released at a time when copy protection schemes were evolving quickly.
Version 3 was written after the invention of fast I/O which was cycle counted bit blasting, two bits at a time, and made possible by the data direction registers in the I/O chips on both ends. Bytes could now be transmitted over the “serial” bus much faster than they would come in from the drive’s head. This enabled true nibble copying as fast as the drive could spin. With fast I/O, the C64 and 1541 performed as fast as an Apple II with its memory mapped floppy.
We weren’t the first with fast I/O, I think that was “Mr. Nibble” which was a program out of Germany. But we were the first and possibly only ones to solve the problem with the VIC II chip’s DMA interfering with the cycle counted I/O. Everyone else worked around this problem by shutting off the video chip during I/O. The solution came after studying when the chip was likely to assert DMA. The chip had a register indicating the vertical raster line. We found it would only assert DMA on every eighth raster, which of course made sense. With this information, we were able to leave the video chip turned on so the user had something to look at while the copy was taking place. We just had to check the raster before the start of every byte sent or received with fast I/O, and just busy loop wait for it if it was in the wrong place. Even with this check in place, the I/O was still fast enough to do true nibble copying on the fly. That was the primary secret of how Copy-Q version 3 did its stuff, and why it was so much better than version 2.
I didn’t write any of version 3; my colleague Don wrote it singlehandedly after I had left for greener pastures. However I was there when many of these problems were solved.
One really cool thing about the 1541 that I’ve never seen mentioned anywhere, and which would have been baffling to anyone disassembling its ROM, is the use it made of a 6502 hardware feature whereby the processor’s arithmetic overflow flag could follow an input pin on the chip itself. So every read or write routine involving the head was littered with lines saying “BVC *” and you wonder initially, how in heck does it get out of that loop?
Of all the stuff I did on the 64, I’m proudest of my work on a terminal emulator called The Communicator, which Tom and I each spent two calendar years at, and eventually marketed through Free Spirit Software. It offered 80, 64 or 40 columns in software with the 64 column mode looking pretty good. Critically, it had a clever graphic scroll routine which could keep pace with 1200 baud line feeds by looking ahead in the serial buffer and scrolling in a single jump as many lines as would be needed. It had a generous capture buffer with a buffer editor, sprite cursors (including a cursor editor) selectible character sets (including a charset editor), queued status messages, VT-52 emulation and even Tektronix 4010 line graphics emulation. The selectible bells included that classic Hazeltine squawk, a recording of which I was able to find in the movie Tron, and replicated with the SID chip.
Truly enjoyable times! I still have my C64, a lot of peripherals, some listings and surely some source code on disk. Thanks for hosting this page.
PS: I think version 3 may have implemented drive-to-drive communication for its quick copy when two 1541’s were available. We had been dreaming about that as a cool possibility while I was still there, and I believe Don did get that working.