README updates
This commit is contained in:
Jeff Parsons
Jeff Parsons
parent
7ce31e0955
commit
abce30fda5
5 changed files with 630 additions and 2 deletions
|
|
@ -7,13 +7,34 @@ permalink: /apps/pdp10/diags/ka10/
|
||||||
PDP-10 KA10 Diagnostics
|
PDP-10 KA10 Diagnostics
|
||||||
-----------------------
|
-----------------------
|
||||||
|
|
||||||
PCjs has archived selected KA10 diagnostic source files from the
|
PCjs has archived selected files from the "KLAD Diagnostic Sources" located at the
|
||||||
[PDP-10 KLAD Diagnostics Sources](http://pdp-10.trailing-edge.com/klad_sources/index.html) and turned them into
|
[PDP-10 KLAD Diagnostics Sources](http://pdp-10.trailing-edge.com/klad_sources/index.html) and turned them into
|
||||||
stand-alone PDP-10 diagnostics, using the new PCjs [MACRO-10 Mini-Assembler](/modules/pdp10/lib/macro10.js).
|
stand-alone PDP-10 diagnostics, using the new PCjs [MACRO-10 Mini-Assembler](/modules/pdp10/lib/macro10.js).
|
||||||
|
|
||||||
Lists of supported [diagnostics](#list-of-ka10-diagnostics) and [reliability tests](#list-of-ka10-reliability-tests)
|
Lists of supported [diagnostics](#list-of-ka10-diagnostics) and [reliability tests](#list-of-ka10-reliability-tests)
|
||||||
are provided below, as well as some [notes](#notes-on-ka10-diagnostics) on assembling the diagnostics.
|
are provided below, as well as some [notes](#notes-on-ka10-diagnostics) on assembling the diagnostics.
|
||||||
|
|
||||||
|
All the files below presumably came from this "[23.15 Mbyte compressed tape image](http://pdp-10.trailing-edge.com/tapes/klad_sources.tap.bz2)"
|
||||||
|
which is described on the [PDP-10 KLAD Diagnostics Sources](http://pdp-10.trailing-edge.com/klad_sources/index.html) page as:
|
||||||
|
|
||||||
|
Start of Saveset Diagnostics -- binaries and documentation on
|
||||||
|
|
||||||
|
strange monitor 0(0) APR#8210
|
||||||
|
|
||||||
|
0 BPI 9-track 13-Dec-100 1:03:45 BACKUP 0(0) tape format 1
|
||||||
|
|
||||||
|
Tape number 1
|
||||||
|
|
||||||
|
The original 23.15 Mbyte file looked like this:
|
||||||
|
|
||||||
|
-rw-------@ 1 Jeff staff 23148930 Feb 3 2002 klad_sources.tap.bz2
|
||||||
|
|
||||||
|
and `bzip2 -d klad_sources.tap.bz2` produced this:
|
||||||
|
|
||||||
|
-rw-------@ 1 Jeff staff 139719984 Feb 3 2002 klad_sources.tap
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
List of KA10 Diagnostics
|
List of KA10 Diagnostics
|
||||||
------------------------
|
------------------------
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -8,3 +8,16 @@ PDP-10 Software Tapes
|
||||||
---------------------
|
---------------------
|
||||||
|
|
||||||
PCjs has not yet archived any PDP-10 software from tape.
|
PCjs has not yet archived any PDP-10 software from tape.
|
||||||
|
|
||||||
|
Tape Formats
|
||||||
|
------------
|
||||||
|
|
||||||
|
This is a topic that will obviously take some time to digest, especially when starting from scratch, so for
|
||||||
|
now, we'll just archive some relevant documents.
|
||||||
|
|
||||||
|
From [http://src.gnu-darwin.org/ports/emulators/klh10/work/klh10-2.0a/doc/vtape.txt](http://src.gnu-darwin.org/ports/emulators/klh10/work/klh10-2.0a/doc/vtape.txt):
|
||||||
|
|
||||||
|
{% highlight text %}
|
||||||
|
{% include_relative vtape.txt %}
|
||||||
|
{% endhighlight %}
|
||||||
|
|
||||||
|
|
|
||||||
493
apps/pdp10/tapes/vtape.txt
Normal file
493
apps/pdp10/tapes/vtape.txt
Normal file
|
|
@ -0,0 +1,493 @@
|
||||||
|
/* VTAPE.TXT - KLH10 Virtual Tape Format
|
||||||
|
*/
|
||||||
|
/* $Id: vtape.txt,v 2.3 2001/11/10 21:24:21 klh Exp $
|
||||||
|
*/
|
||||||
|
/* Copyright © 1994-1999, 2001 Kenneth L. Harrenstien
|
||||||
|
** All Rights Reserved
|
||||||
|
**
|
||||||
|
** This file is part of the KLH10 Distribution. Use, modification, and
|
||||||
|
** re-distribution is permitted subject to the terms in the file
|
||||||
|
** named "LICENSE", which contains the full text of the legal notices
|
||||||
|
** and should always accompany this Distribution.
|
||||||
|
*/
|
||||||
|
|
||||||
|
One of the methods used by the KLH10 to emulate PDP-10
|
||||||
|
magnetic tape devices is to provide support for "virtual tapes".
|
||||||
|
These virtual tapes are in reality disk files on the native host
|
||||||
|
system which have a specific format. Because they are native disk
|
||||||
|
files, it is far easier and faster to manipulate these virtual tape
|
||||||
|
images (for reading, writing, copying, archival, and transport over
|
||||||
|
networks) than would be the case for real physical tapes.
|
||||||
|
|
||||||
|
The purpose of this description is to allow users to generate or
|
||||||
|
maintain virtual tapes using their own tools in addition to the ones
|
||||||
|
provided in the KLH10 distribution. In most cases these tools can be
|
||||||
|
nothing more than a text editor and a simple copy program such as Unix
|
||||||
|
"dd".
|
||||||
|
|
||||||
|
VIRTUAL TAPE FORMATS
|
||||||
|
====================
|
||||||
|
|
||||||
|
Several virtual tape formats exist, developed more or less
|
||||||
|
independently. The KLH10 software can handle most of them and others
|
||||||
|
could be added if necessary. These formats are:
|
||||||
|
|
||||||
|
"RAW" - original KLH10 format
|
||||||
|
"TPS" - Wilson & Supnik format
|
||||||
|
"TPC" - DECUS/Shoppa format
|
||||||
|
"ITSDUMP" - special KLH10 format for ITS
|
||||||
|
|
||||||
|
|
||||||
|
"RAW" VIRTUAL TAPE: Directory and Data files
|
||||||
|
==================
|
||||||
|
|
||||||
|
Each RAW-format virtual tape consists of two native files, one
|
||||||
|
for the actual tape data and the other to describe that data. For
|
||||||
|
example, a virtual tape with the name "kosh" would consist of these
|
||||||
|
two files:
|
||||||
|
|
||||||
|
Virtual tape "kosh":
|
||||||
|
kosh - Tape directory (text; defines structure of data)
|
||||||
|
kosh.tap - Tape data (binary; one byte per tape frame)
|
||||||
|
|
||||||
|
|
||||||
|
"RAW" DATA FILE FORMAT (.TAP)
|
||||||
|
|
||||||
|
The tape data file is simply a continuous sequence of 8-bit bytes
|
||||||
|
corresponding to the logical stream of 8-bit tape data frames. There is
|
||||||
|
nothing in this file except tape data; there are no record boundaries or
|
||||||
|
tapemarks. Because this is a binary data file, all operations on this
|
||||||
|
file must preserve the data exactly.
|
||||||
|
|
||||||
|
|
||||||
|
"RAW" DIRECTORY FILE FORMAT (.TDR)
|
||||||
|
|
||||||
|
The tape directory is a text file that describes the contents of
|
||||||
|
its associated tape data file; it defines how the tape is structured in
|
||||||
|
terms of record boundaries, tapemarks, length, and internal format. It
|
||||||
|
can be used to describe anything about the tape in an easily readable
|
||||||
|
and editable form.
|
||||||
|
|
||||||
|
The directory is formatted as a set of logical text lines. Each
|
||||||
|
line begins with a keyword, optionally followed by data. Comments are
|
||||||
|
introduced by a semi-colon character (';') and continue to the end of
|
||||||
|
that physical line. Blank lines are ignored. Whitespace is also
|
||||||
|
ignored except at the start of a line, where indentation may be used
|
||||||
|
only when continuing a logical <filedesc> line over several physical
|
||||||
|
lines.
|
||||||
|
|
||||||
|
Keywords:
|
||||||
|
TF-Format: <fmtword> [<filename>]
|
||||||
|
; Tape datafile format and optional filename
|
||||||
|
<#>: <filedesc> ; File/Record descriptors
|
||||||
|
<indentation> <filedesc> ; optional continuation of above
|
||||||
|
EOT: ; Physical End of Tape, remaining text ignored.
|
||||||
|
|
||||||
|
<fmtword> - REQUIRED. Describes how the tape file data is stored on
|
||||||
|
disk. Currently only one keyword is fully supported:
|
||||||
|
"raw" - 8-bit bytes, one per frame.
|
||||||
|
|
||||||
|
<filename> - DEPRECATED. Optional name of tape data file, a feature
|
||||||
|
no longer used (ie ignored on input, not generated on output).
|
||||||
|
The tape data filename is either specified at mount time or
|
||||||
|
dynamically generated using ".tap" as an extension to the name of
|
||||||
|
the tape directory file. This extension replaces ".tdr" if it
|
||||||
|
exists, otherwise ".tap" is simply appended.
|
||||||
|
|
||||||
|
<#> - location in data file of 1st record beginning next file. For "raw"
|
||||||
|
format this corresponds to the logical frame # on tape as well, but
|
||||||
|
for other formats this may serve a realignment purpose.
|
||||||
|
The string "BOT" is considered equivalent to "0".
|
||||||
|
|
||||||
|
<filedesc> - a list of <recdesc> record descriptors composing the file,
|
||||||
|
separated by whitespace. The list may be empty, as is normally
|
||||||
|
the case for two consecutive tapemarks that signal a logical EOT.
|
||||||
|
|
||||||
|
<recdesc> - A record descriptor, with the format
|
||||||
|
<len>[*<cnt>][E[<type>]]
|
||||||
|
where:
|
||||||
|
<len> - decimal record length, in frames (8-bit bytes)
|
||||||
|
<cnt> - # times this record length recurs.
|
||||||
|
E - indicates error when reading this record (or the last of a
|
||||||
|
series). <type> is an optional # and specifies additional
|
||||||
|
information, if any, as to nature of the error.
|
||||||
|
|
||||||
|
The string "EOF" is a special <recdesc> that signals a tape mark.
|
||||||
|
|
||||||
|
|
||||||
|
TAPE DIRECTORY EXAMPLE:
|
||||||
|
|
||||||
|
Here is an example of a tape directory file for a small dump:
|
||||||
|
|
||||||
|
; DUMPER saveset of PS:<SYSTEM> ; Human-readable comment
|
||||||
|
TF-Format: raw ; Required, and must be "raw"
|
||||||
|
0: 2590*8407 EOF ; First file
|
||||||
|
21774130: EOF ; Second file (empty == logical EOT)
|
||||||
|
EOT: ; Physical EOT
|
||||||
|
|
||||||
|
Note that comments can exist, that the data file format is RAW, and
|
||||||
|
that it starts at frame 0 with a 2590-byte record which is repeated
|
||||||
|
8407 times, followed by an EOF tapemark, then another EOF tapemark.
|
||||||
|
The emulator software generates the second EOF using a new line so
|
||||||
|
that the tape location (21774130) can serve as a validity cross-check;
|
||||||
|
this is a compromise between putting everything on a single line or
|
||||||
|
putting each record on its own line, either of which is equally valid.
|
||||||
|
|
||||||
|
"TPS" FILE FORMAT (.TAP, .TPS, .TPE)
|
||||||
|
====================================
|
||||||
|
|
||||||
|
This is the format used by Bob Supnik's SIMH emulators. It is
|
||||||
|
almost the same as John Wilson's E11 format, which it was intended to
|
||||||
|
resemble.
|
||||||
|
|
||||||
|
A TPS file is assumed to consist of 8-bit bytes.
|
||||||
|
|
||||||
|
Each record starts with a 4-byte header in little-endian order.
|
||||||
|
The high bit of this 32-bit header is set to indicate an error of
|
||||||
|
some kind (similar to the 'E' flag in a RAW-format control file) and
|
||||||
|
the remaining 31 bits contain the record length N.
|
||||||
|
|
||||||
|
This header is followed by N data bytes plus, if N is odd, a padding
|
||||||
|
byte (of undefined value) at the end. Following this is a copy of the
|
||||||
|
4-byte record header.
|
||||||
|
|
||||||
|
Tapemarks are represented by a single header with N=0.
|
||||||
|
|
||||||
|
The reason for having the record length both before and after the
|
||||||
|
record data is so tape motion in the reverse direction can be more
|
||||||
|
easily simulated.
|
||||||
|
|
||||||
|
The E11 (.TPE) format is identical except there are no padding bytes.
|
||||||
|
|
||||||
|
|
||||||
|
"TPC" FILE FORMAT (.TPC)
|
||||||
|
========================
|
||||||
|
|
||||||
|
This format is not as flexible as the others but was
|
||||||
|
apparently quite commonly used for DECUS tape images, and Tim Shoppa
|
||||||
|
has a "couple thousand" TPC images stashed away.
|
||||||
|
|
||||||
|
A TPC file is assumed to consist of 8-bit bytes.
|
||||||
|
|
||||||
|
Each record starts with a 2-byte header in little-endian order,
|
||||||
|
containing 16 bits of record length N.
|
||||||
|
|
||||||
|
This header is followed by N data bytes plus, if N is odd, a padding
|
||||||
|
byte (of undefined value) at the end. Unlike TPS format, there is no
|
||||||
|
trailing header.
|
||||||
|
|
||||||
|
Tapemarks are represented by a single header with N=0.
|
||||||
|
|
||||||
|
Obviously it is difficult to use this format directly when reverse
|
||||||
|
tape motion is desired; an internal representation must be built.
|
||||||
|
|
||||||
|
|
||||||
|
TAPE GENERATION
|
||||||
|
|
||||||
|
There are three principal ways to create virtual tapes:
|
||||||
|
|
||||||
|
(1) Using the emulator to write tapes.
|
||||||
|
(2) Copying from real PDP-10 tapes.
|
||||||
|
(3) Creating synthesized tapes "by hand".
|
||||||
|
|
||||||
|
|
||||||
|
TAPE GENERATION [1]: Using the emulator
|
||||||
|
=======================================
|
||||||
|
|
||||||
|
Method [1] is described in the documentation for the emulator
|
||||||
|
proper; see the section "Using Virtual Tapes" in USAGE.TXT.
|
||||||
|
|
||||||
|
|
||||||
|
TAPE GENERATION [2]: Copying a real tape
|
||||||
|
========================================
|
||||||
|
|
||||||
|
This is likely to be the most common use of virtual tapes for a
|
||||||
|
new installation. This is also the only way to move data in and out of
|
||||||
|
a virtual system if there is no network support.
|
||||||
|
|
||||||
|
The simplest method for copying a real tape is to use the TAPEDD utility
|
||||||
|
provided with the emulator, as follows:
|
||||||
|
|
||||||
|
<Mount the physical tape on a drive such as /dev/rmt0a>
|
||||||
|
|
||||||
|
% tapedd it=/dev/rmt0a otv=kosh
|
||||||
|
|
||||||
|
This will copy the tape into a virtual tape named "kosh" with whatever
|
||||||
|
extension is appropriate for the format. Note that the TAPEDD
|
||||||
|
arguments have a form similar to that of the standard Unix DD utility,
|
||||||
|
but are not the same. Invoking TAPEDD without arguments will cause it
|
||||||
|
to list the possible options, most of which are never needed.
|
||||||
|
|
||||||
|
If you want to copy a virtual tape back onto a physical tape, then
|
||||||
|
the counterpart to the above command would be:
|
||||||
|
|
||||||
|
% tapedd itv=kosh ot=/dev/rmt0a
|
||||||
|
|
||||||
|
If for some reason TAPEDD is not available or you want to build a virtual
|
||||||
|
tape that isn't a direct copy of an existing physical tape, you will need
|
||||||
|
to get your hands dirty with method [3].
|
||||||
|
|
||||||
|
TAPEDD allows specifying the virtual tape format with a letter following
|
||||||
|
the "v". For example:
|
||||||
|
|
||||||
|
% tapedd it=/dev/rmt0a otvs=kosh
|
||||||
|
|
||||||
|
will copy a tape into a TPS format file called "kosh.tps".
|
||||||
|
|
||||||
|
|
||||||
|
TAPE GENERATION [3]: Creating a synthesized tape
|
||||||
|
================================================
|
||||||
|
|
||||||
|
One of the primary reasons for implementing virtual tapes as a
|
||||||
|
RAW-format pair of files (data and directory) was to simplify the
|
||||||
|
process of creating and managing these tapes by hand in an extremely
|
||||||
|
portable way, without using any special software tools.
|
||||||
|
|
||||||
|
To generate the tape directory file, all you need is a text editor.
|
||||||
|
|
||||||
|
To generate the tape data file, normally it suffices to use the Unix
|
||||||
|
utility "dd" or equivalent device-to-device copying program. You simply
|
||||||
|
need to append every byte of tape data into a sequential binary file.
|
||||||
|
|
||||||
|
For example, the tape data file corresponding to the sample tape
|
||||||
|
directory above could have been read with a command like this:
|
||||||
|
|
||||||
|
% dd if=/dev/rmt0a of=kosh.tap bs=126b
|
||||||
|
0+8407 records in
|
||||||
|
0+8407 records out
|
||||||
|
|
||||||
|
Note that to use this technique properly you must have some prior
|
||||||
|
knowledge of the record sizes on the tape. For one thing, the blocksize
|
||||||
|
specified must be larger than the largest possible record size, to avoid
|
||||||
|
record truncation (hence the bs=126b); but more importantly, without
|
||||||
|
knowing the record size you don't know what to put in the tape directory
|
||||||
|
(TDR) file. In this case, we know that TOPS-20 DUMPER records are <518
|
||||||
|
words * 5 bytes/word> = 2590 bytes and so the appropriate <recdesc> is
|
||||||
|
2590*8407. But if the records were of different lengths then DD
|
||||||
|
provides no way for you to tell what these lengths were; this is one
|
||||||
|
reason TAPEDD is easier.
|
||||||
|
|
||||||
|
[Aside: TOPS-20 DUMPER could actually use a blocking factor of up to 15,
|
||||||
|
so that records could be 15*518*5 = 38850 bytes long, but for virtual
|
||||||
|
tapes the blocking is irrelevant and a factor of 1 always works for
|
||||||
|
DUMPER.]
|
||||||
|
|
||||||
|
To read multiple files from a tape using DD you must use a non-rewind
|
||||||
|
device specification, such as "/dev/nrmt0a", and invoke DD once for
|
||||||
|
each file. Remember to insert "EOF"s at appropriate places in the
|
||||||
|
descriptor file.
|
||||||
|
|
||||||
|
Although there is an UNIX utility called READ20 that can extract
|
||||||
|
native files from TOPS-20 DUMPER format tapes (real or virtual), there
|
||||||
|
is currently none for the inverse operation. In order to transport
|
||||||
|
native files into the virtual system without a network, pretty much
|
||||||
|
your only option is to synthesize a virtual tape where the contents
|
||||||
|
are simple data files.
|
||||||
|
|
||||||
|
WFCONV is a handy utility included with the emulator that will help
|
||||||
|
prepare such files. It acts as a conversion filter, copying the
|
||||||
|
standard input to the standard output and converting the data from one
|
||||||
|
PDP-10 tape format to another. In order to fully understand why this is
|
||||||
|
needed, you need to understand something about PDP-10 tape formats; for
|
||||||
|
now, just note the following examples, and see the appendix for details.
|
||||||
|
|
||||||
|
Example 1: transferring an ASCII text file:
|
||||||
|
|
||||||
|
# Make NL -> CRLF and convert into core-dump format
|
||||||
|
% wfconv -tc > temp.tap
|
||||||
|
# Find size of file
|
||||||
|
% ls -l temp.tap
|
||||||
|
-rw-rw-r-- 1 klh klh10 18641 Apr 1 1994 temp.tap
|
||||||
|
# Use size to compute number of 512-byte records
|
||||||
|
# 18641/512 = 36, plus leftover record of 209
|
||||||
|
% cat > temp
|
||||||
|
TF-Format: raw
|
||||||
|
0: 512*36 209 EOF EOF ; 36 records plus a short 37th
|
||||||
|
EOT:
|
||||||
|
^D
|
||||||
|
%
|
||||||
|
;; Then in TOPS-20 after mounting the tape "temp":
|
||||||
|
;; Note default format is CORE-DUMP, default reclen is 512.
|
||||||
|
@copY (FROM) mta0: (TO) temp.txt
|
||||||
|
MTA0: => TEMP.TXT.1 [OK]
|
||||||
|
@vd temp.txt
|
||||||
|
|
||||||
|
PS:<OPERATOR>
|
||||||
|
TEMP.TXT.1;P777700 8 3729(36) 20-Apr-97 01:00:59 OPERATOR
|
||||||
|
@
|
||||||
|
|
||||||
|
|
||||||
|
Example 2: transferring a binary file of 8-bit bytes (no conversion needed):
|
||||||
|
|
||||||
|
% cp temp.dat temp.tap
|
||||||
|
% ls -l temp.tap # Find size of file
|
||||||
|
-rw-rw-r-- 1 klh klh10 18641 Feb 13 1994 temp.tap
|
||||||
|
% cat > temp
|
||||||
|
TF-Format: raw
|
||||||
|
0: 2560*7 721 EOF EOF
|
||||||
|
EOT:
|
||||||
|
^D
|
||||||
|
%
|
||||||
|
;; Then in TOPS-20 after mounting the tape "temp":
|
||||||
|
@set taPE rECORD-LENGTH (TO) 2560
|
||||||
|
@set taPE fORMAT (TO) iNDUSTRY-COMPATIBLE
|
||||||
|
@copY (FROM) mta0: (TO) temp.dat,
|
||||||
|
@@byTE (SIZE) 8
|
||||||
|
@@
|
||||||
|
MTA0: => TEMP.DAT.1 [OK]
|
||||||
|
@vd temp.dat
|
||||||
|
|
||||||
|
PS:<OPERATOR>
|
||||||
|
TEMP.DAT.1;P777700 10 18641(8) 19-Apr-97 23:57:46 OPERATOR
|
||||||
|
@
|
||||||
|
|
||||||
|
|
||||||
|
Example 3: building a TOPS-20 installation tape
|
||||||
|
|
||||||
|
If you already have a TOPS-20 system, especially one with local
|
||||||
|
modifications (which pretty much includes everyone), you may wish to
|
||||||
|
build your own installation tape. The following illustrates what the
|
||||||
|
tape directory of the V7.0 TOPS-20 installation tape looks like. Note
|
||||||
|
it does not have an initial bootstrap on it since MTBOOT is assumed to
|
||||||
|
be already loaded in the PDP-10 memory.
|
||||||
|
|
||||||
|
; Tape directory for V7.0 TOPS-20 installation tape
|
||||||
|
; Bytes: 22519060, Records: 8704, Files(EOF marks): 7
|
||||||
|
TF-Format: raw
|
||||||
|
0: 2560*597 EOF ; MONITR.EXE
|
||||||
|
1528320: 2560*125 EOF ; EXEC.EXE
|
||||||
|
1848320: 2560*8 EOF ; DLUSER.EXE
|
||||||
|
1868800: 1270 EOF ; DLUSER data
|
||||||
|
1870070: 2560*36 EOF ; DUMPER.EXE
|
||||||
|
1962230: 2590*7937 EOF ; DUMPER savesets for <SYSTEM>, etc.
|
||||||
|
22519060: EOF
|
||||||
|
EOT:
|
||||||
|
|
||||||
|
All of these files must be in core-dump format. You can generate the
|
||||||
|
tape either by:
|
||||||
|
(1) creating it on a real TOPS system and then using it directly
|
||||||
|
or using TAPEDD to copy it into a virtual tape.
|
||||||
|
(2) copying the necessary files over, converting them into core-dump
|
||||||
|
format, and concatenating them to form a virtual tape.
|
||||||
|
|
||||||
|
See "klt20.txt" for more details on how such an installation tape is
|
||||||
|
actually used.
|
||||||
|
|
||||||
|
|
||||||
|
Quick lesson in tape formats:
|
||||||
|
|
||||||
|
A PDP-10 word is 36 bits. The 8-bit bytes ("frames" on 9-track
|
||||||
|
drives) that are now universal for tape don't fit exactly into 36 bits,
|
||||||
|
which opens a Pandora's Box of packing options. The basic formats
|
||||||
|
offered at one time or another on Digital systems are as follows:
|
||||||
|
|
||||||
|
WFCONV mode TOPS-20 name
|
||||||
|
----------- ------------------
|
||||||
|
a ANSI-ASCII
|
||||||
|
c CORE-DUMP
|
||||||
|
h HIGH-DENSITY
|
||||||
|
i INDUSTRY-COMPATIBLE
|
||||||
|
s SIXBIT
|
||||||
|
|
||||||
|
Only CORE-DUMP and INDUSTRY-COMPATIBLE are universally supported; the
|
||||||
|
others are features of older or newer formatters. In general, the TOPS-20
|
||||||
|
monitor expects CORE-DUMP format so that should be your normal choice.
|
||||||
|
|
||||||
|
Tape_Coredump (5 tape bytes per word)
|
||||||
|
B0 1 2 3 4 5 6 7
|
||||||
|
8 9 10 11 12 13 14 15
|
||||||
|
16 17 18 19 20 21 22 23
|
||||||
|
24 25 26 27 28 29 30 31
|
||||||
|
0 0 0 0 32 33 34 35
|
||||||
|
|
||||||
|
Tape_Indust (4 tape bytes per PARTIAL word)
|
||||||
|
B0 1 2 3 4 5 6 7
|
||||||
|
8 9 10 11 12 13 14 15
|
||||||
|
16 17 18 19 20 21 22 23
|
||||||
|
24 25 26 27 28 29 30 31 ; Bits 32-35 are unused!
|
||||||
|
|
||||||
|
Tape_Sixbit (6 tape bytes per word)
|
||||||
|
0 0 B0 1 2 3 4 5
|
||||||
|
0 0 6 7 8 9 10 11
|
||||||
|
0 0 12 13 14 15 16 17
|
||||||
|
0 0 18 19 20 21 22 23
|
||||||
|
0 0 24 25 26 27 28 29
|
||||||
|
0 0 30 31 32 33 34 35
|
||||||
|
|
||||||
|
Tape_Ascii (5 tape bytes per word)
|
||||||
|
0 B0 1 2 3 4 5 6
|
||||||
|
0 7 8 9 10 11 12 13
|
||||||
|
0 14 15 16 17 18 19 20
|
||||||
|
0 21 22 23 24 25 26 27
|
||||||
|
35 28 29 30 31 32 33 34
|
||||||
|
|
||||||
|
Tape_Hidens (9 tape bytes per 2 words)
|
||||||
|
B0 1 2 3 4 5 6 7
|
||||||
|
8 9 10 11 12 13 14 15
|
||||||
|
16 17 18 19 20 21 22 23
|
||||||
|
24 25 26 27 28 29 30 31
|
||||||
|
32 33 34 35 B0 1 2 3
|
||||||
|
4 5 6 7 8 9 10 11
|
||||||
|
12 13 14 15 16 17 18 19
|
||||||
|
20 21 22 23 24 25 26 27
|
||||||
|
28 29 30 31 32 33 34 35
|
||||||
|
|
||||||
|
|
||||||
|
WFCONV operation notes
|
||||||
|
======================
|
||||||
|
|
||||||
|
Invoking WFCONV without arguments will print out a summary similar to
|
||||||
|
the following:
|
||||||
|
|
||||||
|
Usage: wfconv -io <infile >outfile\n\
|
||||||
|
where 'i' and 'o' are chars specifying the input and output formats:
|
||||||
|
c - Core-dump (std tape format, 4 8-bit, 1 4-bit bytes = 36 bits)
|
||||||
|
h - High-density (FTP 36-bit image, 9 8-bit bytes = 72 bits)
|
||||||
|
a,7 - Ansi-Ascii (4 7-bit, 1 8-bit byte = 36 bits)
|
||||||
|
s,6 - Sixbit (6 6-bit bytes = 36 bits)
|
||||||
|
u - Unixified (Alan Bawden format, various = 36 bits)
|
||||||
|
t - Text-Newline (CRLF-NL conversion; 5 7-bit bytes = 35 bits ONLY)
|
||||||
|
d - Debug (for output only)
|
||||||
|
Note: EOF on input always causes zero-padding up to a PDP-10 word boundary.
|
||||||
|
|
||||||
|
Typical uses of WFCONV would be as follows:
|
||||||
|
|
||||||
|
1. Examining a PDP-10 text file copied from a tape:
|
||||||
|
|
||||||
|
# Convert from core-dump to ansi-ascii (preserve CRs)
|
||||||
|
$ wfconv -ca < file.tap > file.asc
|
||||||
|
or:
|
||||||
|
# Convert from core-dump to text-newline (convert CRLFs to NLs)
|
||||||
|
$ wfconv -ct < file.tap > file.txt
|
||||||
|
|
||||||
|
2. Preparing a text file for writing to tape:
|
||||||
|
|
||||||
|
# Convert from ansi-ascii to core-dump (preserve NLs)
|
||||||
|
$ wfconv -ac < file.asc > file.tap
|
||||||
|
or:
|
||||||
|
# Convert from text-newline to core-dump (convert NLs to CRLFs)
|
||||||
|
$ wfconv -tc < file.txt > file.tap
|
||||||
|
|
||||||
|
3. Preparing a file for tape after transferring it from a real PDP-10
|
||||||
|
using FTP 36-bit Image mode:
|
||||||
|
|
||||||
|
# Convert from high-density (FTP Image) to core-dump
|
||||||
|
$ wfconv -hc < file.ftp > file.tap
|
||||||
|
|
||||||
|
|
||||||
|
Note:
|
||||||
|
|
||||||
|
Due to the fact that PDP-10 words are used as the canonical input
|
||||||
|
conversion target (and output conversion source), input is always
|
||||||
|
effectively rounded up to a word boundary.
|
||||||
|
|
||||||
|
This can cause the addition of a few trailing zero bytes when converting
|
||||||
|
from Text-Newline or Ansi-ASCII format, so WFCONV is not a
|
||||||
|
general-purpose text-to-text conversion program. For that, one can use:
|
||||||
|
|
||||||
|
# To insert CR (must use ^V or equiv to quote the ^M)
|
||||||
|
$ sed 's/$/\^M/' temp.nls > temp.crlfs
|
||||||
|
|
||||||
|
# To delete CR (must use ^V or equiv to quote the ^M)
|
||||||
|
$ sed 's/\^M$//' temp.crlfs > temp.nls
|
||||||
|
|
||||||
101
apps/pdp10/tops10/README.md
Normal file
101
apps/pdp10/tops10/README.md
Normal file
|
|
@ -0,0 +1,101 @@
|
||||||
|
---
|
||||||
|
layout: page
|
||||||
|
title: PDP-10 TOPS-10
|
||||||
|
permalink: /apps/pdp10/tops10/
|
||||||
|
---
|
||||||
|
|
||||||
|
PDP-10 TOPS-10
|
||||||
|
--------------
|
||||||
|
|
||||||
|
Having never used TOPS-10 in real life, it seemed like a good idea to get familiar with it first, using another
|
||||||
|
emulator. Thankfully, [The Digital Antiquarian](http://www.filfre.net/) created "[TOPS-10 in a Box](http://www.filfre.net/2011/05/tops-10-in-a-box/)",
|
||||||
|
everything you need to run TOPS-10 on a virtual PDP-10.
|
||||||
|
|
||||||
|
From README.txt (in the "TOPS-10 in a Box" zip file):
|
||||||
|
|
||||||
|
STARTING YOUR VIRTUAL PDP-10
|
||||||
|
============================
|
||||||
|
|
||||||
|
1. Bring up a command prompt in the PDP-10 In a Box directory using whatever technique is normal for your platform.
|
||||||
|
|
||||||
|
2. Enter "pdp10 tops10.cfg".
|
||||||
|
|
||||||
|
3. At the "BOOT>" prompt, just press enter.
|
||||||
|
|
||||||
|
4. At the "Why reload:" prompt, enter "NEW".
|
||||||
|
|
||||||
|
5. At the "Date:" prompt, just press enter to accept your host computer's current date.
|
||||||
|
If you wish, you may enter another date in the format "MM-DD-YYYY".
|
||||||
|
|
||||||
|
6. At the "Time:" prompt, just press enter to accept your host computer's current time.
|
||||||
|
If you wish, you may enter another time in the format "HHMMSS".
|
||||||
|
|
||||||
|
7. At the "Startup option:" prompt, enter "GO".
|
||||||
|
|
||||||
|
8. After a moment, the system will place you in the system operator's console (denoted by the "OPR>" prompt).
|
||||||
|
To work with programs and files like a normal user, just type "EXIT" here.
|
||||||
|
|
||||||
|
Unfortunately, my first attempt hung after step #3, which I resolved by downgrading from [SIMH V4.0](https://github.com/simh/simh/releases/tag/v4.0-devel)
|
||||||
|
to the older [SIMH V3.9](http://simh.trailing-edge.com/sources/simhv39-0.zip). Here's the resulting output:
|
||||||
|
|
||||||
|
PDP-10 simulator V3.9-0
|
||||||
|
Listening on port 2020 (socket 5)
|
||||||
|
Modem control activated
|
||||||
|
Auto disconnect activated
|
||||||
|
Logging to file "tops10.log"
|
||||||
|
BOOT V4(76)
|
||||||
|
|
||||||
|
BOOT>
|
||||||
|
[Loading from DSKB:SYSTEM.EXE[1,4]]
|
||||||
|
|
||||||
|
KS10 07-Oct-88
|
||||||
|
Why reload: NEW
|
||||||
|
Date:
|
||||||
|
Time:
|
||||||
|
Startup option: GO
|
||||||
|
[Rebuilding the system search list from the HOM blocks]
|
||||||
|
|
||||||
|
[Rebuilding the active swapping list from the HOM blocks]
|
||||||
|
|
||||||
|
[Rebuilding the system dump list from the HOM blocks]
|
||||||
|
|
||||||
|
|
||||||
|
KS10 09:09:41 CTY system 4097
|
||||||
|
Connected to Node CENTRA(0) Line # 42
|
||||||
|
.LOGIN 1,2
|
||||||
|
.R OPR
|
||||||
|
|
||||||
|
[CCPWFD Waiting for file daemon to start]
|
||||||
|
%%TTY STOMPER - Starting
|
||||||
|
OPR>
|
||||||
|
9:09:51 -- Message from the Accounting System --
|
||||||
|
Account validation is not required
|
||||||
|
|
||||||
|
9:09:52 -- Begin auto take file --
|
||||||
|
File: SYS:SYSTEM.CMD[1,4]
|
||||||
|
|
||||||
|
9:09:52 -- End auto take file --
|
||||||
|
17 lines processed
|
||||||
|
|
||||||
|
OPR>
|
||||||
|
|
||||||
|
At this point, I stopped, because now that I knew the `pdp10` binary from
|
||||||
|
[SIMH V3.9](http://simh.trailing-edge.com/sources/simhv39-0.zip) worked on my system (macOS), I wanted to
|
||||||
|
create an Xcode project to build *just* that binary, and make it easier for me to modify and debug that binary.
|
||||||
|
|
||||||
|
I had already run `make` to build the official SimH `pdp10` binary, so in order to isolate all the commands required
|
||||||
|
to build *just* `pdp10`, I re-ran `make` with `-B` to unconditionally remake all targets and `-n` to print the commands
|
||||||
|
that would be executed with executing them, and then isolated the PDP10-specific command(s) with `grep`:
|
||||||
|
|
||||||
|
make -Bn | grep pdp10
|
||||||
|
|
||||||
|
I was pleasantly surprised to see that there was only one (albeit rather lengthy) command:
|
||||||
|
|
||||||
|
gcc -std=c99 -U__STRICT_ANSI__ -O2 -finline-functions -flto -fwhole-program -I . -D_GNU_SOURCE -DUSE_READER_THREAD \
|
||||||
|
-DHAVE_DLOPEN=dylib PDP10/pdp10_fe.c PDP11/pdp11_dz.c PDP10/pdp10_cpu.c PDP10/pdp10_ksio.c PDP10/pdp10_lp20.c \
|
||||||
|
PDP10/pdp10_mdfp.c PDP10/pdp10_pag.c PDP10/pdp10_rp.c PDP10/pdp10_sys.c PDP10/pdp10_tim.c PDP10/pdp10_tu.c \
|
||||||
|
PDP10/pdp10_xtnd.c PDP11/pdp11_pt.c PDP11/pdp11_ry.c PDP11/pdp11_cr.c scp.c sim_console.c sim_fio.c sim_timer.c \
|
||||||
|
sim_sock.c sim_tmxr.c sim_ether.c sim_tape.c -DVM_PDP10 -DUSE_INT64 -I PDP10 -I PDP11 -o BIN/pdp10 -lm -lpthread \
|
||||||
|
-ldl -flto -fwhole-program
|
||||||
|
|
||||||
|
It was time to build the Xcode project.
|
||||||
|
|
@ -15,7 +15,7 @@ PDP-10 Hardware Publications
|
||||||
----------------------------
|
----------------------------
|
||||||
|
|
||||||
- [PDP-10 System Reference Manual (May 1968)](http://archive.pcjs.org/pubs/dec/pdp10/ka10/DEC-10-HGAA-D_PDP-10_System_Reference_Manual_May1968.pdf) [[Original PDF](http://bitsavers.trailing-edge.com/pdf/dec/pdp10/KA10/DEC-10-HGAA-D_PDP-10_System_Reference_Manual_May1968.pdf)]
|
- [PDP-10 System Reference Manual (May 1968)](http://archive.pcjs.org/pubs/dec/pdp10/ka10/DEC-10-HGAA-D_PDP-10_System_Reference_Manual_May1968.pdf) [[Original PDF](http://bitsavers.trailing-edge.com/pdf/dec/pdp10/KA10/DEC-10-HGAA-D_PDP-10_System_Reference_Manual_May1968.pdf)]
|
||||||
- [DECSYSTEM-10/DECSYSTEM-20 Processor Reference Manual (June 1982)](http://archive.pcjs.org/pubs/dec/pdp10/tops10/AA-H391A-TK_DECsystem-10_DECSYSTEM-20_Processor_Reference_Jun1982.pdf) [[Original PDF](http://bitsavers.org/pdf/dec/pdp10/TOPS10_softwareNotebooks/vol05/AA-H391A-TK_DECsystem-10_DECSYSTEM-20_Processor_Reference_Jun1982.pdf)]
|
- [DECSYSTEM-10/DECSYSTEM-20 Processor Reference Manual (June 1982)](http://archive.pcjs.org/pubs/dec/pdp10/kl10/AA-H391A-TK_DECsystem-10_DECSYSTEM-20_Processor_Reference_Jun1982.pdf) [[Original PDF](http://bitsavers.org/pdf/dec/pdp10/TOPS10_softwareNotebooks/vol05/AA-H391A-TK_DECsystem-10_DECSYSTEM-20_Processor_Reference_Jun1982.pdf)]
|
||||||
|
|
||||||
PDP-10 Software Publications
|
PDP-10 Software Publications
|
||||||
----------------------------
|
----------------------------
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue