This document represents the SVD Serial Protocol as of March 5, 2005 and as implemented in version 1.6 of the firmware and beyond.

Important Notes

First off, the protocol is very simple, probably too simple. There are no checksums or retransmission or anything. I guess I was thinking "why bother, I'm the only one using this thing." Maybe someday a more robust protocol can be used.

Hardware

The SVD uses a PIC 16C63B, with a built-in UART. Wired to that is a MAX232 to interface to standard PC serial ports. As an RS232 interface, it runs fine up to 115k...I haven't tried to push it beyond that, not really having anything that can go faster on the PC-side. However, the PIC is running at 20MHz so it could do serial transfers up to about 1Mb or so. Running at 115k a DD floppy takes around 10 secs.

Basic Transfer Theory

The SVD listens to the serial port through the standard PIC interrupt. The first byte of a transaction that is received is the command, followed by differing data based upon the command. Note that each command byte is echo'd back to the sender.

During the transfer of disk data, the SVD sends back a "progress" character after each track. This character is >. For a 10 sector disk, eleven 256-byte blocks are transferred back-to-back before the progress character is sent back. This is one header block, followed by the ten sectors.

Note that the SVD is programmed to support only 256-byte sectors now, though the transfer protocol provides for alternate sector sizes.

The SVD responds to a BREAK by resetting. I figured this was the easiest way to get control of the SVD back when a transfer goes bad. It turns out, however, that I use the BREAK all of the time in the SVD control software. It is sure to put the SVD into a known state.

The ^A is used as the autobauding "attention" character. After the SVD is reset, it listens for a ^A and sets the baud rate to match it. Once the SVD is auto-bauded, the ^A causes the version number to be transmitted back. The SVD control program sends a bunch of ^A's to the SVD when it starts up, just waiting for the return version.

While the SVD is running, it generates > and < characters whenever the virtual "head" moves. This is debugging information that I kinda' got used to.

SVD Data Format

The SVD expects data in a particular format. This format is derived to allow the SVD to access and transmit floppy data in an efficient form for the hardward...so it is rather obtuse.

In general, the data format consists of a group of 256-byte blocks, each representing a sector (the SVD can only handle formats with 256 bytes per sector currently). For each set of sectors that make up a track, there is a header block. So for a 40-track 10-sector image, there are 40 groups of 10 sectors each with a header block, or 440 blocks in total.

The blocks representing sectors are verbatim sector data. The header block contains sector header and CRC information for each sector of a track. So when the SVD is generating floppy signals for a track, it first sends out the sector header information from the header block, then jumps to the appropriate data block to generate the sector data. It then jumps back to the header block for the data CRC. It then begins generating the next sector header information.

The SVD data format has a few more complications to it that are beyond the scope of this document...for now.

Normal Commands

Note that reception of any of these commands causes the return transmission of the same character, before anything else that may be transmitted back.

^@	[0x00]	nop - just returns the same thing
^A	[0x01]	print version number - also causes self-sync
^B	[0x02]	dump a disk, next byte is disk number
^D	[0x04]	reset (does a hard reset)
^H	[0x08]	start the disk(s) running
^P	[0x10]	stop the disk(s) running
(spc)	[0x20]	load a disk, next bytes are: disk#, sects, tracks, secsize, then data
@	[0x40]	extended/debug commands (see below)
alt-@	[0x80]	unused

Extended/Debug Commands

@^@	[0x40 0x00]	nop
@^A	[0x40 0x01]	move head out (increase)
@^B	[0x40 0x02]	move head in (decrease)
@^D	[0x40 0x04]	move to track zero
@^H	[0x40 0x08]	dump state disk 0
@^P	[0x40 0x10]	dump state disk 1
@(spc)	[0x40 0x20]	dump state disk 2
@@	[0x40 0x40]	unused
@alt-@	[0x40 0x80]	unused

Detailed Command Description

^@	[0x00]	This command doesn't do anything. It just causes a ^@to be sent back.
^A	[0x01]	This command has two purposes: autobauding and version report. After the SVD has been reset, it waits for a ^A so it can determine the speed of the link. After it has autobauded, the ^A causes a version report to be sent back. Note that if the SVD receives a string of bad characters, those with framing errors, it will automatically reset. So a string of ^A's will usually allow you to gain control over the SVD. Note that a serial BREAK will cause a reset too. ^B (0x02) (NOTE - this command changes in v1.6 of the SVD firmware. in 1.5 it doesn't upload the tracks/sectors. And v1.5 doesn't provide a good way to get that data.) Remember to STOP the SVD before issuing this command! Use the ^P (below). This command uploads a specified image from the SVD. Only the image data is transmitted, it is assumed that the caller knows the number of sectors and tracks. If you don't, use the "dump state" command. The SVD expects the following after this command: byte #2 = disk number: ^@ (0x00) = disk #0 ^A (0x01) = disk #1 ^B (0x02) = disk #2 The data coming back is simply the raw header and sector blocks, organized by tracks then sectors. (In v1.6, this data is prefixed by first the disk number, then the number of sectors, and then the number of tracks.) there is an upload protocol - describe that here

^D (0x04) Just another way to do a reset! ^H (0x08) After the disk images have been downloaded to the SVD, this command tells the SVD to starting responding to floppy requests. If this command isn't sent, the SVD will just sit there, ignoring the floppy signals. ^P (0x10) This command will invert the effect of ^H. It should be used before uploading a floppy image. Otherwise, the memory pointers will get all messed up, and nothing will work right. (spc) (0x20) This is the most popular command, it begins the process of downloading an image to the SVD. The SVD expects the following after this command: byte #2 = disk number: ^@ (0x00) = disk #0 ^A (0x01) = disk #1 ^B (0x02) = disk #2 byte #3 = number of sectors (eg. ^J (0x0a) for 10 sects) byte #4 = number of tracks (eg. "(" (0x28) for 40 trks) byte #5 = sector size (0 = 128, 1 = 256, 2 = 384, 3 = 512 ... 7 = 1024) bytes #6 on = the disk data (see above "SVD FORMAT") Note that the SVD expects data for (sectors + 1) * tracks. So for a 10 sector, 40 track image, it expects 440 blocks of 256 bytes. After a track as been sent ((sectors + 1) blocks of 256 bytes), a progress byte is transmitted back. This character is ">". @ (0x40) The "@" leads into the extend/debug command set. alt-@ (0x80) This command does nothing currently. @^@ (0x40 0x00) - extended command This command does nothing currently. @^A (0x40 0x01) - extended command This command moves the currently active image "virtual" head out (increase track number). @^B (0x40 0x02) - extended command This command moves the currently active image "virtual" head in (decrease track number). @^D (0x40 0x04) - extended command This command moves the currently active image "virtual" head to track zero. @^H (0x40 0x08) - extended command Dump the state of Disk #0. This command dumps/uploads the current state of the images on the SVD to the PC. You should only issue this command when the disk is quiescent and you have "shut-down" data generation. Otherwise, the disk image may be switched in the middle of data generation. The SVD image state is dumped as follows, where each XX is a hexidecimal number. The parenthesis describe the value and are NOT part of transmitted data. B: XXXX (base of the SVD memory) T: XX (tracks) S: XX (sectors) #: XX (sector size) b: XX (track blocks) =: XX (current track) C: XXXX (current image base memory) R: XX (magical "remainder") @^P (0x40 0x10) - extended command Dump the state of Disk #1. See the description of dump results above. @(spc) (0x40 0x20) - extended command Dump the state of Disk #2. See the description of dump results above. @@ (0x40 0x40) This command does nothing currently. @ alt-@ (0x40 0x80) This command does nothing currently.