github.com/PDP-10.klh10
1
0
Fork 0
mirror of https://github.com/PDP-10/klh10.git synced 2026-04-28 12:47:06 +00:00
Code Issues Releases Wiki Activity

Overlay panda-dist/klh10-2.0h

Browse Source 
by the late MRC, Mark Crispin.
Source: probably the former http://panda.com/tops-20/ .
panda-dist.tar.gz dated Mar 30  2007.
This commit is contained in:
Olaf Seibert
2015-04-27 23:07:21 +02:00
parent 00b977cfde
commit 58b59dbaa1
102 changed files with 28844 additions and 1575 deletions
Download Patch File Download Diff File Expand all files Collapse all files

67
doc/bugs.txt Normal file
View File

@@ -0,0 +1,67 @@
/* BUGS.TXT - KLH10 known bug list
*/
/* $Id$
*/
/* Copyright © 2002 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.
*/
KNOWN BUGS
==========
- KS TOPS-10 7.03 disk boot produces:
KLH10 PANIC: rh11_iobeg: drv/ctrlr mismatch: 7/0
Reported by Quebbeman 23-Nov-2001.
(Another race condition? Unable to reproduce.)
- KS TOPS-10 7.03 install from tape periodically hangs on MT.
(This is believed to be race condition similar to KL boot,
thus fixed in 2.0E, but must confirm.)
Weirdness. From msg to Supnik:
Date: Tue, 30 Apr 2002 3:34:23 EDT
From: Ken Harrenstien <klh@panix.com>
To: Bob Supnik <bsupnik@us.inter.net>
Cc: klh@panix.com
Subject: Interesting T10+KS10 CTY interaction
Message-ID: <CMM.0.90.4.1020152063.klh@panix2.panix.com>
I was trying to clean out my bug list and looked into the one where
TOPS-10 on a KLH10 KS10 sometimes complains "?Device hung" while reading
from magtape.
I don't yet know the exact sequence of events, but it turns out this
is directly affected by the duration between TOPS-10 giving the FE
a CTY output character, and the FE's "done" interrupt of the KS10.
By default I have this delay set to roughly 50 instructions for
TOPS-20, which is needed to get around some poor driver code. TOPS-10
seemed to work fine with the same default so I left it as is.
However, if I reset this delay to 0 (same as for the ITS version), I
get no magtape hangs!
This is really bizarre. I am used to problems caused by devices that
are too fast, or CPU loops that are too fast, but this one doesn't fit
the pattern. It means that an instantaneous response from the FE
works, but one delayed by a mere 50 instructions will repeatably screw
something up -- perhaps losing a RH11 interrupt or something. This
happens using "synchronous" debugging mode where one virtual usec is
one instruction execution, so there are no real-time factors and
everything is in theory reproducible.
My question is, for SIMH did you encounter anything similar, or are
you aware of anything in the TOPS-10 monitor that might be relevant?
I notice that your FE implementation defaults to a SERIAL_OUT_WAIT
delay of "10", though I'm not sure what that means (10 what?). Since
that's generic for all of your simulated machines I assume it doesn't
necessarily have KS10 implications.
--Ken

43
doc/cmdref.txt
View File

