WarpCopy64 Protocol

While waiting for contact to be made with Graham, I thought I’d just list some of my findings about the commands/services made available by the WarpCopy64 protocol, in case these will be useful to somebody else one day.

WarpCopy64 Services:

0x01 - PING      - Ping the server
0x02 - ACK       - Packet acknowledgement

0x08 - DUMP      - Read all blocks from disk and send them to the network client where a whole disk image is saved to a D64 file

0x0c - PREPARE   - Prepare to send single blocks to the network client on-demand, by uploading some drivecode to the requested drive and blanking the screen
0x0d - DONE      - Release bus lines and unblank the screen (finish sending single blocks on-demand)
0x0e - READBLOCK - Read a single block from disk (in the drive selected with PREPARE) and send it to the network client (after patching the drivecode for a specific t/s)

0x18 - OPEN      - Open a file using DOS commands
0x19 - CLOSE     - Close a file using DOS commands
0x1a - FREAD     - Read data from the open file and send it to the network client. Note: when the file is "$" the next command is used instead
0x1b - DREAD     - Read a line from the directory listing (discarding the next line link) and send it to the network client (line length is 28 bytes for a standard directory listing)
0x1c - FWRITE    - Receive data from the network client and write it to the open file

0x1F - TBD       - TBD

0x28 - RESTORE   - Receive disk image blocks from the network client and write them all to disk

0x31 - SLOWREAD  - Slow read block from disk and send it to the network client
0x32 - SLOWWRITE - Receive block from the network client and slow write it to disk

0x3F - TBD       - TBD

In the above documentation the word block is used to refer to a disk sector. The network client is the PC application itself.

In this context it doesn’t matter, but, generally speaking, a block’s position is identified by a single index, where a sector’s position is identified by the couple track/sector. One can obviously convert a block index to a track/sector couple and the other way around as the block chain is essentially a serialised version of disk sectors, ordered by track and sector.

About luigidifraia

I am a Senior DevOps Engineer so I get to work with the latest technologies and open-source software. However, in my private time I enjoy retro-computing.
This entry was posted in Retrocomputing, Reverse Engineering, Technical and tagged , , , , , , , , . Bookmark the permalink.

4 Responses to WarpCopy64 Protocol

  1. V-12 says:

    Hi Luigi. Would you like to describe differences between yours IECHost and Warpcopy64? I’m using second one from time to time since many of years and I’m happy from it. Wonder if your IEChost is better?

    • luigidifraia says:

      I don’t think anything can beat Graham’s solution, based on his experience within the disk community alone. However, IECHost has the advantage that it does NOT require a Commodore 64 + RR-Net to dump/restore disk images or manipulate disk contents, it is still well supported and maintained, and I might implement user suggestions in future, if they are in line with the underlying goal: handle well-working DOS disks.

      • V-12 says:

        Yeah, you are right. Seems that this is the best advantage. What about speed of copying (read/write)?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s