Direct Drive-to-Drive Copy <part 1>

Commodore's serial bus protocol (a.k.a. IEC bus) seems to be designed in such a way that you could easily tell one drive to send data directly to another, taking the C64 out of the picture. Here I explore that idea.

A device on the commodore serial bus can be commanded to either talk or listen.  In general use, when reading from an open file the C64 tells the drive to talk, then the computer acts as a listener and data is transferred.  When writing to a file, the computer tells the device with the open file to listen, then becomes the talker and sends the data.  I didn't have to study the serial bus protocol very long at all before thinking "wow, what would happen if we just told one device to talk and the other to listen?"

I realize that the application of this would be limited to copying a single file, but it has continued to intrigue me ever since.  This is not unlike what is actually done on SCSI and IEEE-488 buses, and the serial bus protocol was modeled after the IEEE bus.  When listening, the C64 follows exactly the same protocol as a drive does when it listens, and the same is true for talking.  The talking and listening devices really have no way to distinguish who is on the other end, so it should be possible.  The sequence would go something like this:

1. C64 opens file on source drive for reading
2. C64 creates new file (i.e., opens for writing) on destination drive
3. Tell destination drive to listen into open file channel
4. Tell source drive to talk from open file channel
5. C64 gets out of the way and lets the data transfer, monitoring the bus activity
6. When activity ceases, C64 steps in and closes both files

I know this is not rocket science.  Utilities exist that perform full-disk copies between two drives without any help from the computer.  But those require software to be uploaded into the drives.  I'm hoping for something a little lower tech.  I'm also relatively certain I could achieve the direct copy by writing some assembly code on the C64, and I will do that if necessary.  But first, I want to see if it is possible to get results using the simplest methods, and work my way up.

Recently I was talking to gsteemso about this very thing and was pleased to discover that he also had this question rattling around in his head.  He is working on a project aimed at allowing a far greater number of devices and computers to be connected to an IEC bus.  When I had an opportunity to visit him at his home, we took a stab at this sucker.

What We Tried

10 INPUT "DEST FILE";N$
20 OPEN 11,11,11,"NUMEROLOGY,P"
30 OPEN 8,8,8,"N"+N$+",P,W"
40 POKE 780,8:SYS 65457
50 POKE 780,8:SYS 65427
60 POKE 780,11:SYS 65460
70 POKE 780,11:SYS 65430

(Note the lack of CLOSE statements.  We performed step 6 ourselves by listening for the drives to stop spinning, and issuing the close commands in immediate mode.)

What We Learned

The first time we tried this, after working out the bugs, it actually seemed to work!  We loaded the test file that had just been written (it was a 1-block BASIC program), and did a VERIFY with the original.  It said "OK" !!!  After a bit of rejoicing, we proceeded to try it on a bit longer program, one that was at least a dozen blocks long.  This time was ... well, less triumphant.  We didn't hear any head stepping sounds, and the drives stopped spinning just as quickly as they had in the first test.  Hmmm...

We closed the files and loaded up the newly written one; we found ourselves staring at a copy of the test program that we were running, and not  the file we were trying to copy!  A closer look revealed that it was an old version of our test program to boot!  How could this be?  After double-checking the file we were trying to copy and anything else we could think of, we paused our head-scratching to try it again.  Maybe just a fluke of some sort.  But the same thing happened again!  The new file that got written contained some part of a file we had previously loaded.  Bizzarro world calling Earth, come in...

Conclusions?

I still cannot explain what we saw.  My best guess would be that there was data left sitting in a buffer from a previous load, and if no data actually got written to the file, perhaps that left-over data got written verbatim into the new file.  It seems a bit far-fetched that the drive did not somehow prepare the buffer contents for the new file being written, but I have seen stranger things in the Commodore world.

Whatever it was that happened, it's safe to say that we did not achieve the desired results.  Something is preventing the data from being transferred between the two devices.  Even though we released the clock and data lines in line 70 of the program, the assumptions made by the Kernal routines had probably already messed up the handshaking and ruined the moment.

It's becoming evident to me that Kernal routines alone will probably not be enough.

What's Next??

I'm still pretty perplexed by the results we got... and I haven't totally ruled out poltergeists or other supernatural phenomena.  But it's probably best left as a separate experiment to explore why the files contained what they did.  What's clear is that none of the correct data is getting copied.

My next step is to learn more about the Serial Bus protocols and the Kernal routines that carry them out..  (The devil will be in the details, I'm sure.)  Then I should be able to put together a solid theory on what's necessary to get 2 drives to talk to each other, and try again.

I will be getting most of my information from the following sources:

• iec-1541-info.pdf -- A collection of information including the well-known Jim Butterfield article on how the IEC bus works.
• myoperatingsystem.org  -- my work-in-progress Annotated ROM Listings
• http://unusedino.de/ec64/technical/misc/c1541/romlisting.html -- A disassembly of the 1541 ROMs