                           SIMH/HP 2100 RELEASE NOTES
                        ================================
                        J. David Bryan <jdbryan@acm.org>
                             Last update: 2021-04-30


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 31, 2021-04-30
======================

This release of the HP 2100 simulator adds the following features:

 - A new PAUSE command has been added to suspend command file execution for a
   user-specified time period.

 - The RUN and GO commands have been enhanced to provide execution for a
   user-specified (realistic) time or a specified number of event ticks.

 - The DELAY option for the BREAK, REPLY, RUN UNTIL, and GO UNTIL commands may
   now specify a (realistic) time period for the delay.

 - The IF command takes a new -E switch to indicate that the quoted strings
   should be parsed for escape sequences (i.e., that begin with a backslash).

 - Read-only and write-only devices, such as the paper tape reader and line
   printer, may now be attached to FIFO (pipe) files on Unix systems, allowing
   simulator input or output to be produced or consumed by external programs.

 - New POWER FAIL and POWER RESTORE commands have been added to permit the CPU
   and other devices to execute power-fail and recovery routines.

 - Simulations of the 12588A/12944B/12991B Power Fail Recovery Systems have been
   added to the CPU device.

 - New SET CPU ARS/NOARS commands have been added to the CPU device to enable or
   disable automatic restart after power restoration.

 - The new SERV trace option has been added to the CPU device to trace power
   failure halts.

 - The LPS device simulation has been rewritten to support compact and expanded
   output modes, manual paper movement commands, more extensive presentation
   of interface and printer hardware registers, and better tracing of internal
   operations.  Operation also now adheres more closely to the HP 2767A
   hardware.  In particular, overprinting is now supported.

 - New SET LPS TOF and PAPERSTEP commands have been added to perform manual
   top-of-form and single-step paper movements.  A new SET LPS MASTERCLEAR
   command manually clears the printer controller.  These commands correspond to
   switches provided by the printer hardware.

 - The HP 12972C 8-channel terminal multiplexer (MPX) now writes characters
   about 20% faster in FASTTIME mode.  Output speed is also about 35% faster
   when using ENQ/ACK handshaking in REALTIME mode.

 - The REALTIME/FASTTIME mode of the MPX device have been moved from the
   individual units to the device, and new LOCALACK/REMOTEACK options have been
   added to select local or remote handling of ENQ/ACK handshaking on a per-port
   basis.

 - Trace options for the MPX device have been overhauled.  A new CMD trace
   option now decodes and reports all commands and parameter options that pass
   between the RTE multiplexer driver and the device, and a new INCO trace
   option reports all command initiations and completions.

 - BACI real-time output performance with ENQ/ACK handshaking has been improved
   by 740% (time to list a specific file reduced from 199 seconds to 27 seconds,
   measured with a Reflection Telnet session as the client).

 - A new LOCALACK/REMOTEACK option has been added to the BACI device to select
   local or remote handling of ENQ/ACK handshaking independent of the existing
   FASTTIME/REALTIME setting.

 - Trace options for the BACI device have been overhauled.  A new CSRW trace
   option decodes all of the control and status words exchanged with the CPU.


