[an error occurred while processing this directive] [an error occurred while processing this directive] Doug Jones's data formats for device emulation [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive]
[an error occurred while processing this directive] (none)
   [an error occurred while processing this directive]

Data Formats for Peripheral Device Emulation

[an error occurred while processing this directive]

(none)

[an error occurred while processing this directive] Part of [an error occurred while processing this directive] the PDP-8 Collection
[an error occurred while processing this directive] See also [an error occurred while processing this directive] (none)
[an error occurred while processing this directive] [an error occurred while processing this directive] (none) Douglas W. Jones [an error occurred while processing this directive] (none)
[an error occurred while processing this directive] (none)
THE UNIVERSITY OF IOWA Department of Computer Science [an error occurred while processing this directive] and (none) [an error occurred while processing this directive]

(none) [an error occurred while processing this directive]

Copyright © (none) This work may be transmitted or stored in electronic form on any computer attached to the Internet or World Wide Web so long as this notice is included in the copy. Individuals may make single copies for their own use. All other rights are reserved.

[an error occurred while processing this directive]
[an error occurred while processing this directive]

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

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:

Line 1 (optional):
Identifies the emulator being used. Typically this will be
	#!pdp8e
Recall 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.

Leader (optional):
The actual core image may be preceeded by any number of lower-case ASCII characters, defined as characters with ASCII codes >= 'a'. This feature is useful when punching IPL files onto paper tape.

Body:
The body of the core image file gives a sequence of 6-bit bytes representing the contents of memory; the two bytes of each 12 bit word are each encoded as a single ASCII character and transmitted most significant byte first. Core images always run from memory location zero up to the highest nonzero location in memory.

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.

Mount requests (optional):
An optional list of files to be mounted immediately follows the body. Each line in this list begins with the letter 'm', followed by a space, the name of a device, and the file to be mounted on that device. For example, the line
	m rx0 floppies/os8sys
requests 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

Run request (optional):
If the line following the body and mount requests is the letter 'r', this indicates that the PDP-8 was running at the time it was powered down -- and that it should come up running if equipped with the power-fail auto-restart option.

Trailer (optional):
Any additional text following the body, mount requests or run request will be ignored! By convention, the following line is recommended:
	end


Punched cards

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://www.cs.uiowa.edu/~jones/cards/

This includes documentation of the data format and some utilities for conversion between ASCII and punched card data formats.


Punched paper tape

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.


DECtape

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.


RX01 diskettes

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.