@@ -1,6 +1,6 @@
/* CMDREF.TXT - KLH10 Command Reference documentation
*/
/* $Id: cmdref.txt,v 2.3 2001/11/10 21:24:21 klh Exp $
/* $Id: cmdref.txt,v 2.4 2002/03/21 09:43:01 klh Exp $
*/
/* Copyright © 1994-1999, 2001 Kenneth L. Harrenstien
** All Rights Reserved
@@ -33,22 +33,28 @@ KLH10 COMMAND REFERENCE: (in ASCII lexical order)
^\, CONTROL-\, ASCII "FS"
This is not exactly a KLH10 command; it is the command escape
character, which can be typed anytime the KN10 is running.
It should halt the KN10 immediately with the message
character, which can be typed anytime the KN10 is running
in order to return to the KLH10 command parser.
If "fe_runenable" is off (default) then ^\ will halt the
KN10 immediately with the message:
[HALTED: FE interrupt]
KLH10> ; command prompt when "halted"
Followed by the KLH10 command parser prompt:
But if "fe_runenable" is on, then ^\ will NOT halt the
KN10. Instead, it will give you a slightly different prompt:
KLH10>
KLH10>> ; command prompt when "running"
Typing ^\ while in the command parser should have no effect,
although this depends on the native OS.
1-STEP
Single-steps the KN10 by executing one instruction. For debugging.
This is the same as "proceed 1".
1-STEP [<n>]
Single-steps the KN10 by executing <n> instructions. For debugging.
<n> defaults to 1 if not specified.
Most useful with TRACE-TOGGLE.
BREAKPT <addr>
@@ -67,6 +73,8 @@ BREAKPT <addr>
CONTINUE
Continues the KN10 at the current PC.
This works whether the KN10 is halted or running, and returns
the CTY back to the KN10 (ie leaves the command parser).
This is the normal method of continuing after interrupting the
KN10 with ^\.
@@ -328,11 +336,7 @@ GO [<addr>]
HALT
Halt KN10 immediately.
Currently this is a no-op because if you're in the KLH10 command
parser that means the KN10 is already halted!
When the KLH10 allows concurrent execution this will become a
meaningful command.
Halt KN10 immediately if running.
HELP [<cmd>]
@@ -378,9 +382,9 @@ NEXT-EXAMINE
Increments the current location ("dot") by 1 and then does "examine".
PROCEED <#>
Single-steps the KN10 by the specified number of instructions.
Most useful with TRACE-TOGGLE.
PROCEED
Similar to CONTINUE, but does not return the CTY to the KN10;
the command parser remains active.
QUIT
@@ -409,6 +413,13 @@ SET [<var>[=<val>]]
information is of use only when debugging. The variables
that a user might plausibly want to set follow below.
SET FE_RUNENABLE=<boolean> - Set desired handling of ^\
Defaults to OFF, which means that ^\ halts the KN10 before
returning to the command parser ("simple" input mode).
If set to ON, ^\ will still return to the command parser but
will keep the KN10 running ("concurrent" input mode).
SET SW=<word-value> - Set KN10 data switches
This is sometimes needed for diagnostics or bootstrap loaders,
which read the data switches as a crude form of input.

9
doc/cmdsum.txt
View File

@@ -1,6 +1,6 @@
/* CMDSUM.TXT - KLH10 Command Summary
*/
/* $Id: cmdsum.txt,v 2.3 2001/11/10 21:24:21 klh Exp $
/* $Id: cmdsum.txt,v 2.4 2002/03/21 09:43:01 klh Exp $
*/
/* Copyright © 1994-1999, 2001 Kenneth L. Harrenstien
** All Rights Reserved
@@ -16,6 +16,7 @@ by functional category. See "cmdref.txt" for more details on each.
BASIC:
^\ Interrupt KN10, return to command parser
help [<cmd>] Shows help for all matching commands (defaults to all)
load <file> Load binary into KN10, sets start-addr
go [<addr>] Start KN10 at address (defaults to start-addr)
@@ -33,10 +34,10 @@ DEBUGGING:
deposit <addr> <val> Deposit value at address
breakpt <addr> Set PC breakpoint to <addr>
1-step Single-step KN10
proceed <#> Single-step # instrs
1-step [<#>] Single-step KN10 # instrs
proceed Proceed KN10 but stay in command parser
trace-toggle Toggle execution trace printout
continue Continue KN10
continue Continue KN10, give it CTY
dump <file> Dump binary from KN10
halt Halt KN10 immediately

7
doc/kldiff.txt
View File

@@ -1,3 +1,8 @@
* As of June 15, 2006, the KLH10 microcode in the Panda distribution
* implements address break. Thus, item [C5] under CPU Hardware Differences
* no longer applies, and the TOPS-20 SET ADDRESS-BREAK command now works as
* expected.
/* KLDIFF.TXT - Differences between KLH10 and KL10
*/
/* $Id: kldiff.txt,v 2.3 2001/11/10 21:24:21 klh Exp $
@@ -187,5 +192,5 @@ Without going into unnecessary detail, here are the main items.
[C11] SBDIAG partially implemented
Only the SBDIAG functions necessary to keep the TOPS-10 and TOPS-20
monitors happy are implemented. The emulated machine pretends to
have a MF20 that responds to the entire range of 22-bit physical
have a MG20 that responds to the entire range of 22-bit physical
memory (4096K).

191
doc/kldiff.txt.orig Normal file
View File

@@ -0,0 +1,191 @@
/* KLDIFF.TXT - Differences between KLH10 and KL10
*/
/* $Id: kldiff.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.
*/
This file attempts to summarize the known visible differences between
the KLH10 emulator's "KN10" processor and an actual DEC KL10,
specifically a Model B CPU running version 442 of the microcode.
It is important to remember that it is very difficult to stumble
across these differences unless you are looking hard. As a practical
matter, for users there is far less of a difference between the KN10
and a KL10 than there were between different releases of the KL10
microcode.
As one illustration of this point, DEC diagnostics are mentioned in
several places, but their reports must be taken with large grains of
salt. Many stopped working for the latest KL10s, and some only worked
when loaded with older microcode; in order to run those, the KLH10 must
be built with a "hybrid" KN10.
USER MODE DIFFERENCES
=====================
[U1] No Public mode.
The KN10 does not implement public mode; it was considered to
have little real use (the KS10 does not implement it), and would make
execution slower. This is discussed in more detail in the exec mode
section.
[U2] Floating point results with normalized operands.
Some floating-point results may differ by a single low-order
bit, particularly FDV with negative operands.
This is noticed by the diagnostic DFKCA.
[U3] Floating point results with unnormalized operands.
There are certain cases where unnormalized operands may
produce different results in the low-order bits, apparently due to
sloppiness in the KL10 hardware.
DFDV is the most notable example; when given wildly
unnormalized operands, some low-order bits are cleared by the KN10 to
produce logically correct results, but these same bits are filled with
mysterious garbage on the KL10. Note that the same operands on a KS10
produce "clean" results that exactly match those of the KN10!
Diagnostics don't notice this as they never use unnormalized
operands.
[U4] Extended instruction set (string ops)
These instructions have so many undefined aspects, and their
microcode implementation changed so often, that it is difficult to say
much here beyond acknowledging that certain esoteric failure cases may
well produce different results. "Normal" cases should all be
identical.
The diagnostic DFKCC detects no differences except for the
intermediate AC values of an interrupted CVTBDx, where a KL10 saves a
fractional quantity and the KN10 saves an integral quantity; but
nothing should actually be examining this intermediate value.
[U5] Traps (1,2,3), PC, Page Fault.
Traps on the KN10 are handled in subtly different ways than
traps on a KL10. For the most part there is no observable difference,
but peculiar cases do exist.
In general, the PC seen by a trap instruction may be different
from that on a KL10 if the offending instruction (which set the trap
flags) was a jump or skip. However, either of these are problematical
for a KL10 trap handler as well.
On the KN10, an instruction that sets any trap flags will
trap as soon as the instruction is complete, with the PC pointing to
the next instruction (and backed up before executing the trap
instruction).
This differs from a KL10 where it is possible for the
next-instruction c(PC) fetch to cause a page fault before the trap is
handled. The diagnostic DFKEA notices this. N.B.: This is not the
same as a page fault during execution of either the offending
instruction or the trap instruction, both of which are correctly
handled.
EXEC MODE DIFFERENCES
=====================
Most of these are hidden from the user altogether.
[E1] No Public or Supervisor modes.
The KN10 does not implement public mode; it was considered to
have little real use, and would make execution slower. The KN10 does
keep the Public bit in page map entries, but never actually sets
Public when fetching instructions from a Public page, nor does it
verify whether an operation is permitted if in Public/Supervisor mode.
Note that the DEC KS10 does not implement this either, so the
functionality is presumably not terribly important.
However, this confuses and ultimately crashes the diagnostic
DFKEB which tests specifically for the operational differences between
user, public, kernel, and supervisor modes.
[E2] No Previous-Context-Public PC flag.
The KN10 always treats PC flag bit 0 as being "overflow",
which means that anything that stores the PC flags in exec mode will
get the state of the overflow flag, rather than the PCP flag as on a
real KL10.
This mildly irritates some diagnostics when run in exec mode,
specifically DFKCA, DFKCB, and DFKDA, which expect bit 0 to stay clear.
[E4] Page fail in interrupt instruction (IO Page Fail)
The KN10 implements the documented behavior for this, which
is to trigger an IO-Page-Fail interrupt rather than taking a page fail
trap. However, according to the diagnostic DFKEA, a real KL10 should
take the trap, contrary to the Processor Reference Manual (p.3-65).
It is unclear whether DFKEA's interpretation is correct or corresponds
to old versions of the KL10. In any case, a monitor should never let
this happen in the first place.
[E5] PXCT in non-zero section
The problem is that no one is sure any more exactly how PXCT
is *supposed* to work, or even how it *does* work on the KL10! The
original KN10 implementation conformed to the available
documentation, and passed the PXCT diagnostic DFKEC perfectly, but
caused page faults when used with real monitors and certain user
programs. The current modified implementation works for all TOPS-10
and TOPS-20 software tested to date, but now triggers two failure
cases in DFKEC.
CPU HARDWARE DIFFERENCES
========================
There are several things about the KL10 hardware that are not
implemented at all in the KN10, either because the features are
never used by a monitor or would be too impractical to implement.
Without going into unnecessary detail, here are the main items.
[C1] Interrupt Instructions - no BLKI, BLKO
Only JSR and XPCW are supported.
(plus AOSE, SKIPE, and JSP to keep diagnostics happy).
[C2] Interrupt Functions - only those needed are implemented.
[C3] CONI/CONO PI, - bits <18:20> not implemented.
The diagnostic DFKDA notices this.
[C4] No Cache
All of the "Sweep Cache" instructions are no-ops that merely
clear Sweep Busy and set Sweep Done. The cache strategy bits <18:19>
in a CONI/CONO PAG, are ignored.
[C5] No Address Break
DATAO APR, remembers the break information for a DATAI APR,
but the actual functionality is not implemented, and will probably
never be, for efficiency reasons.
The diagnostic DFKDA notices this.
[C6] Time Base doubleword - not updated except by RDTIME.
[C7] Interval Counter - not as precise.
[C8] No Execution Account counter
[C9] No Memory Account counter
[C10] No Performance Analysis counter
[C11] SBDIAG partially implemented
Only the SBDIAG functions necessary to keep the TOPS-10 and TOPS-20
monitors happy are implemented. The emulated machine pretends to
have a MF20 that responds to the entire range of 22-bit physical
memory (4096K).