--------------------
Implementation Notes
--------------------

 - In prior releases, the IF command always parsed quoted strings for escapes.
   This resulted in problems on Windows systems when pathnames containing
   backslashes caused parsing errors.  For example, IF EXIST "\hp\2100.data"
   would result in an "Invalid argument" error because of the invalid octal
   escape (value > 177 octal).  IF now does not parse for escapes unless the new
   -E switch is present.  This new behavior might require changes to existing
   command files.

 - The external end of a FIFO (pipe) file must be connected before a simulated
   device unit is attached.  Otherwise, erroneous console operation will result.

 - The simulator now passes the Power Fail/Auto-Restart diagnostic as described
   in the "hp2100_diag.txt" file.

 - The prior SET POWEROFF and SET POWERON options for the LPS and LPT devices
   have been removed.  Use POWER FAIL LPS and POWER RESTORE LPS, e.g., as
   replacements.

 - For convenience when running early HP operating systems where the HP 2767 is
   the only line printer supported, the LPS device is now enabled by default.
   This may cause a select code conflict if another device is configured to use
   the LPS default select code of 14.  An explicit SET LPS DISABLED command may
   be needed in this case.

 - ATTACHing a file to the paper tape reader (PTR device) now reports an error
   if the file does not exist.  Prior releases would create empty files if
   filenames were misspelled.

 - Part of the speed improvement of the MPX device is enabling FASTTIME mode for
   the on-board microprocessor controller, which is shared between all
   multiplexer ports.  As a result, it is no longer possible to set individual
   ports to REALTIME or FASTTIME mode; the mode now applies to the device as a
   whole.  However, per-port configuration of ENQ/ACK handling (local or remote)
   is maintained by the new LOCALACK/REMOTEACK unit options.  The simulator
   defaults to FASTTIME for the device and LOCALACK for each unit, retaining the
   same default behavior as in prior releases.  Changes from the default,
   though, may now require different SET MPX commands to achieve the desired
   results.

 - Local handling of ENQ/ACK handshaking that had been part of the BACI FASTTIME
   setting has been split out into its own option setting.  The simulator
   defaults to FASTTIME and LOCALACK, retaining the same default behavior as in
   prior releases.  Changing to REALTIME mode, though, may require an additional
   SET BACI REMOTEACK command if the prior real-time handshaking behavior is
   desired.

 - Under RTE, FASTTIME with LOCALACK output speeds of the available terminal
   devices are as follows (normalized to the output speed of the 8-channel
   multiplexer when connected via Telnet to a Reflection session):

     * MPX  =  1x
     * BACI =  3x slower
     * TTY  =  5x slower
     * MUX  = 28x slower

   These speeds reflect the designs of the underlying hardware.  The MPX device
   uses DCPC (DMA) to transfer characters in blocks between the CPU and the
   multiplexer buffers.  The BACI device is also buffered and transfers in
   blocks, but it uses I/O instructions instead of DCPC to transfer characters
   one-at-a-time.  The TTY device is unbuffered and transfers one character per
   driver interrupt.  The MUX is also unbuffered with one interrupt per
   character, but the main time loss is in the driver completion after each
   output line.  Because the MUX driver is privileged, completion is performed
   by setting the driver to time out after one TBG tick.  Because the TBG is
   calibrated and ticks at a 10 millisecond rate, no more than 100 driver
   completions can be accomplished in each second of wall-clock time.  This
   results in a severe performance penalty on fast host systems.

 - While the simulator has been passing the HP 2767A line printer diagnostic as
   described in the "hp2100_diag.txt" file, printed output did not conform to
   that described in the diagnostic manual.  This has been corrected.

 - In expanded mode, 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.

 - To implement power failure and restoration correctly, the actions of the
   RESET <device> and RESET -P <device> commands have changed slightly.  In
   prior versions, resetting a device would initialize the device and its
   associated interface card, while resetting with the -P switch would restore a
   device and interface to their power-on conditions.  In hardware, however, a
   device and its interface card are powered separately -- the former
   independently, and the latter by the CPU.  To bring the simulator into
   alignment with the hardware, resetting a device now only affects the device,
   while resetting the CPU affects both the CPU and all interface cards.  A
   RESET or RESET -P command that does not specify a device resets all devices,
   including the CPU, all interfaces, and all peripherals as before.

 - The internal interface between the CPU's I/O subsystem and the device
   simulators has changed.  In particular, the division of labor between a
   device's SCP reset routine and the power-on PRESET handler is no longer
   arbitrary.  User-written device simulators will have to be modified; see the
   revisions to "The Third I/O Implementation" section of "The Evolution of the
   HP 21xx/1000 I/O Simulation" document for details.



