Solace Virtual Tape Drive


Like most 8-bit micros of that era, the Sol used a cheap audio cassette interface as a mass storage medium. The Sol was a bit unusual in that it supported up to two tape drives, numbered unit 1 and unit 2; unit 1 was the primary drive. Even if you didn't have the pleasure of experiencing such a clunky I/O device back in 1978, you can now relive some of the past glories, thanks to the invention of the Sol Virtual Tape interface.

screenshot of virtual tape interface

By choosing "File/Tape 1" or "File/Tape 2" from the main menu of Solace, a modeless dialog box pops up presenting the user interface for the Sol Virtual Tape. This dialog has its own menu bar, as seen above. The buttons are largely self-explanatory, but for a few notes here. Pressing REC causes both REC and PLAY to appear depressed. To help prevent accidentally recording on a virtual tape, the recorder must be in a STOP state before pressing REC.

The buttons can either be pressed, or the same function can be selected through the File menu.

The File menu is also used to create a new, blank virtual tape, to load an existing virtual tape, or to save a virtual tape to disk. By convention, Solace uses the file extension .SVT (Sol Virtual Tape), although virtual tapes can have any extension at all.

Tape Position

To the right of the buttons is a four digit tape position indicator. The indicator is calibrated in seconds of tape. Normally this indicator passively indicates how many seconds of tape have been played out. Either selecting the "File/Time..." menu item or clicking on the counter on the dialog box will bring up a dialog allowing you to directly set the position on the tape:

screenshot of tape position indicator and control

Time is entered as a decimal number. The time resolution is 1/10th of a second.


The second SVT menu item is the Label... item. Selecting it will bring up the following dialog:

screenshot of tape label dialog

Each virtual tape can have up to about 2 KB of text associated with the tape, as if the label was written on the cassette face. To prevent accidental modification, by default the label can't be edited. To edit the label, check the Label Editing enabled box.

Real cassette tapes have a write protect tab on the top of the case. Solace preserves this feature. Somewhat non-intuitively, access to this virtual write protect tab comes via the same Label... dialog. Checking or unchecking Tape write protect does the trick.

SVT Options

Real home tape players play the tape past the read/write head at 1 7/8 ips (inches per second). Due to limitations of bandwidth and design compromises to keep the tape interface simple, this limits the Sol to transferred data at no more than 1200 bits per second. The Sol also allowed reading and writing at a (presumably) more reliable 300 bits per second.

By default Solace behaves like a real Sol. If Solace is reading a file recorded at a different speed than its current setting, the file will be unreadable. This can be especially confusing when a tape has files recorded in different speeds as you must know ahead of time what speed each file is recorded in before you can even see the file on a CATalog of the tape.

Selecting the Options.../Tape menu from the main Solace menu will provide the following dialog:

screenshot of emulator tape options dialog

By selecting the "Ignore baud rate" checkbox, Solace will record files at whatever speed is chosen by the program that is running, but will ignore that detail when reading files.

Choosing Real-time will cause Solace to scan the tape at normal speeds (1200 bps or 300 bps). By choosing the Fast button, Solace will advance the tape as fast as the program can handle it. This robs the user of the faithful emulation of the unpleasantness of dealing with a cassette tape storage device. Some people...

The "Allow forcing motor enable" checkbox requires some explanation. Normally, there are two cables running between the Sol and a cassette player. One carries the audio signals to and from the cassette player to read and write data from the tape. The other cable is a motor enable wire. When this cable is plugged into the tape player's "remote" jack, it gives the Sol the abilitity to start and stop the tape mechanism. More precisely, the settings of the buttons must be such that the motor wants to move AND the Sol has allowed it to happen or not via the remote jack. It sounds good, but in practice there are often times when a user just wants to advance or rewind a tape, but unless the Sol happens to have energized its tape control relay, nothing is going to happen.

To get around this, users have to resort to stopping their program, going into SOLOS, typing "CAT", doing their tape business, then resuming their program. That is tedious and not always possible. Another option is to remove the cable from the remote jack, advance the tape, then remember to plug it back in again. A final option is to install a switch across the wire pair that is in the remote jack; shorting the two wires together has the same effect as when the Sol energizes is tape motor relay.

Solace supports this last hack when the "Allow forcing motor enable" is set in the Options menu. As can be seen in the two diagrams below, the first is the appearance when the "Allow forcing motor enable" control isn't checked, and the second is when it is checked. When this control is visible, clicking on the check box allows the tape position to be manipulated even when the Sol isn't trying to drive the motor.


screenshot of tape virtual interface without motor control
screenshot of tape virtual interface with motor control

.SVT File Format

The virtual tapes are stored on disk in a human-readable ASCII format. The file representing the tape consists of a sequence of lines, each terminated by a carriage return. Solace reads and writes files in this format, and typically a user doesn't need to know any of this. However, if you want to construct a tape by hand, repair a file, or manually change around the order of files on the tape, you need to understand the format.

Unfortunately, because the file format isn't random access (that is, the location on the actual disk file of a byte at a given logical offset isn't directly computable knowing only the logical offset), the virtual tape image isn't updated in real time. Instead, Solace keeps the random access version in memory, where reads and writes are easily done. The file isn't written back to disk unless the user requests it via the File/Save or File/Save As... dialog. However, Solace will remind the user that a tape is in a modified state should the user perform some action that would lose changes.

SVT1: Solace Virtual Tape Format 1
This tag must appear as the first line of the file, and only the first line. It is used to confirm the proper file is being loaded and to allow future format variations.
If this line appears anywhere in the file, the tape we be treated as if the write protect tab was set. It is most useful if it appears near the head of the file.
; comment
any text after the ; is a comment.
L <ASCII string>
This specifies one line that appears on the label of the cassette tape. Although the lines may be scattered through the file, by convention they appear immediately after the special first line. The total length of all label lines must be less than 1024. Extra labels will be ignored.
B 300
B 1200
Sets the baud rate. Must be one or the other. It can even change in the middle of a tape. The specified baud rate applies to all subsequent C, D and H, and F commands until another B command changes it.
S dddd
dddd (decimal) tenth's of a second of silence. Leading zeros not required.
C dddd
dddd (decimal) tenth's of a second of carrier. Leading zeros not required.
D aabbccddeeff ...
Specifies a sequence of data bytes, as hex digits. Spaces are ignored. There can be up to 32 bytes on one line. Before each pair of digits, zero to two error indication flags may appear in order to represent a bad tape:
# = framing error
+ = overrun error

The flags apply to the byte immediately following the error flags. The error flags don't persist beyond the next byte. For instance:

D 125B+239A#15+#CD002A9F
D 12 5B +23 9A #15 +#CD 00 2A 9F

These two lines are equivalent, as spaces are ignored. Both mean good bytes 12, 5B, then an overrun with byte 23, then good byte 9A, then framing error with data byte 15, then an overrun and a framing error with byte CD, then good bytes 00, 2A, 9F.

Although it might seem strange to allow representing errors in a virtual tape that should be perfect, there are two good reasons why it can be useful. The first reason is that when developing a utility for interacting with tapes for eventual use on a real Sol, it is nice to be able to test error handling.

The second reason is that I intend to write a utility to dump anything found on a tape to virtual tape, for archival purposes. Even if the whole program can't be read it, it is better than giving up after the first error, like SOLOS does. After the fact it may be possible to use a little brain power to patch up the bad bytes manually and restore the whole program.

Finally, there is the "magic hex" values MM, which represents one character time of carrier. This is used to model fine-scale timing; the C command models time on the scale of tenths of seconds. The MM value may not be preceded by the error flags.

Create a standard SOLOS/CUTER tape header block, using the supplied parameters. It is also possible to create header blocks using the D command, this is just a convenient shorthand for creating and identifying program boundaries.

It is especially useful for building virtual tapes in conjunction with the F command.

AAAAA is the ascii name that would appear in the tape header for the file. It is up to five characters long. If it is less than five characters, it is padded with 00 bytes. If you need to pad with spaces, use \20 (type these three characters literally).

TT is the type byte, in hex, that would appear in the tape header for the file. Typical values are:

    20 (space)
    42 (B -- BASIC)
    43 (C -- BASIC)
    47 (G -- game)
    4D (M -- music)
    50 (P -- program)

LLLL is the hex length of the file that would appear in the tape header for the file.

SSSS is the hex starting address that would appear in the tape header for the file.

XXXX is the execution address that would appear in the tape header for the file. Typically it would be the same as SSSS.

F <real_filename>
Data is specified indirectly, using an .ENT or a .HEX file.

Note .ENT and .HEX files have no way of representing error conditions. Also, both types of files can have overlapping data ranges and holes, but this can't be represented via the cassette interface, so the file must have monotonically increasing addresses; holes will be filled with dummy 00 bytes, and non-monotonic addresses will cause an error.

<real_filename> is the name of the .ENT or .HEX file on the local file system.

.SVT Limitations

Unlike real tapes, virtual tapes are held in the emulator's memory and changes to the tape aren't committed to the version on disk unless explicitly directed to do so. Although directly accessing the disk as bytes are transferred between Solace and the virtual tape has some merit, it seemed too prone to accidental erasures and other goof ups. Perhaps even more importantly, it was in conflict with the format chosen to represent virtual tapes on disk.

Don't forget, virtual tapes have a maximum 30 minute capacity, so don't attempt to store the contents of a CD-ROM on one.

Back to Solace main page.

Last update: September 25, 2001