43
doc/news.txt
View File

@@ -1,6 +1,6 @@
/* NEWS.TXT - KLH10 Change Summaries and other news
*/
/* $Id: news.txt,v 2.1 2001/11/19 12:13:12 klh Exp $
/* $Id: news.txt,v 2.6 2002/05/21 17:14:52 klh Exp $
*/
/* Copyright © 2001 Kenneth L. Harrenstien
** All Rights Reserved.
@@ -11,21 +11,38 @@
** and should always accompany this Distribution.
*/
KNOWN BUGS
==========
Still outstanding:
- KS TOPS-10 7.03 install from tape periodically hangs on MT.
- KS TOPS-10 7.03 disk boot produces:
KLH10 PANIC: rh11_iobeg: drv/ctrlr mismatch: 7/0
(Of course, this will never be a complete list!)
KLH10 CHANGES
=============
KLH10 2.0G: 21-May-2002
- Fixed Large File Support for disks.
- New XBLT algorithm to fix obscure bug.
- Unibus warnings now suppressed unless ub_debug is set.
- NetBSD makefiles fixed.
- DTE timezone tweaked for DST compensation.
- Added KLH10_I_CIRC conditional to allow CIRC on non-ITS systems.
KLH10 2.0E: 23-Apr-2002
- Added workaround for T10/T20 tape boot races (more prevalent
with ever-faster processors that zip through timing loops).
- Linux hardware tape support done for now, will be better when
Linux tape driver (st.c) is fixed.
- Now uses nanosleep() on systems supporting it.
- Changed all makefiles that invoke GCC to use -O3 instead of -O.
This should improve performance slightly, at some risk of
breakage.
KLH10 2.0D: 28-Mar-2002
- Several VMTAPE bugs fixed; revised RAW format code.
- DTE now reports correct local timezone (used by KL TOPS-20).
- Tape drive serial #s are now uniquized (like disks).
- Now uses Large File Support on systems that have it; can now
handle tapes of over 2GB on 32-bit systems.
KLH10 2.0C: 20-Mar-2002
- Added concurrent command mode.
- Better Linux hardware tape support; still not complete.
KLH10 2.0A: 19-Nov-2001
- Revised ARP code in dpimp.c to fix problems with Linux port;
ITS networking now supported on Linux!

