mirror of
https://github.com/open-simh/simh.git
synced 2026-01-13 07:20:12 +00:00
2013 lines
94 KiB
Plaintext
2013 lines
94 KiB
Plaintext
SIMH/HP 2100 RELEASE NOTES
|
|
================================
|
|
J. David Bryan <jdbryan@acm.org>
|
|
Last update: 2020-11-07
|
|
|
|
|
|
This file documents the release history of the simulator for the Hewlett-Packard
|
|
2114, 2115, 2116, 2100, 1000-M, 1000-E, and 1000-F machines.
|
|
|
|
The home page for the HP simulators is:
|
|
|
|
http://simh.trailing-edge.com/hp/
|
|
|
|
An HP 2100 "release" is made when one or more major changes have been
|
|
incorporated. Each release is documented below and describes the changes (new
|
|
features and corrected errors) that have occurred since the prior release. A
|
|
revised "HP 2100 Simulator User's Guide" accompanies every release where
|
|
user-visible changes were made.
|
|
|
|
A "release update" is made to fix minor errors that do not affect normal user
|
|
operation. Examples of updates might be expansion or correction of source file
|
|
comments, minor algorithm improvements, or rewording of error messages. Updates
|
|
are not documented here, although every change is reported in the change logs
|
|
that appear at the beginning of all HP 2100 source files.
|
|
|
|
The HP simulators were previously associated with the "SIMH 4.0" project here:
|
|
|
|
https://github.com/simh/simh
|
|
|
|
...but are no longer. Any simulator reporting itself as "V4.x" is not
|
|
authorized and not supported by your HP maintainer. Regression testing with the
|
|
original HP diagnostics suites is performed only on the simulators available
|
|
from the trailing-edge site. See the notes below for more information on this
|
|
transition.
|
|
|
|
|
|
|
|
===============================
|
|
Reporting Bugs in the Simulator
|
|
===============================
|
|
|
|
If you find a bug in the HP 2100 simulator, please report it directly to your HP
|
|
maintainer at the address shown at the top of these notes. Please attach a
|
|
console log that shows the simulator version and contains a reproducible test
|
|
case that illustrates the problem. See the SET CONSOLE LOG command in the
|
|
"Console Options" section of the "SIMH Users' Guide" for details on how to
|
|
enable logging and the SHOW VERSION command in the "Displaying Parameters and
|
|
Status" section.
|
|
|
|
|
|
|
|
=============================
|
|
The 4.x to 3.x SCP Transition
|
|
=============================
|
|
|
|
Internally, a SIMH simulator consists of a "front end," designated the Simulator
|
|
Control Program (SCP), and a "back end" that provides the machine-specific
|
|
personality. SCP provides the simulator prompt, console commands such as ATTACH
|
|
and RUN, and common library modules for magnetic tape, terminal, and other
|
|
device support. SCP manages command file execution, cooperates with the back
|
|
end to configure the CPU and I/O devices, and relinquishes control to the back
|
|
end to execute machine instructions when a RUN, GO, or CONTINUE command is
|
|
entered.
|
|
|
|
The SIMH project was created and led by Bob Supnik through SCP version 3.9.
|
|
Mark Pizzolato then assumed stewardship and substantially extended SCP for
|
|
version 4.0. Recently, Bob has produced SCP version 3.10, which adopts some,
|
|
but not all, of the new features provided with version 4.0. It also has a
|
|
markedly simpler internal structure compared to 4.0.
|
|
|
|
The HP 2100 simulator had been migrated from SCP 3.9 to 4.0, but the rapid
|
|
development cycle and greatly increased complexity introduced a number of errors
|
|
and incompatibilities that made it very difficult to ensure stable HP simulator
|
|
operation. Regression testing became problematic; often the SCP would change
|
|
between simulator testing and code release. This has led to an untenable
|
|
support situation.
|
|
|
|
Therefore, starting with Release 29, the simulator has been retargeted to SCP
|
|
3.10 and its successors, which will be used for all future releases. This does
|
|
not affect machine execution, i.e., once a RUN or GO command is given, but it
|
|
does have consequences for user-written command files, as SCP 3.10 does not
|
|
implement all of the new-for-4.0 commands.
|
|
|
|
The HP simulators provide a superset of the SCP 3.10 commands. These are
|
|
documented in the "SIMH Users' Guide Supplement" that is provided in PDF format
|
|
in the "doc" subdirectory of the distribution archive. Those with existing
|
|
user-written command files should consult this document for the ramifications of
|
|
the SCP transition.
|
|
|
|
|
|
|
|
===================
|
|
General Information
|
|
===================
|
|
|
|
The simulator passes the HP 24396 offline diagnostic suite with some expected
|
|
failures due to unimplemented features. For example, the disc diagnostic
|
|
error-correction logic tests and the tape diagnostic CRCC and LRCC tests fail,
|
|
as these features are not supported. However, all features that are required
|
|
for operation of the supported HP operating systems pass their respective
|
|
diagnostic tests. See the accompanying "hp2100_diag.txt" file for details.
|
|
|
|
The simulator has been tested with the following operating systems:
|
|
|
|
- SIO, BCS, and MTS.
|
|
|
|
- 2000E, 2000F, and 2000 Access Time-Shared BASIC.
|
|
|
|
- DOS, DOS-M, and DOS-III.
|
|
|
|
- RTE, RTE-B, RTE-C, RTE-II, RTE-III, RTE-IV, RTE-IVB, and RTE-6/VM.
|
|
|
|
The user's manual for the simulator is provided in PDF format in the "doc"
|
|
subdirectory of the distribution archive.
|
|
|
|
For those intending to run 2000F or 2000/Access Time-Shared BASIC, a monograph
|
|
entitled "Running HP 2000 Time-Shared BASIC on SIMH" is available from the
|
|
"Documentation" section of the simulator site listed above. It discusses the
|
|
requirements for successful TSB startup and operation and the issues involved in
|
|
synchronizing the dual-CPU simulation setup required by TSB. TSB has run
|
|
successfully on SIMH for many years, but the advent of multi-core host machines
|
|
has increased the difficulty in getting the two SIMH instances to coordinate
|
|
properly. The paper presents some configuration guidelines that improve the
|
|
probability of successfully running TSB.
|
|
|
|
Another paper available from the simulator site is entitled "The Evolution of
|
|
the HP 21xx/1000 I/O Simulation" and describes the several I/O simulation
|
|
designs that have been employed in the simulator as it has evolved to
|
|
accommodate the widening range of I/O device interfaces. It also describes in
|
|
detail the current design and its tradeoffs, and serves as a tutorial for those
|
|
intending to write their own HP interface simulations.
|
|
|
|
|
|
-----------------------
|
|
Compiling the Simulator
|
|
-----------------------
|
|
|
|
Compilation instructions are documented in Section 1 of the "SIMH Users' Guide
|
|
Supplement" that is provided in PDF format in the "doc" subdirectory of the
|
|
distribution archive.
|
|
|
|
|
|
------------------
|
|
Available Software
|
|
------------------
|
|
|
|
Ready-to-run software kits for several of the HP 21xx/1000 operating systems are
|
|
available from the "Software Kits" section of the simulator site listed above.
|
|
Each kit contains a bootable disc or tape image and associated command files
|
|
that automate the system startup process. Command files to perform new system
|
|
generations are also included. Refer to the site for details.
|
|
|
|
The Computer History Museum has graciously arranged with HP to offer the HP 1000
|
|
Software Collection with a sublicense for non-commercial use by private
|
|
individuals. The Collection is hosted by Bitsavers at:
|
|
|
|
http://www.bitsavers.org/bits/HP/HP_1000_software_collection/
|
|
|
|
QCTerm, a free HP 700 terminal emulator for Microsoft Windows, is available from
|
|
the HP Computer Museum at:
|
|
|
|
http://www.hpmuseum.net/display_item.php?sw=585
|
|
|
|
Use of an HP terminal via a serial port or an HP terminal emulator via Telnet
|
|
enables more advanced screen editing features of the RTE operating systems.
|
|
Generic Telnet clients generally will work, albeit with reduced functionality.
|
|
|
|
Manuals describing the operation of HP software are available from Bitsavers at:
|
|
|
|
http://www.bitsavers.org/pdf/hp/1000/
|
|
http://www.bitsavers.org/pdf/hp/2000TSB/
|
|
http://www.bitsavers.org/pdf/hp/21xx/
|
|
|
|
...and from the HP Computer Museum at:
|
|
|
|
http://www.hpmuseum.net/collection_document.php#CS
|
|
|
|
|
|
----------------
|
|
Year 2000 Issues
|
|
----------------
|
|
|
|
RTE-6/VM Revision 6200 is Y2K compliant, except for the READR and SAVER
|
|
programs. The errors are cosmetic only.
|
|
|
|
RTE-IVB Revision 5010 is not Y2K compliant. All of the failures are in
|
|
subsystems; the operating itself (time-of-day clock) accommodates dates through
|
|
2059. All of the errors are cosmetic. Typically, punctuation characters appear
|
|
in the years, e.g., "19:0" for 2000.
|
|
|
|
All other HP operating systems are not Y2K compliant. For these, the system
|
|
time should be set to a corresponding year in the 20th century. Refer to the
|
|
"Variable Substitution" section of the "SIMH Users' Guide Supplement" for
|
|
details on using the %DATE_RRRR% and %DATE_RR% substitution variables on
|
|
non-Y2K-compliant systems.
|
|
|
|
|
|
-----------------------------
|
|
Bugs in RTE-IVB Revision 5010
|
|
-----------------------------
|
|
|
|
Testing during simulator development revealed the presence of a bug in RTE-IVB
|
|
Revision 5010:
|
|
|
|
- The $BALC module in the system library has a bug that causes memory
|
|
corruption. This module is used by the ACCTS program and manifests itself by
|
|
printing gibberish after the "PLEASE LOG ON:" prompt.
|
|
|
|
Specifically, the internal MXEV routine performs a cross-store indirect via a
|
|
location in Table Area II (XSA $MAXI+0,I). This fails because the indirect
|
|
chain is resolved in the user map, but TA II is not present in the user map
|
|
of large-background programs, such as ACCTS. Therefore, the location in the
|
|
user map corresponding to $MAXI in the system map is used as the pointer to
|
|
the location to store.
|
|
|
|
A workaround is to load the ACCTS program as a regular background program
|
|
instead of as a large background program. Regular background programs
|
|
include Table Area II in the user map. Note that ACCTS requires SSGA access,
|
|
so use "OP,BGSS" for online loading or specify "ACCTS,19,90" in the Parameter
|
|
Input Phase of a system generation.
|
|
|
|
|
|
|
|
======================
|
|
Release 30, 2020-11-07
|
|
======================
|
|
|
|
This release of the HP 2100 simulator adds the following features:
|
|
|
|
- A new concurrent-mode FLUSH command has been added to flush terminal logs and
|
|
attached device files that otherwise would be flushed only when the simulator
|
|
is stopped. This allows external examination of these files while the
|
|
simulator continues to run.
|
|
|
|
- Terminal multiplexer line logs are now flushed each time the simulator stops.
|
|
Prior to this, closing and then reopening a line log was the only way to post
|
|
buffered writes to disc.
|
|
|
|
- The -N (new file) option has been added to the SET BACI LOG, SET MPX LOG, and
|
|
SET MUXL LOG commands to create new, blank log files. Without the option,
|
|
the commands will append to existing log files.
|
|
|
|
- The HP 12972C 8-channel terminal multiplexer (MPX) and 12920A 16-channel
|
|
terminal multiplexer (MUX) now allow channels to be omitted from the
|
|
connection order. For example, a SET MPX LINEORDER=0-3 command permits
|
|
connections to channels 0 through 3. Additional Telnet connection attempts
|
|
will be rejected with an "All connections busy" message, and attempting to
|
|
attach a serial port to a line not in the connection order will be rejected
|
|
with a "Unit not attachable" message.
|
|
|
|
- A new INTERLOCK option has been added to the IPL device. This provides a
|
|
more precise way of synchronizing the two simulator processes running the HP
|
|
2000 Time-Shared BASIC operating system. Entering a SET IPL INTERLOCK=<n>
|
|
command restricts each process to executing <n> machine instructions before
|
|
performing a rendezvous with the other process. In this way, both processes
|
|
remain in approximate lock-step, which substantially improves system startup
|
|
reliability, even when one process is preempted during initialization by the
|
|
host operating system. An associated SHOW IPL INTERLOCK command displays the
|
|
current interlock value.
|
|
|
|
- The IPL device now works on FreeBSD and Cygwin host platforms, as well as the
|
|
Windows and Linux platforms that were previously supported.
|
|
|
|
- A new -E switch has been added to the ATTACH IPL command. This enables
|
|
falling back to timed waits if the host platform does not support the
|
|
synchronization routines necessary for the SET IPL WAIT and SET IPL SIGNAL
|
|
commands.
|
|
|
|
- The CMD trace option for the IPL device now decodes and reports all TSB
|
|
commands that pass between the System Processor and the I/O Processor.
|
|
|
|
- The PSERV and STATE trace options have been added to the IPLO device.
|
|
Enabling the PSERV option traces the periodic calls to the new process
|
|
synchronizer. Enabling the STATE option traces calls to the host platform
|
|
event routines, as well as internal synchronizer states during rendezvous.
|
|
|
|
|
|
--------------------
|
|
Implementation Notes
|
|
--------------------
|
|
|
|
- The terminal multiplexer LINEORDER option now omits unspecified lines from
|
|
the connection order. Prior versions appended unspecified lines to the end
|
|
of the specified order. To obtain the prior behavior, append the keyword ALL
|
|
as the last parameter to the connection order list.
|
|
|
|
- New releases of the HP 2000F and 2000 Access software kits use the SET IPL
|
|
INTERLOCK command instead of the prior SET IPL WAIT/SIGNAL commands to
|
|
synchronize the two simulator instances and provide more reliable system
|
|
startup under a wider variety of host system conditions.
|
|
|
|
- The 2000 Access software kit now includes a command file to run the
|
|
program that converts files between Access and 2000 C/F systems.
|
|
|
|
- The "Running HP 2000 Time-Shared BASIC on SIMH" monograph has been
|
|
extensively revised to cover the application of the new SET IPL INTERLOCK
|
|
command to the TSB startup command files.
|
|
|
|
- The previous method of sleeping for a few milliseconds during 2000 Access
|
|
startup to avoid IOP initialization errors is no longer required when the
|
|
new IPL interlock is used. The capability has been retained, however, and
|
|
will be used if the host platform does not support synchronization events.
|
|
|
|
- The size of the shared memory area that simulates the processor
|
|
interconnection cables of the IPL device has been changed. On Linux and
|
|
macOS systems, this area is implemented by a file named "HP 2100-MEM-<code>",
|
|
where <code> is he code number supplied to the ATTACH IPL command. The file
|
|
is located in the "/dev/shm" directory. If the file is present, it must be
|
|
removed before running the simulator, or a "File open error" will result when
|
|
an ATTACH IPL is attempted. The new release of the simulator removes the
|
|
file automatically when a DETACH IPL is performed, so manual removal must be
|
|
done only once.
|
|
|
|
|
|
----------
|
|
Bugs Fixed
|
|
----------
|
|
|
|
1. PROBLEM: Breakpoint actions after an included true IF are discarded.
|
|
|
|
VERSION: Release 29.
|
|
|
|
OBSERVATION: If a breakpoint has actions that include an IF command
|
|
followed by additional actions, and the IF command evaluates to TRUE, then
|
|
the IF actions executed, but the remaining breakpoint actions are
|
|
discarded. For example:
|
|
|
|
sim> set environment X=0
|
|
sim> break 10 ; if "%X%" == "0" echo X is 0 ; echo Done
|
|
sim> go
|
|
|
|
One would expect to see:
|
|
|
|
Breakpoint, P: 00010 (NOP)
|
|
sim> if "0" == "0" echo X is 0
|
|
sim> echo X is 0
|
|
X is 0
|
|
sim> echo Done
|
|
Done
|
|
sim>
|
|
|
|
Instead, only the first ECHO is performed. The second one is discarded.
|
|
However, execution is correct if the IF condition is false:
|
|
|
|
sim> set environment X=1
|
|
sim> break 10 ; if "%X%" == "0" echo X is 0 ; echo Done
|
|
sim> go
|
|
|
|
Breakpoint, P: 00010 (NOP)
|
|
sim> if "1" == "0" echo X is 0
|
|
sim> echo Done
|
|
Done
|
|
sim>
|
|
|
|
CAUSE: IF actions are executed by setting the breakpoint action pointer to
|
|
the action list and returning to the command loop. While the IF command is
|
|
executing, the pointer is pointing at the "echo Done" part of the
|
|
breakpoint action list. However, if the IF condition is true, the pointer
|
|
is changed to point at the "echo X is 0" command, and the remaining
|
|
breakpoint actions are lost.
|
|
|
|
RESOLUTION: Modify "if_cmd" (sim_extension.c) to append the remaining
|
|
breakpoint actions to the actions specified by the IF command, so that the
|
|
former are not lost.
|
|
|
|
STATUS: Fixed in Release 30.
|
|
|
|
|
|
2. PROBLEM: Linking with recent compilers results in duplicate symbol errors.
|
|
|
|
VERSION: Releases 29.
|
|
|
|
OBSERVATION: If the simulator is compiled with a recent compiler version,
|
|
the link step fails with duplicate symbol errors. The symbols reported are
|
|
"sim_vm_release", "vm_sim_vm_init", "vm_console_input_unit", and
|
|
"vm_console_output_unit".
|
|
|
|
CAUSE: The VM hook extension mechanism is implemented with "tentative
|
|
definitions" of the hook variables. The C standard says:
|
|
|
|
"If a translation unit contains one or more tentative definitions for an
|
|
identifier, and the translation unit contains no external definition for
|
|
that identifier, then the behavior is exactly as if the translation unit
|
|
contains a file scope declaration of that identifier, with the composite
|
|
type as of the end of the translation unit, with an initializer equal to
|
|
0."
|
|
|
|
This behavior is such that if no module contains a definition with an
|
|
initializer, the hook will have a zero value. However, if a module
|
|
contains a definition with an initializer, the hook is assigned that value.
|
|
This allows hooks to be set without changing the hook's tentative
|
|
definition simply by including a VM module that declares it with an
|
|
initializer.
|
|
|
|
This mechanism relies on the linker to resolve the multiple definitions of
|
|
a given hook to a single reference. For this to occur, the compiler must
|
|
mark tentative definitions as "common" allocations, e.g., with the
|
|
"-fcommon" option to gcc. Traditionally, gcc (and clang, etc.) defaults to
|
|
common allocations for tentative definitions. However, the gcc manual
|
|
claims that, "This behavior is not required by ISO C, and on some targets
|
|
may carry a speed or code size penalty on variable references."
|
|
|
|
Newer versions (starting with gcc 10) default to data allocations instead
|
|
("-fno-common"), and multiple tentative definitions now result in duplicate
|
|
symbol errors rather than merged accesses.
|
|
|
|
RESOLUTION: Modify sim_extension.h to declare "vm_sim_vm_init" only if the
|
|
USE_VM_INIT symbol is defined. Modify "ex_initialize" (sim_extension.c) to
|
|
remove the tentative definition and to make the external "vm_sim_vm_init"
|
|
call conditional on USE_VM_INIT. Modify "one_time_init" (hp2100_sys.c) to
|
|
set the "sim_vm_release" hook directly. Modify "tty_reset" (hp2100_tty.c)
|
|
to set the console unit hooks directly. This removes all tentative
|
|
definitions from the simulators.
|
|
|
|
STATUS: Fixed in Releases 30.
|
|
|
|
|
|
3. PROBLEM: Trace output to stdout on Unix results in stair-step output.
|
|
|
|
VERSION: Release 29.
|
|
|
|
OBSERVATION: Directing the trace output to "stdout" on a Unix system
|
|
results in lines stair-stepping across the screen. For example:
|
|
|
|
sim> set console debug=stdout
|
|
sim> set cpu debug=instr
|
|
sim> step 2
|
|
|
|
...produces this output:
|
|
|
|
>>CPU instr: - 0000 00000 000000 NOP
|
|
>>CPU instr: - 0000 00001 000000 NOP
|
|
|
|
CAUSE: Trace statements are output with LF ('\n') line ends and depend on
|
|
host-system translation to the proper line-end convention when the lines
|
|
are written to the trace log. However, while the simulator is executing
|
|
instructions, the console is placed in "raw" mode so that output
|
|
translation, which would interfere with the output from the target
|
|
operating system, is not done. As there are no carriage returns in the
|
|
trace output stream when writing to stdout, the console cursor simply drops
|
|
in place to the next line, so that each line begins at the same column
|
|
where the previous line ended.
|
|
|
|
RESOLUTION: Modify "hp_trace" (hp2100_sys.c) to convert a terminating LF
|
|
to a CR LF sequence if output is to stdout. Also modify "sim_instr"
|
|
(hp2100_cpu.c) to add CR characters to the stdout stream where line
|
|
termination is done explicitly.
|
|
|
|
STATUS: Fixed in Release 30.
|
|
|
|
|
|
4. PROBLEM: The trace line for an I/O error simulation stop is incomplete.
|
|
|
|
VERSION: Release 29.
|
|
|
|
OBSERVATION: With simulation stops on I/O errors enabled, a CPU trace
|
|
correctly records the stop, but the stop description is incomplete. For
|
|
example:
|
|
|
|
sim> set ipl enabled
|
|
sim> attach -s ipl 1
|
|
sim> set cpu stop=ioerr
|
|
sim> set cpu debug=instr
|
|
sim> set console debug=stdout
|
|
sim> go
|
|
|
|
...produces trace output that ends with:
|
|
|
|
>>CPU instr: - 0000 00061 000000 simulation stop: Cable not connected to
|
|
|
|
...while the simulation console reports the full message, "Cable not
|
|
connected to the IPLI device."
|
|
|
|
CAUSE: The trace statement printer for the stop calls "sim_error_text" to
|
|
obtain the description of the stop status, but that routine does not handle
|
|
VM-specific additions. Upon returning to SCP, the "run_cmd" routine prints
|
|
the "sim_error_text" but then calls a VM-specified "sim_vm_fprint_stopped"
|
|
routine to handle additions to VM stops.
|
|
|
|
RESOLUTION: Modify "sim_instr" (hp2100_cpu.c) to call the VM-specific
|
|
simulation stop handler via the "sim_vm_fprint_stopped" hook if an I/O
|
|
error stop occurred.
|
|
|
|
STATUS: Fixed in Release 30.
|
|
|
|
|
|
5. PROBLEM: ATTACH/DETACH MUXL <network-port> succeeds but should not.
|
|
|
|
VERSION: Release 29.
|
|
|
|
OBSERVATION: The HP 12920A multiplexer simulator defines two devices: the
|
|
MUX device that contains the polling unit, and the MUXL device that
|
|
contains the terminal line units. The poll unit is attached with the:
|
|
|
|
ATTACH MUX <network-port>
|
|
|
|
...command. Line units are attached to serial ports with the:
|
|
|
|
ATTACH MUXL <serial-port>
|
|
|
|
...command. These behave as expected. However, the:
|
|
|
|
ATTACH MUXL <network-port>
|
|
|
|
...command succeeds but attaches the port to the MUX device. This is
|
|
incorrect and should be prohibited.
|
|
|
|
CAUSE: The "muxl_attach" routine passes a poll unit pointer to the
|
|
"tmxr_attach_unit" routine. The latter routine attaches the poll unit
|
|
instead of the passed line unit when a device is referenced. However, the
|
|
poll unit belongs to a different device, and so the mux line routine
|
|
attaches the port to the mux poll device.
|
|
|
|
RESOLUTION: Modify "muxl_attach" and "muxl_detach" (hp2100_mux.c) to pass
|
|
NULL for the poll unit in the "tmxr_attach_unit" calls. Modify the
|
|
"ex_tmxr_attach_unit" and "ex_tmxr_detach_unit" routines (sim_extension.c)
|
|
to reject the call if a device was referenced and a NULL poll unit pointer
|
|
was passed.
|
|
|
|
STATUS: Fixed in Release 30.
|
|
|
|
|
|
|
|
======================
|
|
Release 29, 2020-02-15
|
|
======================
|
|
|
|
This release of the HP 2100 simulator adds the following features:
|
|
|
|
- A new CONCURRENT option has been added to the SET CONSOLE command. Entering
|
|
CTRL+E with concurrent mode enabled allows the simulator to continue to run
|
|
while presenting an "scp>" prompt for command entry. This permits SCP
|
|
commands, such as an ATTACH of a magnetic tape image, to be performed without
|
|
causing the simulated system clock to lose time and without disturbing
|
|
command file execution.
|
|
|
|
Concurrent mode is enabled by default. If the prior mode where CTRL+E stops
|
|
the simulator is desired, a SET CONSOLE NOCONCURRENT command may be placed in
|
|
the "simh.ini" global initialization file that is read automatically at
|
|
startup. See the "SIMH Users' Guide Supplement" for details.
|
|
|
|
- The 12731A Memory Expansion Module has been separated from the CPU simulator
|
|
and assigned to its own device ("MEM"). The MEM registers are now displayed
|
|
and altered with the EXAMINE MEM <reg> and DEPOSIT MEM <reg> commands and
|
|
have been renamed, with the map registers separated into the four functional
|
|
sets. Enabling and disabling the device is performed indirectly by the SET
|
|
CPU DMS and SET CPU NODMS firmware-installation commands, rather than by the
|
|
typical SET MEM ENABLED/DISABLED commands. The CPU feature table in Section
|
|
3.1 of the HP2100 User's Guide has been corrected to show that the MEM is an
|
|
option for the 1000 M/E/F-Series machines, and 1000 systems without memory
|
|
expansion may be simulated by disabling the DMS instruction set.
|
|
|
|
- Two instances of the 12566B Microcircuit Interface have been added; the
|
|
device designations are MC1 and MC2. These devices simulate only the
|
|
interface cards and do not have attached peripherals. They are intended as
|
|
interrupt and data loopback targets for several HP diagnostic programs and,
|
|
as such, are disabled by default.
|
|
|
|
- An internal "Keyboard Poll" unit has been added to coordinate keyboard input
|
|
polling. This unit will be visible in the SHOW QUEUE display.
|
|
|
|
- The TTY device may now be disabled, as its input poll coordination
|
|
responsibilities have been transferred to the internal keyboard poll unit.
|
|
This permits correct I/O configuration for systems that do not use a keyboard
|
|
device (e.g., the I/O Processor in an HP 2000 Time-Shared BASIC system) or
|
|
for RTE systems that use the BACI as the system console device. Previously,
|
|
the TTY device would have remained enabled but been assigned a high select
|
|
code "out of the way" of the correctly configured set of I/O devices.
|
|
|
|
- A new SHOW CPU IOCAGE command has been added to display the set of I/O device
|
|
interfaces currently installed in the CPU card cage. The devices appear in
|
|
select code order, beginning with select code 10 and ending with the last
|
|
occupied select code. This makes checking select code assignments and
|
|
identifying conflicts much easier than using the SHOW DEVICES command.
|
|
|
|
- The SHOW CPU ROMS command has been extended to add descriptions of the
|
|
bootstrap loader ROMs installed in HP 1000 CPUs.
|
|
|
|
- The list of the simulated devices displayed by the SHOW DEVICES command has
|
|
been rearranged to this order: CPU, CPU devices, and I/O devices
|
|
alphabetically. The prior order was essentially random, making it difficult
|
|
to locate specific devices.
|
|
|
|
- New SET <dev> REALTIME and SET <dev> FASTTIME commands have been added to the
|
|
TTY, PTR, and PTP devices. The optimized timing values used may be altered
|
|
via the corresponding register interfaces.
|
|
|
|
- The SET PTR DIAGNOSTIC command has been enhanced to provide a second
|
|
diagnostic mode. If a paper tape image file is not attached, then the new
|
|
mode simulates the installation of a loopback connector in place of the
|
|
reader cable, permitting the General Purpose Register Diagnostic to test the
|
|
interface. If a file is attached, then the existing mode converts the
|
|
attached paper tape image into a continuous loop by logically joining the
|
|
ends of the tape, which is needed by the High-Speed Tape Reader/Punch
|
|
Diagnostic.
|
|
|
|
- The new SET PTR REWIND command repositions the attached tape image to the
|
|
beginning, so that the tape may be re-read. This is helpful, for instance,
|
|
when re-running and specifying different output options to a program that
|
|
takes its input from the paper tape reader.
|
|
|
|
- The new SET PTP DIAGNOSTIC command installs a loopback connector in place of
|
|
the paper tape punch cable to run the General Purpose Register Diagnostic on
|
|
the interface. The new SET PTP PUNCH command reinstalls the punch cable and
|
|
restores normal punch operation.
|
|
|
|
- Configurable debug tracing has been added to the TTY, PTR, and PTP devices.
|
|
|
|
- All I/O devices that had not supported debug tracing previously now provide
|
|
an IOBUS option to trace data and signals sent and received across the I/O
|
|
backplane bus. All peripheral devices now support at least minimal tracing.
|
|
|
|
|
|
--------------------
|
|
Implementation Notes
|
|
--------------------
|
|
|
|
- The change from SCP 4.0 to 3.x may affect user-written command files. Be
|
|
sure to review Section 3, "SCP 4.x-to-3.x Conversion," of the "SIMH Users'
|
|
Guide Supplement."
|
|
|
|
- The DO command now executes more quietly by default. Specifically, the
|
|
"Breakpoint" and "Step expired" messages that normally result from BREAK, GO
|
|
UNTIL, and STEP command completions are suppressed, as are the informational
|
|
messages from ATTACH and DETACH, such as "Creating new file." This provides
|
|
a cleaner console display log when automated prompts and responses are used.
|
|
Adding the -A switch to the DO invocation will restore the previous noisier
|
|
behavior. See the "DO Command" section of the Supplement for details.
|
|
|
|
- The SHOW CPU ROMS command is now rejected if the CPU is not a 1000.
|
|
|
|
- The ION and ION_DEFER CPU registers have been renamed to INTSYS and INTEN,
|
|
respectively, to match the names used in the HP engineering documentation.
|
|
Note that the sense of INTEN is now reversed: a value of 0 indicates that
|
|
interrupts are not enabled (i.e., are deferred), while 1 indicates that
|
|
interrupts are enabled (not deferred).
|
|
|
|
- The TTY KTIME register has been removed. This register was intended to allow
|
|
the user to set the keyboard polling interval, but it never worked; instead,
|
|
the keyboard poll rate was (and is) always fixed at 100 Hz.
|
|
|
|
- The TTY TTIME register had been described as the "Time from I/O initiation to
|
|
interrupt" but it actually sets the optimized (FASTTIME) time for Teletype
|
|
print/punch operations.
|
|
|
|
- The prior method of rewinding a paper tape by doing DEPOSIT PTR POS 0 does
|
|
not work if the console is in concurrent mode. Use the new SET PTR REWIND
|
|
command instead.
|
|
|
|
- The I/O system simulation has been rewritten to model the actual hardware
|
|
more closely. This has no user-visible impact, except that IOBUS tracing now
|
|
accurately reflects the hardware I/O bus signals. For example, the PRH and
|
|
PRL signals now appear in IOBUS traces and show the I/O priority settings.
|
|
Any user-written device interfaces will have to be changed to use the new I/O
|
|
structure; the Microcircuit Interface in hp2100_mc.c is a simple example that
|
|
may be used as a model for the changes needed.
|
|
|
|
- The hp2100_stddev.c source file has been split into hp2100_pt.c (PTR and
|
|
PTP), hp2100_tty.c (TTY) and hp2100_tbg.c (TBG).
|
|
|
|
- hp2100_cpu.c has been split into hp2100_cpu.c (CPU and I/O), hp2100_mem.c
|
|
(main memory, MP, and MEM), and hp2100_dma.c (DMA1 and DMA2). A new
|
|
hp2100_cpu_dmm.h file contains the interface declarations for these three
|
|
modules.
|
|
|
|
- hp2100_fp.c and hp2100_fp1.c have been renamed to hp2100_cpu_fp.c and
|
|
hp2100_cpu_fpp.c, respectively, and hp2100_fp.h and hp2100_fp1.h have been
|
|
combined into hp2100_cpu_fp.h.
|
|
|
|
- hp2100_cpu1.h has been retired; its declarations have been moved into
|
|
hp2100_cpu.h.
|
|
|
|
|
|
----------
|
|
Bugs Fixed
|
|
----------
|
|
|
|
1. PROBLEM: The multiplexer upper data card status trace is incorrect.
|
|
|
|
VERSION: Release 28.
|
|
|
|
OBSERVATION: Tracing status on the upper data card of the 12920A
|
|
Asynchronous Multiplexer Interface with the SET MUX DEBUG=CSRW command
|
|
produces incorrect results. For example:
|
|
|
|
>>MUX csrw: Status is channel 17 | seeking | breaklost | receive
|
|
>>MUX iobus: Returned data 042012 with signals (none)
|
|
|
|
Given the status word 042012 octal, the correct status interpretation is
|
|
"channel 17 | diagnose | lost | receive".
|
|
|
|
CAUSE: A comma is missing after the "break" string constant in the
|
|
"upper_status_names" array initializer. This causes the "break" and "lost"
|
|
strings to be concatenated and used for bit 1. As a result, the "diagnose"
|
|
and "seeking" strings are used for bits 2 and 14 instead of 3 and 15.
|
|
|
|
RESOLUTION: Modify the "upper_status_names" initializer (hp2100_mux.c) to
|
|
use the correct set of status names.
|
|
|
|
STATUS: Fixed in Release 29.
|
|
|
|
|
|
2. PROBLEM: Tracing the $MPV instruction prints the wrong mnemonic.
|
|
|
|
VERSION: Release 28.
|
|
|
|
OBSERVATION: Tracing memory protect interrupts on an RTE-6/VM system
|
|
displays the trap cell instruction mnemonic as "ostst" (the firmware test
|
|
instruction):
|
|
|
|
>>CPU instr: U 0170 26072 000005 interrupt
|
|
>>CPU fetch: S 0000 00005 105355 instruction fetch
|
|
>>CPU instr: S 0000 00005 105355 ostst
|
|
>>CPU opnd: * **** 26072 105355 entry is for a memory protect violation
|
|
|
|
...instead of the expected "$MPV" (memory protect violation instruction):
|
|
|
|
>>CPU instr: U 0170 26072 000005 interrupt
|
|
>>CPU fetch: S 0000 00005 105355 instruction fetch
|
|
>>CPU instr: S 0000 00005 105355 $MPV
|
|
>>CPU opnd: * **** 26072 105355 entry is for a memory protect violation
|
|
|
|
CAUSE: The RTE-6/VM OS firmware designates four instruction opcodes as
|
|
"dual-use." Opcodes 105354-105357 take different actions, depending on
|
|
whether or not they are executed from a trap cell during an interrupt. The
|
|
routine that formats these instructions for trace output determines the
|
|
mnemonic table to use by the address in which the instruction is stored.
|
|
|
|
The address value is also used to communicate to the "fprint_instruction"
|
|
routine whether or not the value array containing the instruction word(s)
|
|
has been loaded. For a CPU instruction trace, only the first word of the
|
|
array is loaded (as part of the instruction fetch), so the address value
|
|
has an upper bit set to indicate this condition. However, the trap cell
|
|
check is not masking this bit off, so instructions executing from trap
|
|
cells are treated as though they are executing from high memory.
|
|
|
|
RESOLUTION: Modify "fprint_cpu" (hp2100_sys.c) to mask the target address
|
|
before checking the location when printing "dual-use" instructions.
|
|
|
|
STATUS: Fixed in Release 29.
|
|
|
|
|
|
3. PROBLEM: DIAGNOSTIC mode of the 12653A Line Printer Interface is not
|
|
modeled correctly.
|
|
|
|
VERSION: Release 28.
|
|
|
|
OBSERVATION: The 12653A Line Printer Interface used with the HP 2767A line
|
|
printer (LPS device) is a modified 12566B Microcircuit Interface. Setting
|
|
the card for DIAGNOSTIC mode simulates the installation of an HP 1251-0332
|
|
diagnostic test (loopback) connector in place of the printer cable and the
|
|
alteration of the jumper configurations to match those required by the
|
|
diagnostics that target this interface.
|
|
|
|
When the Direct Memory Access Diagnostic for the 2115/2116 computer (DSN
|
|
101105) was first run, Test 17, which tests character unpacking during
|
|
output, failed. It was originally thought that the 12578A DMA card for the
|
|
2115 and 2116 had a one-cycle startup latency that did not exist in the
|
|
12607B, 12895A, and 12897B DMA cards for the 2114, 2100, and 1000-series
|
|
CPUs. This latency was added to the simulation in version 3.7-0, and the
|
|
diagnostic passed.
|
|
|
|
Sometime later, the schematic for the 12578A card was studied more closely,
|
|
revealing that the first DMA cycle occurred immediately upon activation
|
|
when SRQ (Service Request) was already asserted, as it was in the
|
|
diagnostic, so the latency counter was removed. In its place, the LPS
|
|
device was modified to change SRQ assertion timing for 211x CPUs.
|
|
|
|
With the loopback connector in place, asserting STC caused the flag to set
|
|
and SRQ to assert after a delay of one instruction. The 12578A diagnostic
|
|
required different jumper settings on the 12653A card than were used by the
|
|
other diagnostics, and it was assumed that this caused the card to assert
|
|
SRQ after a delay of two instructions. These changes were made in version
|
|
3.9-0.
|
|
|
|
A copy of the 12653A interface manual was obtained recently, and studying
|
|
the schematic revealed that the unusual jumper settings still resulted in
|
|
SRQ assertion after a one-instruction delay. Restoring the simulation to
|
|
the correct delay caused diagnostic test 17 to fail again.
|
|
|
|
CAUSE: Timing analysis of the response to DMA cycles on 2115 and 2116
|
|
machines shows that the jumper settings employed by the diagnostic suppress
|
|
setting of the Flag Buffer flip-flop, so no SRQ assertion occurs. The STC
|
|
and CLF signal assertions that start an I/O operation are coincident and
|
|
one T-period in duration (200 ns) in all combinations of CPU models and
|
|
cycle types EXCEPT when asserted for a 211x DMA cycle, where they are two
|
|
T-periods in duration (400 ns) and CLF lags STC by one T-period. With the
|
|
DMA diagnostic strapping, the Flag Buffer flip-flop is set by the STC and
|
|
then cleared by the lagging CLF in the same DMA cycle. This inhibits SRQ,
|
|
so DMA pauses until the diagnostic can examine the DMA state and then issue
|
|
a programmed STC/CLF to assert SRQ. This permits test 17 to succeed.
|
|
|
|
RESOLUTION: Create a new 12566B Microcircuit Interface simulator
|
|
(hp2100_mc.c) to implement the three different strapping behaviors required
|
|
by the various DMA diagnostics. Simplify "lps_interface" (hp2100_lps.c) to
|
|
operate in the manner expected by the General Purpose Register Diagnostic
|
|
when the card is in DIAGNOSTIC mode.
|
|
|
|
STATUS: Fixed in Release 29.
|
|
|
|
|
|
4. PROBLEM: Simulation stops are reported improperly in CPU traces.
|
|
|
|
VERSION: Release 28.
|
|
|
|
OBSERVATION: A simulation stop that occurs while CPU tracing is enabled
|
|
reports the cause of the stop in the trace log. However, stop reasons
|
|
specific to the HP simulator are not reported properly. For example,
|
|
tracing a halt instruction reports "simulation stop: Error 5" instead of
|
|
"simulation stop: Programmed halt".
|
|
|
|
CAUSE: The "sim_error_text" routine called to obtain the error translation
|
|
does not return simulator-specific messages. Instead, the routine returns
|
|
the generic message, "Error <n>", where <n> is the value of the simulator-
|
|
specific stop code.
|
|
|
|
RESOLUTION: Modify the simulation stop trace at the end of the instruction
|
|
postlude in "sim_instr" (hp2100_cpu.c) to call "sim_error_text" for SCP
|
|
errors and to obtain HP-specific messages from the "sim_stop_messages"
|
|
array.
|
|
|
|
STATUS: Fixed in Release 29.
|
|
|
|
|
|
5. PROBLEM: RTE-IVB FMGR aborts with a DM error during :DL,2 output.
|
|
|
|
VERSION: Release 28.
|
|
|
|
OBSERVATION: Entering a DL,2 command at the system console begins listing
|
|
the cartridge but then aborts partway through with this error:
|
|
|
|
DM VIOL = 100377
|
|
DM INST = 126313
|
|
ABE 0 177777 0
|
|
XYO 47252 0 0
|
|
DM FMGR 34463
|
|
FMGR ABORTED
|
|
|
|
The system generation log shows that address 34463 is within the "CLOSE"
|
|
subroutine. The violating instruction is a JMP 34313,I that attempts to
|
|
return from the subroutine. However, the return address is 14054,I (i.e.,
|
|
an indirect pointer) that points to 2000,I that points to 77765,I that is
|
|
in unmapped memory. This generates a MEM read violation.
|
|
|
|
CAUSE: The subroutine does a JSB .ENTR at entry to obtain the parameters
|
|
and adjust the return address. As this system has the Fast FORTRAN
|
|
Processor firmware, the JSB .ENTR is replaced with the .ENTR microcode
|
|
instruction. A CPU trace shows that a TTY interrupt is generated after the
|
|
JSB 45,I that calls the subroutine. Because JSB,I disables interrupt
|
|
recognition, the TTY interrupt is deferred until the next instruction
|
|
executes. The .ENTR instruction checks for interrupts when resolving the
|
|
address of each supplied subroutine parameter. Consequently, the deferred
|
|
TTY interrupt is recognized when the first parameter is resolved, and the
|
|
.ENTR instruction exits with the P register set so that the instruction
|
|
will be reexecuted when the TTY interrupt handler exits.
|
|
|
|
However, the return address was updated before the interrupt was
|
|
recognized, so reexecution updates the return address a second time. This
|
|
results in an incorrect address, which causes the DM abort when the
|
|
subroutine attempts to return.
|
|
|
|
RESOLUTION: Modify the .ENTR handler in "cpu_ffp" (hp2100_cpu3.c) to
|
|
update the return address only if the instruction executes to completion.
|
|
|
|
STATUS: Fixed in Release 29.
|
|
|
|
|
|
6. PROBLEM: The MEM Violation Register is not freezing for a DM error.
|
|
|
|
VERSION: Release 28.
|
|
|
|
OBSERVATION: The value that RTE reports for the Memory Expansion Module's
|
|
Violation Register during a DM abort does not match the value of the VR
|
|
obtained by a CPU trace. For example, a trace may show:
|
|
|
|
>>CPU instr: U 0167 34464 000005 interrupt
|
|
>>CPU reg: - **** ***** ****** MPF 030000, MPV 034463, MES 163454, MEV 100377
|
|
|
|
...but then:
|
|
|
|
>>CPU instr: S 0023 47516 101731 RVA
|
|
>>CPU fetch: S 0023 47517 000040 instruction fetch
|
|
>>CPU reg: - **** 01454 000000 A 160377, B 034463, X 047252, Y 000000, E o I
|
|
|
|
The value returned by the RVA (Read Violation Register) instruction is not
|
|
the same as the MEV (MEM Violation) value reported by the trace.
|
|
Consequently, the value reported by RTE as "DM VIOL =" is wrong.
|
|
|
|
CAUSE: The VR is being changed when it is supposed to be frozen. The MEM
|
|
schematic shows that the VR clock is inhibited by -MEV until CTL5 goes low
|
|
and then high again. That is, a MEM violation inhibits the VR clock, which
|
|
is reenabled when the MP control flip-flop is set (i.e., when MP is
|
|
reenabled). With CTL5 low, VR should not update.
|
|
|
|
RESOLUTION: Modify "dm_violation" (hp2100_mem.c) to inhibit updating the
|
|
VR if "mp_mevff" is set or "mp_control" is clear.
|
|
|
|
STATUS: Fixed in Release 29.
|
|
|
|
|
|
7. PROBLEM: DETACH -F LPT will not detach if the print buffer is not empty.
|
|
|
|
VERSION: Release 27.
|
|
|
|
OBSERVATION: The 2607/13/17/18 line printers do not allow the operator to
|
|
take the printer offline if unprinted characters remain in the print
|
|
buffer. Instead, the request is deferred until printing completes.
|
|
|
|
The LPT simulator follows this hardware behavior when processing a DETACH
|
|
LPT command, which simulates running out of paper. If printing is still
|
|
pending or, for the 2607 only, the paper position is not at the
|
|
top-of-form, the message "Command not completed" is printed, and the detach
|
|
is deferred until a print command empties the print buffer and paper
|
|
movement ceases.
|
|
|
|
A "force" option is provided to detach the printer paper image file
|
|
immediately, regardless of the printer condition. DETACH -F LPT works if
|
|
the paper position is not at the TOF. However, it does not work if the
|
|
print buffer contains unprinted characters; "Command not completed" is
|
|
displayed instead.
|
|
|
|
Entering RESET LPT followed by DETACH LPT works, but the partial print
|
|
buffer is discarded rather than flushed to the output file.
|
|
|
|
CAUSE: The "lp_detach" routine sets TOF status if the -F switch is
|
|
specified, but it does not alter the buffer state.
|
|
|
|
RESOLUTION: Modify "lp_detach" (hp2100_lpt.c) to write a partial line to
|
|
the output file before detaching when the -F option is specified.
|
|
|
|
STATUS: Fixed in Release 29.
|
|
|
|
|
|
8. PROBLEM: BREAK needs an extra keystroke to stop an HP 2000/Access program.
|
|
|
|
VERSION: 3.7-1
|
|
|
|
OBSERVATION: According to the "HP 2000/Access BASIC Reference Manual" (HP
|
|
22687-90001), pressing the terminal BREAK key halts program execution and
|
|
prints STOP on the user's terminal. For example, running this program:
|
|
|
|
10 FOR I=1 TO 10000
|
|
20 PRINT I
|
|
30 NEXT I
|
|
40 END
|
|
|
|
...and pressing BREAK during execution does stop the program output.
|
|
However, STOP is not printed until another key (any key) is pressed.
|
|
|
|
Enabling tracing of the multiplexer and the processor interconnect kit
|
|
shows that the break is being recognized by the IOP, which then notifies
|
|
the SP by sending a "User abort request" command over the interconnect
|
|
link. In response, the SP sends "Kill terminal output" and a "User is
|
|
being aborted" commands to the IOP, followed by a "Process output string"
|
|
command to print STOP on the user's terminal. The IOP begins the output by
|
|
sending a SYNC character before the STOP string. When the transmit
|
|
interrupt occurs after SYNC transmission, the IOP reads the input data
|
|
register from the mux data card. The data value is 0, which the IOP
|
|
interprets as another break request. The IOP then sends another "User
|
|
abort request" command to the SP, which responds with a "Kill terminal
|
|
output" command, and the cycle repeats. Only when a character is pressed
|
|
does the input register data change from 0 to a non-zero value, allowing
|
|
the abort cycle to finish.
|
|
|
|
CAUSE: In hardware, the input data register normally holds the character
|
|
received from the selected multiplexer channel. This character has been
|
|
assembled by a shift register that is designated the "accumulator" from the
|
|
bits arriving on the serial input line. After a send operation, the input
|
|
data register also stores the value from the accumulator. In this case,
|
|
however, the value is that contained in the shift register after all of the
|
|
bits of the output character have been shifted out to the serial output
|
|
line. As each output character is padded on the left with 1 bits
|
|
(representing the serial stop bits) to an 11-bit length, if the character
|
|
length is less than 11, at least one 1-bit will remain in the register.
|
|
Therefore, when the IOP reads the register during processing of the
|
|
transmission interrupt, the value will be non-zero, and the IOP will not
|
|
restart BREAK processing.
|
|
|
|
Under simulation, however, a send operation places the last received
|
|
character in the input data register instead of the shifted send character.
|
|
As the last received character was zero (for the BREAK key press), the IOP
|
|
sees another break request and starts the abort cycle over from the
|
|
beginning.
|
|
|
|
RESOLUTION: Modify "mux_data_int" (hp2100_mux.c) to place the proper value
|
|
in the input data register when a send interrupt is requested.
|
|
|
|
STATUS: Fixed in Release 29.
|
|
|
|
|
|
9. PROBLEM: The parity status reported in the MUX input trace is incorrect.
|
|
|
|
VERSION: Release 28.
|
|
|
|
OBSERVATION: The parity bit (bit 15) of the received data word reflects
|
|
the computed parity of the data bits: 1 for odd parity and 0 for even
|
|
parity. However, when tracing the multiplexer lower (data) card, the
|
|
reported parity is incorrect. For example:
|
|
|
|
>>MUXL csrw: Input data is channel 0 | odd parity | 0003
|
|
|
|
The data value (3) has even parity, but it is reported as odd.
|
|
|
|
CAUSE: The trace reporting string is correctly set to report odd parity
|
|
for bit 15 set and even parity for bit 15 clear. However, the trace format
|
|
structure specifies the starting bit as bit 0 instead of bit 15. So the
|
|
report actually reflects the state of bit 0.
|
|
|
|
RESOLUTION: Modify "lower_input_format" (hp2100_mux.c) to reflect the
|
|
correct offset of the parity bit.
|
|
|
|
STATUS: Fixed in Release 29.
|
|
|
|
|
|
10. PROBLEM: 2000/Access programs may hang during long printer output.
|
|
|
|
VERSION: Release 28.
|
|
|
|
OBSERVATION: When printing or punching a large amount of output data, an
|
|
Access BASIC program may hang. Output generation stops for no apparent
|
|
reason. The only recourse is to press the BREAK key to stop the program.
|
|
|
|
CAUSE: There is a race condition between the system processor (SP) and the
|
|
I/O processor (IOP) during output to non-shareable devices controlled by
|
|
the IOP. The race occurs more frequently when a large amount of output is
|
|
generated quickly.
|
|
|
|
The cause is this code in subroutine #IPAL in the SP main program source
|
|
(TSB.asm) that is used to send buffered output data to IOP-connected
|
|
devices:
|
|
|
|
LDA ERTMP SEND
|
|
IOR ALB REQUEST
|
|
JSB SDVRP,I CODE
|
|
LDB #IPAL RETRIEVE
|
|
INB BUFFER
|
|
LDA B,I LENGTH
|
|
JSB SDVRP,I SEND TO IOP
|
|
SFS CH2 WAIT FOR
|
|
JMP *-1 ACKNOWLEDGEMENT
|
|
CLF 0
|
|
LIA CH2 RETRIEVE RESPONSE
|
|
|
|
If this "allocate buffer" ("ALB") request is refused by the IOP because all
|
|
output buffers are in use, the resulting "no buffer available" response
|
|
will cause the SP to issue a "release buffers" command to the IOP and then
|
|
suspend the user's program until the IOP sends a "wake up user" command to
|
|
indicate buffer availability. When the line printer completes its
|
|
operation on the current output buffer, the IOP frees it and then sends the
|
|
command to the SP to resume the user's output.
|
|
|
|
The problem occurs when the line printer completes just as the allocate
|
|
buffer request is made. That request sends two words: the ALB request code
|
|
and the buffer length. The IOP denies the request but then immediately
|
|
follows it with the "wake up user" command to indicate that a buffer is now
|
|
available. If the command arrives between the time the SP sends the buffer
|
|
length word and the time it picks up the response, the user program will
|
|
hang. This occurs because the response causes the SP to set a flag
|
|
indicating that the user has been suspended for buffer availability. If
|
|
the "wake up user" command arrives before that flag is set, the command is
|
|
ignored. So the SP is waiting for the IOP to issue the wake up, but the
|
|
IOP has already issued it. This leaves the suspension in force until the
|
|
user aborts the program by pressing the BREAK key.
|
|
|
|
Nominally, only about nine instructions execute between the STC CH2 (within
|
|
the SDVRP subroutine) that causes an IOP to accept the buffer length word
|
|
and the SFS CH2 (above) that detects that the IOP's acknowledgement has
|
|
arrived. However, the SP's interrupt system is on during the above SFS CH2
|
|
/ JMP *-1 loop, and the processor interconnect has the highest I/O
|
|
interrupt priority. So if, say, a time-base generator interrupt occurs
|
|
during the SFS loop, several dozen instructions may be executed before
|
|
control returns to the loop. If, during that time, the IOP command
|
|
arrives, the resulting higher-priority interrupt is handled before the loop
|
|
return, and the command is ignored because the "user is suspended" flag has
|
|
not been set.
|
|
|
|
RESOLUTION: Modify "card_service" (hp2100_ipl.c) to ensure that an IOP
|
|
status response is picked up before an IOP command if both are seen during
|
|
the same poll and to insert a long delay between these actions.
|
|
|
|
Note that this is a workaround, and not a solution, as there is no general
|
|
way to ensure that the response is read by the SP program before a pending
|
|
IOP command is recognized. That's because the SP does not read the
|
|
responses of some commands it sends, so simply holding off input card
|
|
commands until the output card data register is read will not work.
|
|
|
|
STATUS: Fixed in Release 29.
|
|
|
|
|
|
11. PROBLEM: RTE-II hangs in DVR31 if a 7900 disc is mounted while running.
|
|
|
|
VERSION: Release 28.
|
|
|
|
OBSERVATION: Mounting a peripheral disc, i.e., unit 1-3, while RTE-II is
|
|
running causes a hang within DVR31 (the RTE disc driver) when a :MC command
|
|
is issued. For example, with a running system, doing:
|
|
|
|
scp> attach DPC1 scratch.disc
|
|
|
|
*RU,FMGR
|
|
:MC,-10
|
|
|
|
...causes the system to become unresponsive. The interrupt system is off,
|
|
and execution is looping within the STATW subroutine within DVR31.
|
|
Examination shows that STA[1] = 040000 (i.e., First Status). The driver
|
|
issues a Seek command to unit 0 and then requests unit 1 status again.
|
|
Because STA[1] has not changed, execution loops forever.
|
|
|
|
If STA[1] is manually set to 000000, the driver exits, and RTE resumes
|
|
normal operation.
|
|
|
|
CAUSE: The Status Register on the 13210A interface is implemented in an
|
|
unusual way. It consists of a set of D-type flip-flops whose D inputs are
|
|
grounded, and whose individual asynchronous presets are tied to the various
|
|
controller and currently selected disc drive status lines. The register is
|
|
clocked, and therefore cleared synchronously, when any command OTHER than
|
|
Status Check is issued. A Status Check command (as well as a Write, Read,
|
|
Check Data, or Initialize command) gates the status signals to the preset
|
|
inputs. The register is therefore "ones-catching," and one-to-zero
|
|
transitions will not be seen by repeated Status Check commands unless some
|
|
other command intervenes to clear the register first.
|
|
|
|
When the selected drive receives a Status Check command, it also asserts
|
|
an internal CLEAR STATUS signal. This clears the Attention and First
|
|
Status flip-flops on the drive after they are reported to the controller.
|
|
|
|
When FMGR attempts to mount a newly attached disc image, DVR31 issues a
|
|
Status Check command and sees the First Status bit set. The driver checks
|
|
to see if the drive had been previously "downed" by a request for the
|
|
unattached drive. If not, then it checks to see if a request is currently
|
|
pending. If so, it issues (but does not complete) a Seek command, followed
|
|
by another Status Check command. The incomplete Seek is necessary to clear
|
|
the status register in order to see that First Status has transitioned from
|
|
one to zero.
|
|
|
|
The DP simulator neglected to clear the drive's First Status flip-flop
|
|
after a Status Check command. Consequently, First Status was returned for
|
|
subsequent Status Check commands, and DVR31 looped internally forever.
|
|
|
|
RESOLUTION: Modify "dpd_svc" (hp2100_dp.c) to clear First Status as well
|
|
as Attention when a Status Check command completes.
|
|
|
|
STATUS: Fixed in Release 29.
|
|
|
|
|
|
|
|
======================
|
|
Release 28, 2018-05-23
|
|
======================
|
|
|
|
This release of the HP 2100 simulator adds the following features:
|
|
|
|
- The IPLI and IPLO devices now use shared memory instead of network sockets to
|
|
simulate the 12875A Processor Interconnect kit that is used to communicate
|
|
between the System Processor and the I/O Processor of the HP 2000B, C, F, and
|
|
Access Time-Shared BASIC operating systems. This change, in addition to a
|
|
new, adaptive service scheduling routine, improves data transfer time between
|
|
the processes by a factor of 7 to 1.
|
|
|
|
- Commands have been added to the IPL device to permit synchronization between
|
|
the two simulator processes running the HP 2000 Time-Shared BASIC operating
|
|
system. This greatly improves system startup reliability and permits the use
|
|
of the HP-documented startup procedure of cross-loading the I/O Processor
|
|
program from the System Processor.
|
|
|
|
- The DIAGNOSTIC options of the IPLI and IPLO devices have been reworked to
|
|
permit testing with the HP General Register Diagnostic as well as the
|
|
Processor Interconnect Cable Diagnostic.
|
|
|
|
- The DEBUG options of the IPLI and IPLO devices have been expanded.
|
|
|
|
- The BOOT command now installs the correct binary loader for the CPU model.
|
|
For example, BOOT PTR installs and runs the Basic Binary Loader (BBL) if the
|
|
CPU is configured as a 2114/15/16 or 2100, or the 12992K Paper Tape Loader
|
|
ROM if the CPU is configured as a 1000 M/E/F-Series. Prior releases
|
|
installed the HP 1000 loader ROM regardless of the CPU model.
|
|
|
|
- The LOAD command has been extended to permit copying of internal device boot
|
|
loaders into memory. LOAD <dev> is identical to BOOT <dev> except that the
|
|
CPU is neither preset nor run. In particular, LOAD CPU is the equivalent of
|
|
pressing the IBL button on the HP 1000 front panel.
|
|
|
|
- The new SET CPU ROMS command permits altering the set of preinstalled boot
|
|
loader ROMs for 1000 CPUs. The new SHOW CPU ROMS command displays the
|
|
currently installed set.
|
|
|
|
- The -N (new file) option to the ATTACH command for disc devices now creates a
|
|
full-size image file, equivalent to formatting the new disc before use.
|
|
|
|
|
|
--------------------
|
|
Implementation Notes
|
|
--------------------
|
|
|
|
- The abbreviated "SET CPU 21MX" command no longer sets the CPU to an E-Series
|
|
model (i.e., to a 21MX-E, a.k.a. 1000-E); instead, it configures the CPU as
|
|
an original 21MX (a.k.a. 1000-M). If an E-Series configuration is desired,
|
|
it must be requested explicitly with the "SET CPU 21MX-E" command.
|
|
|
|
- The "RESET -P CPU" command no longer restores the BBL to the protected memory
|
|
area of 21xx machines. The "LOAD PTR" command may be used to perform this
|
|
function.
|
|
|
|
- The previous behavior of the "ATTACH -N" command for disc devices, i.e.,
|
|
creating a new zero-length image file, may be emulated by first deleting the
|
|
file and then attaching it without specifying the -N switch. For instance,
|
|
the "DELETE <file>" and "ATTACH <unit> <file>" commands produce a new
|
|
zero-length file as "ATTACH -N <unit> <file>" did before this change. The
|
|
"ATTACH -N" behavior of other devices, e.g., magnetic tape drives and
|
|
printers, did not change; a zero-length file is still created.
|
|
|
|
- With the change to a shared-memory implementation, only a single "ATTACH IPL"
|
|
command is required per instance to establish communication. The System
|
|
Processor instance issues an "ATTACH -S IPL <code>" command, and the I/O
|
|
Processor instance must issue a corresponding "ATTACH -I IPL <code>" command,
|
|
where the <code> parameter is a user-selected decimal number that identifies
|
|
the instance pair. The prior "ATTACH [-L | -C] [ IPLI | IPLO ] <port>"
|
|
commands are deprecated but retained, so that existing command files will
|
|
still work. However, they too will use shared memory rather than network
|
|
connections. Consequently, the SP and IOP instances are now required to
|
|
execute on the same machine, and the <ip-address> option is no longer
|
|
supported.
|
|
|
|
- Multiple consecutive CLC 0 instruction executions now cause only a single CRS
|
|
assertion to the I/O devices. Therefore, IOBUS tracing when running HP 2000
|
|
Time-Shared BASIC systems no longer generates a pair of trace lines for each
|
|
of the 131,072 consecutive CLC 0 executions typically used to initialize the
|
|
12920A Asynchronous Multiplexer.
|
|
|
|
- The 12875A Processor Interconnect section of the HP2100 User's Guide has been
|
|
revised to describe the new ATTACH protocol and process synchronization
|
|
commands.
|
|
|
|
- A list of device boot loaders installed for given device/CPU combinations has
|
|
been added to the user's guide.
|
|
|
|
- The "21MX-M" and "21MX-E" CPU options that had been inadvertently omitted
|
|
from the last release of the user's guide have been restored.
|
|
|
|
- The "Running HP 2000 Time-Shared BASIC on SIMH" monograph has been revised to
|
|
cover the application of the new process synchronization commands to TSB
|
|
startup command files.
|
|
|
|
- Preconfigured software kits for 2000E, 2000F, and 2000 Access that employ
|
|
the new shared memory and process synchronization commands are now available;
|
|
see the "Available Software" section above for details.
|
|
|
|
|
|
----------
|
|
Bugs Fixed
|
|
----------
|
|
|
|
1. PROBLEM: Serial port output stalls are not handled properly.
|
|
|
|
VERSION: Release 27.
|
|
|
|
OBSERVATION: The TTY, BACI, MPX, and MUX devices support I/O via host
|
|
serial ports as well as via Telnet connections. While TTY, BACI, and MPX
|
|
output via Telnet works correctly, output via serial ports fails. TTY
|
|
output drops characters if the serial port stalls. Attempting to output to
|
|
the BACI results in "Console Telnet output stall" and a simulator stop.
|
|
Output to the MPX results in dropped characters and eventually an "IOPE"
|
|
(parity error) message from RTE.
|
|
|
|
CAUSE: The terminal multiplexer library (sim_tmxr.c, part of the SIMH
|
|
framework) had provided a 256-byte output buffer for each line, independent
|
|
of the connection type (Telnet or serial). The library was changed to
|
|
reduce the serial buffer size to one byte. The BACI and MPX devices are
|
|
internally buffered and default to a "FASTTIME" mode that sends the entire
|
|
internal buffer to the library output routine. When the routine receives
|
|
the second character, it returns SCPE_STALL status to indicate a buffer
|
|
overflow. The device simulations did not expect and did not properly
|
|
handle this status.
|
|
|
|
The TTY and MUX devices are not buffered internally and were not affected
|
|
by the loss of serial buffering. However, the TTY would drop output
|
|
characters if the host serial buffer overflowed.
|
|
|
|
RESOLUTION: Modify "tto_svc" (hp2100_stddev.c), "baci_term_svc"
|
|
(hp2100_baci.c), and "line_service" (hp2100_mpx.c) to handle terminal
|
|
multiplexer library buffer overflows properly.
|
|
|
|
STATUS: Fixed in Release 28.
|
|
|
|
|
|
2. PROBLEM: The PTR device DIAGNOSTIC option shown in the user's guide does
|
|
not exist.
|
|
|
|
VERSION: Release 27.
|
|
|
|
OBSERVATION: The "HP2100 Simulator User's Guide" says that specifying the
|
|
DIAGNOSTIC option for the PTR device "converts the attached paper tape
|
|
image into a continuous loop" for use by the paper tape reader diagnostic
|
|
program. However, entering a "SET PTR DIAGNOSTIC" command gives a
|
|
"Non-existent parameter" error.
|
|
|
|
CAUSE: The option name specified in the PTR device's modifier table is
|
|
"DIAG". It should be "DIAGNOSTIC" to match the option names used in the
|
|
other device simulations.
|
|
|
|
RESOLUTION: Modify "ptr_mod" (hp_stddev.c) to use the correct option name.
|
|
|
|
STATUS: Fixed in Release 28.
|
|
|
|
|
|
3. PROBLEM: First Status is not cleared properly on the DP device.
|
|
|
|
VERSION: Release 27.
|
|
|
|
OBSERVATION: Execution of the RTE-I paper tape bootstrap for the 7900A and
|
|
the 2000F loader for the 7900A halts with disc errors. The offending disc
|
|
status word is 040001 octal, which denotes First Status and Any Error.
|
|
Both programs expect disc status to be clear after an initial Seek and Read
|
|
are performed. However, the disc drive and interface manuals state that
|
|
First Status is cleared by a Status Check command, which is not being
|
|
issued.
|
|
|
|
CAUSE: Examination of the schematics in the 7900A Disc Drive Operating and
|
|
Service Manual (07900-90002 February 1975) and the 13210A Disc Drive
|
|
Interface Kit Operating and Service Manual (13210-90003 November 1974)
|
|
shows that, contrary to the documentation, First Status is cleared on a
|
|
Read, Write, Check Data, or Initialize command, as well as on a Status
|
|
Check command. The current DP implementation follows the manual
|
|
description rather than the schematics, so it fails to clear First Status
|
|
when the initial Read is performed.
|
|
|
|
RESOLUTION: Modify "dp_goc" (hp2100_dp.c) to clear First Status as well as
|
|
Attention when one of the applicable commands is performed.
|
|
|
|
STATUS: Fixed in Release 28.
|
|
|
|
|
|
4. PROBLEM: 2000F and Access will not boot from a 7900 drive using the BMDL.
|
|
|
|
VERSION: Release 27.
|
|
|
|
OBSERVATION: Attempting to boot Time-Shared BASIC from a 7900 using the
|
|
Basic Moving-Head Disc Loader for the HP 2100 CPU results in a HLT 1
|
|
(unrecoverable disc error) in the TSB loader. Booting the same system with
|
|
the 12992A loader ROM for the HP 1000 succeeds.
|
|
|
|
The BMDL configures DMA for an oversize (~32000 word) transfer and expects
|
|
the disc to terminate the operation with End of Cylinder (EOC) status. The
|
|
TSB bootstrap successfully loads into memory. When it starts, it issues a
|
|
CLC 0,C followed by a Check Status command that is expected to return zero,
|
|
i.e., all status bits clear. However, the EOC bit is set, and the
|
|
bootstrap halts with a HLT 1.
|
|
|
|
CAUSE: The "Disc Interface 1 PCA Schematic Diagram" in the HP 13210A Disc
|
|
Drive Interface Kit Operating and Service Manual (13210-90003, August 1974)
|
|
shows that the CRS signal, which is generated by the CLC 0 instruction,
|
|
does not affect the Status Register contents. However, examination of an
|
|
actual hardware interface PCA shows that CRS assertion does clear the
|
|
register.
|
|
|
|
RESOLUTION: Modify "dpcio" (hp2100_dp.c) to clear the status register on
|
|
receipt of a CRS signal. Note that later versions of the service manual
|
|
(May 1975 and May 1978) show the correct CRS connection.
|
|
|
|
STATUS: Fixed in Release 28.
|
|
|
|
|
|
5. PROBLEM: Forcibly disconnected 2000E multiplexer ports are unresponsive.
|
|
|
|
VERSION: Release 27.
|
|
|
|
OBSERVATION: The HP Time-Shared BASIC system sets a limit on the time
|
|
allowed between dataset connection and login. By default, this is 120
|
|
seconds but may be changed by the PHONES system operator command. If the
|
|
user does not complete a login within the time allowed, the dataset will be
|
|
disconnected.
|
|
|
|
This action occurs as expected on the 2000E system, but while reconnecting
|
|
to the port succeeds, the line is unresponsive. More importantly,
|
|
attempting to SLEEP the system hangs after responding to the "MAG TAPE
|
|
SLEEP?" question.
|
|
|
|
CAUSE: Examining the source code where the SLEEP hang occurs shows that
|
|
the system is waiting in a loop for output to complete on the disconnected
|
|
port. The forced disconnect code, which is shared by the PHONES, KILLID,
|
|
and SLEEP commands, calls the BYE processor to log out an active user.
|
|
However, for a PHONES disconnect, the user is not logged in. The BYE
|
|
processor handles this condition correctly, but it returns to a common
|
|
routine (LLEND) that outputs a line feed to the port. The multiplexer
|
|
simulation omits a write to a disconnected port but also erroneously omits
|
|
the output completion interrupt request. Consequently, TSB believes that
|
|
the output is still in progress and therefore waits, in an infinite loop,
|
|
for the completion interrupt that never occurs. Also, while the port is in
|
|
output mode, input is turned off, so the port appears to be unresponsive
|
|
when reconnected.
|
|
|
|
RESOLUTION: Modify "muxo_svc" (hp2100_mux.c) to set "mux_xdon" to 1 to
|
|
trigger the completion interrupt regardless of whether or not the port is
|
|
connected to a Telnet session.
|
|
|
|
STATUS: Fixed in Release 28.
|
|
|
|
|
|
|
|
======================
|
|
Release 27, 2017-09-06
|
|
======================
|
|
|
|
This release of the HP 2100 simulator adds the following features:
|
|
|
|
- Support for the HP 2613, 2617, and 2618 line printers has been added to the
|
|
LPT device. The default printer remains the HP 2607.
|
|
|
|
- The LPT device simulation has been rewritten to support realistic and
|
|
optimized timing, compact and expanded output modes, custom VFU tape images,
|
|
and tracing of internal operations.
|
|
|
|
- The LOAD command has been rewritten to load files containing absolute binary
|
|
loaders into the protected address space of the 21xx machines and configure
|
|
the I/O instructions. For the 1000, LOAD can also be used to load boot
|
|
loader ROM images other than those provided directly by the simulator.
|
|
|
|
- The DUMP command has been added to write the binary loader currently resident
|
|
in memory to an absolute binary file.
|
|
|
|
- The TTY punch unit and the LPS, LPT, and PTP devices now position a newly
|
|
attached file at the end of the file rather than at the start. As a result,
|
|
output will append to, rather than overwrite, the existing content.
|
|
|
|
- The DA, DP, DQ, and DS disc devices add the PROTECT and UNPROTECT options.
|
|
These replace the now-deprecated LOCKED and WRITEENABLED options and more
|
|
accurately reflect the labelling of the data protection switches on the disc
|
|
drives.
|
|
|
|
- The simulator message that is displayed when a programmed halt occurs has
|
|
been changed to indicate that the halt code comes from the T-register value.
|
|
|
|
- The Basic Binary Loader (BBL) is now installed by default in the 21xx
|
|
machines. It is automatically configured to the select code of the paper
|
|
tape reader. It may be overwritten with a different loader (e.g., the Basic
|
|
Binary Disc Loader or Basic Moving-head Disc Loader) using the LOAD command.
|
|
Performing a power-on reset of the CPU reinstalls the BBL.
|
|
|
|
- Symbolic display and entry has been rewritten to improve efficiency and
|
|
expanded to cover the full instruction set including optional microcode
|
|
extensions that are currently enabled.
|
|
|
|
- CPU instruction execution and data accesses may be selectively traced. The
|
|
resulting trace listing is similar to the output of a logic analyzer
|
|
connected to the CPU and I/O buses.
|
|
|
|
- DMA/DCPC commands, status, and data accesses may be selectively traced.
|
|
|
|
- TBG commands, status, and service entries may be selectively traced.
|
|
|
|
- The DIAG option of the TBG device has been replaced with the REALTIME, W1A,
|
|
W1B, W2A, and W2B options. Configuring the TBG to run its diagnostic now
|
|
uses the REALTIME and W2B options, and restoring the normal configuration
|
|
uses the CALTIME and W2A options. The W1A and W1B options extend the
|
|
software compatibility of the TBG.
|
|
|
|
- The MUXM device has been renamed MUXC to reflect that it is the multiplexer
|
|
control card. The previous MUXM name is deprecated but will still work in
|
|
existing simulation command files.
|
|
|
|
- The multiplexer control card (MUXC) may be enabled and disabled independently
|
|
of the upper and lower data cards (MUX and MUXL), reflecting its optional
|
|
status in hardware configurations.
|
|
|
|
- Memory address parsing for commands has been changed to add <page>.<offset>
|
|
format for physical addresses, where both the page and the offset range from
|
|
0 to 1777 octal. Linear addressing is now restricted to the 32K logical
|
|
address space (0 to 77777 octal). Memory display uses linear addressing for
|
|
locations within the logical address space; locations above 32K use the
|
|
physical address format.
|
|
|
|
- The previously separate STOP_INST, STOP_DEV, STOP_IOE, and INDMAX
|
|
pseudo-registers used to stop the simulator under certain conditions have
|
|
been replaced by the SET CPU STOP=<stopname>[,<stopname>...] and the SET CPU
|
|
INDIR=<limit> commands. Stops may be temporarily bypassed by adding the -B
|
|
switch to the command that resumes execution.
|
|
|
|
- The HP 2100 Simulator User's Guide has been rewritten and significantly
|
|
expanded.
|
|
|
|
|
|
--------------------
|
|
Implementation Notes
|
|
--------------------
|
|
|
|
- The simulator passes the HP 2613/17/18 line printer diagnostic as described
|
|
in the "hp2100_diag.txt" file.
|
|
|
|
- The line printer terminates each print line with the HP-standard CR/LF pair.
|
|
If the output file is to be retained as a text file on a Unix system, removal
|
|
of the carriage returns, e.g., via the "dos2unix" utility, may be desirable.
|
|
|
|
- The LOAD command can no longer be used to read general absolute binary paper
|
|
tape images into memory. The ATTACH PTR and BOOT PTR commands must now be
|
|
used to read paper tapes.
|
|
|
|
- The OS, OSTBG, VMA, EMA, VIS, and SIGNAL CPU debug flags have been removed.
|
|
Tracing of these firmware instructions is now performed by specifying SET CPU
|
|
DEBUG=EXEC and SET CPU EXEC with the appropriate opcode range and mask, as
|
|
follows:
|
|
|
|
* SET CPU DEBUG=OS => SET CPU EXEC=105340;177760
|
|
* SET CPU DEBUG=VMA => SET CPU EXEC=105240;177760
|
|
* SET CPU DEBUG=EMA => SET CPU EXEC=105240;177760
|
|
* SET CPU DEBUG=VIS => SET CPU EXEC=101460;173760
|
|
* SET CPU DEBUG=SIGNAL => SET CPU EXEC=105600;177760
|
|
|
|
- The separate tracing of time-base generator interrupt instructions provided
|
|
by the OS and OSTBG CPU debug flags is no longer supported. Entering the
|
|
replacement command above traces all OS instructions, including the TBG
|
|
interrupt instructions.
|
|
|
|
- The TIMER, RRR 16, .FLUN, and the OS/VMA, VIS, and SIGNAL self-test
|
|
instructions are no longer exempt from the undefined/unimplemented
|
|
instruction stop tests. Attempted execution of these instructions without
|
|
the appropriate firmware options installed will cause simulation stops if the
|
|
UNDEF (TIMER and RRR) or UNIMPL (.FLUN and self-tests) option is enabled.
|
|
Because of this change, the default state of the unimplemented instruction
|
|
stop has been reversed from "on" to "off".
|
|
|
|
- The "stop on I/O error" features controlled by the STOP_IOE register values
|
|
have been removed from the DR, LPS, LPT, MSC, MTC, and PTP devices, as all of
|
|
these report I/O error status to the CPU via their interface input registers.
|
|
STOP_IOE has been removed from the PTR device and replaced with SET CPU
|
|
STOP=IOERR, as this device does not report I/O error status to the CPU
|
|
through its interface.
|
|
|
|
- The LOCKED and WRITEENABLED options for the MSC and MTC devices are
|
|
deprecated. The supported method of write-protecting a tape drive is to
|
|
attach the tape image with the -R (read-only) switch or by setting the host
|
|
operating system's read-only attribute on the tape image file. This
|
|
simulates removing the write ring from the tape reel before mounting it on
|
|
the drive. There is no hardware method of write-protecting a mounted and
|
|
positioned tape reel.
|
|
|
|
- If the previous ATTACH behavior (overwriting rather than appending) is
|
|
desired for the TTY punch unit and the LPS, LPT, and PTP devices, set the
|
|
device's (P)POS register to 0 after attaching.
|
|
|
|
|
|
----------
|
|
Bugs Fixed
|
|
----------
|
|
|
|
1. PROBLEM: EXAMINE -M for addresses > 32K displays misleading operands.
|
|
|
|
VERSION: Release 26.
|
|
|
|
OBSERVATION: Current-page memory references of instructions residing above
|
|
the 32K logical address space are printed as though they reside at their
|
|
locations modulo 32K. For example, DEPOSIT 170001 026020 and EXAMINE -M
|
|
170001 displays JMP 70020, and DEPOSIT 200001 026020 displays JMP 20.
|
|
|
|
CAUSE: The printed addresses assume that the instructions will be executed
|
|
from their respective pages (modulo 32). However, instructions can be
|
|
executed only when they are mapped into the logical address space, and any
|
|
given physical page may be mapped to any arbitrary logical page.
|
|
Therefore, the address printed may not represent the actual logical address
|
|
after mapping.
|
|
|
|
RESOLUTION: Modify "fprint_cpu" (hp2100_sys.c) to use Z/C address notation
|
|
for memory references in instructions residing in physical memory above
|
|
32K.
|
|
|
|
STATUS: Fixed in Release 27.
|
|
|
|
|
|
2. PROBLEM: Enabling IOP firmware should not be allowed on the 1000 F-Series.
|
|
|
|
VERSION: Release 26.
|
|
|
|
OBSERVATION: The command "SET CPU 1000-F,IOP" is allowed, but it should
|
|
not be, as the IOP firmware is not supported on this machine.
|
|
|
|
CAUSE: The F-Series does not provide the firmware mapping table entries
|
|
that permit operation of the 2000/Access I/O Processor firmware. IOP
|
|
instruction opcodes 10x400-17 and 10x420-37 are marked as "HP Reserved" in
|
|
the F-Series mapping table, and opcodes 10x460-77 are dedicated to the VIS
|
|
microcode.
|
|
|
|
RESOLUTION: Modify the "cpu_features" array (hp2100_cpu.c) to remove the
|
|
IOP option from the 1000 F-Series entry.
|
|
|
|
STATUS: Fixed in Release 27.
|
|
|
|
|
|
3. PROBLEM: A rejected model change still changes the CPU options.
|
|
|
|
VERSION: Release 26.
|
|
|
|
OBSERVATION: Changing to a CPU model that does not support the current
|
|
memory size will reduce memory to the maximum supported by the new model.
|
|
If the truncated portion contains non-zero values, the simulator will ask
|
|
for confirmation before proceeding. If the truncation is rejected, the CPU
|
|
options are still set to those of the new model, even though the old model
|
|
is retained. For example:
|
|
|
|
sim> SET CPU 1000-F,128K
|
|
sim> SHOW CPU
|
|
CPU idle disabled
|
|
128KW, 1000-F, EAU
|
|
FP, no IOP, DMS
|
|
FFP, DBI, no EMA/VMA
|
|
no VIS, no SIGNAL
|
|
sim> DEPOSIT 100000 1
|
|
sim> SET CPU 2116
|
|
Really truncate memory [N]?NO
|
|
Command not completed
|
|
sim> SHOW CPU
|
|
CPU idle disabled
|
|
128KW, 1000-F, no EAU
|
|
no FP, no IOP, no DMS
|
|
no FFP, no DBI, no EMA/VMA
|
|
no VIS, no SIGNAL
|
|
|
|
CAUSE: The CPU options are set before the memory size is changed, so when
|
|
the size change is rejected, the new CPU options are retained.
|
|
|
|
RESOLUTION: Modify "cpu_set_model" (hp2100_cpu.c) to perform the memory
|
|
size change first, so that if it is rejected, the CPU options have not been
|
|
changed.
|
|
|
|
STATUS: Fixed in Release 27.
|
|
|
|
|
|
4. PROBLEM: Virtual memory mapping fails for accesses above 126 MB.
|
|
|
|
VERSION: Release 26.
|
|
|
|
OBSERVATION: A program using virtual memory provided by the RTE-6/VM
|
|
operating system may access up to 128 MB of data, although VMA programs
|
|
default to a 16 MB limit. Accesses to data in virtual memory are mapped
|
|
through the last two DMS user map registers. Normally, each VMA access
|
|
maps in the memory page corresponding to the virtual address plus the
|
|
following memory page. This allows access to single items up to 1024 words
|
|
in size starting at any offset within the (first) page.
|
|
|
|
If a data item resides in the last 2 MB of virtual memory, access to an
|
|
item that crosses the page boundary is incorrect. Instead of accessing
|
|
words in the second page, the accesses wrap around within the first page.
|
|
|
|
CAUSE: The suit number part of the virtual address is not restored before
|
|
checking the allocation status of the page table entry corresponding to the
|
|
second (spillover) page. As a result, an unallocated second page in the
|
|
last 2 MB of virtual memory is seen as beyond the VM area limit, and
|
|
instead of generating a page fault to allocate the second page, the map
|
|
registers are set up to prevent access to the second page by setting the
|
|
first page address into both map registers.
|
|
|
|
RESOLUTION: Modify "cpu_vma_lbp" (hp2100_cpu5.c) to check for spill page
|
|
allocation correctly.
|
|
|
|
STATUS: Fixed in Release 27.
|
|
|
|
|
|
5. PROBLEM: Memory expansion is not disabled when DMS is disabled.
|
|
|
|
VERSION: Release 26.
|
|
|
|
OBSERVATION: If the Memory Expansion Module in a 1000-Series CPU has been
|
|
enabled, and then the DMS firmware option is disabled or the CPU is changed
|
|
to a model that does not support memory expansion (e.g., a 2100), memory
|
|
expansion remains enabled. In this case, memory accesses should revert to
|
|
physical addressing, but instead logical-to-physical address translation
|
|
through the currently enabled map remains in effect.
|
|
|
|
CAUSE: Disabling DMS should set the "dms_enb" flag to 0, but it does not.
|
|
|
|
RESOLUTION: Modify "set_model" and "set_option" (hp2100_cpu.c) to clear
|
|
the "dms_enb" flag if DMS is not enabled after the model or option change.
|
|
|
|
STATUS: Fixed in Release 27.
|
|
|
|
|
|
|
|
======================
|
|
Release 26, 2017-05-01
|
|
======================
|
|
|
|
This release of the HP 2100 simulator does not add any new features.
|
|
|
|
|
|
--------------------
|
|
Implementation Notes
|
|
--------------------
|
|
|
|
- Starting with the next release, the LOAD command will be rewritten to load
|
|
files containing absolute binary loaders into the protected address space of
|
|
the 21xx machines and configure the I/O instructions. The LOAD command is
|
|
not designed for general loading of absolute binary files, as it does not
|
|
initialize the A and B registers as some HP software expects. It is intended
|
|
only to install bootstrap loaders. The BOOT PTR command is the proper
|
|
simulation of the hardware absolute paper tape loader.
|
|
|
|
|
|
----------
|
|
Bugs Fixed
|
|
----------
|
|
|
|
1. PROBLEM: The RWCS debug option shown in the user's guide does not exist.
|
|
|
|
VERSION: Release 25.
|
|
|
|
OBSERVATION: The "HP2100 Simulator User's Guide" says that the RWCS debug
|
|
option may be specified for the DS and DA devices to trace "disk read/
|
|
write/control/status commands." However, entering a SET DS DEBUG=RWCS
|
|
command gives an "Invalid argument" error.
|
|
|
|
CAUSE: The option name is misspelled; the correct option is RWSC.
|
|
|
|
RESOLUTION: Modify "hp2100_doc.doc" to list the correct option name.
|
|
|
|
STATUS: Fixed in Release 26.
|
|
|
|
|
|
2. PROBLEM: Halt opcodes 1060xx and 1070xx do not display in mnemonic form.
|
|
|
|
VERSION: Release 25.
|
|
|
|
OBSERVATION: Halt instructions 106000-106077 and 107000-107077 are not
|
|
displayed in mnemonic form, either directly with an EXAMINE -M command
|
|
or in the message displayed for a programmed halt. These instruction
|
|
ranges are displayed in octal only.
|
|
|
|
CAUSE: Section 3.20, "Input/Output Instructions," of the "HP 1000
|
|
M/E/F-Series Computers Technical Reference Handbook" (HP 5955-0282, March
|
|
1980) says, in part, "Bit 11, where relevant, specifies the A- or
|
|
B-register or distinguishes between set control and clear control;
|
|
otherwise, bit 11 may be a logic 0 or a logic 1 without affecting the
|
|
instruction (although the assembler will assign zeros in this case)." The
|
|
HLT instruction does not specify the A/B register, so the valid opcodes are
|
|
102000-102077, 103000-103777, 106000-106077, and 107000-107077. However,
|
|
the latter two ranges are omitted from the "opcode" and "opc_val" tables
|
|
used for decoding.
|
|
|
|
RESOLUTION: Add the 1060xx/107xx range to the "opc_val" table and a second
|
|
"HLT" string to the "opcode" table (hp2100_sys.c) to permit mnemonic
|
|
display of this instruction range.
|
|
|
|
STATUS: Fixed in Release 26.
|
|
|
|
|
|
3. PROBLEM: The SFB (scan for byte) opcode displays as SBT (store byte).
|
|
|
|
VERSION: Release 25.
|
|
|
|
OBSERVATION: Entering the "EVAL -M 105767" command should display the
|
|
"SFB" mnemonic. Instead, it displays "SBT".
|
|
|
|
CAUSE: The entry in the opcode mnemonic table corresponding to the 105767
|
|
value is "SBT", which is incorrect. It should be "SFB" (SBT is 105764).
|
|
|
|
RESOLUTION: Modify the "opcode" table (hp2100_sys.c) to use the correct
|
|
mnemonic for the SFB instruction.
|
|
|
|
STATUS: Fixed in Release 26.
|
|
|
|
|
|
4. PROBLEM: Host file system seek errors are not caught.
|
|
|
|
VERSION: Release 25.
|
|
|
|
OBSERVATION: The MAC/ICD disc library checks for host file system read or
|
|
write errors and returns Uncorrectable Data Error status if an error is
|
|
indicated. However, host file system seeks are simply assumed to succeed;
|
|
no indication of an error is given if a call fails. A failed seek should
|
|
be detected, and a Drive Fault (positioner error) should be returned.
|
|
|
|
CAUSE: Oversight.
|
|
|
|
RESOLUTION: Modify "position_sector" (hp2100_disclib.c) to test the
|
|
"sim_fseek" call for error status and to simulate a Drive Fault (AGC error)
|
|
if the call fails.
|
|
|
|
STATUS: Fixed in Release 26.
|
|
|
|
|
|
5. PROBLEM: Set Flow Control and Cancel commands fail if port key is not set.
|
|
|
|
VERSION: Release 25.
|
|
|
|
OBSERVATION: HP 8-channel multiplexer commands that refer to ports do so
|
|
indirectly by passing a port key, rather than a port number. The
|
|
key-to-port translation is established by the "Set Port Key" command, which
|
|
must be executed before any port-specific commands. If a port key has not
|
|
been established, then all port-specific commands should be ignored.
|
|
However, the "Cancel first receive buffer" and "Set flow control" commands
|
|
cause program corruption if the key has not been set.
|
|
|
|
CAUSE: The test for key validity is improperly applied for these commands.
|
|
|
|
RESOLUTION: Modify "exec_command" (hp2100_mpx.c) to ignore these commands
|
|
if the port key has not been set.
|
|
|
|
STATUS: Fixed in Release 26.
|
|
|
|
|
|
6. ENHANCEMENT: Improve the EAU shift and rotate instruction simulations.
|
|
|
|
VERSION: Release 25.
|
|
|
|
OBSERVATION: The shift and rotate instructions (ASL, ASR, LSL, LSR, RRL,
|
|
and RRR) perform 32-bit operations on the combined B and A registers. The
|
|
original implementation treated the 16-bit registers independently.
|
|
However, it is faster and smaller to form a 32-bit operand, apply the
|
|
operation, and then split the operand back into the B and A registers.
|
|
Modern compilers, such as gcc, recognize the shifting and masking patterns
|
|
necessary for a rotation and generate a single rotate-left or rotate-right
|
|
machine instruction.
|
|
|
|
RESOLUTION: Modify "cpu_eau" (hp2100_cpu1.c) to reimplement the shift and
|
|
rotate instructions as 32-bit operations.
|
|
|
|
STATUS: Fixed in Release 26.
|
|
|
|
|
|
|
|
======================
|
|
Release 25, 2017-01-11
|
|
======================
|
|
|
|
This is the initial checkpoint release of the HP 2100 simulator, corresponding
|
|
to the 25th set of changes to the simulator code base. The following devices
|
|
are currently simulated:
|
|
|
|
- 2114C CPU with up to 16 KW of memory
|
|
- 2115A CPU with up to 8 KW of memory
|
|
- 2116C CPU with up to 32 KW of memory
|
|
- 2100A CPU with up to 32 KW of memory
|
|
- 1000 M/E/F-Series CPU with up to 1024 KW of memory
|
|
- EAU, FP, IOP, DMS, FFP, DBI, VIS, and SIGNAL microcode extensions
|
|
- RTE-IV EMA or RTE-6/VM OS and VMA microcode extensions
|
|
- 12531C Buffered Teleprinter Interface with one 2752 Teleprinter
|
|
- 12539C Time Base Generator
|
|
- 12557A Disc Controller with four 2870 drives
|
|
- 12559C Magnetic Tape Controller with one 3030 drive
|
|
- 12565A Disc Controller with two 2883 drives
|
|
- 12566B Microcircuit Interface with a loopback connector
|
|
- 12578A Direct Memory Access Controller
|
|
- 12581A Memory Protect
|
|
- 12597A Duplex Register Interface with one 2748 Paper Tape Reader
|
|
- 12597A Duplex Register Interface with one 2895 Paper Tape Punch
|
|
- 12606B Fixed Head Disc Controller with one 2770/2771 drive
|
|
- 12607B Direct Memory Access Controller
|
|
- 12610B Drum Controller with one 2773/2774/2775 drive
|
|
- 12620A Privileged Interrupt Fence
|
|
- 12653A Printer Controller with one 2767 Line Printer
|
|
- 12792C 8-Channel Asynchronous Multiplexer
|
|
- 12821A Disc Interface with four 7906H/7920H/7925H drives
|
|
- 12845B Printer Controller with one 2607 Line Printer
|
|
- 12875A Interprocessor Link
|
|
- 12892B Memory Protect
|
|
- 12895A Direct Memory Access Controller
|
|
- 12897B Dual-Channel Port Controller
|
|
- 12920A 16-Channel Terminal Multiplexer
|
|
- 12936A Privileged Interrupt Fence
|
|
- 12966A Buffered Asynchronous Communications Interface
|
|
- 13037D Disc Controller with eight 7905/7906/7920/7925 drives
|
|
- 13181A Magnetic Tape Controller with four 7970B drives
|
|
- 13183A Magnetic Tape Controller with four 7970E drives
|
|
- 13210A Disc Controller with four 7900 drives
|
|
|
|
The "HP 2100 Simulator User's Guide" manual describes the configuration and
|
|
operation of each of these devices in detail.
|
|
|
|
|
|
--------------------
|
|
Implementation Notes
|
|
--------------------
|
|
|
|
- New bug fixes will now be listed in this file under the associated release
|
|
rather than in their previous location (hp2100_bugfixes.txt).
|
|
|
|
- Starting with the next release, the LOAD command will restrict its operation
|
|
to the addresses occupied by the bootstrap loaders, i.e., the last 64
|
|
locations in memory (up to 32K). The LOAD command is not designed for
|
|
general loading of absolute binary files, as it does not initialize the A and
|
|
B registers as some HP software expects. It is intended only to install
|
|
bootstrap loaders. The BOOT PTR command is the proper simulation of the
|
|
hardware absolute paper tape loader.
|
|
|
|
|
|
----------
|
|
Bugs Fixed
|
|
----------
|
|
|
|
1. PROBLEM: DPC device documentation uses the wrong disc drive model number.
|
|
|
|
VERSION: Release 24.
|
|
|
|
OBSERVATION: The comments in the hp2100_dpc.c source file and Section 2 of
|
|
the "HP2100 Simulator User's Guide" say that the DPC device supports the
|
|
2871 disc drive, while Section 2.6.1 of the User's Guide says that the
|
|
support is for the 2781 disc drive. Neither of these model numbers is
|
|
correct.
|
|
|
|
Contemporaneous literature (e.g., the "2116B Computer Price List," dated
|
|
June 1970) states that the disc memory subsystem consists of the HP 2870A
|
|
Moving Head Disc, HP 2871A Disc Controller, HP 2881A Power Supply, and HP
|
|
2882A Cabinet.
|
|
|
|
CAUSE: The controller model number is used instead of the drive model
|
|
number, while the "2781" number is a transposition of "2871."
|
|
|
|
RESOLUTION: Modify the initial comments in the DPC device source file
|
|
(hp2100_dpc.c) and modify the sections of the HP2100 Simulator User's Guide
|
|
to use the correct disc drive model number (2870).
|
|
|
|
STATUS: Fixed in Release 25.
|
|
|
|
|
|
2. PROBLEM: The BOOT DRC command does not execute correctly.
|
|
|
|
VERSION: Release 24.
|
|
|
|
OBSERVATION: Attempting to boot DOS from a fixed-head disc or drum does
|
|
not work. The CPU sits in a loop waiting for DMA to finish, but it never
|
|
does.
|
|
|
|
CAUSE: The DMA control word in the DR device bootstrap is not configured
|
|
during BOOT DRC processing, so DMA is communicating with the wrong device.
|
|
|
|
RESOLUTION: Modify "drc_boot" (hp2100_dr.c) to set the fixed disc/drum
|
|
select code into the DMA control word before returning.
|
|
|
|
STATUS: Fixed in Release 25.
|
|
|
|
|
|
3. PROBLEM: The valid command "DEPOSIT 2000 JMP 2001" is rejected.
|
|
|
|
VERSION: Release 24.
|
|
|
|
OBSERVATION: Regarding symbolic input, the HP2100 User's Manual says that
|
|
the "C" and "Z" flags, signifying a current-page or zero-page reference,
|
|
respectively, are not needed "...when entering [memory reference]
|
|
instructions into CPU memory; the simulator figures out from the target
|
|
address what mode to use." While the valid command "DEPOSIT 1000 JMP 1001"
|
|
correctly enters a zero-page jump into memory, the valid command "DEPOSIT
|
|
2000 JMP 2001" does not enter a current-page jump. Instead, an "Invalid
|
|
argument" error occurs.
|
|
|
|
CAUSE: The "parse_sym" routine looks for the optional "C" or "Z" flag when
|
|
parsing memory reference instructions and sets a flag if either is
|
|
specified. The test for a current-page reference is performed only if the
|
|
reference type was not explicitly specified. However, the sense of the
|
|
test is reversed.
|
|
|
|
RESOLUTION: Modify "parse_sym" (hp2100_sys.c) to correct the test for C/Z
|
|
option specification.
|
|
|
|
STATUS: Fixed in Release 25.
|
|
|
|
|
|
4. PROBLEM: The invalid command "DEPOSIT 2000 JMP C 2001" is accepted.
|
|
|
|
VERSION: Release 24.
|
|
|
|
OBSERVATION: Regarding symbolic input, the HP2100 User's Manual says that
|
|
"The address is an octal number in the range 0 - 77777; if C or Z is
|
|
specified, the address is a page offset in the range 0 - 1777." However,
|
|
specifying a page offset > 1777 is accepted without complaint if it is
|
|
within the current page range.
|
|
|
|
CAUSE: Error checking for memory reference instruction entry is
|
|
incomplete.
|
|
|
|
RESOLUTION: Modify "parse_sym" (hp2100_sys.c) to ensure that the range
|
|
check is enforced if either C or Z is specified.
|
|
|
|
STATUS: Fixed in Release 25.
|
|
|
|
|
|
5. PROBLEM: Punched output does not appear on TTY devices lacking a paper
|
|
tape punch.
|
|
|
|
VERSION: Release 24.
|
|
|
|
OBSERVATION: Running the HP contributed library program "HP 2000F BASIC
|
|
for DOS-M/DOS III" does not produce any console output when using terminal
|
|
driver DVR00 as required by the program. When using alternate terminal
|
|
driver DVR05, console output appears but console input does not work
|
|
properly.
|
|
|
|
CAUSE: DOS-M and DOS-III support two modes of console I/O: ASCII mode and
|
|
binary mode. ASCII mode appends carriage-return/line-feed characters on
|
|
output and strips them on input. Binary mode sends and receives bytes
|
|
exactly as supplied.
|
|
|
|
DVR00 is required because DVR05 does not support the binary I/O mode
|
|
required by the program. However, DVR00 assumes that a binary write is to
|
|
be directed to the console's paper tape punch rather than the console
|
|
printer and therefore sets the TTY interface's "punch flip-flop" instead of
|
|
the "print flip-flop" to accompany the text output. The simulation of the
|
|
HP 12531 interface card associated with the TTY device discards output if
|
|
the punch flip-flop is set and the punch unit (TTY2) is not attached.
|
|
|
|
The problem occurs because only a connected HP 2754 teleprinter (a modified
|
|
Teletype ASR35) reacts to the print and punch flip-flop signals. All other
|
|
supported terminal devices ignore the signals and print whatever output is
|
|
supplied (an HP 2752 -- a rebadged ASR33 -- has a manual control for the
|
|
punch, but the punch and printer operate together when the punch is on).
|
|
The 2000F BASIC program apparently was designed for use with one of these
|
|
other terminals, which print normally even though only the punch flip-flop
|
|
is set.
|
|
|
|
RESOLUTION: Modify "tto_out" (hp2100_stddev.c) to honor the print and
|
|
punch flip-flop settings and separate the output as directed only if the
|
|
console punch unit is attached (simulating an HP 2754). When the unit is
|
|
detached, all output is delivered to the console printer, regardless of the
|
|
flip-flop settings (simulating all other console devices).
|
|
|
|
STATUS: Fixed in Release 25.
|