Data Formats for Peripheral Device Emulation
Part of
the PDP-8 Collection
|
Emulators for antiquated machines must frequently emulate strange I/O devices on modern storage media. This file documents the formats used by my emulator, available from:
ftp://ftp.cs.uiowa.edu/pub/jones/pdp8/
This emulator uses files under the host operating system to emulate storage devices. The following device types are supported:
The following sections provide documentation for each of these devices; additional documentation is contained in the emulator source, but those hoping to develop competing emulators or those hoping to write code for conversion to or from these data formats may find this an easier source of information.
Core memory retains its contents from one run to the next, so whenever the PDP-8 emulator is "powered down" and a "core file" is mounted, it will save the contents of the emulator's memory. The core file format used here is adapted from Charles Lasner's .IPL file format, so it should be easy to take a saved emulator core file and load it on a real PDP-8.
Core image files are text files (this is a consequence of the use of .IPL format). The file is structured as follows:
#!pdp8eRecall that the UNIX execve() kernel call executes files that begin with the string "!#" by executing the program following the "!#" prefix as an interpreter to interpret the remainder of the file. Therefore, an attempt to execute a core image file will automatically launch the PDP-8 emulator, with its emulated core memory initialized from this file.
Within the core image, control characters and blanks are ignored. Usually, on dumping a core image, 64 characters (32 words of PDP-8 memory) will be dumped on a line, followed by an LF character, but the emulator can read lines of any length.
The ASCII representation a of the 6-bit code c is '!'+C; this uses the upper case letters, numerals and most of the ASCII punctuation marks for data encoding.
m rx0 floppies/os8sysrequests that the file floppies/os8sys be mounted on the device rx0. The legal device names depend on the emulator's configuration; typically, these are:
CORE -- the core image file
RX0 -- the RX01 disk transports
RX1
DT0 -- the DecTape drives
DT1
CDR -- the card reader
PTP -- the paper tape punch
PTR -- the paper tape reader
end
In short, emulated card decks are emulated as binary files beginning with the three-character ASCII prefix H80 or H82 indicating standard 80 column cards or nonstandard 82 column cards (those cards with unreadable punches in columns 0 and 81; some punched-card verifiers used these columns to indicate that the card failed verification, and some older keypunches could be made to punch these columns).
Following the prefix is a series of card records. Each card record begins with a 3 byte header (with the most significant bit set in each of the 3 bytes). Fields in this header are reserved for emulated display of cards and card decks to indicate color, preprinted form and other details; these details are ignored by the PDP-8 emulator. Following the header, each card consists of 80 (or 82) 12 bit columns, packed 2 columns in 3 consecutive 8-bit bytes, with bytes and 12 bit columns packed and read from left to right, most significant bit first on bytes, and the top edge of card first for card columns.
For additional detail, see:
http://homepage.cs.uiowa.edu/~dwjones/cards/
This includes documentation of the data format and some utilities for conversion between ASCII and punched card data formats.
Punched paper tape is represented by files. If the tape is punched in a manner conforming to the conventions of ASCII usage, the files will be readable as conventional text files. If the tape is punched with binary information, the files may still appear to be text files, but opening them for editing will generally produce nonsense. This usage exactly mirrors the effects users expected with paper tape and Teletypes -- any paper tape could be mounted on a teletype and listed, in local mode, but if you tried to list a binary file, you got nonsense.
Emulated DECtapes are represented as binary files, beginning with the text 'DECtape\n' in the first 8 characters. The remainder of the tape consists of 8 bit bytes, each containing 2 "lines" of data from the tape, formatted as:
_ _ _____ _____
|_|_|_|_|_|_|_|_|
|0|1| 0 | 1 | even/odd line in 2-line sequence
| | |
marks data
Note that each "line" of the physical DECtape held 3 bits of data, and a mark
bit. The mark bits were only written once, when the tape was formatted. When
a DECtape is read (in the forward direction) into a 12 bit word, the data
from 4 lines on tape are read into consecutive 3-bit nibbles as follows:
_ _ _ _ _ _ _ _ _ _ _ _
|_|_|_|_|_|_|_|_|_|_|_|_|
|0 2|3 5|6 8|9 11| bit in word
| | | | |
| 1 | 2 | 3 | 4 | line number in sequence
|1 2 3|1 2 3|1 2 3|1 2 3| bit in line
All levels of data formatting above the level specified here are under the
control of software when the TD8E interface is used. The emulated tape format
given here allows any standard or nonstandard recording format and any length
of DECtape the user might be tempted to emulate. By convention, however,
data blocks are always an even number of 18-bit words in length, and each
data block is delimited by 10 18-bit words (5 at each end). In addition,
a 6-line end-of-tape mark is included at each end of the tape.
A standard PDP-8 DECtape has 1474 blocks of 516 lines each (129 12-bit words or 258 bytes in the emulated representation given here). Adding in the extra formatting information for start and end of block brings each block up to 576 lines (288 bytes in the emulated representation). This gives a tape-length of 849024 lines, to which the 6-line end-of-tape marks are added, giving a total tape-length of 849036 lines (424518 bytes in emulated form). The last two blocks at each end are never used for data -- these provide turn-around zones in which the tape-drive can stop and reverse direction without running the tape off one reel or another.
Emualted RX01 diskettes are represented by binary files that begin with the 4-character ASCII string 'rx01' in bytes 0 to 3 of the file.
Bytes 4 through 255 hold the deleted data bits, one bit per sector of the disk. In IBM's original intended use for this disk format, it appears that each sector was supposed to hold one line of text in a word-processing document, and setting this bit could be used to delete a line from the document. To my knowledge, no PDP-8 software, other than diagnostics, ever used the deleted data bits, but there are enough of them, in aggregate, to hold almost 2 sectors of data! Deleted data bits are packed least-significant bit first, into bytes, in sector order within a track, and in track order within the disk.
Bytes 256 and up hold the data sectors of the disk, 128 bytes per sector, 26 sectors per track (numbered 1 to 26), and 77 tracks per disk (0 to 76), for a total of 256256 bytes of data per disk, and 256512 bytes per emulated RX01 disk. There is no provision to emulate other data formats on an IBM single-sided single-density diskette, for example, other sector sizes, nor is there a provision to emulate nonstandard sector numbering sector RX01 disk.
There is also no provision to simulate the effects of nonstandard interleaving. By default, RX01 diskettes were not formatted with any interleaving, and OS-8 imposed an interleaving structure in software. The emulated RX01 diskettes are accurately emulate the hardware side of this arrangement.