102
doc/usage.txt
View File

@@ -1,6 +1,6 @@
/* USAGE.TXT - KLH10 Usage Instructions
*/
/* $Id: usage.txt,v 2.3 2001/11/10 21:24:21 klh Exp $
/* $Id: usage.txt,v 2.4 2002/03/21 09:43:01 klh Exp $
*/
/* Copyright © 1994-1999, 2001 Kenneth L. Harrenstien
** All Rights Reserved
@@ -11,30 +11,33 @@
** and should always accompany this Distribution.
*/
This file provides basic pointers for using the KLH10.
See "install.txt" for information on installing and configuring the KLH10.
This file provides basic pointers for KLH10 operation. See
"install.txt" for information on KLH10 installation and configuration.
KLH10 STARTUP:
You should not start the KLH10 unless you have installed it in
its "home directory" and are connected to that directory (see the file
"install.txt" if necessary). Then simply give the following shell
command:
% klh10
A KLH10 installation has several binaries; the one you want to
start is normally called either "kn10-ks" or "kn10-kl" depending on
the version you have built. These should all be installed in a KLH10
"home directory" and you should be connected to that directory (see
the file "install.txt" if necessary). Then simply give the following
shell command:
The KLH10 will start up, allocate and clear KN10 memory, and begin
reading commands from the default file "klh10.ini". If you wish to
use a different init file, you can specify it on the command line, for
example:
% klh10 test.ini ; Use "test.ini" instead of "klh10.ini"
% klh10 /dev/null ; Use nothing
% ./kn10-kl ; or ./kn10-ks
The KN10 process will start up, allocate and clear KN10 memory, and
begin reading commands from the default file "klh10.ini". If you wish
to use a different init file, you can specify it on the command line,
for example:
% ./kn10-kl test.ini ; Use "test.ini" instead of "klh10.ini"
% ./kn10-kl /dev/null ; Use nothing
Or you can simply edit or delete "klh10.ini" itself.
KLH10 COMMAND PARSER:
After starting the KLH10 you will be talking to the command
After starting the KN10 you will be talking to the command
parser. This serves a function very similar to that of the RSX20F
PARSER front-end program for a real KL10. However, the KLH10 commands
are nothing like PARSER commands. For a list of the commands, see
@@ -44,18 +47,18 @@ the files "cmdsum.txt" and "cmdref.txt".
parser is to get the KN10 configured, load a bootstrap program, and
start it; from there on you interact only with the KN10. This can all
be done automatically by commands in the "klh10.ini" file, and it is
highly advisable to at least configure the KN10 devices this way,
highly advisable to at least configure the KN10's devices this way,
using the information in "install.txt".
KLH10 BOOTSTRAPPING:
The KLH10 is capable of loading PDP-10 binary files directly
into its KN10 memory with the "load" command. The KLH10 uses the
native OS filesystem as its "front-end filesystem", and does not
require a special area on a virtual disk. Ordinarily you will use
this capability to load a PDP-10 bootstrap program, which when started
will then load either the TOPS-10 or TOPS-20 monitor. For example:
KLH10 is capable of loading PDP-10 binary files directly into
its KN10 memory with the "load" command; it uses the native OS
filesystem as its "front-end filesystem", and does not require a
special area on a virtual disk. Ordinarily you will use this
capability to load a PDP-10 bootstrap program, which when started will
then load either the TOPS-10 or TOPS-20 monitor. For example:
KLH10> load boot.exe
@@ -100,30 +103,47 @@ building a "front-end filesystem" area is not necessary. See the file
KLH10 COMMANDS vs KN10 EXECUTION:
It is very important to understand that the KLH10 is always
doing only one of two things. It is either reading and executing
commands typed to it, or it is running the KN10 which is executing
PDP-10 instructions. There is no way to enter KLH10 commands without
temporarily suspending KN10 execution.
Previous KLH10 versions had no way to enter KLH10 commands
without suspending KN10 execution. This is no longer the case, and
there are now 3 principal modes of console input:
While the KLH10 is reading commands, nothing else is
happening, and your typein is seen only by the KLH10 command parser.
The KN10 does not run until you give an explicit command to start or
resume execution.
[1] Simple command mode, prompt "KLH10>" (or "KLH10#" during init).
The KN10 is halted.
CTY input goes to the KLH10 command parser.
CTY output is halted as the KN10 is halted.
While the KN10 is running, your typein is seen only by the
[2] Concurrent command mode, prompt "KLH10>>".
The KN10 is running.
CTY input goes to the KLH10 command parser.
CTY output is accepted from the KN10.
[3] CTY I/O mode, no prompt.
The KN10 is running.
CTY input/output goes to/from the KN10.
The latter two modes are similar to the way a real KL system works,
with its front-end PDP-11 independent of the KL10 CPU.
In "simple" mode, the KLH10 is always doing only one of two things.
It is either reading and executing KLH10 commands typed to it, or it
is running the KN10 which is executing PDP-10 instructions. While the
KLH10 parser is reading commands, nothing else is happening, and your
typein is seen only by the parser. The KN10 does not run until you
give an explicit command to start or resume execution.
In "CTY" mode, the KN10 is running and your typein is seen only by the
PDP-10, as CTY input. You can return to the KLH10 command parser at
any time by typing the command escape character (^\, CONTROL-\, ASCII
"FS", octal 034), which suspends KN10 execution. Control also returns
to the command parser if the KN10 halts for any reason.
"FS", octal 034). This normally suspends KN10 execution and enters
"simple" mode, but if the fe_runenable variable is "on" then it will
enter "concurrent" mode.
Control also returns to the command parser if the KN10 halts for any
reason.
Future versions of the KLH10 may allow concurrent execution so
that KLH10 commands can be given while the KN10 continues to run,
similar to the way a real KL system works with its front-end PDP-11
independent of the KL10 CPU. For now, simplicity is stability.
STOPPING THE KLH10:
STOPPING THE KN10:
Normally, you will be running a PDP-10 monitor. Bring it down
as you would for a real KL10, except that at the point where you type
@@ -214,6 +234,8 @@ background:
(3) Terminate the emulator by sending a SIGTERM signal, e.g.
% kill <pid>
This will attempt to perform a graceful shutdown of the OS by
internally executing the SHUTDOWN command.
Check the log file to make sure that everything went OK. This file
simply records all output to the emulated CTY. If you wish to observe
@@ -222,7 +244,7 @@ it while the emulator is running, do "tail -f logfile".
Again, UNIX unfortunately provides no mechanism for re-attaching a
terminal to a background process, so there is currently no way to provide
input to the emulated CTY in this situation. Eventually this feature
will be provided by a front-end daemon that can be connected to at will.
may be provided by a front-end daemon that can be connected to at will.
USING VIRTUAL TAPES: