Retro/pcjs
Watch
1
0
Fork
You've already forked pcjs
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

README updates

Browse source
This commit is contained in:
Jeff Parsons 2017-04-30 10:13:05 -07:00 • committed by Jeff Parsons
commit abce30fda5
5 changed files with 630 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

23
apps/pdp10/diags/ka10/README.md
View file

@ -7,13 +7,34 @@ permalink: /apps/pdp10/diags/ka10/
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
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)
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
------------------------

13
apps/pdp10/tapes/README.md
View file

@ -8,3 +8,16 @@ PDP-10 Software Tapes
---------------------
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
View 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
View 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.