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.
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.
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:
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:
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.
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:
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.
Phew.
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.
# = 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.
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.
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.
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