----------
Bugs Fixed
----------

  1. PROBLEM:  IF with some pathname arguments can produce erroneous results.

     VERSION:  Release 30.

     OBSERVATION:  The IF EXIST command can be used to test for the existence of
     a filename.  However, if the filename contains a Windows path, the command
     can fail with an "Invalid argument" error without ever testing the file.
     For example:

       sim> if not exist "..\HP\2100\data" echo File does not exist!
       Invalid argument
       sim>

     A simple comparison can also fail with an error.  For example, assuming
     that the first substitution argument is "..\2100":

       sim> if "%1" == "" echo Path name is missing.
       Invalid argument

     The existence test can also produce erroneous results:

       sim> attach -n lpt .\newfile.txt
       sim> if not exist ".\newfile.txt" echo File does not exist!
       File does not exist!
       sim>

     CAUSE:  The IF command takes quoted strings as arguments.  Quoted strings
     are processed for escapes that start with backslash characters.  Windows
     paths contain subdirectory names separated by backslashes.  If the first
     character or characters of the next subdirectory or filename forms a valid
     escape, the escaped value will be substituted before the file existence
     test, resulting in a failing test.  If the characters form an invalid octal
     escape, i..e, resulting in a value > 177 octal, an "Invalid argument" error
     occurs.

     RESOLUTION:  Modify "parse_quoted_string" (sim_extension.c) to accept an
     "escape" argument that indicates whether escape substitution is to be
     performed on the quoted string.  Modify "ex_break_cmd" and "ex_reply_cmd"
     to pass TRUE for the escape argument.  Modify "ex_if_cmd" to pass TRUE if
     the new "-E" switch was present or FALSE if it was not.

     STATUS:  Fixed in Release 31.


  2. PROBLEM:  Concurrent DO following RUN/GO <pc> jumps to <pc> on resumption.

     VERSION:  Release 30.

     OBSERVATION:  A DO command may be entered in concurrent mode to execute a
     series of commands stored in a file.  When the command is entered,
     execution is suspended while each command in the file is performed and then
     resumed when the command file is exhausted.  However, if execution was
     started with a RUN or GO command that specified a new program counter
     value, execution will resume at that location rather than at the location
     where suspension occurred.  An example illustrates the problem:

       HP 2100 simulator V3.11-2 Release 30

       sim> deposit 0   JMP 100
       sim> deposit 1-7 NOP
       sim> deposit 10  JMP 0

       sim> deposit P 0
       sim> step

       Step expired, P: 00010 (JMP 0)
       sim> step

       Step expired, P: 00000 (JMP 10)
       sim> step

       Step expired, P: 00010 (JMP 0)
       sim> step

       Step expired, P: 00000 (JMP 10)
       sim>

     As can be seen, the two program instructions jump between locations 0 and
     10.  Starting execution with:

       sim> go 3

     ...causes the simulator to execute the no-operation instructions at
     locations 3 through 7, and then jump between locations 10 and 0 repeatedly.

     Now, given a command file "halt.sim" that contains:

       deposit 5 HLT 0
       set console debug=stdout
       set cpu debug=instr

     ...then issuing a DO command to perform the deposit should not affect
     simulator execution, because the halt instruction is bypassed by the jumps,
     and the instruction trace should show only the repeated jumps.  However:

       scp> do halt.sim

       Debug output to "STDOUT"
       >>CPU instr: - 0000 00003  000000  NOP
       >>CPU instr: - 0000 00004  000000  NOP
       >>CPU instr: - 0000 00005  102000  HLT 0
       >>CPU instr: - 0000 00005  102000  simulation stop: Programmed halt

       Programmed halt, T: 102000 (HLT 0), P: 00006 (NOP)
       sim>

     CAUSE: After stopping execution to perform the DO command, the run handler
     routine is reentered with the original command ("GO 3") rather than simply
     continuing.  In this case, the program counter is reset before execution
     continues.  Moreover, if the original command was RUN, all devices would be
     reset before execution continued, destroying the existing device state.

     RESOLUTION:  Modify "ex_run_cmd" (sim_extension.c) to change the command to
     CONTINUE before execution is resumed following a concurrent DO.

     STATUS:  Fixed in Release 31.


  3. PROBLEM:  Listing a disc file to a MUX terminal eventually hangs.

     VERSION:  Release 30.

     OBSERVATION:  When running a privileged RTE system, listing a long file on
     a 7920 disc with the FMGR "LI" command will produce output for a while and
     then hang.  Doing "EQ,1" shows that the disc drive is busy.  Stopping and
     resuming simulation will resume output for a while longer before the
     listing hangs again.

     A trace of the DS device shows that the hang occurs when a seek completes
     before the driver issues an STC to enable the seek completion interrupt
     just before exiting.  The trace log ends with:

       >>DS  serv: Unit 0 delay 3 service scheduled
       >>DS  rwsc: Unit 0 position 8293888 seek command initiated
       >>DS  serv: Unit 0 delay 100 service scheduled
       >>DS  rwsc: Unit 0 seek command completed
       >>DS iobus: Received data 000000 with signals STC | SIR | IEN
       >>DS  cmds: [STC] Control set
       >>DS iobus: Received data 000000 with signals ENF | SIR | IEN
       >>DS iobus: Returned data 000000 with signals (none)
       >>DS iobus: Returned data 000000 with signals (none)

     As can be seen from the IOBUS trace, the "ds_interface" routine is being
     called recursively.

     CAUSE:  In an unprivileged system, the driver executes an STC to enable
     interrupts and exits shortly after issuing the seek command.  When the seek
     completes, the drive sets its Attention bit, and the resulting interrupt
     reenters the driver to continue with the read or write call.

     In a privileged system, however, the driver executes with the interrupt
     system on and the privileged interrupt fence holding off interrupts until
     the driver exits.  If a privileged interrupt (in this case, from the
     terminal multiplexer) occurs while the disc driver is executing, control is
     transferred to the MUX driver.  Depending on the length of time spent in
     the MUX driver, seek completion can occur while that driver is executing,
     and the Attention interrupt will be pending when the disc driver regains
     control and executes its STC.

     In simulation, the Attention interrupt is treated as an asynchronous event,
     and so "io_assert_ENF" is called in the "poll_drives" routine to ensure
     that the interrupt is registered.  In an unprivileged system, and most of
     the time in a privileged system, the disc driver will have executed the STC
     and exited before the seek completes, and the "io_assert_ENF" call is
     needed to register the interrupt.  However, if the driver is delayed due to
     a privileged interrupt, then the assert call is made within the
     "ds_interface" routine that is processing the STC.

     This causes the recursive call, and while the return from the inner call
     correctly sets the interrupt request (because the control, flag buffer, and
     flag flip-flops are now all set), it is suppressed because the privileged
     interrupt fence is holding off PRH to the interface.  But then the return
     from the outer call clears the interrupt because at the time of the STC
     call, the flag and flag buffer had not been set by the poll.  Consequently,
     the seek completion interrupt never occurs, and the listing suspends on the
     incomplete disc read call.

     Stopping and restarting the simulator sends ENF and SIR to all devices as
     part of the instruction prelude, which reestablishes the interrupt request
     and allows the driver to complete.  This resumes the listing until another
     privileged interrupt allows a seek to complete before the disc driver has
     exited.

     The problem is, however, generic.  Several devices have interfaces that may
     set their flags in response to interface actions, such as STC or IOO.  Any
     such action will result in a recursive call that may lose interrupts.

     RESOLUTION:  Modify the "IO_TABLE" definition (hp2100_cpu.c) to add an
     "active" flag and a "deferred_set" of inbound signals, and modify
     "io_dispatch" to detect recursive calls and to defer the second call until
     the first completes.  This changes a recursive call into a pair of
     sequential calls.  After the change, the resulting trace now shows:

       >>DS  rwsc: Unit 0 seek command completed
       >>DS iobus: Received data 000000 with signals STC | SIR | IEN
       >>DS  cmds: [STC] Control set
       >>DS  rwsc: Controller polled drives for attention
       >>DS  rwsc: Unit 0 requested attention
       >>DS iobus: Assertion of signals ENF | SIR deferred
       >>DS iobus: Returned data 000000 with signals (none)
       >>DS iobus: Received data 000000 with signals ENF | SIR | IEN
       >>DS iobus: Returned data 000000 with signals (none)

     STATUS:  Fixed in Release 31.


  4. PROBLEM:  Break key does not stop long output on the 8-channel multiplexer.

     VERSION:  Release 30.

     OBSERVATION:  Attempting to interrupt a long output to an 8-channel
     multiplexer (MPX) port in FASTTIME mode with the Break key doesn't work.
     For example, while using FMGR to list a >1000 record relocatable library
     file to the terminal, pressing Break does not stop the listing and print
     the Multi-Terminal Monitor prompt.  In multiple attempts, most of the time
     the prompt will appear only after the last record is output and before the
     FMGR prompt reappears.  In a small number of cases, the MTM prompt will
     appear but only after several hundred more records are printed.

     Enabling tracing on the MPX device shows that the Break key is being
     detected as soon as it is pressed.  This should queue an "unsolicited
     interrupt" in the MPX that will notify the RTE driver the next time an
     "Enable Unsolicited Interrupts" command is received.  The driver sends this
     command just before exiting the driver continuation section, so the Break
     notification interrupt should be delivered at that point.  However, the
     trace shows that a "Disable unsolicited interrupts" command, indicative of
     RTE driver reentry, is received before the unsolicited interrupt is
     generated.

     CAUSE:  The "Enable Unsolicited Interrupts" command is sent to the MPX by
     an OTA and an STC from the driver just before the driver exits back to RTE.
     In response, MPX schedules the command on the controller unit using a delay
     of 631 event ticks to represent the hardware microprocessor controller
     overhead.  When the event expires, the controller service completes the
     command and schedules a status check with another delay of 631 event ticks.
     When that event expires, the controller service routine sees the Break
     detection and generates the Unsolicited Interrupt to inform the driver that
     the Break key has been pressed.

     In REALTIME mode, the write buffer is sent to the Telnet port one character
     at a time, with 1646 event ticks between character transmissions at 9600
     baud.  FMGR takes only about 500-600 event ticks from the driver return to
     send another output request to the terminal, so the MPX is continually
     waiting for a write buffer to empty before completing each request.  While
     it is waiting, the Break request can be recognized.

     In FASTTIME mode, the write buffer is sent in a single operation between
     one event tick and the next, so the driver always completes write
     operations without waiting for a free buffer.  However, controller timing
     delays are not adjusted for FASTTIME mode, so FMGR will output the next
     line before the scheduled status check can discover the Break.  As a
     result, the "Disable unsolicited interrupts" command that is issued at
     driver entry preempts the Break notification.  Only when all of the records
     are printed is the controller idle long enough for the Break interrupt to
     be recognized.

     RESOLUTION:  Add a new "times" array that contains both real and fast
     timing delays for the controller unit and add a new "activate_unit" routine
     (hp2100_mpx.c) that selects between the times for controller service
     scheduling.

     Also, change the "mpx_mod" table to move the REALTIME/FASTTIME option from
     the individual port units to the device, as the controller timing is shared
     between all multiplexer ports, and add a new REMOTEACK/LOCALACK unit option
     to retain ENQ/ACK handshaking as a per-port option.

     STATUS:  Fixed in Release 31.


  5. PROBLEM:  MPX FASTTIME mode does not change the event service times.

     VERSION:  Release 30.

     OBSERVATION:  The description of the 8-channel multiplexer FASTTIME option
     in the "HP 2100 Simulator User's Guide" says that, "Optimized timing
     reduces the [transmission and reception] timing to the minimum necessary to
     operate correctly...," but actually this does not occur.  The MPX device
     uses the same event delays for a given baud rate, regardless of the
     REALTIME/FASTTIME setting.

     The apparent improvement in output speed in FASTTIME mode is due solely to
     transferring data to the Telnet port in blocks, rather than character by
     character.  This can be seen by timing the output after selecting a slow
     (e.g., 110) baud rate for the port and comparing the output time for the
     same output at 9600 baud.  In FASTTIME mode, there should be no difference,
     but there is.

     CAUSE:  FASTTIME mode does implement the mentioned optimization but does
     not change the character I/O timing delays.

     RESOLUTION:  Modify "line_service" and "poll_service" (hp2100_mpx.c) to use
     a single optimized event delay for character I/O in FASTTIME mode,
     regardless of the baud rate selected.

     STATUS:  Fixed in Release 31.


  6. PROBLEM:  BACI FASTTIME mode does not change the event service time.

     VERSION:  Release 30.

     OBSERVATION:  The description of the Buffered Asynchronous Communications
     Interface FASTTIME option in the "HP 2100 Simulator User's Guide" says
     that, "Enabling optimized timing with the FASTTIME option reduces the
     timing to the minimum necessary to operate correctly...," but actually this
     does not occur.  The BACI device uses the same event delays for a given
     baud rate, regardless of the REALTIME/FASTTIME setting.

     The apparent improvement in output speed in FASTTIME mode is due solely to
     transferring data to the Telnet port in blocks, rather than character by
     character.  This can be seen by timing the output after selecting a slow
     (e.g., 110) baud rate for the port and comparing the output time for the
     same output at 9600 baud.  In FASTTIME mode, there should be no difference,
     but there is.

     CAUSE:  FASTTIME mode does implement the mentioned optimization but does
     not change the character I/O timing delays.

     RESOLUTION:  Modify "line_service" and "poll_service" (hp2100_baci.c) to
     use an optimized event delay for character I/O in FASTTIME mode, regardless
     of the baud rate selected.

     STATUS:  Fixed in Release 31.


  7. PROBLEM:  Binary reads on the BACI device generate interrupts continuously.

     VERSION:  Release 30.

     OBSERVATION:  The RTE driver for the BACI device (DVR05) supports HP
     terminals with integrated cartridge-tape units.  The CTUs are often
     configured as the system binary input and output devices.  If an
     inadvertent binary read is issued to one of the CTUs, the BACI device
     generates interrupts continuously, crippling RTE performance.

     CAUSE:  In hardware, the only modem status line connected between the 264x
     terminal and the BACI via the 12966-60008 cable is RI (Ring Indicator), but
     this input is actually connected to the terminal's RTS line.  This
     connection is used during binary reads; when an end-of-record indication
     occurs, the terminal momentarily drops the RTS line.  DVR05 programs the
     card to interrupt when RTS drops to detect this EOR condition.

     BACI modem status interrupts are not "ones-catching."  Instead, the
     interrupt condition must be disabled to prevent a second interrupt for the
     same status change.  DVR05 does not do this because it expects the change
     to be momentary.  However, modem status is not simulated in terminal mode,
     and the resulting permanent "RI off" condition results in continuous
     interrupts when the BACI is programmed to detect the drop.

     RESOLUTION:  Modify "update_status" (hp2100_baci.c) to set the RI input
     status line always active when the card is in terminal mode.

     STATUS:  Fixed in Release 31.


  8. PROBLEM:  The DEPOSIT LPT OVPCHR '@ command deposits ' not @.

     VERSION:  Release 30.

     OBSERVATION:  Specifying an implied character operand for the line
     printer's OVPCHR register results in the wrong value being stored:

       sim> DEPOSIT LPT OVPCHR '@
       sim> EXAMINE -A LPT OVPCHR
       OVPCHR: '''

     The same command for a different register produces the expected result:

       sim> DEPOSIT LPT OUTPUT '@
       sim> EXAMINE -A LPT OUTPUT
       OUTPUT: '@'

     Section 2.2.2, "Symbolic Display and Entry," of the "HP 2100 Simulator
     User's Guide" says, "In the absence of a mode switch or a specified
     symbolic default, entering values with a leading ' (apostrophe) implies
     -A...."  There is no definition of a "specified symbolic default" in the
     manual, but identical commands should be parsed identically.

     CAUSE:  The "parse_sym" routine uses a register's internal format flag, if
     present, to parse operands if an explicit format switch is not supplied.
     For the LPS device, the OVPCHR register specifies the REG_A flag, which is
     used to imply -A for entry, while the OUTPUT register specifies REG_X,
     which enables symbolic entry but otherwise does not imply a format.  If -A
     is specified, the first character (') is correctly used as the operand
     value.  However, the user cannot see the internal flag and so has no way of
     knowing what flags are present on what registers, leading to confusing
     results.

     RESOLUTION:  Modify "parse_sym" (hp2100_sys.c) to ignore the hidden
     register format flags when assessing operand parsing implications, and
     remove the "specified symbolic default" wording from the manual.  Only use
     an explicit format switch or an implied leading character to establish the
     parsing mode.

     STATUS:  Fixed in Release 31.


  9. PROBLEM:  DS has an undocumented "u3" register.

     VERSION:  Release 30.

     OBSERVATION:  The "HP 2100 Simulator User's Guide" describes a DS device
     register named CYL, but doing "EXAMINE DS STATE" lists no register with
     that name.  Instead, there is an undocumented register named "u3".

     CAUSE:  CYL is a macro alias for "u3".  The register definition uses the
     same name and so is substituted during compilation.

     RESOLUTION:  Modify the disc library (hp2100_disclib.c/h) to change the
     internal alias from upper case to title case (e.g., from CYL to Cyl).

     STATUS:  Fixed in Release 31.



======================
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.
