HP 2100 Simulator Fixes
                             =======================


INCORPORATED FIXES
------------------

The following modifications have been incorporated into the global code base and
released to the public:


  1. PROBLEM:  Booting from magnetic tape reports "HALT instruction, P: 77756
     (000400)".  However, [77755] is HLT 77 (102077), [77756] is ALF,ALF
     (001727).

     VERSION:  3.2-0

     OBSERVATION:  The value 000400 is supposed to be "ALF,ALF", i.e., the
     decoded memory value at P.

     CAUSE:  "fprint_stopped" in "scp.c" calls "cpu_ex" in "hp2100_cpu.c", which
     calls "dms_cons" to display the virtual (logical) address.  However, at the
     halt in the mag tape boot loader, DMS is not enabled, so the map registers
     are meaningless (they happen to be zeros, so the access is to physical
     address 001756).

     RESOLUTION:  Alter "dms_cons" in "hp2100_cpu.c" to condition DMS mapping on
     "dms_enb".

     STATUS:  Fixed in version 3.2-1.



  2. PROBLEM:  Terminal output from RTE is indented three spaces, e.g., "START
     RECONFIGURATION" appears as "   START RECONFIGURATION", and the "- " prompts
     after answering "YES" to "I/O RECONFIGURATION?" do not appear.

     VERSION:  3.2-0

     OBSERVATION:  Use of a debugger reveals that the output sequence to the TTY
     is <nul><nul><nul>- <cr><nul><nul><nul><nul><nul><lf>.

     CAUSE:  RTE is outputting nulls to allow the (physical) TTY carriage time to
     move, but these are overwriting the prompt character in the simulation (note
     that a real TTY absorbs nulls, i.e., they don't affect the printed output).
     The TTY emulator should strip nulls from output to console.

     RESOLUTION:  Alter "tto_out" in "hp2100_stddev.c" to suppress nulls sent to
     the TTY printer.

     STATUS:  Fixed in version 3.2-1.



  3. PROBLEM:  Completing the reconfiguration and exiting hangs the system after
     printing the first few characters of the output line.  RTE is stuck in a
     loop in $CIC.

     VERSION:  3.2-0

     OBSERVATION:  At the entry to $CIC (system map address 43221), RTE uses the
     undocumented instruction "SFS 0,C" to both test and turn off the interrupt
     system.  This is confirmed in the "RTE-6/VM Technical Specifications" manual
     (HP 92084-90015), section 2.3.1 "Process the Interrupt", subsection "A.1
     $CIC":

       "Test to see if the interrupt system is on or off. This is done with the
        SFS 0,C instruction. In either case, turn it off (the ,C does it)."

     ...and in section 5.8, "Parity Error Detection":

       "Because parity error interrupts can occur even when the interrupt system
        is off, the code at $CIC must be able to save the complete system status.
        The major hole in being able to save the complete state is in saving the
        interrupt system state. In order to do this in both the 21MX and the 21XE
        the instruction 103300 was used to both test the interrupt system and
        turn it off."

     CAUSE:  The simulator does not respond to the "H/C bit" on the "SFS 0"
     instruction, so the interrupt system is not turned off.

     RESOLUTION:  Modify "hp2100_cpu.c" and the various devices to respond to the
     "H/C bit" on the "SFS" and "SFC" instructions, and modify "hp2100_sys.c" to
     decode the "H/C bit" on those instructions (note that while the
     documentation refers specifically only to "SFS 0", the schematics of the
     21MX appear to indicate that the bit will work on any SFS instruction -- and
     the SFC instruction too, for that matter).

     STATUS:  Fixed in version 3.2-1.



  4. PROBLEM:  RTE sits in the idle loop.  TBG/TTY interrupts are not occurring,
     so "SET TIME" is not output.

     VERSION:  3.2-0

     OBSERVATION:  The memory protect flag is set, inhibiting all lower-priority
     interrupts, such as the TBG and TTY.  If the MP flag is cleared manually,
     RTE prints "SET TIME" and comes up sufficiently to respond to operator
     attention commands.  The system time is seen to increment properly.

     Unlike most other I/O devices, the MP flag flip-flop is cleared
     automatically when the interrupt is acknowledged and not by a programmed
     instruction (CLF and STF affect the parity error enable FF instead).
     Section 4.4.3 "Memory Protect and I/O Interrupt Generation" of the "HP 1000
     M/E/F-Series Computers Engineering and Reference Documentation" (HP
     92851-90001) says:

       "When IAK occurs and IRQ5 is asserted, the FLAGBFF is cleared, FLAGFF
        clocked off at next T2, and IRQ5 will no longer occur."

     CAUSE:  The MP flag flip-flop is not being cleared automatically when the
     interrupt is acknowledged.

     RESOLUTION:  Modify "hp2100_cpu.c" to reset the MP flag on IAK5.

     STATUS:  Fixed in version 3.2-1.


     OBSERVATION:  The MEV flag indicates the source of the interrupt (set for
     DMS violation, clear for MP violation).  If this is tested with a SFS or SFC
     instruction after an MP interrupt, it is observed that DMS interrupts are
     not being indicated properly.  SFS 05 never skips.

     CAUSE:  The MP flag is being used to condition the response for SFS 05 and
     SFC 05.  Examination of the schematics for the MP card in the engineering
     documentation shows that the SFS and SFC I/O backplane signals gate the
     output of the MEVFF onto the SKF line unconditionally.

     RESOLUTION:  Modify "hp2100_cpu.c" to remove conditioning on MP flag for SFS
     05, SFC 05.

     STATUS:  Fixed in version 3.2-1.



  5. PROBLEM:  Attempting to run any program causes a DM violation.

     VERSION:  3.2-0

     OBSERVATION:  BCKOF is scheduled when the system starts and is the first
     program to DM abort.  Examining the DMS maps seems to indicate that the user
     and system maps are set up reasonably.  However, examining memory with
     the "ex -u" and "ex -s" commands reveals the same data in both sets of
     locations.  The "ex" command isn't using the DMS maps properly.

     CAUSE:  String constants are used instead of character constants,
     preventing the DMS map switches from being recognized.

     RESOLUTION:  Modify "hp2100_cpu.c" to use character constants rather than
     string constants in "dms_cons" so that DMS map switches work correctly.

     STATUS:  Fixed in version 3.2-1.


     OBSERVATION:  The DM abort is occurring when JSB EXEC is done from a user
     program.  The EXEC target is below the MP fence, and the expected action is
     an MP violation interrupt that is recognized and processed by the system as
     a legal call to the system executive.  However, the MP violation isn't
     occurring, so the SJP instruction at the actual EXEC entry point (present
     to catch EXEC calls made with the interrupt system off) is attempted, and
     that causes the DM violation, due to execution of a protected instruction
     from the user map.

     CAUSE:  Memory writes aren't being checked for an MP violation if DMS is
     enabled, i.e., if DMS is enabled, and the page is writable, then whether
     the target is below the MP fence is not checked.

     RESOLUTION:  Modify "hp2100_cpu.c" to do MP check on all writes after DMS
     translation and violation checks are done (so, to pass, the page must be
     writable AND the target must be above the MP fence).

     STATUS:  Fixed in version 3.2-1.



  6. PROBLEM:  The "WHZAT" program isn't showing the current time, program type,
     priority, etc.

     VERSION:  3.2-0

     OBSERVATION:  Running the program with "RU,WHZAT" shows that the current
     time (etc.) is simply missing, as though zero-length strings are being
     written, or all characters in the string are being written to the same
     location.

     CAUSE:  The SBT instruction isn't incrementing the B register, so all
     characters are being overwritten.

     RESOLUTION:  Modify the processing of the SBT instruction in "hp2100_cpu.c"
     to increment B.

     STATUS:  Fixed in version 3.2-1.



  7. PROBLEM:  The simulator may abort with an access exception when examining
     memory.

     VERSION:  3.2-0

     OBSERVATION:  If DMS is enabled but a map register contains a page greater
     than defined memory, attempting to examine the logical address corresponding
     to that page register causes an access exception.

     CAUSE:  The "cpu_ex" and "cpu_dep" routines attempt to prevent this, but the
     validation is being made on the logical, not the physical address.

     RESOLUTION:  Modify "cpu_ex" and "cpu_dep" in "hp2100_cpu.c" to check the
     physical addresses against the physical memory limit.

     STATUS:  Fixed in version 3.2-1.



  8. PROBLEM:  Pressing a key during output does not give an RTE prompt.

     VERSION:  3.2-0

     OBSERVATION:  Running, e.g., WHZAT and pressing a key during the listing
     does not interrupt the system as expected.  Pressing a key when the system
     is idle does give a prompt.

     CAUSE:  Detection of key presses during output is accomplished by DVR00 with
     the 12531C card by reading the data register after output is complete.  If
     no key was pressed, the register will have the value of 377 octal.  If a key
     was pressed, the value will be something other than this.  SIMH is not
     passing the keystrokes into the output data register.

     RESOLUTION:  Modify tty routines in "hp2100_stddev.c" to simulate the shift
     of a character into the data register concurrently with an output operation.

     STATUS:  Fixed in version 3.2-1.



  9. ENHANCEMENT:  Programmed halt should report the halt code (i.e., the numeric
     HLT instruction).

     VERSION:  3.2-0

     OBSERVATION:  When a programmed halt occurs on the actual 21MX, the T
     register (current memory contents) is automatically selected on the CPU
     front panel.  The T register displays the numeric HLT instruction.  Many HP
     programs communicate program status via the numeric halt instruction codes
     themselves.  For example, a HLT 77 (102077) is universally used to mean
     "proper operation completed."  The mag tape boot loader, for instance, will
     HLT 11 (102011) if a checksum error is detected and HLT 00 (102000) if the
     mag tape status is anything unexpected.  The HP diagnostics also make
     extensive use of halt codes, and their numeric values are tabulated in the
     diagnostic manuals to correspond with certain results.

     Currently, the simulator displays only the P register value (which points to
     HLT + 1) and the contents of the memory location at P (which displays the
     instruction one beyond the HLT), e.g.:

       HALT instruction, P: 77756 (ALF,ALF)
       sim>

     This, however, fails to communicate the status implied by the HLT code,
     which must be obtained by entering "ex 77755" after the halt.

     RESOLUTION:  Modify "hp2100_sys.c" to make the halt status message a
     variable instead of a constant string, and modify "hp2100_cpu.c" to format
     the status message with the halt code, as follows:

       HALT instruction 102077, P: 77756 (ALF,ALF)
       sim>

     STATUS:  Fixed in version 3.2-1.



 10. ENHANCEMENT:  Add an M register (current pointer to memory) and a T register
     (contents of the memory location at P).

     VERSION:  3.2-0

     OBSERVATION:  The 21MX computer presents eight hardware registers: A, B, M,
     T, P, S, O, and E.  From the 21MX M-Series Computer Operating and Reference
     Manual (02108-90037):

       "The M-register hold the address of the memory cell currently being read
        from or written into by the CPU.

       "The data transferred into or out of memory is routed through the
        T-register.  When displayed, the T-register indicates the contents of the
        memory location currently pointed to by the M-register.  The A- or
        B-register contents are displayed if the M-register contents are 000000
        or 000001, respectively."

     However, the simulator does not expose these registers as part of the CPU
     state.  Internally, they are not needed, but the simulation user would
     expect to be able to view and set their contents, so they should be
     implemented.

     When the machine halts, the front panel microroutines display the T
     register after initiating a read of memory via the M register.  So T always
     reflects the contents of memory addressed by M.  For machine halts due to
     the front panel HALT button being pressed or due to execution of a HLT
     instruction not in an interrupt trap cell, M is set to P-1.  If, however,
     the machine halts due to the execution of a HLT instruction in an interrupt
     trap cell, M is set instead to the address of the trap cell (P still points
     to the next instruction to be executed).

     RESOLUTION:  Modify "hp2100_cpu.c" to add M and T registers to the CPU
     state.  T must be read-only, because there is no way to determine positively
     when a store into T has been done.

     STATUS:  Fixed in version 3.2-1.



 11. ENHANCEMENT:  Change the DMS map register contents to display and enter in
     the format as documented by the HP hardware manual.

     VERSION:  3.2-0

     OBSERVATION:  The simulated DMS map registers are stored in an internal
     format that does not correspond to the real DMS hardware.  Specifically, the
     physical page address is shifted left by ten bits, and the read- and
     write-protect bits are in bits 1-0 rather than 15-14.  This is done for
     performance reasons and is reasonable and proper.  However, this internal
     format is exposed as the external representation, which is unfamiliar to the
     simulation user.  The user expects to be able to view and set the DMS map
     registers in the same format as the real machine.

     RESOLUTION:  Modify "hp2100_cpu.c" and "hp2100_defs.h" to use the documented
     format.

     STATUS:  Fixed in version 3.2-1.



 12. ENHANCEMENT:  Provide map-specific simulation breakpoints.

     VERSION:  3.2-0

     OBSERVATION:  When DMS is enabled, separate address spaces exist for system
     and user programs.  In debugging, one may have to set breakpoints in either
     address space.  Currently, breakpoints are map-agnostic, i.e., only the
     address needs to match.  This leads to the potential for breaking when not
     intended and can be frustrating if, for example, the desired user-mode break
     location happens to correspond with the TBG handling code in the system.

     RESOLUTION:  Modify "hp2100_cpu.c" to add map-specific breakpoints.

     STATUS:  Fixed in version 3.2-1.



 13. ENHANCEMENT:  Rename the F register to MPFR.

     VERSION:  3.2-0

     OBSERVATION:  There is no F register defined in the 21MX register set.  Its
     name is confusing to the new simulation user.  Moreover, there is an MPVR
     (memory protect violation register), but the memory protect fence register
     appears to be missing.  Renaming makes the exposed register set more
     consistent with HP nomenclature.

     RESOLUTION:  Modify "hp2100_cpu.c" to change the name of the register from
     "F" to "MPFR", and move the location in the CPU state to precede the memory
     protect violation register "MPVR", so that these two MP-related values
     appear together.

     STATUS:  Fixed in version 3.2-1.



 14. ENHANCEMENT:  Rename the IADDR register to CIR.

     VERSION:  3.2-0

     OBSERVATION:  The address of the currently interrupting device is contained
     in the Central Interrupt Register (CIR) in HP documentation.  Renaming makes
     the exposed register set more consistent with HP nomenclature.

     RESOLUTION:  Modify "hp2100_cpu.c" to change the name of the register from
     "IADDR" to "CIR".

     STATUS:  Fixed in version 3.2-1.



 15. PROBLEM:  Under RTE, the backspace key deletes the entire line, rather than
     just the last character entered.

     VERSION:  3.2-0

     OBSERVATION:  Pressing the backspace key should delete the last character
     entered.  Pressing the DEL key (CTRL+BACKSPACE) should delete the entire
     line.  RTE is behaving as though DEL were being sent when the backspace key
     is pressed.

     CAUSE:  The simulator is unconditionally translating backspace (CTRL+H) to
     DEL (CTRL+BACKSPACE), ostensibly for the convenience of some DEC operating
     system.

     STATUS:  Fixed in version 3.2-1.



 16. ENHANCEMENT:  Provide a settable "auto linefeed" mode so that the TTY will
     follow each CR with LF (DSGEN and DOS itself require that lines end with CR
     and LF, contrary to RTE, which uses CR only).

     VERSION:  3.2-0

     OBSERVATION:  Always following ENTER with CTRL+J is awkward.  An "AUTO LF"
     mode is desirable.

     RESOLUTION:  Implement a "SET TTY AUTOLF" command to implement "auto
     linefeed" mode.

     STATUS:  Fixed in version 3.2-1.



 17. PROBLEM:  Loading an absolute binary paper tape image with "BOOT PTR" causes
     the boot loader to hang.

     VERSION:  3.2-0

     OBSERVATION:  BOOT PTR looks for 12 feed frames (nulls) to signify EOT.  A
     real paper tape would have feed frames punched after the file data for a
     trailer.

     CAUSE:  At the end of the attached file, "ptr_svc" (hp2100_stddev.c) fails
     if STOP_IOE is set, otherwise silently does nothing.  SIMH wrongly requires
     that the feed frames appear in the attached file, rather than supplying the
     feed frames from the PTR simulation.  If they are not in the file, the
     simulation hangs, just as the real paper tape reader would do if the tape
     ran out.

     RESOLUTION:  Alter "ptr_svc" (hp2100_stddev.c) to fail if STOP_IOE is set,
     or to supply feed frames upon encountering the end of the attached file.
     "SET PTR TRLLIM" sets the maximum number of feed frames to supply.  Note
     that RTE needs at least 30 feed frames before signaling EOT.

     STATUS:  Fixed in version 3.2-1.



 18. PROBLEM:  The 7900 boot loader fails to load any data from the disc into
     memory.

     VERSION:  3.2-0

     OBSERVATION:  The loader completes, but memory is untouched.

     CAUSE:  There is a transcription error in the boot loader code.

     RESOLUTION:  Alter "dp_rom" (hp2100_dp.c) to change the erroneous "OTA 6,C"
     to the correct "SFS 6,C".

     STATUS:  Fixed in version 3.2-1.



 19. PROBLEM:  Using the DOS-III D2607 (DVR12) driver with the LPT (2607/12845)
     simulation results in garbled output.

     VERSION:  3.2-0

     OBSERVATION:  Doing an "ATTACH LPT 2607.printer" and then a ":JOB,FRED" in
     DOS results in the following:

       00000000  0C 0A 4A 4F 20 52 44 20-32 4D 59 37 20 54 4D 3D   ..JO RD 2MY7 TM=
       00000010  30 33 4D 4E 20 32 34 53-43 2E 4A 61 46 56 46 7F   03MN 24SC.JaFVF.
       00000020  7F 7F 7F 47 18 73 43 46-21 4D 09 1A 0B 31 1C 67   ...G.sCF!M...1.g
       00000030  0A                                                .

     ...instead of the expected:

       00000000  4A 4F 42 20 46 52 45 44-20 20 31 32 2D 4D 41 59   JOB FRED  12-MAY
       00000010  2D 37 35 20 20 54 49 4D-45 3D 31 30 35 33 20 4D   -75  TIME=1053 M
       00000020  49 4E 2E 20 33 32 2E 31-20 53 45 43 53 2E 0D 0A   IN. 32.1 SECS...

     CAUSE:  The intercharacter wait time is too long (1000 instructions).  The
     driver waits a maximum of 300 instructions before exiting to wait for the
     interrupt.  However, there is a bug in the driver that garbles output if the
     wait time expires.  It never does when using a real printer, so the bug
     wasn't seen.

     Note that the interline time (100 instructions) is actually shorter than the
     intercharacter time!  Also, the interline time appears to be set to the
     "serial output time," which bears no relation to the parallel line printer!

     RESOLUTION:  Change the intercharacter time to 5 instructions and the interline
     time to 10,000 instructions in hp2100_lpt.c.

     STATUS:  Fixed in version 3.2-1.



 20. PROBLEM:  Issuing a read on a magnetic tape for fewer words than are in the
     pending record (e.g., doing ":LI,8,B" when there are more than 128 words in
     the next record) results in a parity error ("IOPE L   8 E 8 S 0  22").

     VERSION:  3.2-0

     OBSERVATION:  FMGR only reads the first 128 words of a record.   Records
     longer than 256 bytes should be truncated when listing.  Instead, timing
     errors (status 22) are reported.  Records shorter than 128 words are listed
     properly.

     CAUSE:  DMA termination before the end-of-record is not being handled
     properly by the 7970E simulator.  The RTE driver sets up DMA control word 1
     with the STC bit (bit 15) clear and the CLC bit (bit 13) set.  The DMA
     transfer proceeds apace until DMA control word 3 (word count) goes to zero.
     At this point, the last cycle logic in "dma_cycle" (hp2100_cpu.c, lines
     2477-2480) issues a CLC to the mag tape data channel.  In "msdio"
     (hp2100_ms.c, lines 272-275), the command and control flags are cleared in
     response.

     The catch here is that the next I/O data transfer is still pending; it was
     set in "msc_svc" (hp2100_ms.c, lines 461-467) via "sim_activate", because
     there were still words in the buffer to transfer.  When that time expires,
     "msc_svc" is called again, and because the data flag is still set (the CLC
     to the data channel issued by DMA to end the transfer occurred _instead_ of
     the CLF that is issued between data transfers), the parity error and timing
     overrun bits are set into the return status at line 462 of hp2100_ms.c.

     RESOLUTION:  Alter "msc_svc" (hp2100_ms.c) to terminate a read if the
     control flip-flop is reset (by DMA termination).

     STATUS:  Fixed in version 3.2-1.



 21. PROBLEM:  Switching pending line edit modes (under EDIT or EDITR) by
     entering the appropriate control codes (e.g., CTRL+I or CTRL+C) print
     graphic characters that disrupt the one-for-one alignment needed for
     editing.

     VERSION:  3.2-1

     OBSERVATION:  Output of control characters that normally do not print or
     cause observable actions (e.g., CR or BEL) should be suppressed, so that
     simulated behavior mimics the action of a real terminal.

     CAUSE:  All characters except NULs are output by the TTY routine.

     RESOLUTION:  Alter "tto_out" (hp2100_stddev.c) to suppress output for all
     control characters (characters < 40 octal), except for BEL, BS, LF, and CR.

     STATUS:  Fixed in version 3.2-2.



 23. PROBLEM:  The documentation for the DMSMAP register set is wrong.

     VERSION:  3.2-1

     OBSERVATION:  "hp2100_doc.txt" says:

       CPU registers include the visible state of the processor as well as the
       control registers for the interrupt system.

       name           models    size  comments

       DMSMAP[4][16]  21MX      16    DMS maps

        should be:

       DMSMAP[4][32]  21MX      16    DMS maps

     ...as there are 32 map registers (1 per 1K page) per set.

     RESOLUTION:  Fix the text.

     STATUS:  Fixed in version 3.2-2.



 24. PROBLEM:  The documentation for the 7900 disc boot is wrong.

     VERSION:  3.2-1

     OBSERVATION:  "hp2100_doc.txt" says:

       The 12557A/13210A supports the BOOT command.  BOOT DPC copies the IBL
       for 7900 class disks into memory and starts it running.  BOOT -R DP
       boots from the removable platter (head 2).

     Entering "boot -r dp" gives "Non-existent device."  The correct command
     is "boot -r dpc".

     RESOLUTION:  Fix the text.

     STATUS:  Fixed in version 3.2-2.



 26. ENHANCEMENT:  For certain errors that stop the simulation, reset the PC to
     report the instruction causing the error, rather than reporting the next
     instruction.

     VERSION:  3.2-2

     OBSERVATION:  Some stops are triggered by the attempted execution of
     instructions.  In these cases, it is more helpful to report the instruction
     causing the error than the next instruction.  Currently, all stops report
     the instruction beyond the cause of the stop (i.e., "P + 1").  The table
     below indicates those stops where it would be more helpful to report the
     instruction causing the stop (i.e., "P"):

      PC       Code      Message Text
     =====  ===========  ====================================
       P    STOP_RSRV    Unimplemented instruction
       P    STOP_IODV    Non-existent I/O device
       P    STOP_IND     Indirect address loop
       P    STOP_NOCONN  No connection on interprocessor link

     RESOLUTION:  Before exiting "sim_instr" (hp2100_cpu.c), reset "PC" to
     "err_PC" for the above cases.

     STATUS:  Fixed in version 3.2-3.



 28. PROBLEM:  Booting 2000E TSB hangs after printing "READY".

     VERSION:  3.2-2

     OBSERVATION:  The code is stuck in a loop, waiting for the 7900 disc data
     channel flag to set.

     CAUSE:  To perform a disc read, the TSB disc driver issues a seek command
     but does not wait for seek completion before issuing the read command to the
     interface.  This is allowed by the interface manual.  The eventual
     interrupt signifies the completion of both the seek and the read commands.

     However, the "drive attention" flag that is normally generated at the end of
     the seek isn't set if the commands overlap in this manner.  When a read
     command is received with a seek in progress, the simulator cancels the seek
     timer and establishes a read timer of a longer duration in its place.  But
     the cancellation of the seek timer also cancels the setting of the "drive
     attention" bit that would have occurred had the seek completed normally, and
     the simulator doesn't supply it explicitly in this case.

     The HP "7900A Disc Drive Operating and Service Manual" (07900-90002) says,
     in section 4-67, "Attention is set high every time a seek has been
     completed and Access Ready comes high."

     TSB code loads the "drive attention" word from the command channel to create
     a "request status" command.  The code assumes that either bit 0 or bit 1
     will be set, so an "ADA =D-1" is done to transform the retrieved 000001 or
     000010 into 000000 or 000001, respectively.  This effectively becomes a
     "request status for unit 0/1" command, which is output to the drive as a
     command.

     However, the simulator bug causes the drive attention word to be 0, so the
     ADA makes the value 177777.  This is an illegal command, so the data channel
     flag never sets.

     RESOLUTION:  Alter "dp_goc" (hp2100_dp.c) to set drive attention when seek
     completion is simulated.

     STATUS:  Fixed in version 3.2-3.



 29. PROBLEM:  Running 2000/Access, the 7900 disc fails to format.

     VERSION:  3.2-2

     OBSERVATION:  The code is hung in a loop, waiting for a drive attention flag
     after the execution of an "Initialize Data" command.

     CAUSE:  The 13210A disc interface passes through attention flags that the
     drives generate as a result of seek completions.  However, the interface
     also generates its own drive attention flag at the conclusion of every
     command except "Status Check."  This internally generated flag is not being
     provided by the 7900 simulator.

     The schematics and flowcharts in the 13210A manual indicate that a local
     attention bit, derived from the unit number in the last command, is provided
     at the conclusion of every command issued except:

       * "Status Check" -- executing this command clears the attention bit.

       * "Seek" -- if the drive is not ready, then a local attention bit is
         provided immediately, else the attention bit from the drive is provided
         when the seek completes.

     RESOLUTION:  Alter (hp2100_dp.c) to provide the needed attention bits.

     STATUS:  Fixed in version 3.2-3.



 30. PROBLEM:  Booting 2000/Access reports "CAN'T USE TAPE" when loading from
     7970.

     VERSION:  3.2-2

     OBSERVATION:  No data is returned in response to reading the first tape
     record.

     CAUSE:  Rewind at BOT should return immediately but is not.  Access does not
     wait for rewind to complete, so it issues the read command while the
     transport is busy.  The command is rejected, so Access tries a CLEAR and
     then a retry, but a bug in Access causes DMA to be started after the CLEAR
     is sent.  When CLEAR completes, READ is attempted again, but DMA is not
     reset.

     Also, the simulator is processing rejected commands when STC CC,C follows a
     rejection.  This should be a NOP.

     RESOLUTION:  Change hp2100_ms.c to do immediate completion for REWIND at
     BOT and to NOP an STC CC,C after a command reject.

     Note that this "fixes" the problem as long as the tape is at load point when
     the Access bootstrap is run.  This would normally be the case, but it
     appears as though Access wouldn't work if the tape had to be rewound!

     STATUS:  Fixed in version 3.2-3.



 31. PROBLEM:  Running the 7970 diagnostic reports "Unit not attached, P: 02741
     (CLF 77)" when executing Test 0.

     VERSION:  3.2-2

     OBSERVATION:  The error is occurring in the basic I/O test for the command
     channel.  The test for the data channel is succeeding.

     CAUSE:  The diagnostic does a STC CC as part of the I/O test.  The last
     command sent was to the interface was SL3.  Unit selects are not supposed to
     be executed, but examination of the card schematics reveals that this will
     set the command FF and the card busy bit and take no further action.  The
     simulator, however, is scheduling an I/O event in response, and when the
     event occurs, unit 3 is not attached, so an error is reported.

     RESOLUTION:  Modify "mscio" (hp2100_ms.c) to not schedule an I/O event if
     the last command was a unit select.

     STATUS:  Fixed in version 3.2-3.



 33. PROBLEM:  Running the 7970 diagnostic reports a number of timing errors,
     with events taking longer or shorter than expected.

     VERSION:  3.2-2

     OBSERVATION:  The diagnostic times certain tape functions (e.g., the time
     from issuing a WRITE command until the first data is requested).  Most of
     these are reported as diagnostic failures.

     CAUSE:  I/O time modeling is not done properly.  In some cases, the times
     indicated are incorrect.  In others, certain characteristics (e.g., that
     operations from BOT take longer, due to the initial gap) aren't modeled at
     all.

     RESOLUTION:  Revise "mscio" and "msc_svc" (hp2100_ms.c) to model actual I/O
     timing characteristics correctly.

     STATUS:  Fixed in version 3.2-3.



 34. ENHANCEMENT:  Provide a method of selecting between realistic and fast
     (optimized) command execution times for the 7970 simulator.

     VERSION:  3.2-2

     OBSERVATION:  The 7970 diagnostic checks command execution times, so to
     pass, the simulator must model these times.  However, they are generally
     much longer than are required by the various operating systems.

     RESOLUTION:  Modify "hp2100_ms.c" to add SET MSC REALTIME, SET MSC FASTTIME,
     and SHOW MSC TIMING commands.  Timing is now set according to the timing
     and interface models in use.

     STATUS:  Fixed in version 3.2-3.



 35. ENHANCEMENT:  Provide a means of printing the internal state of the 7970
     tape simulator.

     VERSION:  3.2-2

     OBSERVATION:  Debugging tape errors would be easier if the tape interface
     commands and status were observable and recordable.  SIMH provides a "DEBUG"
     mode command set to allow devices to provide this information.

     RESOLUTION:  Modify "hp2100_ms.c" to add debug-mode calls.

     STATUS:  Fixed in version 3.2-3.



 36. PROBLEM:  The 7970 tape diagnostic fails Test 12, Subtest 4.

     VERSION:  3.2-2

     OBSERVATION:  Test 12 forces data and timing errors.  Execution reports:

       H154 UNIT 000000
       H102 RECORD 000103
       H054 COMMAND 000223
       H155 STATUS IS      1 000 100 010 000 010
       H155 AND SHOULD BE  1 000 000 010 010 010

       TEST  12
       E100 DATA OR ODD BYTE ERROR

     In test 12, step 3, a 100-word WRITE is interrupted after 64 words with a
     CLEAR command, followed by a WRITE FILE MARK.  The diagnostic manual says,
     "This procedure creates a record with a known parity error."  The simulator
     CLEAR command processing detects the write-in-progress and writes a
     simulated tape record with the MTR_ERF flag to indicate a bad record.

     In step 4, the records are backspaced, and a READ UNTIL FILE MARK command is
     issued without transferring any data.  This should set the timing error bit
     (bit 4) in the status word.  In the status word reported, it is not set.

     CAUSE:  The simulator implementation of the CLEAR command erroneously clears
     the data channel command FF.  When the READ UNTIL FILE MARK command is
     issued, no data transfer is attempted, so the timing error does not occur.

     RESOLUTION:  Modify the CLR command in "mscio" (hp2100_ms.c) to leave the
     data channel control and flag FFs untouched.

     STATUS:  Fixed in version 3.2-3.



 37. PROBLEM:  Running the RTE off-line disc backup program DBKUP and doing a
     save to tape with verify hangs after printing "VERIFYING."

     VERSION:  3.2-2

     OBSERVATION:  Using the 7970 debug mode reveals that the program does a
     rewind in preparation for verifying.  Then, after the command completes but
     while the rewind is in progress, a read is issued.  This is rejected due to
     REW + TBUSY being set (rewind still in progress).  After rejection, a clear
     is issued and completes.  At this point, the program appears to hang.

     CAUSE:  The RTE tape driver retries rejected commands by clearing the
     interface and reissuing the originally rejected command.  However, the
     simulator erroneously clears both command and data channel control FFs and
     sets both flag FFs in response to the CLR command.  Clearing the control FFs
     means that no completion interrupt is generated as a result of the CLR, so
     the driver is never reentered to reissue the rejected command, and the
     program stays in the I/O suspend state forever.

     RESOLUTION:  Modify the CLR command in "mscio" (hp2100_ms.c) to set both
     the command control and data FFs.

     STATUS:  Fixed in version 3.2-3.



 38. PROBLEM:  The 13183A (7970) simulator reports "odd byte" status when an EOF
     is detected.

     VERSION:  3.2-2

     OBSERVATION:  For the NRZI (13181A) interface, an EOF is a single special
     character in the data stream, so odd byte status is set when it is detected.
     For the PE (13183A) interface, EOF is an erasure pattern that is detected by
     the drive itself and communicated to the interface as a status line.  Odd
     byte status is not set when the 13183A interface indicates an EOF.

     CAUSE:  Odd byte status on EOF is not conditional on interface type.

     RESOLUTION:  Modify "ms_map_err" (hp2100_ms.c) to condition odd byte status
     with EOF on interface type.


     OBSERVATION:  The FSF and BSF processors in "msc_svc" treat EOF separately
     from other tape errors, but the separate code takes precisely the same
     action as does the generic error mapper.

     RESOLUTION:  Modify "msc_svc" (hp2100_ms.c) to remove the separate
     treatment and call the generic error mapper unconditionally.

     STATUS:  Fixed in version 3.2-3.



 39. PROBLEM:  The 7970 simulator does not report "odd byte" status when a tape
     record with an odd byte length is read.

     VERSION:  3.2-2

     OBSERVATION:  A tape record containing an odd number of bytes is read, but
     the odd byte status bit isn't set at completion of the read.

     CAUSE:  The RC and RFF processors in "msc_svc" are not testing for this
     condition.

     RESOLUTION:  Modify "msc_svc" (hp2100_ms.c) to set the odd byte status bit
     if the last record read contained an odd number of bytes and to zero the
     unused byte (as specified on page 4-11 of the 13181B manual).

     STATUS:  Fixed in version 3.2-3.



 40. PROBLEM:  The 7970 simulator fails Test 12, Subtest 2 when configured as a
     13183A interface.

     VERSION:  3.2-2

     OBSERVATION:  The test issues a RFF command and waits for the first data
     flag.  It then reads status in a loop and waits for the odd byte bit to set
     before continuing.  If this bit doesn't set within 65K iterations, the test
     fails.

     CAUSE:  The 13183A hardware passes the odd/even byte FF output through as
     the odd byte status bit, so this bit will be seen to toggle as data is
     received.  The simulator, by contrast, sets the odd byte flag only at the
     end of the transfer.  While the interface manual states that the odd byte
     status is only valid after the command flag FF sets, the diagnostic depends
     on seeing this bit toggle once during the transfer.

     The 13181A hardware enables the odd byte status bit only when the
     end-of-record is detected.  However, because odd byte status occurs when EOF
     is detected, the diagnostic test will still succeed, albeit at the end of
     the RFF command rather than at the beginning.

     RESOLUTION:  Modify "msc_svc" (hp2100_ms.c) to set the odd byte status bit
     at the beginning of the transfer if configured as a 13183A interface and
     then to set or clear it as appropriate at the end of the transfer.

     STATUS:  Fixed in version 3.2-3.



 41. ENHANCEMENT:  Add a configurable reel length setting to the 7970 simulator
     and provide end-of-tape status returns.

     VERSION:  3.2-2

     OBSERVATION:  The 7970 diagnostic provides an option to inhibit rewinds
     during test loops to allow the EOT status to be tested.  The simulated tape,
     however, is effectively infinite; EOT is never returned, as there is no
     predefined tape length.  An option to provide a simulated end-of-tape
     indication would be helpful.

     RESOLUTION:  Modify "hp2100_ms.c" to add SET MSCn REEL=<length> and SHOW
     MSCn REEL and to return EOT status if motion beyond the defined tape length
     is attempted.  Reel lengths may be set to 600, 1200, or 2400 (feet).
     Setting the length to 0 inhibits EOT, i.e., the reel length is effectively
     unlimited.

     Modify "mscio" to return EOT status when current tape position is beyond a
     calculated end-of-tape marker position (marker position is calculated as the
     ideal tape reel capacity, i.e., the number of bytes per inch times the
     length of the tape in inches).

     STATUS:  Fixed in version 3.2-3.



 42. PROBLEM:  Running the RTE off-line disc backup program PSAVE and doing a
     save to a new tape gives an initial "IOPE" after specifying the tape label.

     VERSION:  3.2-2

     OBSERVATION:  Upping the driver causes the program to continue properly.
     Saving to a "used" tape does not exhibit this problem.

     CAUSE:  The PSAVE program is attempting to read the new tape.  The tape
     simulation library is reporting MTSE_EOM (end of medium), as the newly
     created tape image file is zero-length.  This is translated to STA_PAR by
     "ms_map_err".  In response, the RTE tape driver retries the read ten times
     and then gives up and reports the parity error.

     RESOLUTION:  End-of-medium has no hardware analog; one cannot have a
     physical tape of zero length.  So the translation to simulated tape status
     is arbitrary.  A new physical tape will "run away," i.e., never return data.
     Some programs, e.g., the RTE tape driver, are written to detect this.
     However, those that aren't will simply hang.  A more useful translation is
     to return EOF marks when a motion is attempted beyond the end of the medium,
     as many programs interpret two successive EOFs as "logical end-of-medium."

     Modify "ms_map_err" (hp2100_ms.c) to return EOF status for MSTE_EOM.

     STATUS:  Fixed in version 3.2-3.



 43. PROBLEM:  EDIT/1000 uses the HT character (CTRL+I) to insert a tab, but
     printing of this character is suppressed.

     VERSION:  3.2-2

     OBSERVATION:  There is no visual indication that the TAB key was pressed to
     insert a HT character.

     CAUSE:  "CNTL_SET" does not include the HT character.

     RESOLUTION:  Modify "hp2100_stddev.c" to add "HT_FLAG", defined as
     "CHAR_FLAG('\t')", to "CNTL_SET".

     STATUS:  Fixed in version 3.2-3.



 44. PROBLEM:  The 7900 disc diagnostic fails Step 55 if two or more units are
     connected.

     VERSION:  3.2-2

     OBSERVATION:  Altering the unit table at the start of the diagnostic to
     include two units (e.g., "0,1") and then running a short pass produces this
     output:

       H65 SHORT PASS  0004,HEADS 0/1,UNIT 00, 0000 ERRORS
       H44 SEEK IN STEP  55
       E10 NO COMMAND FLAG
       H33 ATTENTION/SEEK-STATUS
       000002  000000
       H51 CYL 0202 HEAD 01 SECTOR 19 WORD COUNT 0128 UNIT 00

     The step tests overlapping seeks.

     CAUSE:  The command channel flag set that normally indicates seek command
     completion is not being deferred by the CLC CC issued in preparation for
     sending another command.  The simulator must defer the flag set until a
     subsequent STATUS CHECK command is issued (this command normally does not
     set the command channel flag but will do so if a pending drive attention
     bit is set).

     RESOLUTION:  Add a "poll attention" state to the simulator and set the
     command channel flag if polling is enabled and one or more drive attention
     bits are set.

     STATUS:  Fixed in version 3.2-3.



 45. PROBLEM:  The 7900 disc diagnostic fails the not-ready tests in Step 14.

     VERSION:  3.2-2

     OBSERVATION:  Running the 7900 diagnostic with S bit 4 set to execute the
     interactive part of Section 1 causes this failure:

       H70 UNLOAD UNIT  0,PUSH RUN

       HALT instruction 102002, P: 03364 (JSB 1430)
       sim> detach dpc0
       sim> go
       H46 READ IN STEP  14
       E64 STATUS IS 000101 SHOULD BE  000105
       H51 CYL 0202 HEAD 00 SECTOR 00 WORD COUNT 1024 UNIT 00

     The diagnostic is expecting the DRIVE BUSY bit to be set.

     CAUSE:  The "unit not attached" simulator state maps to the "drive not
     ready" hardware state.  In this state, both the NOT READY and the DRIVE BUSY
     status bits should be set.

     Referring to the "Drive Control Assembly A9" schematic on page 5-43 of the
     "7900A Disc Drive Operating and Service Manual" (HP 07900-90002), the "Drive
     Ready" signal is forced low via U22B if the "Load Switch Off" signal is
     asserted (setting the "Load Switch" off unloads the heads).  Also, the
     "Access Ready" signal is forced low via U35A if the "Drive Ready" signal is
     low.  Schematic "Input/Output Multiplex Assembly A7" on page 5-39 shows that
     these signals are inverted and driven onto the cable to the CPU interface.

     The 13210A interface manual schematic for "Disc Interface PCA 1" shows that
     both signals are inverted twice and presented to the CPU as status bits 6
     and 2, respectively.  So "not Drive Ready" becomes NOT READY, and "not
     Access Ready" becomes DRIVE BUSY.

     RESOLUTION:  Modify "dpd_svc" (hp2100_dp.c) to set both the NOT READY and
     DRIVE BUSY bits when the unit is not attached.

     STATUS:  Fixed in version 3.2-3.



 46. PROBLEM:  The 7900 disc diagnostic loops forever in Step 15.

     VERSION:  3.2-2

     OBSERVATION:  Running the 7900 diagnostic with S bit 4 set to execute the
     interactive part of Section 1 causes this failure:

       H40 PROTECT U/D THEN READY UNIT  0

       [CTRL+E]
       Simulation stopped, P: 76734 (TIMER)
       sim> set dpc0 locked
       sim> att dpc0 7900-U0.scratch.disc
       sim> go

       H40 PROTECT U/D THEN READY UNIT  0
       H40 PROTECT U/D THEN READY UNIT  0
       H40 PROTECT U/D THEN READY UNIT  0

     The diagnostic is waiting for the CC flag to set when the drive becomes
     ready (i.e., when the unit is attached).

     CAUSE:  Section 4-67 of the "7900A Disc Drive Operating and Service Manual"
     (HP 07900-90002) says, "Attention is set high every time a seek has
     completed and Access Ready comes high."  This includes the initial
     head-loading seek when the drive becomes ready.  The "Troubleshooting
     Diagrams (Sheet 2 of 4)" on page 5-17 show that after the heads load, Drive
     Ready, First Status, Access Ready (a.k.a. not Busy), and Attention are
     asserted.  The corresponding code in "dpc_attach" sets First Status but not
     Attention.

     In addition, the last diagnostic command prior to the loop is a STATUS
     CHECK.  This leaves the 13210A interface polling for attention bits, and
     when one is asserted, the command channel flag FF is set.  However, the
     simulator makes no provision for this; the flag is checked once at the end
     of the status command, but no further checks are made thereafter.

     RESOLUTION:  Modify "dpc_attach" (hp2100_dp.c) to set the ATN flag when the
     unit is attached and, if drive polling is enabled, to set the command
     channel flag.

     STATUS:  Fixed in version 3.2-3.



 47. PROBLEM:  The 7900 disc diagnostic fails the write-protect tests in Step 16.

     VERSION:  3.2-2

     OBSERVATION:  Running the 7900 diagnostic with S bit 4 set to execute the
     interactive part of Section 1 causes this failure:

       H40 PROTECT U/D THEN READY UNIT  0

       [CTRL+E]
       Simulation stopped, P: 76734 (TIMER)
       sim> set dpc0 locked
       sim> attach dpc0 7900-U0.scratch.disc
       sim> go

       H44 SEEK IN STEP  16
       E64 STATUS IS 040001 SHOULD BE  042001
       H51 CYL 0000 HEAD 00 SECTOR 00 WORD COUNT 0128 UNIT 00

     The diagnostic is expecting the DATA PROTECT bit to be set.

     CAUSE:  The UNIT_WPRT flag is being checked in the FNC_STA processing in
     "dpd_svc", but the referenced unit is the data channel unit, not the command
     channel unit where the flag is actually set.

     RESOLUTION:  Alter "dpd_svc" (hp2100_dp.c) to check the command channel unit
     instead of the data channel unit when looking for write-protect indication.

     STATUS:  Fixed in version 3.2-3.



 48. PROBLEM:  The 7970E diagnostic hangs in test 33 if the tape is not at BOT.

     VERSION:  3.2-2

     OBSERVATION:  The test issues a REWIND/OFFLINE to each unit in turn and
     looks for the REW status bit to deny before proceeding.

     CAUSE:  The simulator resets this bit for the REWIND command but not for
     REWIND/OFFLINE.  More generically, though, the simulator is reporting unit
     status (REW, BOT) when the unit is off-line.

     RESOLUTION:  Modify "mscio" (hp2100_ms.c) to remove unit-specific status
     from the status return when the unit is not attached.

     STATUS:  Fixed in version 3.2-3.


     OBSERVATION:  The status for REWIND/OFFLINE when not at BOT isn't quite
     correct.  The hardware indicates "Rewinding" (bit 10) for a short time
     before going off-line.

     CAUSE:  The simulator is detaching (i.e., going off-line) immediately upon
     command execution.

     RESOLUTION:  Modify "mscio" (hp2100_ms.c) to detach after the interface
     execution delay.

     STATUS:  Fixed in version 3.2-3.


     OBSERVATION:  The status for REWIND and REWIND/OFFLINE when at BOT isn't
     quite correct.  The hardware does not indicate "Tape Unit Busy" (bit 9) if
     the unit is at BOT, because the tape never moves.

     CAUSE:  The simulator generates "Tape Unit Busy" whenever a service event is
     scheduled, but this status should not occur if a rewind is issued at BOT.

     RESOLUTION:  Modify "mscio" (hp2100_ms.c) to condition STA_TBSY on rewind at
     BOT.

     STATUS:  Fixed in version 3.2-3.



 51. PROBLEM:  The diagnostic configurator misidentifies the host CPU.

     VERSION:  3.2-3

     OBSERVATION:  Running the diagnostic configurator in conversational mode
     produces these hardware detection results using various CPU settings (note
     that STOP_INST must first be set to 0 to prevent unimplemented instruction
     traps):

       set cpu 2116 --> "2114, DMA, NO MPRT, 32K MEMORY"
       set cpu 2100 --> "21MX E, DMA, NO MPRT, 32K MEMORY"
       set cpu 21MX --> "21MX E, DMA, MPRT, 32K MEMORY"

     CAUSE:  Two model-specific behaviors are not implemented:

       * The S-register is read-only on the 2115/2116.

       * LIA 6/7 (actually, the "floating" state of the internal S-bus) returns
         -1 on the 21MX, and 0 on the 2114/2115/2116/2100.

     These behaviors are tested by the configurator to determine the CPU type.

     NOTE: the 21MX is detected as a "E-Series" model.  This is due to the
     presence of the TIMER instruction (TIMER is not implemented on the
     "M-Series" and is decoded as an MPY instruction on that system).

     RESOLUTION:  Modify "ovfio", "dmpio", and "nulio" (hp2100_cpu.c) to
     implement the above behaviors.

     STATUS:  Fixed in version 3.3-0.



 52. PROBLEM:  Displaying the CCA, CCB, and CCE instructions via "examine -m"
     prints "CLA,CMA", "CLB,CMB", and "CLE,CME" respectively.

     VERSION:  3.2-3

     OBSERVATION:  While "CLA,CMA" (e.g.) is logically what the "CCA" instruction
     does, it is invalid assembler syntax (although it is accepted by the
     "deposit" routine).

     CAUSE:  The "mtab" array contains values to mask the instruction under
     consideration to the significant bits.  For the CLA/B, CMA/B, and CCA/B
     instructions, the mask values are 006400, 007000, and 007400, respectively.
     They should all be 007400.  For the CLE, CME, and CCE instructions, the mask
     values are 002100, 002200, and 002300.  They should all be 002300.

     RESOLUTION:  Modify "mtab" (hp2100_sys.c) to use the proper masks for these
     alter-skip group instructions.

     STATUS:  Fixed in version 3.3-0.



 53. PROBLEM:  The paper tape diagnostic has several tests that depend on
     creating and using a tape loop.

     VERSION:  3.2-3

     OBSERVATION:  Tests 4, 5, and 11 use a loop of tape.  The pattern for the
     loop is punched by test 7.  To run tests 4, 5, and 11, multiple copies of
     the pattern must be stored in a "loop" file, and the tests must be exited
     before the "loop" runs out.  A better solution would be to have a settable
     "loop mode" that rewinds the tape image file when EOF is encountered.

     RESOLUTION:  Modify "ptr_mod" (hp2100_stddev.c) to add SET PTR DIAG and
     SET PTR READER commands, and modify "ptr_svc" to add support for loop mode.

     STATUS:  Fixed in version 3.3-0.



 54. PROBLEM:  The time base generator (CLK) cannot be disabled.

     VERSION:  3.2-3

     OBSERVATION:  The TBG was an option for HP systems, and certain DOS
     operating system features behave differently, depending on the presence or
     absence of the TBG.  It is desirable to allow those features to be observed
     during simulation.

     CAUSE:  The "clk_dev" structure lacks the DEV_DISABLE flag.

     RESOLUTION:  Modify "clk_dev" (hp2100_stddev.c) to add the DEV_DISABLE flag.

     STATUS:  Fixed in version 3.3-0.



 55. ENHANCEMENT:  Move the memory protect simulation from the CPU to a new MP
     device, allow MP to be disabled, and add the 12892B memory protect feature
     jumpers W5 (JSB), W6 (INT), and W7 (SEL1).

     VERSION:  3.2-3

     OBSERVATION:  Memory protect is an option card in 2116/21MX systems and
     should have its own device entry in the simulator.  The device should be
     disabled to indicate that the card is absent.

     Setting the CPU model to 2100 or 21MX should enable MP, although it may be
     subsequently disabled if desired.  Setting the CPU model to 2116 should
     disable MP.  The simulator should initialize with MP disabled.

     The "B" version of the 21MX memory protect card added three jumpers to
     modify the "standard" memory protect behavior.  The W5 (JSB) option
     prohibited JSB to locations 0 and 1.  The W6 (INT) option inhibited the
     indirect interrupt holdoff.  The W7 (SEL1) option allowed I/O instructions
     referencing select codes other than 1.

     RESOLUTION:  Modify "hp2100_cpu.c" to create the MP device and add commands
     for setting the above options and support for the associated features.

     STATUS:  Fixed in version 3.3-0.



 56. ENHANCEMENT:  Allow DMA to be disabled.

     VERSION:  3.2-3

     OBSERVATION:  DMA is an option card on all machines, so disabling it should
     be allowed.  Note that disabling DMA0 should disable DMA1 and vice-versa.
     (There was no single-channel DMA option except on the 2114.)

     RESOLUTION:  Modify "hp2100_cpu.c" to permit DMA to be disabled.

     STATUS:  Fixed in version 3.3-0.



 57. PROBLEM:  Setting the CPU to 21MX and a memory size > 32K and then changing
     the CPU to either 2100 or 2116 does not reset the memory size to a legal
     value.

     VERSION:  3.2-3

     OBSERVATION:  The 2100 and 2116 machines have a maximum memory size of 32K.
     This limit is enforced when setting the memory size, i.e., "Invalid
     argument" is reported when attempting to set these machines to a memory size
     > 32K.  However, if the machine is first set to 21MX, the memory size is
     increased beyond 32K, and then the machine is reset to 2100 or 2116, the
     memory size will remain larger than 32K.

     CAUSE:  No check on memory size is made when the machine type is set.

     RESOLUTION:  Modify "cpu_mod[]" (hp2100_cpu.c) to call "cpu_set_opt" when
     changing the CPU model, and modify "cpu_set_opt" to call "cpu_set_size"
     if the current memory size is > 32K and the new model is 2100 or 2116.  If
     the memory above 32K is not empty, and the "Really truncate memory" question
     is answered in the negative, "Command not completed" is printed, and the CPU
     change is aborted.

     STATUS:  Fixed in version 3.3-0.



 59. ENHANCEMENT:  The 2607 line printer simulator (LPT) now supports local
     OFFLINE/ONLINE and POWEROFF/POWERON settings.

     VERSION:  3.2-3

     OBSERVATION:  The 2607 printer returns different status for power-off and
     offline conditions.  A local "power off" command is needed to simulate the
     power-off or cable-disconnected state, and a local offline command is needed
     to simulate the PRINT button up state.  This allows proper status to be
     returned to programs that expect it (e.g., RTE, diagnostics).

     RESOLUTION:  Modify "lptio" (hp2100_lpt.c) to implement local power off and
     offline settings and to return proper status for these conditions.

     STATUS:  Fixed in version 3.3-0.



 60. PROBLEM:  The 2607 line printer simulator (LPT) does not supply the proper
     status for the paper-out condition.

     VERSION:  3.2-3

     OBSERVATION:  Paper-out is simulated by detaching the printer image file.
     When detached, the simulator returns status 040000 (paper out).  However,
     the 12845 Line Printer Operating and Service Manual (HP 12845-90001) states
     in section 2-33, "[The paper-out] signal is asserted only when the format
     tape in the line printer has reached the bottom of form."  So the expected
     status should be 000000 unless the printer is positioned at BOF.

     CAUSE:  "lptio" is not checking for BOF before returning paper-out status.

     RESOLUTION:  Modify "lptio" (hp2100_lpt.c) to set the paper-out status bit
     only if the current print location is BOF.

     STATUS:  Fixed in version 3.3-0.



 61. PROBLEM:  Issuing a TOF to the 2607 line printer (LPT) leaves the paper on
     the second line instead of the first.

     VERSION:  3.2-3

     OBSERVATION:  The RTE driver for the 2607 printer implements a top-of-form
     request by issuing a VFU call to channel zero.  On a real printer, this
     leaves the paper positioned at the first line on the page.  The simulator,
     however, leaves the paper positioned at the second line.  Examining the LPT
     registers shows that LCNT is 0 immediately after an ATTACH but is 1 after a
     TOF request.

     CAUSE:  The TOF is simulated by sending a form-feed to the printer image
     file.  This is being incorrectly followed by a line-feed and a line counter
     increment.

     RESOLUTION:  Modify "lpt_svc" (hp2100_lpt.c) to suppress the line-feed and
     line counter increment after a TOF request.

     STATUS:  Fixed in version 3.3-0.



 62. ENHANCEMENT:  The 2767 line printer simulator (LPS) now supports local
     OFFLINE/ONLINE and POWEROFF/POWERON settings.

     VERSION:  3.2-3

     OBSERVATION:  The 2767 printer returns different status for power-off and
     offline conditions.  A local "power off" command is needed to simulate the
     power-off or cable-disconnected state, and a local offline command is needed
     to simulate the PRINT button up state.  This allows proper status to be
     returned to programs that expect it (e.g., RTE, diagnostics).

     RESOLUTION:  Modify "lpsio" (hp2100_lps.c) to implement local power off and
     offline settings and to return proper status for these conditions.

     STATUS:  Fixed in version 3.3-0.



 63. PROBLEM:  Command files that reduce CPU memory size cannot run unattended.

     VERSION:  3.2-3

     OBSERVATION:  Command files that change CPU settings will pause for operator
     intervention if memory size is being reduced, previous memory size was more
     than 32K, and the memory being truncated contained non-zero data.  In this
     case, a prompt ("Really truncate memory?") is issued to the console.  As the
     response is not taken from the command file, there is no way to continue
     without user intervention.

     CAUSE:  The "cpu_set_size" routine calls "get_yn", which reads from "stdin."

     RESOLUTION:  Modify "cpu_set_size" (hp2100_cpu.c) to respond to a new "-F"
     switch that indicates that truncation should be forced without prompting.

     STATUS:  Fixed in version 3.3-0.



 64. PROBLEM:  Attempting to output to the 2767 simulator (LPS) via RTE-IVB
     causes not-ready and illegal interrupt errors.

     VERSION:  3.2-3

     OBSERVATION:  With the 2767 printer assigned to select code 21 and logical
     unit 12, attempting to print results in "IONR L 12 E12 S 0   0", followed by
     one "ILL INT 21" error for each character output.

     CAUSE:  The RTE driver understands that the 2767 prints in four 20-character
     zones and that character output within a zone is buffered.  It therefore
     assumes that a buffered character will be accepted within three instruction
     times.  If the printer is still busy after that, the printer is declared "not
     ready" and is downed.  Subsequent interrupts are not expected (the printer
     is assumed to be malfunctioning), resulting in the illegal interrupt
     messages.

     The 2767 simulator defines the character transfer time as four instructions
     and has no provision for detecting print zones.  The driver assumes that it
     can fill a zone rapidly within the driver and will have to exit the driver
     to wait for an interrupt at the end of each zone.

     RESOLUTION:  Modify "lpsio" and "lps_svc" (hp2100_lps.c) to reduce the
     buffer transfer time to two instructions and to determine the end of a zone
     in order to take an appropriately longer time before interrupting.

     STATUS:  Fixed in version 3.3-0.



 65. ENHANCEMENT:  Provide a method of selecting between realistic and fast
     (optimized) command execution times for the 2767 simulator.

     VERSION:  3.2-3

     OBSERVATION:  The 2767 diagnostic checks command execution times, so to
     pass, the simulator must model these times.  However, they are generally
     much longer than are required by the various operating systems.

     RESOLUTION:  Modify "hp2100_lps.c" to add SET LPS REALTIME and SET LPS
     FASTTIME commands.  Timing is now set according to the timing model in use.

     STATUS:  Fixed in version 3.3-0.



 66. ENHANCEMENT:  Provide a means of printing the internal state of the 2767
     printer simulator.

     VERSION:  3.2-3

     OBSERVATION:  Debugging printer errors would be easier if the printer
     interface commands and status were observable and recordable.  SIMH provides
     a "DEBUG" mode command set to allow devices to provide this information.

     RESOLUTION:  Modify "hp2100_lps.c" to add debug-mode printouts.

     STATUS:  Fixed in version 3.3-0.



 67. PROBLEM:  The console "break" and "delete" character settings are not saved
     across a simulation SAVE/RESTORE.

     VERSION:  3.2-3

     OBSERVATION:  The console interrupt character set via SET CONSOLE WRU=<val>
     is preserved when the simulation is SAVEd and then later RESTOREd.  However,
     the values set via SET CONSOLE BRK=<val> and SET CONSOLE DEL=<val> are lost
     and revert to their default settings.

     CAUSE:  Only "sim_int_char" is included in the hidden CPU state.

     RESOLUTION:  Modify "cpu_reg" (hp2100_cpu.c) to include BRK and DEL
     registers corresponding to "sim_brk_char" and "sim_del_char".

     STATUS:  Fixed in version 3.3-0.



 69. PROBLEM:  Attempting to disable the DP controller by doing SET DPD DISABLED
     is rejected with "Command not allowed."  Attempting to disable the DR
     controller by doing SET DRD DISABLED is accepted, but the controller remains
     enabled.

     VERSION:  3.2-3

     OBSERVATION:  Section 2.3 of "hp2100_doc.txt" states, "For devices with more
     than one device number, disabling or enabling any device in the set disables
     all the devices."  This is not true, however, for most multiple-card
     devices.  SET <dev> DISABLED is rejected for the DPD, DQD, MSD, MUXL, and
     MUXM devices.  For the DRD, IPLI, and MTD devices, the command is accepted
     but does not disable the device.

     CAUSE:  The "DEV_DISABLE" flag is missing from the "DEVICE" structures of
     the DPD, DQD, MSD, MUXL, and MUXM devices.  Also, for all multiple devices,
     the device "dev_reset" function must call "hp_enbdis_pair" with the
     appropriate parameter to synchronize the enable/disable state of both
     devices.

     RESOLUTION:  Modify the "DEVICE" structures and "dev_reset" routines as
     needed to the affected source files (hp2100_dp.c, hp2100_dq.c, hp2100_dr.c,
     hp2100_ipl.c, hp2100_ms.c, hp2100_mt.c, and hp2100_mux.c).

     STATUS:  Fixed in version 3.3-0.



 70. PROBLEM:  The 2871 disc diagnostic fails Status Checks in Step 1.  The
     checks are related to the ANY ERROR bit.

     VERSION:  3.2-3

     OBSERVATION:  Running the 2871 diagnostic causes this failure:

       H44 SEEK IN S1
       E64 STATUS IS 000001 SHOULD BE  000000
       H51 CYL 0000 HEAD 00 SECTOR 00 WORD COUNT 0000 UNIT 00

     The diagnostic is not expecting the ANY ERROR bit (bit 0) to be set with the
     ATTENTION bit (bit 15).  The simulator is returning status 100001 from the
     seek operation (bit 15 is always masked by the diagnostic before reporting).

     Resuming the diagnostic produces this error:

       H44 SEEK IN S1
       E64 STATUS IS 000005 SHOULD BE  000004
       H51 CYL 0001 HEAD 00 SECTOR 00 WORD COUNT 0000 UNIT 00

     The diagnostic is not expecting the ANY ERROR bit (bit 0) to be set with the
     BUSY bit (bit 2).

     CAUSE:  The ANY ERROR bit is set by the simulator if any status bit is set
     other than bit 10 (HUNTING) or bit 7 (unused).  This is correct for the
     13210A interface but not for the 12557A interface.

     From the "12557A Cartridge Disc Interface Operating and Service Manual" (HP
     12557-90001, September 1970), Table 2.6, "Disc Status Word" lists the
     following meanings for the status bits:

       Bit 0:  ANY ERROR.  A "1" indicates that any of the remaining 15 bits
               (except bits 2, 3, and 7) is a "1".

       Bit 15: ATTENTION.  A "1" indicates that an operation previously in
               progress on the selected disc drive unit has terminated either
               through normal completion or due to occurrence of an error or
               other unusual condition.  During execution of all commands except
               Status Check, the condition is generated when command execution
               terminates regardless of the cause for termination.

     This would imply that the ANY ERROR bit would set with the ATTENTION bit.
     However, on page 2-16, Section 2.50, "Design Considerations," this
     statement appears:

       Following each interrupt, the program must issue a Status Check command to
       the disc drive unit that executed the storage command and verify that the
       ANY ERROR bit (bit 0) is not a "1" in the disc status word.

     Given that the ATTENTION bit sets for each command completion, and given
     that the ANY ERROR bit is expected to be zero after a normal command
     completion, the implication is that ATTENTION does not set ANY ERROR.

     RESOLUTION:  Modify "dpcio" (hp2100_dp.c) to set the ANY ERROR bit for all
     status bits except bits 2, 3, 7, and 15 if the 12557A interface is selected.

     STATUS:  Fixed in version 3.3-0.



 71. PROBLEM:  The 2871 disc diagnostic fails not-ready Status Checks in Step 0.

     VERSION:  3.2-3

     OBSERVATION:  Running the 2871 diagnostic causes this failure:

       H43 UNIT  0 NOT READY CHECK IN S0
       E64 STATUS IS 000105 SHOULD BE  000101
       H51 CYL 0202 HEAD 00 SECTOR 00 WORD COUNT 3072 UNIT 00

     The diagnostic is not expecting the DRIVE BUSY bit (bit 2) to be set when
     the drive is not ready.

     CAUSE:  The simulator is returning both NOT READY and DRIVE BUSY.  This is
     correct for the 13210A interface but not for the 12557A interface.

     RESOLUTION:  Modify "dpd_svc" (hp2100_dp.c) to set the DRIVE BUSY bit for
     the "drive not ready" condition only if the 13210A interface is selected.

     STATUS:  Fixed in version 3.3-0.



 72. PROBLEM:  The 2871 disc diagnostic fails the head-load test in Step 0.

     VERSION:  3.2-3

     OBSERVATION:  Running the 2871 diagnostic reports this message to test for
     head loading:

       H40 READY UNIT  0

     After stopping the simulation, attaching a disc image file, and resuming,
     the above message continues to repeat.  The diagnostic is expecting the
     command-channel flag to set and drive status to return ATTENTION (bit 15)
     and FIRST SEEK (bit 14).

     CAUSE:  To prepare the interface to poll for drive attention, the diagnostic
     issues a Status Check command to the interface.  However, because the
     returned status word is not of interest, the diagnostic does not precede
     this with an STC,C to the data channel.  As the data command flip-flop is
     not set, the simulator waits in "dpd_svc" in state "FNC_STA", rather than
     proceeding to state "FNC_STA1", where the poll flag is set.  With the poll
     flag clear, the subsequent file attach does not set the command-channel flag
     or the associated drive status.

     Figure 3-7, "Status Check Operation Flow Diagram", on page 3-17 of the
     "12557A Cartridge Disc Interface Operating and Service Manual" (HP
     12557-90001, September 1970) implies that the data-channel command flip-flop
     must be set before the command-channel control flip-flop is set to initiate
     the command.  However, there is no hardware interlock on the interface to
     require this.  Moreover, the diagnostic clearly expects the drive attention
     to be detected, so the drive poll must occur, even without the data
     transfer.

     The STC DC asserts the "data encode" signal to the disc controller, and the
     STC CC asserts the "command encode" signal.  The latter initiates the Status
     Check operation, but there is no indication as to what happens if the "data
     encode" assertion does not precede it.  Typical operation would be that
     "device encode" initiates the operation and "device flag" signals the
     termination.  Without "device encode", "device flag" wouldn't occur.  Based
     on the diagnostic expectation, the implication is that the data-channel flag
     does not set, but the Status Check command does complete, and drive polling
     does start.

     RESOLUTION:  Modify "dpd_svc" (hp2100_dp.c) to complete the Status Check
     command and proceed to polling without setting the data-channel flag if the
     command flip-flop is not set, and the 12557A interface is selected.

     STATUS:  Fixed in version 3.3-0.



 73. PROBLEM:  The 2883 diagnostic fails the cyclic-check test in Step 4.

     VERSION:  3.2-3

     OBSERVATION:  Running the diagnostic causes this failure:

       H22 CYCLIC CHECK IN S4
       E10 NO COMMAND FLAG
       H51 CYL 0000 HEAD 00 SECTOR 00 WORD COUNT 0000 UNIT 00

     The error is a result of the diagnostic executing a Cyclic Check command
     with a sector count of 0.  Coupled with an initial seek to cylinder 0,
     head 0, and sector 0, this should check the maximum of 460 sectors before
     terminating with an End of Cylinder status.

     CAUSE:  The diagnostic is timing out.  The "12565A Disc Interface Kit
     Operating and Service Manual" (HP 12565-90003, August 1973) states in
     Section 2-45 on page 2-11, "The data rate of the disc drive is 156,000 words
     per second," giving a transfer time of 6.41 microseconds.  At an average of
     2 microseconds per instruction, the transfer time should be 3 instructions.
     It is currently set to 5.

     RESOLUTION:  Change "dqc_xtime" (hp2100_dq.c) from 5 to 3.

     STATUS:  Fixed in version 3.3-0.



 74. PROBLEM:  The 2883 disc diagnostic fails not-ready Status Checks in Step 0.

     VERSION:  3.2-3

     OBSERVATION:  Running the diagnostic causes this failure:

       H43 UNIT   0 NOT READY CHECK IN S0
       E64 STATUS IS 000104 SHOULD BE  000101
       H51 CYL 0202 HEAD 19 SECTOR 00 WORD COUNT 0046 UNIT 00

     The diagnostic is expecting the ANY ERROR bit (bit 0) and is not expecting
     the POSITIONER BUSY bit (bit 2) to be set when the drive is not ready.

     CAUSE:  The simulator is returning both NOT READY and POSITIONER BUSY.  From
     the "12565A Disc Interface Kit Operating and Service Manual" (12565-90003,
     Aug-1973), page 2-12, Table 2-5, "Disc Status Word," we have:

       Bit 6, NOT READY.  A "1" indicates that the selected disc drive unit is
       not connected to the disc controller, or is not sequenced up with disc
       spinning and heads loaded, or is in an unsafe condition.

       Bit 2, POSITIONER BUSY.  A "1" indicates the selected drive is busy
       executing a Position command.

       Bit 0, ANY ERROR.  A "1" indicates that "PL0 unsafe" condition has been
       detected or that one or more of the remaining 7 bits is a "1".

     RESOLUTION:  Modify "dqd_svc" (hp2100_dq.c) to set the ANY ERROR bit and
     remove the POSITIONER BUSY bit for the "drive not ready" condition.

     STATUS:  Fixed in version 3.3-0.



 75. PROBLEM:  Doing an OTA/OTB to the command channel of the 13210A interface
     fails to clear the control and command flip-flops.

     VERSION:  3.2-3

     OBSERVATION:  From the "13210A Disc Drive Interface Kit Operating and
     Service Manual" (13210-90003, Nov-1974), examination of Figure 5-2, "Disc
     Interface 1 PCA Schematic Diagram" shows that doing an OTA or OTB to the
     command channel will clear the control and command flip-flops.  Gate U16C
     feeds both the qualified CLC and IOO signals to the reset side of the
     command-channel control flip-flop.  Therefore, an output operation
     additionally will act as though a CLC had been done.

     CAUSE:  The action was omitted.

     RESOLUTION:  Modify "dpcio" (hp2100_dp.c) to perform a CLC CC if an OTA or
     OTB CC occurs, and the 13210A interface is selected.

     STATUS:  Fixed in version 3.3-0.



 76. PROBLEM:  The 2883 disc diagnostic fails the multi-unit Cyclic Check test in
     Step 5.

     VERSION:  3.2-3

     OBSERVATION:  Running the diagnostic causes this failure:

       H22 CYCLIC CHECK IN S5
       E64 STATUS IS 000000 SHOULD BE  000021
       H51 CYL 0001 HEAD 00 SECTOR 00 WORD COUNT 0128 UNIT 00

     The diagnostic does a seek to CHS 0/0/0 of unit 0, followed by a seek to CHS
     1/0/0 of unit 1, followed by a Cyclic Check of one sector of unit 0.  This
     should cause ADDRESS ERROR, because the second seek sets the controller
     Record Address Register (RAR) to 1/0/0, the read of unit 0 is done from
     0/0/0 (set by the first seek), and the two do not compare.  However, the
     simulator returns NO ERROR.

     CAUSE:  The DQ simulator has separate RARs for each unit.  The 12565A
     controller has a single RAR that is shared between all units.  (Note that
     the DP simulator has the same problem.)

     RESOLUTION:  Modify "hp2100_dq.c" and "hp2100_dp.c" to implement a single,
     shared RAR and per-unit current positions.

     STATUS:  Fixed in version 3.3-0.



 77. PROBLEM:  The 2773 (DR) drum diagnostic is unable to determine the number of
     sectors per track during initialization.

     VERSION:  3.2-3

     OBSERVATION:  Running the diagnostic causes this failure:

       H46 DEVICE PARAMETER DETERMINATION
       E47 UNABLE TO DETERMINE SECTORS PER TRACK
       H44 TRACK 0000 SECTOR 00 WORD COUNT 0000

     The diagnostic is attempting to determine the number of sectors per track by
     repeatedly reading the disc status word and examining the current sector
     field.

     CAUSE:  The disc status word is malformed.  The next sector address should
     appear in bits 14-8, but instead they are ORed with the lower-byte status
     flags, corrupting the status return value.

     RESOLUTION:  Modify "drcio" (hp2100_dr.c) to shift the next sector address
     to the upper byte before merging the status flags.

     STATUS:  Fixed in version 3.3-0.



 78. PROBLEM:  The 2773 (DR) drum diagnostic reports read/write status failures.

     VERSION:  3.2-3

     OBSERVATION:  Running the diagnostic causes this failure:

       H41 WRITE IN  ST
       E35 STATUS IS 0 000 110 010 000 000
           SHOULD BE D DDD DDD D10 D00 1D0
       H44 TRACK 0000 SECTOR 00 WORD COUNT 0064

     The diagnostic is expecting the Writing Enabled Flag bit to be set.

     CAUSE:  The simulation fails to return Writing Enabled status on tracks for
     which writing is permitted (all tracks).

     RESOLUTION:  Modify "drcio" (hp2100_dr.c) to set the Writing Enabled status
     when the track control word is output.

     STATUS:  Fixed in version 3.3-0.



 79. PROBLEM:  The 7900 disc drive (DP) fails to seek check if an invalid sector
     is supplied.

     VERSION:  3.2-3

     OBSERVATION:  From the "13210A Disc Drive Interface Kit Operating and
     Service Manual" (13210-90003, Nov-1974), section 3-55 states that Seek Check
     status is set during a Seek command for three conditions: the cylinder
     addressed is greater than 202, the sector addressed is greater than 23, or a
     head-positioning operation is still in progress.  The simulator fails to
     implement the second condition.

     CAUSE:  The check is omitted.

     RESOLUTION:  Modify "dpd_svc" (hp2100_dp.c) to set Seek Check status if the
     sector is out of range and the 13210A interface is selected.

     STATUS:  Fixed in version 3.3-0.



 80. PROBLEM:  The 2773 (DR) drum diagnostic fails the read test in Step 2.

     VERSION:  3.2-3

     OBSERVATION:  Running the diagnostic causes this failure:

       H42 READ IN S2
       E43 DATA WORD 0063 IS 000000 SHOULD BE  046160
       H44 TRACK 0000 SECTOR 00 WORD COUNT 0064

     Examination of the data file reveals that the failure is occurring on write.
     The last word of the buffer is not being written to the drum (64 words are
     to be transferred via DMA, but only 63 are output).

     CAUSE:  The DMA control word is set up to do a CLC on the last word.  On all
     words but the last, DMA dispatches an OTA DC followed by a CLF DC.  On the
     last word, DMA dispatches OTA DC followed by CLC DC,C.  This does a
     "sim_cancel", causing the scheduled transfer of the last word to be aborted.

     RESOLUTION:  Modify "hp2100_dr.c" to add "drc_run" to model the "Run
     Flip-Flop" from the hardware interface, and call "sim_cancel" in "drdio"
     only if "drc_run" is zero (i.e., not during a transfer).

     STATUS:  Fixed in version 3.3-0.



 81. PROBLEM:  If a partial sector is written to the 2773 drum, the remainder of
     the sector is filled with zeroes instead of replicating the last word
     written.

     VERSION:  3.2-3

     OBSERVATION:  The "12606B Disc Memory Interface Kit Operating and Service
     Manual" (12606-90012, Mar-1970) and "12610B Drum Memory Interface Kit
     Operating and Service Manual" (12610-9001, Feb-1970) state in Section 4-91
     and 4-92, respectively, that "...The last word will be repeated on the drum
     until the end of the sector is reached."  The simulator replicates zeros
     instead.

     CAUSE:  The wrong value was used.

     RESOLUTION:  Modify "drc_svc" (hp2100_dr.c) to use "drd_obuf" instead of "0"
     to fill out the remainder of a sector.

     STATUS:  Fixed in version 3.3-0.



 82. PROBLEM:  The 2773 (DR) diagnostic fails the sector address check in Step 1.

     VERSION:  3.2-3

     OBSERVATION:  Running the diagnostic causes this failure:

       H21 SECTOR ADDRESS CHECK IN S1
       E55 SECTOR  27 MISSING IN STATUS
       H44 TRACK 0000 SECTOR 00 WORD COUNT 0000

     The number of the missing sector is random.

     The diagnostic checks to ensure that each sector in the track is detected by
     checking current sector field of the status word.  The loop to read status
     words is 13 instructions long.  The simulator computes a current sector
     number from the current time; this sector changes every 10 instructions.
     Therefore, in a 13-instruction loop, a sector eventually will be skipped.

     CAUSE:  The timing model of the drum is incorrect.  Sectors should increment
     about every 256 instructions for the 2770/2771 and every 384 instructions
     for the 2773/2774/2775.

     RESOLUTION:  Modify "dr_set_size" (hp2100_dr.c) to set the per-word transfer
     time to reflect the model in use, and modify "GET_CURSEC" to determine the
     sector number properly from the current simulation time.

     STATUS:  Fixed in version 3.3-0.



 83. PROBLEM:  The 2770 (DR) diagnostic fails the write test in step T.

     VERSION:  3.2-3

     OBSERVATION:  Running the diagnostic causes this failure:

       H41 WRITE IN  ST
       E7 PARITY BIT ERROR
       H44 TRACK 0000 SECTOR 00 WORD COUNT 0064

     The diagnostic is expecting the parity error bit (bit 1) to be set at the
     conclusion of writes when using the 12606 interface.  This is an artifact of
     the interface design.

     CAUSE:  The status return from the 12606 interface is not modeled properly.

     RESOLUTION:  Modify "drv_svc" (hp2100_dr.c) to return DRS_PER at the
     conclusion of writes when configured as a 2770/2771 disk.

     STATUS:  Fixed in version 3.3-0.



 84. PROBLEM:  The 2770 (DR) diagnostic fails the track origin test in step T.

     VERSION:  3.2-3

     OBSERVATION:  Running the diagnostic causes this failure:

       E2 CLF OR SFS FAILED-CHANNEL  27

     The diagnostic is expecting an SFS CC instruction to skip when the track
     origin is detected.  Section 3-62 of the "12606B Disc Memory Interface Kit
     Operating and Service Manual" (12606-90012, March 1970) states, "If the
     track origin has been passed since performance of the CLF instruction, a
     program skip occurs."  This is not occurring.

     CAUSE:  The track origin detection feature of the 12606 interface is not
     implemented.

     RESOLUTION:  Modify "drcio" (hp2100_dr.c) to schedule an "origin passed"
     event on the data channel when CLF is executed and to check to see if that
     event timer is still running when SFS is executed to determine if the track
     origin has passed.

     STATUS:  Fixed in version 3.3-0.



 85. PROBLEM:  The 2770 (DR) diagnostic fails the SCP flip-flop test in step T.

     VERSION:  3.2-3

     OBSERVATION:  Running the diagnostic causes this failure:

       E3 SFC FAILED WITH FLAG CLEAR-CHANNEL 27

     The diagnostic is expecting an SFC CC instruction to skip when the SCP
     (Sector Clock Phase) flip-flop is clear.   Section 3-65 of the "12606B Disc
     Memory Interface Kit Operating and Service Manual" (12606-90012, March 1970)
     states, "If the SCP flip-flop is clear, a program skip takes place.  If the
     flip-flop is in the set state, no skip occurs."  This is not occurring.

     Also, the SCP flip-flop state is not being reflected in status bit 15
     ("Sector Flag").

     Finally, the 12610 command-channel interface does not drive the SKF
     backplane signal, so SFC CC on that interface should never skip.

     CAUSE:  The SCP test feature of the 12606 interface is not implemented.

     RESOLUTION:  Modify "drcio" (hp2100_dr.c) to skip when SFC CC is executed if
     the simulated head position is more than three words from the end of the
     current sector and the 12606 interface is selected, not to skip when SFC CC
     is executed and the 12610 interface is selected, and to reflect the SCP
     flip-flop state in bit 15 of the status word for both interfaces.

     STATUS:  Fixed in version 3.3-0.



 86. PROBLEM:  The 2770 (DR) diagnostic fails the read inhibit test in step 1.

     VERSION:  3.2-3

     OBSERVATION:  Running the diagnostic causes this failure:

       H53 READ INHIBIT CHECK IN S1
       E35 STATUS IS 0 011 001 110 000 100
           SHOULD BE D DDD DDD D11 D00 100
       H44 TRACK 0000 SECTOR 00 WORD COUNT 0000

     The diagnostic is expecting the read inhibit bit (bit 6) to be set for one
     sector time after an OTA/OTB instruction specifies a read operation when
     using the 12606 interface.  Section 4-113 of the "12606B Disc Memory
     Interface Kit Operating and Service Manual" (12606-90012, March 1970)
     states, "...The RI [Read Inhibit] signal from the disc ensures that at least
     a full sector elapses between the occurrence of sector coincidence and the
     setting of the SAC FF."  This is not occurring.

     CAUSE:  The read-inhibit feature of the 12606 interface is not implemented.

     RESOLUTION:  Modify "drcio" (hp2100_dr.c) to save the simulation time when
     an OTA/OTB is executed that specifies a read operation and to compare that
     to the current simulation time when LIA/LIB is executed and set the Read
     Inhibit status bit if one sector time has not elapsed.

     STATUS:  Fixed in version 3.3-0.



 87. PROBLEM:  The 2770 (DR) diagnostic fails the sector address check in step
     1.

     VERSION:  3.2-3

     OBSERVATION:  Running the diagnostic causes this failure:

       H66 BEGIN S1
       H21 SECTOR ADDRESS CHECK IN S1
       E55 SECTOR  90 MISSING IN STATUS
       H44 TRACK 0000 SECTOR 00 WORD COUNT 0000

     The diagnostic checks to ensure that each sector in the track is detected by
     checking current sector field of the status word.  The sector counter is one
     ahead of the sector currently under the head.  For the 90-sector 2770/2771
     disk, sector numbers are expected to range from 0 to 90, with the 90 state
     being provided while the last sector is under the head, and the 0 state
     being provided transiently between the "Track Origin" signal and the start
     of the first sector.

     Note that this problem does not occur on the 32-sector 2773/2774/2775 drum,
     because the sector counter is only five bits long, so instead of indicating
     sector 32 while sector 31 is under the head, the counter wraps around to
     zero while the last sector is under the head, and the 0 state persists a
     bit longer than the others.

     CAUSE:  The simulated sector counter is calculated incorrectly.

     RESOLUTION:  Replace the previous "GET_CURSEC" macro with a new "dr_seccntr"
     function (hp2100_dr.c) to model the sector counter accurately.

     STATUS:  Fixed in version 3.3-0.



 88. ENHANCEMENT:  Add a TRACKPROT=n modifier to specify the number of protected
     tracks and PROTECTED and UNPROTECTED modifiers to change the protection
     state of the designated tracks to the 277x (DR) simulator.

     VERSION:  3.2-3

     OBSERVATION:  The 12606/12610 interfaces provide a track protection switch
     on the data channel card and specification of the number of tracks to be
     protected.  The simulation should provide this feature.

     RESOLUTION:  Modify "drc_mod" (hp2100_dr.c) to add track protection features
     to the command channel (Bob says that this is a "controller" feature).

     STATUS:  Fixed in version 3.3-0.



 89. PROBLEM:  The 2767 line printer should not print non-printing characters.

     VERSION:  3.2-3

     OBSERVATION:  The 2767 printer repertoire is the 64 character ASCII subset
     from codes 32 to 95 (SPACE to "_").  Section 4-6 of the "2767A Line Printer
     Operating and Service Manual" (HP 02767-90002) says, in part, "On entering
     the print cycle, the characters in memory are checked for nonprintable
     characters and scanned and compared against the output of the character
     counter.  Nonprintable characters are immediately erased from memory."  This
     does not occur with the LPS simulator; all characters are passed through to
     the line printer image file.

     CAUSE:  There is no check for non-printing characters.

     RESOLUTION:  Modify "lps_svc" (hp2100_lps.c) to replace non-printing
     characters with blanks (equivalent to the hardware not firing the associated
     print hammer).

     STATUS:  Fixed in version 3.3-0.



 90. PROBLEM:  The 2767 line printer should overprint the current line if sent
     more than 80 characters.

     VERSION:  3.2-3

     OBSERVATION:  The 2767 printer drum is 80 columns wide.  Section 4-4 of the
     "2767A Line Printer Operating and Service Manual" (HP 02767-90002) says, in
     part, "The 80 print positions are divided into four zones, each having 20
     consecutive print positions," and Section 4-5 says, in part, "Up to 20
     characters can be received and stored in this manner, and the print cycle is
     started on receipt of either the 20th character or a format control
     character."  Section 4-8 says, "If the print cycle is originally initiated
     on receipt of the 20th printable character, then signal ZCAV is generated
     upon completion of printing.  The zone control register is incremented by 1
     and DEMAND LINE enabled.  The next printable character received will be
     printed in the leftmost position of zone 2."  The implication is that
     the 81st printable character sent will be printed in zone 1, column 1.

     CAUSE:  There is no check for the maximum character count per line.

     RESOLUTION:  Modify "lps_svc" (hp2100_lps.c) to output a CR after every 80
     characters sent without an intervening LF or FF to simulate overprinting.

     STATUS:  Fixed in version 3.3-0.



 92. ENHANCEMENT:  The T register now reflects changes to the M register made
     during simulation stop.

     VERSION:  3.3-0

     OBSERVATION:  On a real HP 21xx, the T (memory contents) register is updated
     automatically after changing the M (memory address) register while the CPU
     is halted.  Under simulation during a simulation stop, this does not occur.
     Providing it would very useful, though, as it would allow the ASSERT command
     to test the contents of memory locations.  In particular, it would allow the
     diagnostics command file to test the Diagnostic Serial Number of the loaded
     program to ensure that the expected value is present.

     RESOLUTION:  Modify "hp2100_cpu.c" to add a "sim_vm_post" routine that
     updates the T register.

     STATUS:  Fixed in version 3.3-1.



 93. PROBLEM:  The 2767 and 2607 (LPS and LPT) simulators do not respond properly
     to output operations initiated when the printers are powered off, offline,
     or out of paper.

     VERSION:  3.3-0

     OBSERVATION:  On the hardware, issuing an STC to start a print operation
     with the power off or with the printer offline or out of paper sets the
     control and command flip-flops, sending the "device command" signal to the
     printer.  The operation then "hangs" until the error is corrected, at which
     point the "device flag" signal is returned to the card.  This causes the
     flag buffer and flag flip-flops to set, completing the operation.

     On the simulator, the operation hangs forever if the paper is out, or
     completes normally if the printer is powered off or offline.  Both actions
     are wrong.

     CAUSE:  There is no provision for detecting the correction of the foregoing
     situations and rescheduling the I/O event.

     RESOLUTION:  Modify "lpt_svc" and "lps_svc" to stop execution if STOP_IOE is
     set and the printer is powered off, offline, or out of paper.  Add
     "lpt_restart" and "lps_restart" routines to restart a hung I/O operation
     when the printer is powered on, set online, or attached.

     Modify "hp2100_defs.h" and "sim_stop_messages" (hp2100_sys.c) to add support
     for STOP_OFFLINE and STOP_PWROFF simulator stop codes.

     STATUS:  Fixed in version 3.3-1.



 94. PROBLEM:  The column count on the 2767 printer doesn't increment when blanks
     are substituted for non-printing characters.

     VERSION:  3.3-0

     OBSERVATION:  Control characters sent to the printer are replaced by blanks
     before being output to the file.  However, the column counter does not
     increment for the replaced characters.

     CAUSE:  Logic error in "lpsio".

     RESOLUTION:  Modify "lpsio" (hp2100_lps.c) to count replaced non-printing
     characters in the column count.

     STATUS:  Fixed in version 3.3-1.



 95. PROBLEM:  Attempting to reboot RTE-IVB after a successful boot fails with
     HLT 02.

     VERSION:  3.3-0

     OBSERVATION:  Starting SIMH and booting RTE-IVB works as expected.  However,
     if the simulation is halted, and an attempt is made to boot RTE a second
     time, the boot fails.  Examination of memory shows that the bootstrap
     extension is being loaded at the wrong address.

     The 7900 boot loader outputs DMA control word 2 to select code 2, then sets
     the control flip-flop on select code 2, then outputs DMA control word 3.
     This sequence depends on the select code 2 control flip-flop (CTL2FF) being
     clear before the loader executes.  Examination shows that the BOOT command
     is not clearing this flip-flop, so both outputs write to control word 3,
     leaving control word 2 (the target address) set to 0.

     CAUSE:  The "dma0_reset" function is not clearing CTL2FF (on the hardware,
     the front panel PRESET button clears CTL2FF).

     RESOLUTION:  Modify "dma0_reset" and "dma1_reset" (hp2100_cpu.c) to clear
     the control flip-flops on select codes 2 and 3, respectively, as well as
     clearing the control flip-flops on select codes 6 and 7.

     STATUS:  Fixed in version 3.3-1.



 96. PROBLEM:  The control flip-flops on select codes 2 and 3 (the DMA
     initialization channels) are not visible.

     VERSION:  3.3-0

     OBSERVATION:  Displaying the DMA channels shows the values of the control
     (and flag, etc.) flip-flops for select codes 6 and 7.  The control
     flip-flops of channels 2 and 3 are not visible and may not be altered via
     the simulator user interface.

     CAUSE:  CTL(2) and CTL(3) have no register assignments in the DMA devices.

     RESOLUTION:  Modify "dma0_dev" and "dma1_dev" (hp2100_cpu.c) to add
     registers for the control flip-flops on select codes 2 and 3.

     STATUS:  Fixed in version 3.3-1.



 97. PROBLEM:  RESET erroneously clears the DMA control words 1-3.

     VERSION:  3.3-0

     OBSERVATION:  Attempting to slow-boot RTE from a 7905 disc fails with a
     "Data Overrun" error from the disc controller.  Examination shows that the
     disc read isn't performed because DMA Control Word 1 (select code) is zero.

     CAUSE:  The RESET (preset) that is done as part of the slow-boot process is
     calling "dma0_reset", which is clearing the three DMA control words.  The
     12897B schematic shows that CRS does not alter the control registers.

     RESOLUTION:  Modify "dma0_reset" and "dma1_reset" (hp2100_cpu.c) to clear
     the control words only on power-on reset.

     STATUS:  Fixed in version 3.3-1.



 98. PROBLEM:  DMA transfers to addresses 0/1 erroneously overwrite the A/B
     register contents.

     VERSION:  3.3-0

     OBSERVATION:  Attempting to boot RTE from a 7905 disc fails with a "Indirect
     address loop" simulation halt.  Examination shows that the B register, which
     is being used as an address pointer, is corrupted by a DMA transfer from the
     disc to address 00001.  The disc read succeeds but overwrites the A and B
     register contents in the process.

     Section I, Paragraph 4-17, "Store Field", of the "HP 1000 M/E/F-Series
     Computers Engineering and Reference Documentation" (HP 92851-90001) says:

       "The A and B addressable flip-flops (ABFF) [38A] can be clocked at the
        end of every microcycle.  Addresses 0 and 1 are detected on the M-bus and
        the flip-flops are set accordingly.  When DCPC uses the M-bus the ABFFST
        signal is suppressed."

     CAUSE:  The "ReadIO" and "WriteIO" routines, used by DMA, are not separating
     accesses to locations 0/1 from accesses to A/B.

     RESOLUTION:  Modify hp2100_cpu.c to separate the A/B registers from memory
     locations 0/1 and to map them equivalently, except during DMA accesses.

     STATUS:  Fixed in version 3.3-1.



 99. ENHANCEMENT:  Add SET CPU modifiers for 21MX-M and 21MX-E variants.

     VERSION:  3.3-0

     OBSERVATION:  The RTE-6/VM startup routine ($STRT) determines whether it is
     executing on a M-series or E-series by executing the TIMER instruction and
     seeing if the B register is incremented.  If it is, then OS microcode
     instructions are used, but these are not supported by SIMH, and an
     "Unimplemented instruction" simulation stop occurs.  RTE-6/VM will boot if
     the CPU is detected as an M-series.

     RESOLUTION:  Modify hp2100_cpu.c to add SET CPU 21MX-M and SET CPU 21MX-E
     modifiers, and enable the TIMER instruction only if the E-series variant is
     selected.

     STATUS:  Fixed in version 3.3-1.



100. PROBLEM:  The JPY instruction does not work.

     VERSION:  3.3-0

     OBSERVATION:  JPY is supposed to add the contents of P+1 to the Y register
     and use the result as the jump target address.  Actually, JPY is adding the
     contents of P+2.

     CAUSE:  The "e_inst" array that indicates how to process operands for the
     extended instructions has the wrong value for the JPY entry.

     RESOLUTION:  Modify "e_inst" (hp2100_cpu.c) to replace the erroneous "X_MR"
     value with the correct "X_NO" value.

     STATUS:  Fixed in version 3.3-1.



101. PROBLEM:  The JRS instruction does not perform a memory protect check on
     the jump target.

     VERSION:  3.3-1

     OBSERVATION:  A JRS to a location below the MP fence is allowed, presuming
     that DMS conditions are satisfied.

     CAUSE:  The JRS simulation routine is missing a memory protect check on the
     target address.

     RESOLUTION:  Add a call to "mp_dms_jmp" in the JRS simulator routine
     (hp2100_cpu1.c) to validate the target address.

     STATUS:  Fixed in version 3.3-2.



102. PROBLEM:  The EXECUTE instruction was never implemented on the 21MX-E.

     VERSION:  3.3-1

     OBSERVATION:  Section 5.7, "Special Instructions," of the "HP 1000
     M/E/F-Series Computers Engineering and Reference Documentation" (HP
     92851-90001) documents three "unsupported" instructions added to the 21MX-E
     series CPU: DIAG, TIMER, and EXECUTE.  Examination of the microcode reveals
     that the EXECUTE instruction (100120) was never implemented; the microcode
     executes a NOP for this instruction code.

     CAUSE:  Improper documentation.

     RESOLUTION:  Alter "cpu_eau" (hp2100_cpu1.c) to handle EXECUTE as an
     undefined instruction.

     STATUS:  Fixed in version 3.3-2.



103. PROBLEM:  Rounding negative unpacked floating-point numbers may yield
     unnormalized results.

     VERSION:  3.3-1

     OBSERVATION:  The floating-point pack routine first rounds by adding +/-
     1/2 LSB to the mantissa.  If rounding causes a carry, the resulting value
     is unnormalized.  An overflow check is made on positive numbers (i.e.,
     "011..." becoming "100..."), but no check for carry into the MSB-1 is made
     for negative numbers ("101..." becoming "110...").

     CAUSE:  The case was omitted.

     RESOLUTION:  Modify "StoreFP" (hp2100_fp.c) to add a normalization check
     for negative numbers.

     STATUS:  Fixed in version 3.3-2.



105. ENHANCEMENT:  The option flags for the various CPU models and options were
     reorganized.

     VERSION:  3.3-2

     OBSERVATION:  To simplify handling of optional instruction sets, the flags
     describing the configuration of the simulated system are reorganized into
     CPU type, model, and options.  This allows simple testing of a class of
     machines (e.g., all 21MX models) or installed options (e.g., IOP microcode
     on any CPU), without having to test each possible machine/option
     combination.

     RESOLUTION:  Modify option flags in "hp2100_cpu.c" and "hp2100_cpu.h" to
     reflect logical hardware grouping and change "cpu_set_opt" accordingly.

     STATUS:  Fixed in version 3.4-0.



106. ENHANCEMENT:  Modularize the handling of optional instruction sets to allow
     for future microcode option simulations.

     VERSION:  3.3-2

     OBSERVATION:  The current CPU simulation decodes all UIG instructions
     inline, so that microcode options that share instruction codes (e.g., the
     2100 IOP and the 2100 FP/FFP) must have tests for CPU type at each code
     point.  Also, tabular instruction operand processing is complicated when
     instructions with differing requirements share code points.

     RESOLUTION:  Split optional CPU instruction (EAU/UIG) processing into its
     own source file (hp2100_cpu1.c), represent each option as a function that
     determines CPU applicability and decodes its own instructions, and
     restructure operand processing so that it is per-option-module, rather than
     global for all options.

     STATUS:  Fixed in version 3.4-0.



107. ENHANCEMENT:  Add the Fast FORTRAN Processor (FFP) microcode option.

     VERSION:  3.3-2

     OBSERVATION:  The Pascal/1000 compiler will not load in an RTE system with
     a three-page driver partition if the FFP option is not present (required to
     reduce code size to fit the logical address space).  Also, RTE systems
     generated with the FFP option will not run unless the option is present.

     RESOLUTION:  Add a simulation of the FFP to "hp2100_cpu1.c", add a new
     extended-precision floating point module "hp2100_fp1.c", and add FFP
     helpers to "hp2100_fp.c" for single-precision operations.

     STATUS:  Fixed in version 3.4-0.



108. ENHANCEMENT:  Separate the online/offline and attach/detach functions for
     the magnetic tape and disc drive simulations.

     VERSION:  3.3-2

     OBSERVATION:  Currently, devices that have loadable media and an offline
     mode simulate both via attach and detach, i.e., attached implies online,
     and detached implies offline.  It is desirable to separate the two, so that
     performing a magnetic tape "rewind/offline" command or disc "head unload"
     action does not detach the image file.

     The RTE tape backup programs set the tape units offline when they are
     exited, and it is awkward to have to respecify the image filename in an
     attach command in order to put the unit back online for a succeeding
     operation (the real tape drive merely requires pressing the "ONLINE"
     button).  Also, being able to "down" untargeted disc drives when performing
     certain read/write operations, e.g., new system installation, is a useful
     safety measure (simply toggling the "UNLOAD" switch accomplishes this on a
     real disc drive).

     RESOLUTION:  Modify "hp2100_ms.c" to add SET OFFLINE/ONLINE and
     "hp2100_dp.c", "hp2100_dq.c", and "hp2100_ds.c" to add SET UNLOADED/LOADED
     commands, as well as to decouple setting a device offline from detaching
     the associated image file.

     STATUS:  Fixed in version 3.4-0.



112. ENHANCEMENT:  Improve reporting of conflicting I/O assignments.

     VERSION:  3.5-1

     OBSERVATION:  The current "dev_conflict" (hp2100_cpu.c) routine has
     three behaviors that might be improved:

       1. It reports only the first device conflict encountered.
       2. It reports the name and select code of only one of the two
          conflicting devices.
       3. It reports the select code in decimal.

     Here is a console log demonstrating these behaviors:

       sim> set ds dev=12
       sim> set muxm dev=12
       sim> set lpt dev=13
       sim> run
       DS device number conflict, devno = 10

       Simulation stopped, P: 00000 (NOP)

     We altered the default configuration to place PTP, DS, and MUXM at
     select code 12 (octal), and CLK and LPT at select code 13 (octal).
     Note that the above reported select code (10) is decimal.

     RESOLUTION:  Modify "dev_conflict" behavior as follows:

       1. Report all device conflicts in ascending select code order.
       2. Report device names for all conflicting devices.
       3. Report conflicting select codes in octal.

     Here is the same console log demonstrating the enhanced behaviors:

       sim> set ds dev=12
       sim> set muxm dev=12
       sim> set lpt dev=13
       sim> run
       Select code 12 conflict: PTP and DS and MUXM
       Select code 13 conflict: CLK and LPT

       Simulation stopped, P: 00000 (NOP)

     STATUS:  Fixed in version 3.5-2.



116. ENHANCEMENT:  Two gcc compiler warnings are corrected.

     VERSION:  3.6-0

     OBSERVATION:  Running gcc in strict ISO C99 standard mode (-std=c99 -Wall
     -pedantic) reveals two warnings:

       HP2100/hp2100_mux.c:160: warning: missing braces around initializer
       HP2100/hp2100_mux.c:160: warning: (near initialization for `mux_ldsc[0]')

     and:

       sim_ether.c: In function `eth_mac_scan':
       sim_ether.c:271: warning: short unsigned int format, short int arg (arg 3)

     CAUSE:  The first warning is due to an incompletely specified declaration.
     The variable is an array of structures, so the (partial) initializer should
     be "{ { 0 } }"  but is actually "{ 0 }".

     The second warning is due to a mismatch between a "sscanf" format and the
     corresponding parameter type.  The format, "%hx", requires a short unsigned
     int parameter, but the parameter is declared as short int.

     RESOLUTION:  The code causing the warnings is corrected.

     STATUS:  Fixed in version 3.7-0.



117. PROBLEM:  The 7970 magnetic tape simulator defaults tape capacity to a
     300-foot reel instead of to an unlimited-size reel.

     VERSION:  3.6-0

     OBSERVATION:  In the absence of an explicit size command, the 7970 tape
     drive reel size is intended to default to an unlimited size, wherein EOT
     never occurs.  In fact, EOT occurs after 300 feet.

     CAUSE:  The logic was inadvertently broken on February 16, 2006 when the
     "revision for new EOT test" was made.

     RESOLUTION:  Remove the "capac" assignments in "mscio" and "msc_svc" and
     add an assignment to "ms_set_reelsize" (hp2100_ms.c), allowing the default
     capacity to remain as 0 (a zero capacity causes "sim_tape_eot" to return
     FALSE).

     STATUS:  Fixed in version 3.6-1.



118. ENHANCEMENT:  Add CAPACITY to 7970 simulator as an alternate to REEL.

     VERSION:  3.6-0

     OBSERVATION:  Other magnetic tape simulators allow setting a CAPACITY to
     indicate the number of megabytes to read or write before returning EOT.
     The 7970 simulator REEL size predated CAPACITY, but it's desirable for
     commonality if both were allowed.

     RESOLUTION:  Alter hp2100_ms.c to support SET CAPACITY in addition to
     SET REEL, and enhance SHOW to display the capacity in MB or feet as
     appropriate.

     STATUS:  Fixed in version 3.6-1.



119. PROBLEM:  The RTE off-line magnetic tape restore program (DSKUP) hangs on
     the first write to the 79xx/13037 disc.

     VERSION:  3.6-1

     OBSERVATION:  The RTE offline restore program hangs when it tries to write
     to the 79xx disc.  The program is looping in a routine that obtains drive
     status by sending the REQUEST STATUS command to the drive.

     CAUSE:  The program expects that the REQUEST STATUS operation will clear
     the status.  If this operation returns DRIVE ATTENTION, the program loops
     until it does not.  However, the simulator does not the clear status value,
     so after the seek completes, DRIVE ATTENTION is returned forever.

     Page 10-10 of the 13037 Disc Controller Technical Information Package (HP
     13037-90902, August 1980) contains this description of the REQUEST STATUS
     command:

       "After receipt of this command, the controller returns two status words
       to the interface.  [...]  The controller then clears Status-1 and waits
       for a command from the same interface or a timeout to occur."

     The controller firmware routine STATS handles the status request.  It calls
     routine CLRST.  The comment for the CLRST routine is, "Subroutine CLRST
     clears status for all commands but status request," but examination of the
     routine shows that it is unconditional.

     RESOLUTION:  Modify the "DSC_RSTA" case in "ds_docmd" (hp2100_ds.c) to
     clear status-1 after returning it.

     STATUS:  Fixed in version 3.7-0.



120. ENHANCEMENT:  Separate TTY mode settings so that keyboard and display may
     be set independently.

     VERSION:  3.6-1

     OBSERVATION:  HP terminals had a CAPS LOCK setting that allowed upper-case
     input with mixed-case output.  The current TTY simulator allows several I/O
     options, but the keyboard and display settings are locked together.

     RESOLUTION:  Modified "tty_set_opt" (hp2100_stddev.c) to allow keyboard
     (TTY0) and display (TTY1) to be set independently.

     STATUS:  Fixed in version 3.7-0.



121. ENHANCEMENT:  Add the HP 93585A double integer instruction set firmware
     option.

     VERSION:  3.6-1

     OBSERVATION:  Later versions of RTE-6/VM were not supported on the 21MX
     M-Series due to logical address space limitations.  The RTE-6 OS and VMA
     firmware options were not available for the M-Series, and some vital system
     programs exceeded the available address space and failed to load when the
     software equivalents were used.  To run these programs, either the OS/VMA
     or double integer firmware support must be added to reduce the address
     space required.

     RESOLUTION:  Add an implementation of the double integer instruction set to
     "hp2100_cpu1.c" and add "DBI/NODBI" options to  "cpu_mod[]" (hp2100_cpu.c)
     to enable and disable the instructions.  Note that the 93585A product
     worked only on the E-Series, but it is available under simulation on the
     M-Series as well.

     STATUS:  Fixed in version 3.7-0.



122. ENHANCEMENT:  Add "1000-M" and "1000-E" CPU options as synonyms for
     "21MX-M" and "21MX-E".

     VERSION:  3.6-1

     OBSERVATION:  The 21MX computer series was renamed the 1000 series with the
     introduction of the F-Series in 1978.  The 21MX/21MX-M became the 1000
     M-Series, and the 21XE/21MX-E became the 1000 E-Series.  There is some
     internal HP documentation that refers to the F-Series as the 21MX-F, but
     the machine was introduced as the 1000 F-Series, and the other machines
     were renamed at the same time.

     RESOLUTION:  Modify "cpu_mod[]" (hp2100_cpu.c) to add "1000-M" and "1000-E"
     options.

     STATUS:  Fixed in version 3.7-0.



123. ENHANCEMENT:  The DMA device is automatically assigned the logical name
     "DCPC" when SET CPU 21MX is done.

     VERSION:  3.6-1

     OBSERVATION:  The term "DMA" is used with the 2116 and 2100 machines.  For
     the 21MX, the equivalent card is termed the "Dual Channel Port Controller."
     "DCPC" is used exclusively in the HP 21MX literature, and users are used to
     working with the "DCPC" name.

     RESOLUTION:  Modify "cpu_set_opt" (hp2100_cpu.c) to assign and deassign
     logical names in response to SET CPU 2116/2100/21MX commands, and add
     "assign_device" and "deassign_device" (scp.h) to the list of global
     routines.

     Note that this enhancement does not proscribe users from using the DMA
     device name with 21MX simulations.

     STATUS:  Fixed in version 3.7-0.



124. PROBLEM:  Running FC under RTE aborts the simulation with an "Invalid
     magtape record length" error.

     VERSION:  3.6-1

     OBSERVATION:  Attempting to run the RTE "FC" ("File Copy") tape archive
     program to generate a tape image fails.  The Read command is failing with
     tape library error 4, "Invalid record length."

     Enabling the debug mode of the 7970 tape drive simulator reveals that FC is
     attempting to leave space at the beginning of the tape for the archive
     directory by issuing a series of GAP commands.  After the files are stored,
     the tape is rewound, and the directory is written, intending to overwrite
     the erased area.

     CAUSE:  FC writes items to the tape in this order: header, marker, comment,
     directory, data file(s), and two EOFs.  FC is issuing GAP commands to leave
     space at the start of the tape for the tape header, which must be written
     after the tape is complete, because the header indicates the number of data
     files that fit on the tape.

     The SIMH mag tape library does not implement the "erase gap" feature, and
     the 7970 simulator treats GAP as a NOP, so no space is reserved at the
     start of the tape image.  When FC rewinds and writes the directory, it
     overwrites the existing records, resulting in a corrupt tape image.

     RESOLUTION:  Implement an "erase gap" feature in the SIMH tape library by
     defining GAP metadata markers, adding a "sim_tape_wrgap" command and
     enhancing the "sim_tape_rdlntf" and "sim_tape_rdlntr" internal functions to
     skip over GAP metadata markers (sim_tape.c).  Alter the 7970 simulator
     (hp2100_ms.c) to use it.  Also, update the "mtdump" utility to report erase
     gaps in tape images.

     Note: All HP 7970 mag tape drivers (SIO, BCS, DOS, RTE) employ the GFM
     (erase gap and write file mark) command to write an EOF to tape.  Also, the
     tape diagnostic tests that an initial gap precedes the first data record or
     EOF written at BOT (a function of the interface card).  Consequently,
     generated tape images contain substantial amounts of GAP metadata.  In
     almost all cases, they are unnecessary.  Therefore, these gaps are written
     only if the REALTIME option is selected.  Note that this does not affect
     the GAP command itself, which always writes gap metadata to tape images.

     STATUS:  Fixed in version 3.7-0.



125. ENHANCEMENT:  Improve error reporting from the 7970 tape simulator.

     VERSION:  3.6-1

     OBSERVATION:  The new "erase gap" support is only implemented for
     SIMH-format tape images.  Attempting to write an erase gap with other
     formats selected correctly returns MTSE_FMT from the library.  However, the
     7970 simulator maps that error (and the MTSE_UNATT error) to SCPE_IERR.
     The resulting "Internal error" message does not help the user identify the
     source of the problem.

     RESOLUTION:  Modify "ms_map_err" (hp2100_ms.c) to return SCPE_FMT and
     SCPE_UNATT for the tape library errors MTSE_FMT and MTSE_UNATT,
     respectively.

     STATUS:  Fixed in version 3.7-0.



126. PROBLEM:  "calc_dma" and "calc_int" are being called needlessly for most
     UIG 0 and UIG 1 instructions.

     VERSION:  3.6-1

     OBSERVATION:  The "calc_dma" and "calc_int" routines must be called after
     any routine that might change the I/O priority chain or set SRQ.  This
     would be after any I/O Group instruction or card I/O action (i.e., card
     service routine called).

     In "hp2100_cpu.c", the dispatch points for "cpu_uig_0" and "cpu_uig_1" call
     these routines unconditionally, but they're only needed if an IOP "PRFIO"
     or "PRFEI" instruction is executed (these execute standard I/O instructions
     as part of their actions).

     CAUSE:  The current code was a temporary expediency when the IOP
     instructions were moved into a separate source module.

     RESOLUTION:  Define a new "NOTE_IOG" status return (hp2100_defs.h) to
     request recalculation of I/O interrupts after instruction execution
     completes, and rename "STOP_INDINT" to "NOTE_INDINT" to reflect that it
     notifies the main instruction execution loop of an interruptibility
     condition, rather than stopping the simulation.  Alter "iogrp" and
     "resolve" (hp2100_cpu.c) respectively, to use these notification codes.

     STATUS:  Fixed in version 3.7-0.



127. ENHANCEMENT:  Use the tape simulator library routine "sim_tape_bot" to
     determine BOT status dynamically for the 7970 simulator.

     VERSION:  3.6-1.

     OBSERVATION:  The 7970 simulator maintains its own BOT status by tracking
     rewinds and motion commands.  It would be simpler to use the routine
     provided by the tape simulation library for this, rather than tracking each
     tape movement.

     Note that prior to the addition of erase gap support, this would not work.
     The diagnostic moved the tape off of BOT by using the GAP command, but this
     was a NOP for the tape simulation library, and the tape remained at BOT,
     leading to diagnostic failures.

     RESOLUTION:  Modify "hp2100_ms.c" to use "sim_tape_bot" instead of tracking
     BOT internally.

     STATUS:  Fixed in version 3.7-0.



128. PROBLEM:  Sending a "controller clear" command to the 7970 magnetic tape
     simulator may cause an unintended write.

     VERSION:  3.6-1

     OBSERVATION:  Clearing a write-in-progress properly writes any accumulated
     partial record.  Sending a second clear may write the record again.

     CAUSE:  Receipt of a CLR command initiates a check for a write-in-progress
     among active units.  If the data buffer pointer is non-zero, then partial
     data has been accumulated, and this is written to the tape image.  The data
     buffer pointer is normally zeroed when a write record command is received
     and the command time delay has transpired.

     If a second write command is sent, and another CLR is done before the
     command time has transpired (and therefore before any data has been
     received from the CPU), then the previous partial record will be written
     again.  This happens because the buffer pointer was not cleared and so
     implies the presence of another partial buffer of data.

     RESOLUTION:  Modify "mscio" (hp2100_ms.c) to clear the buffer pointer
     after a partial record is written.

     STATUS:  Fixed in version 3.7-0.



129. ENHANCEMENT:  Improve debugging information from the 7970 simulator.

     VERSION:  3.6-1

     OBSERVATION:  Debugging problems such as the "controller clear" bug would
     be easier if the debug logging decoded the tape commands and included all
     controller actions.  Currently, tape commands are reported in octal, and
     only some actions are reported.

     RESOLUTION:  Modify "hp2100_ms.c" to add additional debug logging and debug
     flags to select subsets of the available information.

     STATUS:  Fixed in version 3.7-0.



130. ENHANCEMENT:  Partition the various microcode options in "hp2100_cpu1.c"
     into separate modules for easier maintenance.

     VERSION:  3.6-1

     OBSERVATION:  With the addition of the double integer instructions and
     potential addition of the RTE-6/VM OS and VMA instructions, the microcode
     option source module, "hp2100_cpu1.c", is becoming unwieldy.  It is
     currently the largest HP source module -- about 50% larger than the rest of
     the CPU implementation.

     RESOLUTION:  Move the microcode options into separate source files, grouped
     by function, and restrict "hp2100_cpu1.c" to contain dispatching and common
     routines.

     STATUS:  Fixed in version 3.7-0.



132. PROBLEM:  The simulator stops with an "Indirect address loop" error when
     running the HP 1000-F FFP diagnostic .GOTO test.

     VERSION:  3.6-1

     OBSERVATION:  According to the HP 2100 documentation, the simulator will
     stop if "more than INDMAX indirect references are detected during memory
     reference address decoding."  INDMAX defaults to 16.  However, attempting
     a reference with exactly 16 indirects stops the simulator with an "Indirect
     address loop" error.

     CAUSE:  The indirect address resolution loop in the "resolve" function
     executes a maximum of INDMAX times.  However, the decision to report an
     error considers only whether the loop counter reached INDMAX and not
     whether the indirect chain was resolved.  Therefore, resolution on the last
     available pass through the loop is still reported as an error.

     RESOLUTION:  Modify "resolve" (hp2100_cpu.c) to report an error if the
     indirect chain is not resolved after exiting the loop.

     STATUS:  Fixed in version 3.7-0.



133. ENHANCEMENT:  Add support for the HP 1000 F-Series CPU model.

     VERSION:  3.6-1

     OBSERVATION:  The Fast FORTRAN Processor option adds simulation support for
     three-word floating-point operations.  Generalizing these to support two,
     three, and four-word operations would allow simulation of the F-Series
     floating-point processor.

     RESOLUTION:  Rework the FFP arithmetic simulations (hp2100_cpu3.c) into
     general operations on multiple-precision operands.  Add support for the
     F-Series FPP instructions.  Add support for the F-Series Scientific
     Instruction Set (SIS) firmware.  Add "1000-F" as a CPU option
     (hp2100_cpu.c).

     Note: rather than have two floating-point simulations (hp2100_fp.c and
     hp2100_fp1.c) that provide the two-word single-precision floating-point
     instructions, they are alternately conditionally compiled, depending on
     whether 64-bit integers are supported.  As the FPP depends on this support,
     compiling with it enables the FPP and therefore the F-Series option, and
     "hp2100_fp1.c" handles the single-precision instructions for the other CPU
     models.  If 64-bit support is not available, then "hp2100_fp.c" handles the
     single-precision instructions, and the F-Series is not available.

     STATUS:  Fixed in version 3.7-0.



134. ENHANCEMENT:  Add support for the 2114 and 2115 CPU models.

     VERSION:  3.6-1

     OBSERVATION:  The 2114 and 2115 are reduced-feature versions of the 2116
     computer.  One could restrict the 2116 environment to give an approximation
     of the 2114 and 2115.  However, these units used a unique DMA card that
     behaved somewhat differently than that used in the 2100 and 1000 (the 12607
     card for the 2114 supported only one DMA channel, for example).  So it
     would be desirable to support the 2114 and 2115 directly and therefore more
     faithfully.

     RESOLUTION:  Add "2114" and "2115" CPU model options (hp2100_cpu.c).

     STATUS:  Fixed in version 3.7-0.



135. ENHANCEMENT:  Add support for 12K and 24K memory sizes.

     VERSION:  3.6-1

     OBSERVATION:  The 2114 and 2115 CPUs supported up to 16K of memory in 4K
     increments.  For accurate simulation, finer granularity than the current
     4K/8K/16K/32K choices is needed.

     RESOLUTION:  Alter the table of memory size (hp2100_cpu.c) to add 12K and
     24K options.

     STATUS:  Fixed in version 3.7-0.



136. PROBLEM:  The DMS self-test instruction (10x701) should be a NOP on 1000-M
     machines.

     VERSION:  3.6-1

     OBSERVATION:  The DMS self-test instruction should complement the A or B
     register only on the 1000-E and F.  On the M, it should be a NOP.  In fact,
     it complements on the M as well.

     CAUSE:  Oversight.

     RESOLUTION:  Modify "cpu_dms" (hp2100_cpu2.c) to execute 10x701 as NOP on
     M-Series machines.

     STATUS:  Fixed in version 3.7-0.



137. ENHANCEMENT:  Add support for 21xx loader enable and disable.

     VERSION:  3.6-1

     OBSERVATION:  The 21xx CPUs are core-based machines.  Binary loaders are
     kept in the top 64 memory locations and are protected from reading and
     writing by front panel LOADER ENABLE switches.  When the switch is off,
     main memory effectively ends 64 locations earlier, i.e., the loader area is
     treated as non-existent.  Some 21xx diagnostics test for this feature and
     will not proceed if the loader area is unprotected.

     RESOLUTION:  Modify hp2100_cpu.c to add loader protection for 21xx models.

     STATUS:  Fixed in version 3.7-0.



138. PROBLEM:  The General Purpose Register Diagnostic fails when run on a 2100.

     VERSION:  3.6-1

     OBSERVATION:  The GP register diagnostic and other diagnostics that test
     the I/O system fail when run on 21xx CPUs.  The failure is in the Basic I/O
     test, Test 00.  The failure is, "E015 INT RTN ADDR ERROR."

     CAUSE:  The 21xx and 1000 CPUs behave differently when holding off
     interrupt requests after executing certain instructions.  At instruction
     fetch time, a pending interrupt request may be deferred if the previous
     instruction was a JMP indirect, JSB indirect, STC, CLC, STF, CLF, SFS (1000
     only), or SFC (1000 only), or was executing from an interrupt trap cell.
     If the CPU is a 1000, then the request is always deferred until after the
     current instruction completes.  If the CPU is a 21xx, then the request is
     deferred unless the current instruction is an MRG instruction other than
     JMP or JMP,I or JSB,I.  Note that for the 21xx, SFS and SFC are not
     included in the deferral criteria.

     RESOLUTION:  Modify "sim_instr" (hp2100_cpu.c) to clear "ion_defer" if
     executing on a 21xx-series CPU and the current instruction is an MRG
     instruction other than JMP or JMP,I or JSB,I.

     STATUS:  Fixed in version 3.7-0.



139. PROBLEM:  The 2100-specific Memory Protect Diagnostic fails when testing
     indirect holdoffs.

     VERSION:  3.6-1

     OBSERVATION:  Running the 2100-specific MP diagnostic fails, even though
     the combined 2100/21MX MP diagnostic passes.  The failure is:

       E26. RETURN ADDRESS INCORRECT FOR CHAINED JMP,I INTERRUPTS

     CAUSE:  The memory protect feature adds an indirect counter that allows a
     pending interrupt to be serviced if more than three levels of indirection
     are encountered.  Currently, the "resolve" routine handles this by
     returning a status code that aborts the current instruction if an interrupt
     is pending and the third indirect level is encountered.  However, the
     actual action of the hardware is to clear any interrupt deferral at the
     third level and to abort the instruction at the fourth.  The diagnostic
     tests that a two-level JMP,I jumps and defers interrupts, a three-level
     JMP,I jumps and then allows interrupts, and a four-level JMP,I aborts and
     then allows interrupts.

     RESOLUTION:  Modify "resolve" (hp2100_cpu.c) to obey the foregoing rules,
     and modify "sim_instr" to set "ion_defer" before calling "resolve" for
     JMP,I and JSB,I instructions.

     STATUS:  Fixed in version 3.7-0.



140. PROBLEM:  The 2114/2115/2116/2100 DMA diagnostic fails with an unexpected
     trap cell halt.

     VERSION:  3.6-1

     OBSERVATION:  Running the 21xx-specific DMA diagnostic fails, even though
     the combined 2100/21MX DMA diagnostic passes.  The failure manifests itself
     as an unexpected trap cell halt, 106002.

     CAUSE:  The diagnostic issues STF 6 and STC 6 instructions to cause a DMA
     interrupt without a transfer to test the priority chain.  This sets the
     transfer (command) flip-flop on SC 6.  In the next test, it does a CLC 0
     and then sets up a one-word DMA transfer from the test device.  Then it
     asserts device SRQ by doing CLC SC and STF SC, and finally it starts the
     device and DMA with STC SC and STC 6,C.

     However, with command set, asserting SRQ starts the transfer immediately,
     even though the control flip-flop is clear.  So the word count has rolled
     over to zero and the transfer terminated by the time the STC 6,C is done to
     "start" the transfer.  At that point, a second transfer is started, and the
     word count of zero implies a transfer of 64K words, which begins scribbling
     over memory.  As the value 140000 had been written to the card before the
     transfer, and as the card is in a loopback mode, 140000 is read from the
     card on each transfer, and so this value overwrites memory.  Eventually,
     the diagnostic attempts a jump indirect through an overwritten location.
     The target value 140000 is interpreted as a DEF 40000,I, and because
     location 40000 contains zero, control transfers to location 0, leading to
     execution of the trap cell halt 106002 in location 2.

     The problem is that the simulator incorrectly implements CRS ("Control
     Reset," the backplane signal that is generated by the CLC 0 instruction) by
     sending a CLC SC to each I/O card.  For many cards, CLC 0 (CRS) and CLC SC
     (CLC) invoke the same action.  They do not on the DMA card, which clears
     the control flip-flop for CLC, but clears the control and command
     flip-flops for CRS.  Clearing the command flip-flop prevents the DMA
     transfer from starting until the STC 6,C instruction in the diagnostic is
     executed.

     RESOLUTION:  Modify "cpuio" (hp2100_cpu.c) to send a new signal, "ioCRS",
     in response to CLC 0 and modify the I/O handlers of all devices to handle
     "ioCRS" as "ioCTL" temporarily until each card response can be verified
     from the schematics.

     STATUS:  Fixed in version 3.7-0.



141. PROBLEM:  The 12566B diagnostic interface card (LPS) does not clear the
     command flip-flop when CLC is done.

     VERSION:  3.6-1

     OBSERVATION:  In SET LPS DIAG mode, a 12566B microcircuit interface card
     with a loopback connector is simulated.  This is provided for the use of
     certain diagnostics that test the I/O system.  Attempting to use this
     simulation with the 2114/2115/2116/2100 DMA diagnostic fails with:

       E136. D1-I/O FLG SET

     even though the combined 2100/21MX DMA diagnostic passes.

     CAUSE:  The diagnostic requires that jumper W9 be set to the "A" position.
     This enables clearing of the device command flip-flop when the CLC
     instruction is executed.  Clearing CMD is intended to stop any I/O in
     progress.

     The diagnostic sets up a one-word output with STC and CLC specified in the
     control word.  At the end of the transfer, "dma_cycle" (hp2100_cpu.c)
     correctly sends LPS a STC,C followed by a CLC,C.  The STC,C starts a
     transfer and therefore schedules an I/O event for completion in one
     instruction.  The CLC,C clears the control flip-flop and the device flag,
     but because "sim_cancel" is not called, the I/O event remains.  When it
     fires, the device flag is set.  The diagnostic is expecting the flag to be
     clear.

     The 2100/21MX diagnostic tests for flag clear by using a control word that
     has neither STC nor CLC present.  This generates a CLF to the interface,
     which correctly clears the device flag (without starting another
     operation).

     RESOLUTION:  Modify "lpsio" (hp2100_lps.c) diagnostic mode to latch the
     input data on STC and schedule the command clear and flag set in two
     instructions.  Also, clear the command flip-flop and cancel any pending I/O
     event if CLC is executed in diagnostic mode.  This more correctly
     implements the response of the hardware under DMA control.

     STATUS:  Fixed in version 3.7-0.



142. ENHANCEMENT:  Add diagnostic loopback capability to the 12920A multiplexer.

     VERSION:  3.7-0

     OBSERVATION:  To run the HP multiplexer diagnostic, a loopback cable is
     needed that interconnects two ports.  To test all sixteen ports, eight
     cables are needed, or the diagnostic must be run eight times while moving
     the single cable from port pair to port pair.  The diagnostic cannot be run
     under simulation, because the 12920A simulator does not provide loopback
     capability.

     RESOLUTION:  Add DIAG/TERM commands to switch between diagnostic cable
     (loopback) mode and terminal cable (Telnet connection) mode.

     STATUS:  Fixed in version 3.7-1.



143. PROBLEM:  The 12920A multiplexer control card diagnostic fails in test 0.

     VERSION:  3.7-0

     OBSERVATION:  Running the control diagnostic reports this failure:

       TEST  00
       E027 PRESET DID NOT CLEAR STATUS ON PORT  01

     The diagnostic is testing each channel after PRESET to verify that the
     status is reset, but the value returned is not as expected.

     CAUSE:  Page 3-6, paragraph 3-38 of the multiplexer service manual states,
     "The channel number is four bits (10 through 13) of every output or input
     word.  When the scan bit is cleared (logic 0) during an OTA/B command, the
     channel number does not change and the status of the same channel is loaded
     by the next LIA/B command."  The diagnostic sets the channel number by an
     OTA to the control card select code.  However, the "ioOTX" handler in
     "muxcio" is not setting the channel to the supplied value for subsequent
     LIA/B use.

     RESOLUTION:  Set "muxc_chan" (hp2100_mux.c) to the channel number supplied
     in the "ioOTX" handler in "muxcio."

     STATUS:  Fixed in version 3.7-1.



144. PROBLEM:  The 12920A multiplexer control card diagnostic fails in test 4.

     VERSION:  3.7-0

     OBSERVATION:  Running the control diagnostic reports this failure:

       TEST  04
       E034 STORED STATUS NO. 1 FAILED  TO INTERRUPT

     The diagnostic sets the multiplexer channel to interrupt on a change in S1
     status, but the interrupt did not occur as expected.

     CAUSE:  The "mux_cntl_int" returns immediately if "muxc_scan" (the scan
     bit) is zero.  This behavior is incorrect; with the scan bit set to zero,
     only the current channel should be tested for interrupt.

     Note that Figure 3-3, the "Simplified Schematic Diagram" on page 3-9 of the
     service manual shows that the status interrupt is conditional on the scan
     bit, but the actual schematic in figure 5-4 on page 5-15 shows that this is
     not the case.

     RESOLUTION:  Modify "mux_cntl_int" (hp2100_mux.c) to test the current
     channel for a status interrupt condition if "muxc_scan" is zero, rather
     than returning directly.

     STATUS:  Fixed in version 3.7-1.



145. PROBLEM:  The 12920A multiplexer data card diagnostic fails in test 1.

     VERSION:  3.7-0

     OBSERVATION:  Running the data diagnostic reports this failure:

       TEST  01
       E032 SEND PORT NUMBER IS  00 SHOULD BE  01

     The diagnostic is reading the transmitted data from the lower select code
     to determine the transmit channel, but the channel number is wrong.

     CAUSE:  The "mux_data_int" function is setting only the upper select code
     status value in response to a transmit interrupt.  The lower select code
     card schematic, figure 5-3 on page 5-11 of the service manual, shows that
     the interrupting channel number is presented on bits 14-10 of the status
     words supplied by both the upper and lower cards.

     RESOLUTION:  Modify "mux_data_int" (hp2100_mux.c) to set "muxl_ibuf" as
     well as "muxu_ibuf" in response to a transmit interrupt.

     STATUS:  Fixed in version 3.7-1.



146. PROBLEM:  The 12920A multiplexer data card diagnostic fails in test 1.

     VERSION:  3.7-0

     OBSERVATION:  Running the data diagnostic reports this failure:

       TEST  01
       E034 DATA RECEIVED ON PORT  00 IS 2125 SHOULD BE  3525

     Data is sent out on one channel is compared for equality when received on
     the other channel.  The values are not equal.

     CAUSE:  Characters delivered to the multiplexer are contained in bits 10-0
     of data words output from the CPU.  In the "ioCTL" handler in "muxlio," the
     output word is masked with OTL_CHAR (01777) to retain just the data before
     storing the result in "mux_xbuf".  However, "mux_xbuf" and the
     corresponding "mux_rbuf" are declared as "uint8", so the upper three bits
     are lost.

     RESOLUTION:  Change the declarations of "mux_xbuf" and "mux_rbuf"
     (hp2100_mux.c) from "uint8" to "uint16" to retain all of the character data
     bits.

     STATUS:  Fixed in version 3.7-1.



147. PROBLEM:  The 12920A multiplexer data card diagnostic fails in test 2.

     VERSION:  3.7-0

     OBSERVATION:  Running the data diagnostic reports this failure:

       TEST  02
       E041 BREAK BIT SHOULD BE SET

     The diagnostic is transmitting an all-space character and testing whether
     the receiver detects this as a break.  The break bit is not being set.

     CAUSE:  The error is misleading.  The actual cause is that an interrupt is
     not occurring on the receive channel, because "mux_rchp" is not being set
     for the target line in "muxi_svc" if SCPE_BREAK is detected, even though
     the break flag is being set in the status word.

     RESOLUTION:  Modify "muxi_svc" (hp2100_mux.c) to indicate a pending
     character if a break is detected.

     STATUS:  Fixed in version 3.7-1.



148. PROBLEM:  The 12920A multiplexer data card diagnostic fails in test 3.

     VERSION:  3.7-0

     OBSERVATION:  Running the data diagnostic reports this failure:

       TEST  03
       E042 PARITY BIT SHOULD BE SET

     The diagnostic is checking that the "parity check" bit (bit 15) of the
     received status word is 1 when odd parity is sent.  The bit is 0.

     CAUSE:  The "odd_par" table has numerous errors in it.  For example, the
     values in columns 006 and 007 should be the opposite of the values in
     columns 016 and 017, but in many cases they are not.

     Also, the "RCV_PAR" macro is setting LIL_PAR if the data has even parity,
     not odd parity.  For example, it returns LIL_PAR on a data value of zero.
     Paragraph 3-23 on page 3-6 of the service manual says, "The parity bit is
     set (logic 1) for odd parity and turned off (logic 0) for even parity."

     RESOLUTION:  Correct the "odd_par" table (hp2100_mux.c) to reflect the
     correct odd parity for all values.  Reverse the sense of the test in
     "RCV_PAR" so that "LIL_PAR" is returned if the received value has odd
     parity.

     STATUS:  Fixed in version 3.7-1.



149. PROBLEM:  The 12920A multiplexer data card diagnostic fails in test 3.

     VERSION:  3.7-0

     OBSERVATION:  Running the data diagnostic reports this failure:

       TEST  03
       E043 RAW PARITY BIT 7

     The diagnostic is checking that bit 7 of the data word contains the desired
     parity (odd or even).  Bit 7 has the wrong value.

     CAUSE:  Parity is not being generated for transmitted characters.

     RESOLUTION:  Modify the "ioCTL" handler in "muxlio" (hp2100_mux.c) to
     generate odd parity and add it to the data if bit 12 of the transmission
     configuration word is set.

     STATUS:  Fixed in version 3.7-1.



150. PROBLEM:  The 12920A multiplexer data card diagnostic fails in test 4.

     VERSION:  3.7-0

     OBSERVATION:  Running the data diagnostic reports this failure:

       TEST  04
       E033 RECEIVE PORT NUMBER IS 00 SHOULD BE  16

     The diagnostic is configuring the diagnose channels and presuming that an
     initial CLC 0 will clear the configuration parameters for all channels.

     CAUSE:  The CLC handler is not performing the master clear function, so
     the previously configured channel 0 is interrupting before the expected
     channel 16.

     Also, the interrupting channel number is truncated to four bits by the
     "PUT_CCH" macro in "mux_data_int", so an interrupt on channel 16 is
     reported as being on channel 0.  Control card channel numbers are four bits
     in size, but data channel numbers are five bits; the wrong macro is being
     used to form the status word.

     RESOLUTION:  Modify the "ioCRS" handler in "muxlio" (hp2100_mux.c) to clear
     all 37 channel transmit and receive parameters in response to a CLC 0.
     Modify "mux_data_int" to use the "PUT_DCH" macro to put the data channel
     number into the return status.

     STATUS:  Fixed in version 3.7-1.



151. ENHANCEMENT:  Add debug printouts to the 12920A multiplexer.

     VERSION:  3.7-0

     OBSERVATION:  Debugging multiplexer behavior would be easier if the
     internal state of the simulator was observable and recordable.

     RESOLUTION:  Modify "hp2100_mux.c" to add debug-mode printouts.

     STATUS:  Fixed in version 3.7-1.



152. ENHANCEMENT:  Add debug printouts to the 12875A Interprocessor Link.

     VERSION:  3.7-0

     OBSERVATION:  Debugging HP 2000 Time Shared BASIC systems would be
     easier if the internal state of the link simulator was observable and
     recordable.

     RESOLUTION:  Modify "hp2100_ipl.c" to add debug-mode printouts.  Modify
     "sim_defs.h" to add a "DEBUG_PRJ" macro.

     STATUS:  Fixed in version 3.7-1.



153. PROBLEM:  The 2000 Access terminal multiplexer does not initialize properly
     approximately three starts in ten on multiprocessor host systems.

     VERSION:  3.7-0

     OBSERVATION:  Booting the 2000 Access Time Shared BASIC system appears to
     start the system correctly, but the terminal multiplexer does not work.
     Typing a CR does not produce the expected "PLEASE LOG IN" message, even
     though the system console is responsive.  Restarting the system often
     corrects the problem.

     CAUSE:  There is a race condition between the system processor (SP) and the
     I/O processor (IOP) during initialization.  A 321-word DMA transfer is done
     from the IOP to the SP.  Immediately after DMA completion, the SP pulses
     the interprocessor link to "set correct flag direction" (according to the
     Access source).  The SP depends on the IOP still being in the DMA
     completion interrupt handler when that pulse occurs, so that it does not
     cause an interrupt and subsequent command processing.

     On a multiprocessor host system, the SP and IOP SIMH processes may run in
     parallel.  If the SP is blocked after DMA completion and before the IPL
     pulse, the IOP may complete its own DMA completion interrupt handling and
     therefore see the pulse as a second DMA command request.  If that occurs,
     the IOP hangs in the DMA transfer, so it never completes initialization of
     the terminal multiplexer.

     RESOLUTION:  Modify the "ioEDT" handler in "iplio" (hp2100_ipl.c) to sleep
     for one millisecond before signaling a DMA completion interrupt for an
     output transfer.  This allows the SP time to pulse the IPL before the IOP
     processes the DMA completion interrupt.  Modify "dma_cycle" (hp2100_cpu.c)
     to pass the DMA channel number and I/O direction flag in the "dat"
     parameter to EDT handlers.

     Note that this is a workaround, and not a solution, as the SP can still
     block between DMA completion and IPL pulsing, which would allow the IOP to
     complete its DMA handling first.

     STATUS:  Fixed in version 3.7-1.



154. PROBLEM:  The 12920A multiplexer simulator encounters a buffer overrun
     error when the five "diagnose" lines are employed.

     VERSION:  3.7-0

     OBSERVATION:  Multiplexer line status is kept in "mux_sta", which is
     defined with 16 elements.  However, there are 21 receive lines for which
     status is kept.  When "mux_diag" is called to service the "diagnose" lines
     (lines 16-20), "mux_sta" is indexed beyond the end of its definition.

     CAUSE:  The size should be "MUX_LINES + MUX_ILINES" instead of "MUX_LINES".

     RESOLUTION:  Modify the size of "mux_sta" (hp2100_mux.c) from 16 to 21
     elements.

     STATUS:  Fixed in version 3.7-1.



155. PROBLEM:  Resetting the 12920A multiplexer does not clear status for the
     receive-only "diagnose" lines.

     VERSION:  3.7-0

     OBSERVATION:  Line status is kept in "mux_sta[0..20]".  Doing a multiplexer
     reset (e.g. RESET, RUN, etc.) clears line status only in lines 0-15.

     CAUSE:  Multiplexer line reset is handled by "mux_reset_ln" in response to
     a device reset.  "mux_reset_ln" is called only for lines 0-15.

     RESOLUTION:  Modify "muxc_reset" (hp2100_mux.c) to clear the variables
     associated with lines 16-20.

     STATUS:  Fixed in version 3.7-1.



157. PROBLEM:  The .DMP instruction returns erroneous results.

     VERSION:  3.7-3

     OBSERVATION:  After creating a FMGR file that occupies the rest of the
     cartridge, the "next track" field in the directory list is wildly
     incorrect.

     CAUSE:  An unsigned multiply is done instead of a signed multiply.
     Multiplying by a small negative number returns an overflow condition.

     RESOLUTION:  Convert the operands to signed integers before multiplying in
     "hp2100_cpu3.c".

     STATUS:  Fixed in version 3.8-0.



158. PROBLEM:  The .DDI instruction returns erroneous results.

     VERSION:  3.7-3

     OBSERVATION:  Attempting to scan an indexed library file that is split into
     multiple extents returns FMGR -012 (SOF or EOF error).  Accessing the
     library file sequentially avoids the error.

     CAUSE:  Extent calculations are in error.  An unsigned divide is done
     instead of a signed divide.

     RESOLUTION:  Convert the operands to signed integers before dividing in
     "hp2100_cpu3.c"

     STATUS:  Fixed in version 3.8-0.



159. ENHANCEMENT:  Portable unsigned-to-signed conversions were added.

     VERSION:  3.7-3

     OBSERVATION:  Conversions from unsigned to signed values, e.g., from
     "uint16" to "int16", using casts or union store/load are not portable.
     They will fail if the size in bits is > 16.  Portable versions are needed.

     RESOLUTION:  Add portable "INT16" and "INT32" macros (hp2100_defs.h) to
     provide uint16-to-int16 and uint32-to-int32 conversions.

     STATUS:  Fixed in version 3.8-0.



160. PROBLEM:  The action of jumpers W5 (JSB), W6 (INT), and W7 (SEL1) for the
     12892B Memory Protect card are reversed.

     VERSION:  3.7-3

     OBSERVATION:  The SET/SHOW MP command sets/reports the jumpers in the wrong
     state.  A jumper flag of 1 is reported as "in" but it is treated as "out"
     by the simulation.

     CAUSE:  The "mp_mod" table treats a jumper flag bit on as indicating an
     installed jumper, but the flag bit actually indicates a removed jumper.

     RESOLUTION:  Reverse the jumper sense in the "mp_mod" table (hp2100_cpu.c).

     STATUS:  Fixed in version 3.8-0.



161. PROBLEM:  The action of jumper W5 (JSB) is incorrect.

     VERSION:  3.7-3

     OBSERVATION:  Executing a JSB below the MP fence and to a write-protected
     page should cause a DM violation.  This occurs if W5 is in, but an MP
     violation is reported if W5 is out.

     CAUSE:  The W5 check is wrong.

     RESOLUTION:  Correct the JSB handler in "sim_instr" (hp2100_cpu.c) to
     report a DM error with W5 out (unless the instruction is JSB 0 or JSB 1, in
     which case an MP error is correct).

     STATUS:  Fixed in version 3.8-0.



162. PROBLEM:  The memory protect MEVFF is not reset when an I/O instruction is
     executed from a trap cell during an interrupt.

     VERSION:  3.7-3

     OBSERVATION:  The Memory Expansion Violation Flip-Flop (MEVFF) is set
     on any DMS violation: read protect, write protect, base-page protect, or
     privilege.  The MEVFF is cleared when MP is re-enabled after the violation
     is handled.

     Any interrupt request automatically disables MP.  MP is re-enabled
     explicitly via an STC 5 instruction or implicitly after a non-HLT I/O
     instruction is executed in the interrupt trap cell.  This latter case does
     not clear the MEVFF under simulation.

     CAUSE:  Improper coding in the interrupt handler.

     RESOLUTION:  Modify "sim_instr" (hp2100_cpu.c) to set "mp_mevff" to zero if
     a non-HLT I/O instruction is executed from a trap cell.

     STATUS:  Fixed in version 3.8-0.



163. PROBLEM:  Running certain RTE-6/VM configurations will cause an
     "unimplemented instruction" stop for the DIAG (100000) instruction.

     VERSION:  3.7-3

     OBSERVATION:  If an RTE-6/VM system is generated with a firmware
     replacement for the $LIBR routine, and a program using the software
     equivalent is run under that system, an "unimplemented instruction" stop
     occurs.  This is actually due to a bug in $RQST (EXEC6).  The instruction
     sequence executed is:

             XOR INSTR          NOW HAVE THE ADDRESS
             RAL,CLE,SLA,ERA    IF INDIRECT
       INDR  XLA A,I            GET NEXT LEVEL
             RAL,CLE,SLA,ERA    CHECK FOR MULTI LEVEL
             JMP INDR           FOUND ONE SO LOOP (MUST END)

     If the sign bit of the A register is zero, the first "RAL,CLE,SLA,ERA"
     improperly skips the first word of the two-word instruction "XLA A,I" and
     executes the second word (100000).  This decodes as a DIAG instruction.
     DIAG should execute as a NOP with the CPU running, as it is only effective
     when executed from single-step mode.  This would mask the bug, as the
     second "RAL,CLE,SLA,ERA" would also skip, taking execution out of the
     sequence; the bug fix would be to replace the first "RAL,CLE,SLA,ERA" with
     a "JMP *+3".  However, the simulator stops instead.

     CAUSE:  The DIAG processor executes as NOP on the E-Series, but no
     equivalent test is made for the F-Series.

     RESOLUTION:  Modify "cpu_eau" (hp2100_cpu1.c) to allow DIAG as NOP on the
     F-Series as well as the E-Series.

     STATUS:  Fixed in version 3.8-0.



164. ENHANCEMENT:  Add the RTE-6/VM operating system accelerator and virtual
     memory firmware instructions.

     VERSION:  3.7-3

     OBSERVATION:  RTE-6/VM "primary" (i.e., factory distribution) systems after
     revision 2401 were generated with the OS/VMA firmware replacements.  Such
     systems will not run under SIMH due to the lack of firmware support.  To
     get later revision systems running without firmware replacements requires a
     bootstrapping process that begins with revision 2340 and generates
     successive systems until the desired revision is reached.  Moreover, later
     revisions of some programs (e.g., TF) will not load due to exceeding the
     logical address space available when software replacements are used.

     RESOLUTION:  Add the OS/VMA instructions (hp2100_cpu5.c, hp2100_cpu6.c) to
     support later primaries and to provide address space reductions in later
     programs.  Add CPU debug support and flags for OS and VMA instructions.

     STATUS:  Fixed in version 3.8-0.



165. ENHANCEMENT:  Change the default breakpoint type from the current static
     setting of "-e" (break unconditionally) to a dynamic setting that matches
     the current DMS mapping ("-n", "-s", or "-u").

     VERSION:  3.2-1

     OBSERVATION:  After reaching a map-specific breakpoint (e.g., a system-map
     breakpoint to debug a device driver), the most common action is to examine
     memory locations and set another breakpoint farther ahead in the code.
     That breakpoint will, of course, be set in the same mapping mode as the one
     just reached, i.e., in the current DMS mapping mode.  Therefore, defaulting
     to "the same map as is currently enabled" leads to the most-used cases not
     requiring additional switches (and therefore the chance of operator error).

     RESOLUTION:  Before exiting "sim_instr" (hp2100_cpu.c), set "sim_brk_dflt"
     to a switch corresponding to the current DMS mapping mode.

     STATUS:  Fixed in version 3.8-0.



166. ENHANCEMENT:  Change the default examine/deposit addressing mode from the
     current static setting of "address is physical" to a dynamic setting that
     matches the current DMS mapping ("-s" or "-u"), and provide a new modifier
     option ("-n") to specify that an address is a physical address.

     VERSION:  3.2-1

     OBSERVATION:  After reaching a breakpoint, it is common to examine memory
     contents.  The most common requirement is to examine memory under the
     currently enabled map, i.e., if a break occurred under the system map, then
     examination of system memory is most likely to be requested (and
     correspondingly for user-map breakpoints).  However, the current default is
     to examine the first 32K of physical memory.  This is a reasonable default
     for non-DMS systems, or when DMS is not enabled, but is awkward when
     debugging mapped environments.

     A switch ("-v") is currently provided to request access under the current
     DMS map, but debugging with DMS active essentially requires specifying that
     switch on every EXAMINE and DEPOSIT command.  It would be more useful if
     this action were the default.

     RESOLUTION:  Modify "cpu_ex", "cpu_dep", and "dms_cons" (hp2100_cpu.c) to
     respond to redefined switch modifiers as follows:

       Old   New   Description
       ===   ===   ===========================================================
       -v          if DMS enabled, use current map, else use unmapped
             -n    use unmapped
       -s    -s    if DMS enabled, use system map, else illegal
       -u    -u    if DMS enabled, use user map, else illegal
       -p    -p    if DMS enabled, use DCPC port A map, else illegal
       -q    -q    if DMS enabled, use DCPC port B map, else illegal

     If a map specifier is used when DMS is not enabled, "Command not allowed"
     results.  Note that the SAVE and RESTORE commands always access memory
     unmapped.  Also, note that operation in non-DMS environments is unchanged,
     i.e., EXAMINE and DEPOSIT with no modifiers still access physical memory as
     before.

     STATUS:  Fixed in version 3.8-0.



169. PROBLEM:  The DPTR register in the DS device cannot be set to any value
     other than 0 or 1.

     VERSION:  3.7-3

     OBSERVATION:  The DPTR register is documented as an 8-bit "sector buffer
     pointer."  However, it is implemented as a single-bit flag in the REG
     structure.  This prohibits setting any value other than 0/1.

     CAUSE:  DPTR is improperly defined with the FLDATA macro.  It should use
     DRDATA instead.

     RESOLUTION:  Modify "ds_reg" (hp2100_ds.c) to define the DPTR register as
     DRDATA instead of FLDATA.

     STATUS:  Fixed in version 3.8-0.



170. ENHANCEMENT:  Add an implementation of the 12966A Buffered Asynchronous
     Communications Interface (BACI) card.

     VERSION:  3.7-3

     OBSERVATION:  Newer RTE primary systems will not run without a system
     console connected to a BACI card using DVR05, as support for the Teletype
     interface using DVR00 had been dropped.  Reconfiguring to a DVR00 driver is
     problematic if another "type 00 driver" (e.g., DVM00) is present in the
     equipment table ahead of DVR00.  Also, some RTE features, such as
     command-stack editing, don't work with the Teletype interface.  Having a
     BACI simulation would allow these systems to run "out of the box."

     RESOLUTION:  Add a BACI simulation (hp2100_baci.c) to the HP simulator.

     STATUS:  Fixed in version 3.8-0.



171. ENHANCEMENT:  Expose the current time base generator (CLK) poll time via a
     device register.

     VERSION:  3.7-3

     OBSERVATION:  It is often helpful to know the number of simulated CPU
     instructions per second on a host machine.  As the CLK device is calibrated
     to real time, knowing the tick rate and the service poll time would allow
     the calculation of the simulated MIPS.  The tick rate is given by the "SEL"
     register, but the poll time is set using a local variable and is not
     visible to the user.

     RESOLUTION:  Added global variable "clk_tick" and register "IPTICK"
     (instructions per tick) to the CLK device (hp2100_stddev.c).

     STATUS:  Fixed in version 3.8-0.



172. PROBLEM:  The "ioCRS" actions are incorrect in several devices.

     VERSION:  3.7-3

     OBSERVATION:  The "ioCRS" signal was added in 3.7-0 to all devices.  As an
     expedient, the action was defaulted to CLC SC, which was how CRS was
     handled before.  Most devices handle CRS as CLC, but not all do.  In
     particular, the TTY and DS devices do not.

     CAUSE:  Expediency.

     RESOLUTION:  Modified the "ioCRS" handlers in "tty_svc" (hp2100_stddev.c)
     and "ds_svc" (hp2100_ds.c) to implement the control reset signal correctly.

     STATUS:  Fixed in version 3.8-0.



173. PROBLEM:  The paper tape reader hangs at EOT after "rewinding" a tape.

     VERSION:  3.7-3

     OBSERVATION:  The POS register records the current position of the file
     attached to the PTR device.  The manual says, "...by changing POS, the user
     can backspace or advance the reader."  Attempting to re-read a tape by
     setting POS to 0 causes the reader to hang when the end-of-tape is
     encountered the second time.

     CAUSE:  The trailing-null counter, "ptr_trlcnt", is not reset when the
     position is.  Therefore, the automatic trailer function does not work the
     second time, and the reader hangs.

     RESOLUTION:  Reset "ptr_trlcnt" when a non-null character is read.

     STATUS:  Fixed in version 3.8-0.



174. PROBLEM:  The .PWR2 instruction returns the wrong value in the A register.

     VERSION:  3.7-3

     OBSERVATION:  The .PWR2 instruction returns the result of the expression
     (ab * 2 ^ n) in the A and B registers.  The B-register value is correct,
     but the A-register value is always 0.

     CAUSE:  The conversion of the high-word value in "fp_unpack" from "fop" to
     "mantissa" is incorrect.  Specifically, the cast to 16 bits should be done
     on the shifted value, but it is improperly done on the unshifted value, so
     that shifting right by 16 always yields a zero value.

     Note that the only other instruction to use "fp_unpack" is .FLUN, but that
     discards the A-register (high mantissa) value and instead returns the
     exponent in A, so the error does not manifest itself there.

     Also note that there are two "fp_unpack" implementations.  The one in error
     is the firmware floating-point version.  The hardware floating-point
     version in "hp2100_fp1.c" is correct and is used when HAVE_INT64 is defined
     during compilation.

     RESOLUTION:  Modify "fp_unpack" (hp2100_fp.c) to correct the conversion.

     STATUS:  Fixed in version 3.8-0.



175. PROBLEM:  The DBI self-test instruction does not skip.

     VERSION:  3.7-3

     OBSERVATION:  The double-integer firmware self-test is supposed to set the
     S register to 102077 octal and return to P+1.  Neither of these actions
     occur.

     CAUSE:  At the time that the DBI firmware was implemented, the source
     microcode and the installation manual were unavailable.  Subsequently, the
     source microcode was located, and the self-test action is now known.

     RESOLUTION:  Modify "cpu_dbi" (hp2100_cpu3.c) to add the proper
     implementation of the DBI self-test instruction.

     STATUS:  Fixed in version 3.8-0.



177. PROBLEM:  The four-word double-precision sine and cosine functions return
     erroneous results.

     VERSION:  3.7-3

     OBSERVATION:  The .SIN and .COS functions return improper values when SIS
     firmware is present.  When the firmware is absent, the results are correct.

     CAUSE:  .SIN and .COS call /CMRT, the common range reduction routine.  This
     routine is implemented in the SIS firmware.  The /CMRT firmware simulation
     is not setting the B register properly to the lower 16 bits of the
     reduction multiple.

     RESOLUTION:  Correct "cpu_sis" (hp2100_cpu4.c) to return the proper value
     in the B register for the /CMRT instruction.

     STATUS:  Fixed in version 3.8-0.



179. ENHANCEMENT:  Add infrastructure changes to support CPU idling in a future
     release.

     VERSION:  3.7-3

     OBSERVATION:  Idle support would be a welcome addition to the HP simulator.

     RESOLUTION:   Modify hp2100_stddev.c to change the TTY (console) input poll
     to use a 10 millisecond calibrated timer, to provide a synchronization
     routine for use by other devices with input polls, and to synchronize the
     CLK to the console poll if it is set for a 10-millisecond period.  Add
     UNIT_IDLE flags to the CLK and TTY input units.  Modify hp2100_mux.c and
     hp2100_baci.c to synchronize Telnet polling with the console poll.

     STATUS:  Fixed in version 3.8-0.



180. PROBLEM:  There is some dead code in hp2100_stddev.c, now that control
     character handling is in sim_console.c.

     VERSION:  3.7-0

     OBSERVATION:  In version 3.2-2, "tto_out" (hp2100_stddev.c) was altered to
     suppress output for all control characters (characters < 40 octal), except
     for BEL, BS, LF, and CR.  This was in support of the RTE line editor.

     In version 3.5-2, generalized support for control character output
     suppression was added to sim_console.c.  This obviated the HP-specific
     handling.  However, some of that code remained in hp2100_stddev.c.

     CAUSE:  Oversight.

     RESOLUTION:  Removed the redundant code.

     STATUS:  Fixed in version 3.8-0.



181. ENHANCEMENT:  Add the RTE-IVB extended memory area firmware instructions.

     VERSION:  3.7-3

     OBSERVATION:  The Pascal/1000 compiler (HP 92832A) relies on EMA
     instructions to manage its internal memory.  EMA software is available, but
     the compiler can exceed the available logical address space if they are
     employed, due to the size of the software routines.

     RESOLUTION:  Add the EMA instructions (hp2100_cpu5.c) to provide address
     space reductions in the Pascal compiler.  Add CPU debug support and flags
     for the EMA instructions.

     STATUS:  Fixed in version 3.8-0.



182. ENHANCEMENT:  Add the Vector Instruction Set firmware instructions.

     VERSION:  3.7-3

     OBSERVATION:  VIS was used in some HP programs, notably SPICE.

     RESOLUTION:  Add the VIS instructions (hp2100_cpu7.c) to provide support
     for HP-SPICE.  Add CPU debug support and flags for the VIS instructions.

     STATUS:  Fixed in version 3.8-0.



183. PROBLEM:  Single-stepping through interrupts does not report instruction
     execution properly.

     VERSION:  3.7-3

     OBSERVATION:  When single-stepping, the simulator prints the next
     instruction to be executed before pausing for a command.  When an interrupt
     is pending, the instruction printed is not correct.  Moreover, a
     single-step command at this point will execute two instructions.

     CAUSE:  There are two problems with the simulator.

     The first is with the simulator routine that prints the next instruction to
     be executed at the end of a step.  It is not checking whether an interrupt
     is pending.  The instruction printed is the next instruction that would
     have been executed, if there had not been an interrupt pending.  But
     because there was an interrupt pending, the next instruction actually
     executed is the trap-cell instruction.

     The second problem is that the simulator is not counting down events during
     the trap cell instruction execution.  During each normal instruction, the
     simulator decreases the event counter, including the step counter.  But it
     omits the decrement for the trap cell instruction.  So single-stepping with
     an interrupt pending actually causes two instruction executions: the
     trap-cell instruction, and the subsequent instruction (usually the target
     of the JMP or JSB in the trap cell).

     RESOLUTION:  Modify "fprint_sym" (hp2100_sys.c) to check for a pending
     interrupt, and if so, to print the trap cell instruction instead of the
     instruction at PC.  Modify "sim_instr" (hp2100_cpu.c) to decrement the
     event counter for trap cell instructions.

     STATUS:  Fixed in version 3.8-0.



184. PROBLEM:  The TTY output interrupt time is too short for MSU BASIC.

     VERSION:  3.7-3

     OBSERVATION:  When running MSU BASIC, this code eventually produces an
     "Indirect address loop, P: 37001 (STA 1,I)" error:

       10 PRINT "HELLO WORLD!"
       20 GOTO 10
       30 END

     CAUSE:  The TTY output rate is abnormally fast compared to the original
     hardware.  The ASR-33 operated at 10 characters per second.  The HP 2116
     processor ran at about 600 instructions per millisecond.  Therefore, the
     TTY would interrupt approximately every 60000 CPU instructions.  But the
     default SIMH configuration (SERIAL_OUT_WAIT) is to interrupt every 100
     instructions --  about 600x the rate of the actual Teletype.

     MSU BASIC (a contributed library program) maintains per-user I/O state
     buffers, one for each of four users, plus one for the I/O system.  When a
     TTY interrupt occurs, the program copies the per-user state into the I/O
     state buffer, enters the TTY driver to output a character, copies the
     updated I/O state back to the per-user buffer, and returns to a monitor
     loop to wait for the completion interrupt, which would occur 100
     milliseconds later on a real machine.

     It takes 85 instructions from the STC that starts the TTY output until the
     updated state copy is completed.  With the TTIME default of 100
     instructions, that is normally just enough time to complete the buffer
     transfer before another interrupt occurs.

     However, MSU BASIC also runs the time base generator (CLK) with a
     one-second period.  The TBG interrupt handler takes from 25 to 71
     instructions.  If the TBG interrupts while the TTY event is active, it will
     absorb enough instructions to cause the TTY interrupt to occur before the
     updated state copy is finished.  That leaves the per-user state buffer
     inconsistent.  As a result of the TTY interrupt, that inconsistent buffer
     is copied to the I/O state buffer, and mayhem ensues.

     RESOLUTION:  Lengthened the TTY output time in "tty_unit" (hp2100_stddev.c)
     from 100 to 200 instructions.

     STATUS:  Fixed in version 3.8-0.



185. ENHANCEMENT:  Add the SIGNAL/1000 firmware instructions.

     VERSION:  3.7-3

     OBSERVATION:  SIGNAL provides firmware acceleration for Fast Fourier
     Transforms and was used in some signal processing applications.

     RESOLUTION:  Add the SIGNAL instructions (hp2100_cpu7.c).  Add CPU debug
     support and flags for the SIGNAL instructions.

     STATUS:  Fixed in version 3.8-0.



186. ENHANCEMENT:  Add idle support to the HP 2100 simulator.

     VERSION:  3.8-0

     OBSERVATION:  The DOS and RTE operating systems keep the current time of
     day by counting TBG ticks.  To maintain accurate time, a simulation must
     run continuously.  Given this requirement for continuous operation, it
     would be helpful if the simulator idled the host processor when these
     operating systems were idle themselves.

     RESOLUTION:  Alter "cpu_mod" to add SET CPU IDLE/NOIDLE commands, and alter
     "sim_instr" to add idle detection for DOS and RTE (hp2100_cpu.c).

     STATUS:  Fixed in version 3.8-1.



188. ENHANCEMENT:  Add a simulation of the 12792C eight-channel multiplexer.

     VERSION:  3.8-0

     OBSERVATION:  The main terminal multiplexer for later RTEs was the 12792,
     and direct support was generated into primary systems from HP.  The A/B/C
     revisions of the multiplexer firmware used the same protocol and drivers on
     RTE-IVB and RTE-6/VM.  The D revision used an incompatible protocol and
     required different drivers that were supported only on RTE-6/VM.

     RESOLUTION:  Add the MPX device (hp2100_mpx.c) to simulate the 12792A/B/C,
     and alter "hp2100_sys.c" and "hp2100_defs.h" to add the device structure
     and default select code assignment.

     STATUS:  Fixed in version 3.8-1.



190. ENHANCEMENT:  Add a simulation of the 12620A/12936A Privileged Interrupt
     Fences.

     VERSION:  3.8-0

     OBSERVATION:  Privileged DOS and RTE systems require the use of a
     privileged interrupt fence card.  This is needed to run the 12920A
     16-channel multiplexer under RTE.  When configured for DIAG operation, the
     LPS device may be used as an RTE fence, although the corresponding line
     printer function is then lost.  The DOS fence (12936A) had a unique
     operation that is not duplicated by any existing simulation.

     RESOLUTION:  Add the PIF device (hp2100_pif.c) to simulate the 12620A and
     12936A, and alter "hp2100_sys.c" and "hp2100_defs.h" to add the device
     structure and default select code assignment.

     STATUS:  Fixed in version 3.8-1.



191. PROBLEM:  The action of certain I/O cards (e.g., the 12936A Privileged
     Interrupt Fence) cannot be modeled by SIMH.

     VERSION:  3.8-0

     OBSERVATION:  Certain I/O actions cannot be implemented within the current
     design of the I/O simulation.  For example, the 12936A card breaks the
     interrupt priority chain when flag OR control is set.  Simulation assumes
     that priority is broken when flag AND control are set.

     CAUSE:  The hardware has I/O signals for interrupt request (IRQ) and
     interrupt priority to lower-priority devices (PRL).  These signals are not
     modeled directly in SIMH.  Rather, they are implied by control, flag, and
     flag buffer set (for IRQ) and control and flag set (for PRL).  If an I/O
     card does not follow these conventions, then the proper action cannot be
     simulated.

     RESOLUTION:  Modify the I/O simulation structure to model hardware signals,
     rather than I/O instructions.  Verify each simulated device's action in
     response to each I/O backplane signal.  Verify each device's reset routine
     to ensure the proper response to RESET (POPIO signal) and RESET -P (PON
     signal).

     STATUS:  Fixed in version 3.8-1.



193. PROBLEM:  The DR and IPL boot loaders do not work.

     VERSION:  3.8-0

     OBSERVATION:  Attempting to boot the DR or IPL devices results in a hang in
     the bootstrap.  Examination shows that the I/O instructions are not being
     configured.

     CAUSE:  The loader protection feature added at revision 3.7-0 must be
     turned off in order to write programmatically to the boot loader area.
     Protection is automatically disabled for the devices using the "ibl_copy"
     function in the CPU, but the DR and IPL devices install their bootstraps
     within their boot routines and do not call "ibl_copy".

     RESOLUTION:  Modify "ipl_boot" (hp2100_ipl.c) and "drc_boot" (hp2100_dr.c)
     to use the "ibl_copy" routine.

     STATUS:  Fixed in version 3.8-1.



195. PROBLEM:  JSB to 0/1 with W5 out and fence = 0 erroneously causes MP abort.

     VERSION:  3.8-0

     OBSERVATION:  The upper bound of protected memory is set by the memory
     protect fence, and the lower bound is normally location 2.  However, the
     lower bound is 0 if the instruction is a JMP, or if the instruction is a
     JSB and jumper W5 is out.  That is, a JMP or a JSB (with W5 out) to any
     location under the memory protect fence will cause a violation.  If the
     fence is set to or below the lower bound, though, then MP violations will
     not occur.

     However, a JSB 0 or JSB 1 with the fence set to 0 or 1 and jumper W5 out
     still causes an MP abort.

     CAUSE:  Improper coding of the W5 test in the JSB simulation.

     RESOLUTION:  Modify the instruction dispatcher "sim_instr" (hp2100_cpu.c)
     to set the protected lower bound for JSB as indicated by W5 and to test the
     target address against the lower bound as well as the MP fence.

     STATUS:  Fixed in version 3.8-1.



196. PROBLEM:  The MEM (DMS) violation register is not being set properly.

     VERSION:  3.8-0

     OBSERVATION:  The STC handler within the MP I/O instruction routine "proio"
     contains an explicit clear of the MEM violation register.  There is no such
     action shown on either the MP or MEM card schematics.  When the statement
     is removed, the Memory Expansion Module Diagnostic (DSN 102103) fails in
     TST21, the "Violation Register Map Bits Test," with an "E302 VR MAP 00"
     error.

     TST21 generates three MEM violations and one MP violation.  The value of
     the MEM violation register is checked after all four violations to confirm
     that the map register address corresponds to the violation location.  The
     value after the MP violation is in error; the violation register still
     contains the value from the prior MEM violation.

     CAUSE:  The simulator updates the violation register whenever a MEM
     violation occurs.  The hardware actually updates the violation register for
     every memory read, every memory write above the lower bound of protected
     memory, and every execution of a privileged DMS instruction.  The register
     is "frozen" when MP is disabled by an MP or DM error to capture the state
     of the MEM (MEVFF sets or CTL5FF clears).

     Examining the violation register value after each MEM violation produces
     the expected result.  Examining it after the MP violation does not, because
     the register is not being set.  As it happens, the MP violation in the
     diagnostic occurs on page 0, so the problem is masked if the violation
     register is set to 0 when MP is enabled.  Other bits in the register are
     wrong in this case, but the diagnostic does not check them.

     It would be proper to fix this problem by updating the violation register
     after each memory access, as is done in hardware.  Fortunately, this isn't
     necessary, as the visible state of the violation register is only available
     via a programmed RVA/B instruction or via the SCP interface.  Therefore, it
     is sufficient if the register is updated:

      - at a DM violation (when freezing)
      - at an MP violation (when freezing)
      - during RVA/B execution (if not frozen)
      - before returning to SCP after a simulator stop (if not frozen)

     The first of these conditions is currently implemented.  The other three
     must be added to address the issue.

     RESOLUTION:  Add a new "dms_upd_vr" routine (hp2100_cpu.c) to update the
     MEM violation register value.  Modify the ABORT macro to take the address
     of the last memory access as the parameter.  Modify the MP abort handler to
     use the memory address to update the MEM violation register.  Add new
     update calls to the RVA/B simulator and to the cleanup code at the end of
     "sim_instr" before returning to SCP.

     STATUS:  Fixed in version 3.8-1.



197. PROBLEM:  The ME Bus Enabled bit in the MEM violation register is not being
     set properly.

     VERSION:  3.8-0

     OBSERVATION:  The ME Bus Enabled bit in the violation register reflects the
     state of the MEBEN (ME Bus Enable) signal on the MEM card.  MEBEN is
     asserted if the MEM is enabled (MAPON signal) and the last memory access
     was not to the unmapped portion of the base page (OFA signal).

     Under simulation, this bit is set if a MEM violation is either a read
     violation or a write violation, and it is clear otherwise (base page or
     privileged instruction violation).  This is correct only for the base page
     violation case; for the other three cases, MEBEN may be either high or low.

     CAUSE:  Incorrect logic in the "dms_viol" routine.

     A base page violation, by definition, occurs if a write is attempted to the
     unmapped portion of the base page.  MEBEN must be off in this case (BPV is
     qualified by -MEBEN).  Each of the other three violations could occur with
     MEBEN either asserted or denied.

     Consider a read from the base page with map 0 indicating read protection.
     If the read is from the mapped portion, MEBEN will be asserted.  If the
     read is from the unmapped portion, MEBEN will be denied.  In either case, a
     read violation will be indicated.  The same conditions pertain to a write
     to the base page with map 0 indicating write protection, and to an
     attempted privileged instruction execution from the base page.

     RESOLUTION:  Modify "dms_upd_vr" (hp2100_cpu.c) to call a new "is_mapped"
     routine to determine if an access is to unmapped memory.

     STATUS:  Fixed in version 3.8-1.



198. PROBLEM:  JMP to a write-protected page fails to signal a DMS violation.

     VERSION:  3.8-0

     OBSERVATION:  The "21MX M-Series Computer Operating and Reference Manual"
     states on page 4-2:

        Any attempt to write to a write-protected page will result in a write
        violation and the memory will not be altered.  In addition, if a page is
        write-protected, a jump or jump indirect instruction to that page will
        cause a write violation and the jump will not occur.

     The write violation for a JMP to a write-protected page does not occur.

     CAUSE:  Coding error in "mp_dms_jmp".

     MEM write and base-page violations are checked when an MPCK micro-order is
     executed.  MPCK asserts the MPCND signal if the address is above the lower
     bound of protected memory (0 for a JMP).  MPCND is qualified with the
     accessed page's write-protect bit for write violations, and with an
     "unmapped access to the base page" signal for base-page violations.  Any
     instruction that executes MPCK will enable these two violation checks, and
     all jump-type instructions do.

     Under simulation, the MEM check for base-page violations is done by the
     "mp_dms_jmp" routine.  However, this routine does not check for write
     violations.

     RESOLUTION:  Modify "mp_dms_jmp" (hp2100_cpu.c) to check for write
     violations as well as base-page violations.

     STATUS:  Fixed in version 3.8-1.



199. PROBLEM:  .GOTO to A/B causes incorrect MP violation.

     VERSION:  3.8-0

     OBSERVATION:  The lower bound of protected memory is normally location 2,
     allowing unrestricted access to the A and B registers (locations 0 and 1,
     respectively).  The MP card checks the instruction register and uses a
     lower bound of 0 for JMP, as well as for JSB if jumper W5 is out.  The JLY
     and JPY microcode also requests a lower bound of 0 by setting the IR to the
     JMP opcode before the MP check.

     Under simulation, the MP check against a lower bound of 0 is done by the
     "mp_dms_jmp" routine (hp2100_cpu.c).  However, this routine is also called
     for the DJP, SJP, UJP, JRS, and .GOTO instructions.  These latter
     instructions should allow access to the A/B registers, but they don't.

     CAUSE:  Logic error.

     RESOLUTION:  Modify "mp_dms_jmp" (hp2100_cpu.c) to accept the protected
     lower bound as a parameter, and modify the JMP, JSB, JLY, JPY, DJP, SJP,
     UJP, JRS, and .GOTO instruction handlers (hp2100_cpu.c, hp2100_cpu2.c, and
     hp2100_cpu3.c) to pass the desired lower bound value.

     STATUS:  Fixed in version 3.8-1.



200. PROBLEM:  UJP fails erroneously with a write-protect violation.

     VERSION:  3.8-0

     OBSERVATION:  Attempting to enable the user map with a UJP instruction
     fails if the target page in the system map is write-protected.

     CAUSE:  The instruction is checking the jump target in the wrong map.

     The DJP, SJP, and UJP instructions validate that the target address is not
     below the MP fence and on a write-protected page.  In firmware, these
     instructions alter the Memory Expansion Unit before validating the jump
     address.  For example, UJP enables the user map and then checks the target
     address using the user map.  Under simulation, the "mp_dms_jmp" check is
     issued before the map is changed, leading to failures.

     RESOLUTION:  Modify "cpu_dms" (hp2100_cpu2.c) to move the "mp_dms_jmp"
     checks to after the MEU update for the DJP, SJP, and UJP instructions.

     STATUS:  Fixed in version 3.8-1.



201. PROBLEM:  Several HP 2100 devices use registers variables < 32 bits without
     REG_FIT.

     VERSION:  3.8-0

     OBSERVATION:  Scalar register variables must be either 32 bits in size or
     declared with the REG_FIT flag.  In the absence of REG_FIT, a 32-bit access
     is assumed by the examine and deposit routines.  Several HP 2100 devices
     use 8- or 16-bit scalar variables as registers without REG_FIT.  This will
     cause failures on big-endian machines.

     Note that arrayed registers are automatically accessed at the minimum size
     implied by the "width" and "offset" values and therefore do not need
     REG_FIT.

     CAUSE:  Coding errors.

     RESOLUTION:  Modify hp2100_baci.c, hp2100_dp.c, hp2100_dq.c, and
     hp2100_mpx.c to add REG_FIT where needed.

     STATUS:  Fixed in version 3.8-1.



202. PROBLEM:  The HP 2100 CPU simulation shadows the A and B registers
     unnecessarily.

     VERSION:  3.8-0

     OBSERVATION:  The A and B register values are stored in two places: as
     "uint16 ABREG[2]" during execution, and as "uint32 saved_AR" and "uint32
     saved_BR" between executions.  The latter was to accommodate the
     requirement that register variables must be 32 bits in size.  That
     requirement was removed in version 3.5-2 for registers declared with the
     REG_FIT flag.

     With REG_FIT, "ABREG[0]" and "ABREG[1]" can be used directly as register
     values, and the code associated with saving and restoring the A and B
     registers can be eliminated.

     CAUSE:  The code wasn't updated to take advantage of the new feature.

     RESOLUTION:  Modify hp2100_cpu.c to use "ABREG[]" variables as register
     values with REG_FIT, and remove the "saved_AR" and "saved_BR" values and
     associated code.  Modify "msc_boot" (hp2100_ms.c) to use "AR" instead of
     "saved_AR".

     STATUS:  Fixed in version 3.8-1.



203. PROBLEM:  RTE break mode does not work with the 12920A multiplexer on fast
     host machines.

     VERSION:  3.8-0

     OBSERVATION:  Hitting the BREAK key when the terminal is idle or output is
     in progress should produce an RTE prompt.  BREAK works properly when the
     terminal is idle, but hitting BREAK when output is in progress does not
     produce a prompt.  This means that long outputs can be neither paused nor
     aborted.

     CAUSE:  The RTE multiplexer driver is a privileged driver.  Privileged
     drivers bypass RTE to provide rapid interrupt handling.  To inform RTE that
     an operation is complete, e.g., that a line has been written, the interrupt
     section of the driver sets a device timeout of one clock tick (10
     milliseconds).  When that timeout occurs, RTE is entered normally to
     complete the I/O transaction.  While the completion timeout is pending, the
     driver ignores any further interrupts from the multiplexer line.

     The maximum communication rate for the multiplexer is 2400 baud, or
     approximately 4.2 milliseconds per character transferred.  A typical line
     of 20 characters would therefore take ~85 milliseconds, plus the 10
     millisecond completion timeout, or about 95 milliseconds total.  BREAK
     recognition would be ignored for roughly 10% of that time.  At lower baud
     rates, recognition would be ignored for a correspondingly smaller
     percentage of the time.

     However, SIMH uses an optimized timing of 500 instructions per character
     transfer, rather than the ~6600 instructions that a character transfer
     should take, and so a typical 20-character line will take about 11,000
     instructions.  On the other hand, the clock tick is calibrated to real
     time, and 10 milliseconds of real time takes about 420,000 instructions on
     a 2.0 GHz PC.  To be recognized, then, the BREAK key must be pressed in a
     window that is open for about 2.5% of the time.  Therefore, the BREAK key
     will be ignored about 97.5% of the time, and RTE break-mode effectively
     will not work.

     RESOLUTION:  Defer BREAK recognition until either a character is output or
     a second successive input poll occurs, providing that we are not in
     diagnostic mode.  This ensures that the BREAK interrupt will be accepted.
     Added a "mux_defer[]" flag (hp2100_mux.c) to record break deferrals.

     STATUS:  Fixed in version 3.8-1.



204. ENHANCEMENT:  Add line connection order support to the 12920A multiplexer.

     VERSION:  3.8-0

     OBSERVATION:  RTE and DOS provide per-line device drivers for the 12920A
     multiplexer.  A method of specifying line connection order is needed, so
     that connection to specific device drivers is possible.

     RESOLUTION:  Add "SET MUX LINEORDER=<range>" and "SHOW MUX LINEORDER"
     commands to the 12920A simulator.

     STATUS:  Fixed in version 3.8-1.



205. PROBLEM:  The LOCKED, WRITEENABLED, and FORMAT commands do not work as
     documented.

     VERSION:  3.8-0

     OBSERVATION:  The HP2100 documentation says that the "SET MTC LOCKED"
     command write-locks the tape drive.  Attempting this, however, results in a
     "Non-existent parameter" error.

     CAUSE:  The commands are part of the wrong command table (MTD instead of
     MTC).

     RESOLUTION:  Modify "mtd_mod" and "mtc_mod" (hp2100_mt.c) to move the
     LOCKED, WRITEENABLED, and FORMAT commands to the command channel to be
     compatible with the MS tape device.

     STATUS:  Fixed in version 3.8-1.



206. PROBLEM:  Wrong mnemonic reported in IAK display for RTE-6/VM OS dual-use
     microcode instructions.

     VERSION:  3.8-0

     OBSERVATION:  RTE-6/VM OS instructions have four "dual-use" opcodes.  These
     have different meanings, and thus different mnemonics, depending on whether
     they are used in interrupt trap cells or not.  For example, the 105357
     opcode is $TBG (time-base generator interrupt handler) if in a trap cell
     and .DSPI (set display indicator) if not.  The mnemonic is correct for the
     EXAMINE command.  A single-step through an interrupt acknowledgement
     displays the wrong mnemonic:

        [CTRL+E]

        Simulation stopped, P: 02040 (JMP 2037)
        sim> s

        Step expired, P: 02037 (IAK 15: .DSPI)
        sim> e -m 15
        15:     $TBG

     The IAK report should also display $TBG.

     CAUSE:  The "fprint_sym" routine detects the IAK and obtains the trap cell
     value, but it fails to change the instruction address, so the address
     remains that of the interrupted instruction.  As dual-use mnemonics depend
     on the instruction address, the mnemonic reported is incorrect.

     RESOLUTION:  Modify "fprint_sym" (hp2100_sys.c) to set the instruction
     address for an interrupt acknowledgement to the interrupt trap cell
     address.

     STATUS:  Fixed in version 3.8-1.



207. PROBLEM:  The 3030 mag tape does not interrupt after a CLR command.

     VERSION:  3.8-0

     OBSERVATION:  Page 2-5 of the 12559A 9-Track Magnetic Tape Unit Interface
     Kit Operating and Service Manual says that the command channel flag
     flip-flop sets when the CLR command completes.  The MT simulator does not
     do this, so the command channel does not interrupt.

     CAUSE:  Coding error.

     RESOLUTION:  Modify "mtcio" (hp2100_mt.c) to set the command channel flag
     when the command completes.

     STATUS:  Fixed in version 3.8-1.



209. ENHANCEMENT:  Add a microcode simulation module for site-specific
     microprograms.

     VERSION:  3.8-0

     OBSERVATION:  The 2100 and 1000 CPUs supported user microprogramming.  A
     user of the HP2100 simulator may have user-written microcode that he would
     like to add to SIMH.  It would be helpful to have the infrastructure in
     place to aid in the implementation of site-specific microprogram
     simulations.

     RESOLUTION:  Add a new "cpu_user" microcode dispatcher and an example
     skeleton microcode simulator (hp2100_cpu0.c).  Alter "cpu_uig_0" and
     "cpu_uig_1" (hp2100_cpu1.c) to route any instruction not allocated to an
     installed firmware option to the user-microcode dispatcher.  In the absence
     of a user-microcode simulation for a given instruction, execution will
     cause an undefined instruction stop.

     STATUS:  Fixed in version 3.8-1.



210. PROBLEM:  The VIS and IOP options conflict on the 1000-F.

     VERSION:  3.8-0

     OBSERVATION:  The Vector Instruction Set and 2000/Access I/O Processor
     instructions share the same opcode range.  Only one or the other should be
     present at a time.  The SET CPU option processor does not enforce this.

     CAUSE:  The case was overlooked when VIS was added.

     RESOLUTION:  Modify "cpu_set_opt" (hp2100_cpu.c) to make the VIS and IOP
     options mutually exclusive on the 1000-F.

     STATUS:  Fixed in version 3.8-1.



211. PROBLEM:  Pressing BREAK on a BACI terminal under RTE locks the card.

     VERSION:  3.8-0

     OBSERVATION:  Under RTE, pressing the BREAK key on a BACI terminal session
     will cause that session to lock up.  If the session was writing, it will
     resume in four seconds.  If it was reading or idle, it will re-enable after
     the timeout period specified for the device in RTE.  If no timeout was
     specified, then the session will remain locked forever.

     CAUSE:  The RTE driver operates the BACI in character mode.  Normally,
     pressing a key while the session is writing or idle will bring up the RTE
     system prompt.

     Pressing BREAK enters a NUL into the FIFO and interrupts with the BREAK
     CONDITION bit set in the status word.  The driver ignores this by sending a
     "reset break status" command and then re-enabling interrupts with an STC
     sc,C instruction.  But the original interrupt was caused not by the BREAK
     status (there is no explicit interrupt-on-BREAK function) but rather by the
     presence of a received character in the FIFO.  So the BACI attempts to
     interrupt again, this time with the BREAK CONDITION bit clear.

     This second interrupt would normally be allowed, as the STC sc,C
     instruction clears the "interrupt lockout" flag that was set when the first
     interrupt was generated.  However, the STC signal handler checks for
     interrupt status between the STC and the succeeding CLF, rather than after
     the CLF.  The result is that the STC clears lockout, then the FIFO status
     sets the flag and lockout, and then the CLF clears the flag, leaving
     interrupt lockout set.  At that point, no interrupt is pending, and no
     future interrupts can occur, because the lockout flag prevents them.

     When device timeout occurs, the card is reinitialized and then re-enabled,
     so it becomes responsive again.

     RESOLUTION:  Modify "baci_io" (hp2100_baci.c) to update the interrupt
     status after the CLF of a STC sc,C instruction.

     STATUS:  Fixed in version 3.8-1.



212. PROBLEM:  Setting a breakpoint on an interrupt trap cell does not work.

     VERSION:  3.8-0

     OBSERVATION:  If a breakpoint is set on an interrupt trap cell, the
     breakpoint does not trip when the corresponding interrupt occurs and the
     trap cell contents are executed.

     CAUSE:  The breakpoint detection code is only in the "normal instruction"
     execution path.

     RESOLUTION:  Modify "sim_instr" (hp2100_cpu.c) to add breakpoint detection
     to the "interrupt trap cell" execution path.

     STATUS:  Fixed in version 3.8-1.



214. PROBLEM:  DMA/DCPC cannot steal consecutive I/O cycles.

     VERSION:  3.8-1

     OBSERVATION:  All DMA and DCPC cards are capable of stealing consecutive
     I/O cycles, presuming that SRQ is asserted at the proper time before each
     cycle.  The current SIMH implementation of DMA/DCPC is capable of stealing
     only every other cycle, even if SRQ is asserted continuously.  The 12821A
     Disc Interface diagnostic checks for consecutive cycle-steal capability and
     fails when run.

     CAUSE:  Each pass through the instruction simulation loop does a device
     timeout check, then a potential DMA cycle, and then an instruction cycle.
     The device timeout calls the card unit service routine, which sets SRQ and
     schedules the next service.  The SRQ is then processed with the DMA cycle,
     which dispatches ioIOI/IOO and ioCLF to the device.  At the end of the DMA
     cycle, the next instruction is executed.

     A device capable of transferring data continuously would leave SRQ asserted
     after the I/O cycle.  But because SRQ is not checked after the DMA cycle,
     the next instruction execution is performed unconditionally.  Therefore,
     even with continuous SRQ assertion, the simulator will interleave DMA
     cycles and instructions.

     RESOLUTION:  Modify the instruction execution loop (hp2100_cpu.c) to
     recalculate SRQ requests after each DMA cycle, and if a request is still
     pending, skip instruction execution.  This allows consecutive DMA cycles
     without intervening instruction executions if SRQ is asserted continuously.

     STATUS:  Fixed in version 3.9-0.



215. PROBLEM:  DMA/DCPC does not give priority to channel 1 during contention.

     VERSION:  3.8-1

     OBSERVATION:  Dual-channel DMA/DCPC cards give priority to channel 1 if
     both channels are requesting a DMA cycle.  If channel 1 SRQ is asserted
     continuously, then no channel 2 cycles will occur until channel 1
     completes.

     Under simulation, channel cycle requests alternate unconditionally.  If
     channel 2 requests a DMA cycle, it will always be granted, regardless of
     any pending channel 1 requests.

     CAUSE:  Each pass through the instruction simulation loop checks for a
     channel 1 request and then a channel 2 request, dispatching DMA cycles as
     indicated.  The check for a channel 2 request should not occur if a channel
     1 request is still pending at the end of its DMA cycle.

     RESOLUTION:  Modify the instruction execution loop (hp2100_cpu.c) to
     inhibit DMA channel 2 if a channel 1 request is still pending after a
     channel 1 cycle.

     STATUS:  Fixed in version 3.9-0.



216. ENHANCEMENT:  Rename DMA channels 0 and 1 to 1 and 2 to match the
     documentation.

     VERSION:  3.8-1

     OBSERVATION:  The HP 2100 simulator presents DMA0 and DMA1 as the DMA
     devices.  However, all HP literature refers to these as channel 1 and
     channel 2.

     RESOLUTION:  Modify the device names (hp2100_cpu.c, hp2100_defs.h, and
     hp2100_sys.c) from 0 and 1 to 1 and 2 to align with HP usage.

     STATUS:  Fixed in version 3.9-0.



217. PROBLEM:  The comments for "cpu_set_idle" (hp2100_cpu.c) are obsolete.

     VERSION:  3.8-1

     OBSERVATION:  The comments for the above routine note the requirement for
     clock stabilization.  This was added in 3.8-1, but the comments were not
     changed.

     CAUSE:  Oversight.

     RESOLUTION:  Removed obsolete comments.

     STATUS:  Fixed in version 3.9-0.



218. PROBLEM:  The 12578A DMA device is modeled incorrectly.

     VERSION:  3.8-1

     OBSERVATION:  The 12578A DMA device simulation incorporates a latency
     counter that delays the first DMA cycle for one instruction after the STC
     is issued to enable the channel.  This is incorrect; if SRQ is already
     asserted, the first cycle occurs immediately after the channel is enabled.

     CAUSE:  Incorrect understanding.

     RESOLUTION:  Modify hp2100_cpu.c to remove the latency counter.

     STATUS:  Fixed in version 3.9-0.



219. PROBLEM:  DMA IOO and CLF/EDT signals are not concurrent.

     VERSION:  3.8-1

     OBSERVATION:  A DMA transfer to the 12821A Disc Interface should not set
     the end-of-data-transfer flip-flop on the DI card until the last word has
     been sent.  Instead, each word transferred sets the flip-flop.

     CAUSE:  In the packed output mode, the end-of-data-transfer flip-flop is
     set either if the the OTx instruction does not clear the flag (i.e., if OTA
     used instead of OTA,C), or if the DMA EDT signal is asserted.  DMA
     transfers are programmed to clear the flag with each write to prevent the
     flip-flop from setting until the EDT signal asserts when the last word is
     output.

     In hardware, CLF or EDT is asserted concurrently with IOO.  In simulation,
     "dma_cycle" calls the device's I/O signal handler with ioIOO, then with
     ioCLF, and then, for the last cycle only, with ioEDT.  At the time that the
     handler receives ioIOO, it has no way of knowing whether ioCLF will follow.
     Therefore, the DI sets its end-of-data-transfer flip-flop on the first word
     transferred instead of on the last word transferred.

     The fundamental problem is that DMA hardware may assert multiple concurrent
     signals, upon which I/O card designs may test and act, but simulation
     serializes the signals and therefore prevents concurrency detection.

     RESOLUTION:  Modify "dma_cycle" (hp2100_cpu.c) to send one set of
     concurrent I/O signals to the target handler for each DMA I/O cycle, and
     modify all I/O device handlers to allow processing of multiple concurrent
     signals.

     STATUS:  Fixed in version 3.9-0.



220. ENHANCEMENT:  Enhance the I/O signal dispatcher to provide for multiple
     devices controlled by the same device signal handler.

     VERSION:  3.8-1

     OBSERVATION:  Currently, the DCPC, IPL, and DI simulations control multiple
     devices.  The first two control a pair of devices each and determine the
     desired device by checking the select code.  The DI will control three,
     complicating the test that would have to be done at each signal handler
     entry.

     RESOLUTION:  Modify "devdisp" (hp2100_cpu.c) to pass the Device Information
     Block (DIB) pointer instead of the select code to device signal handlers,
     and modify all signal handlers accordingly.  Modify all device DIBs to add
     card numbers to allow for multiple-device handlers.

     STATUS:  Fixed in version 3.9-0.



221. PROBLEM:  The LPS diagnostic mode is modeled incorrectly.

     VERSION:  3.8-1

     OBSERVATION:  The 12578A DMA simulation was modified to remove the latency
     from enabling a channel to issuing the first DMA cycle.  After this change
     was made, the card failed DMA diagnostic test 17.

     CAUSE:  The LPS device offers a diagnostic mode that simulates a 12566B
     Microcircuit Interface card equipped with a loopback connector.  This
     configuration is used for a number of diagnostics that require an I/O card
     in addition to the card under test.  Typically, this is to test I/O or
     interrupt capability.  Jumpers on the card configure it for the diagnostic
     response expected.  The SET LPS DIAG mode configures the card properly for
     all diagnostics except the 12578A DMA diagnostic.

     SET LPS DIAG simulates jumper W1 in position C and W2 in position B.  In
     these positions, an STC will set the card flag one instruction later.  When
     used for a DMA transfer, instructions and DMA cycles will interleave 1:1,
     i.e., DMA will steal every other cycle.

     The 12578A diagnostic requires jumper W1 in position B and W2 in position
     C.  In these positions, an STC will set the card flag two instructions
     later, so DMA will steal every third cycle, allowing two instructions
     between DMA cycles.  The 12578A diagnostic depends on this and will report
     errors otherwise.

     RESOLUTION:  Modify "lpsio" (hp2100_lps.c) to schedule device service in
     DIAG mode in three instructions if the CPU is a 2114, 2115, or 2116 and in
     two instructions otherwise.

     STATUS:  Fixed in version 3.9-0.



222. PROBLEM:  The 12821A Disc Interface diagnostic aborts with "Unit not
     attached."

     VERSION:  3.8-1

     OBSERVATION:  The 12821A Disc Interface diagnostic locates the card to test
     by issuing a CLC sc,C / OTA sc / LIA sc sequence to each card in the card
     cage; this writes a zero value and then looks for a specific response that
     is characteristic of the DI.  When the zero value is written to the MT
     device (HP 3030 tape drive), it responds with "Unit not attached."

     CAUSE:  The MT device is unusual in that commands are executed when they
     are written to the card, rather than in response to STC.  Therefore, when
     the zero value is written, the MT device attempts to interpret that value
     as a command.

     The IOO processor checks for a valid command before proceeding.  Zero is
     not a valid command, but the check is not coded properly.  The search
     through the command table loops for the number of bytes in the table, not
     for the number of entries.  One of the values beyond the end of the table
     equals zero, so the command is considered valid, and unit service is
     scheduled.  The unit service routine determines that the unit is not
     attached and returns an error code, causing a simulator stop.

     RESOLUTION:  Modify "mtcio" (hp2100_mt.c) to use the count of command table
     entries as the loop count.

     STATUS:  Fixed in version 3.9-0.



223. ENHANCEMENT:  Consolidate reporting of consecutive CRS signals.

     VERSION:  3.8-1

     OBSERVATION:  HP 2000 Time Shared BASIC begins its start sequence by
     issuing 128K CLC 0 instructions.  This sequence is required by the 12920A
     Terminal Multiplexer.  If debugging is enabled, the IPL device writes 128K
     lines to the log file.  It would be more helpful if the ioCRS processor
     detected consecutive calls and summarized them in a single line.

     RESOLUTION:  Modify "iplio" (hp2100_ipl.c) to add a CRS invocation counter
     and to report a single debug line for consecutive CRS calls.

     STATUS:  Fixed in version 3.9-0.



224. PROBLEM:  Simulation stops are ignored during DMA cycles.

     VERSION:  3.8-1

     OBSERVATION:  An I/O routine may return an error code other than SCPE_OK to
     stop the simulator.  For example, IPL may return SCPE_IOERR if STC is
     issued to a card with a disconnected socket.  If the device is invoked via
     programmed I/O, an error value return will cause a simulation stop.  If the
     device is invoked by DMA, it will not.

     CAUSE:  The "iogrp" function returns the status code to the instruction
     loop, but the "dma_cycle" function ignores status returns from the I/O
     handlers.

     RESOLUTION:  Modify "dma_cycle" (hp2100_cpu.c) to return the status from
     the device signal handler, and modify "sim_instr" to stop instruction
     execution if the returned status is not SCPE_OK.

     STATUS:  Fixed in version 3.9-0.



225. PROBLEM:  Simulation stops do not always preserve the CPU state for
     restarting.

     VERSION:  3.8-1

     OBSERVATION:  If the CPU simulator is stopped by certain errors, e.g., an
     unimplemented instruction execution, simulation control returns with the
     CPU state set as it was just prior to the error.  This allows the error to
     be corrected and simulation to be resumed.  It also allows identification
     of the problem instruction.

     Other errors, e.g., SCPE_IOERR returned by the IPL device signal handler,
     stop the CPU after processing the offending instruction.  In this case, the
     PC points to the instruction after the offending instruction, so
     identification, correction, and resumption are more difficult.  DMA cycles
     are also affected, as DMA registers are updated even if the I/O cycle
     fails.

     CAUSE:  The CPU instruction and DMA cycle routines do not back out properly
     when a simulation stop is indicated by a device signal handler.

     RESOLUTION:  Modify "sim_instr" (hp2100_cpu.c) to back out the current
     instruction if it indicates a simulation stop (except for the HLT
     instruction), modify "dma_cycle" to update the address and word count only
     if the I/O cycle completes successfully, and modify "iplio" (hp2100_ipl.c)
     to allow for restarting of a failed I/O cycle.

     STATUS:  Fixed in version 3.9-0.



226. PROBLEM:  The comments for the floating-point divide routine are
     incomplete.

     VERSION:  3.8-1

     OBSERVATION:  In the comments for the "divide" function in "hp2100_fp1.c",
     the explanation of the simulation implementation trails off with, "The
     resulting 32-bit quotient is ..."  It appears that the comments were never
     finished before release.

     CAUSE:  Oversight.

     RESOLUTION:  Expanded and completed the comments in the "divide" function
     (hp2100_fp1.c).

     STATUS:  Fixed in version 3.9-0.



227. PROBLEM: The 13037 disc controller returns incorrect status for a disabled
     drive.

     VERSION:  3.8-1

     OBSERVATION:  The same "unit present; heads unloaded" status is reported
     for both an enabled but unattached unit and a disabled unit.  The latter
     should report "unit not present" status.

     CAUSE:  SIMH initially defines the DS device as having eight 7905 drives
     connected to the controller.  Each drive reports "heads unloaded" status
     (Status-2 bits 1-0 = 11) until it has a disc image attached.  If a unit is
     disabled, it continues to report "heads unloaded" status.  It should be
     reporting "unit not present" (Status-2 bits 1-0 = 10) status.

     RESOLUTION:  Modify "ds_updds2" (hp2100_ds.c) to report an "enabled and
     unloaded" condition as Not Ready and Busy, and a "disabled" condition as
     Not Ready only.

     STATUS:  Fixed in version 3.9-0.



228. PROBLEM:  The 13037 disc controller returns incorrect status for an
     auto-seek beyond the drive limits.

     VERSION:  3.8-1

     OBSERVATION:  When an auto-seek causes the disc address to move beyond the
     drive limits, the wrong status is returned.  For example, the following
     OPDSN program:

       SM,3         -- set file mask to auto-seek, cylinder mode, incremental
       SK,410,2,47  -- seek to last sector of the drive
       RD,256       -- read two sectors
       EN

     ...results in Cylinder Compare Error status; status-2 shows a seek check.
     The result is identical if SM,1 (surface auto-seek, rather than cylinder
     auto-seek) is used.

     If the RD,256 is replaced by RF,276, the result is Normal Completion and a
     seek check.  The resulting disc address is 411,0,1.

     If decremental seeks are used:

       SM,13        -- set file mask to auto-seek, cylinder mode, decremental
       SK,0,2,47    -- seek to last sector of the first cylinder
       RD,256       -- read two sectors
       EN

     ...the status return is the same as above.

     In each of these cases, the result should be Status-2 (Seek Check) on the
     second sector transfer.

     CAUSE:  If an auto-seek exceeds the drive bounds, a seek check is correctly
     detected, but it is not reported back to the host.

     RESOLUTION:  Modify "ds_start_rw" (hp2100_ds.c) to check for Seek Check on
     an auto-seek and to report Status-2 if set.  Also, a reseek resulting from
     a cylinder miscompare now either succeeds if the cylinder is valid or
     reports Status-2 and Seek Check if the cylinder is invalid.  Finally, an
     invalid head or sector value reports Status-2 and Seek Check instead of
     Head-Sector Compare Error (Head-Sector and Cylinder Compare Errors can only
     occur during sparing operations which are not supported in simulation).

     STATUS:  Fixed in version 3.9-0.



229. PROBLEM: The 13037 Read Without Verify command does not verify the address
     when a track boundary is crossed.

     VERSION:  3.8-1

     OBSERVATION:  The Read Without Verify command is identical to the Read
     command except that it skips address verification before beginning the
     read.  If the read continues past a track boundary and auto-seek is
     enabled, the new track location should be verified.  This does not occur.
     The following OPDSN program illustrates the problem:

       SM,3           -- set file mask to auto-seek, cylinder mode, incremental
       SK,0,0,47      -- seek to last sector on cylinder 0 head 0
       DB,128,000047  -- fill the sector buffer with the CHS address
       WD,128         -- write sector 0/0/47
       DB,128,000100  -- fill the sector buffer with the CHS address
       WD,128         -- write sector 0/1/0
       SK,1,0,47      -- seek to the last sector on cylinder 1 head 0
       DB,128,100047  -- fill the sector buffer with the CHS address
       WD,128         -- write sector 1/0/47
       DB,128,100100  -- fill the sector buffer with the CHS address
       WD,128         -- write sector 1/1/0
       SK,0,0,47      -- seek to last sector on cylinder 0 head 0
       AR,1,0,47      -- change controller address to cylinder 1
       RW,256         -- read two sectors
       DR,120,135     -- display end of first sector and start of second sector
       EN

     If address verification is performed at the end of track 0, the second
     sector will be read from 1,1,0 instead of 0,1,0 because of the cylinder
     miscompare after the auto-seek:

       0120: 000047  000047  000047  000047  000047  000047  000047  000047
       0128: 100100  100100  100100  100100  100100  100100  100100  100100

     However, the above program prints:

       0120: 000047  000047  000047  000047  000047  000047  000047  000047
       0128: 000100  000100  000100  000100  000100  000100  000100  000100

     ...indicating that address verification was not done for either sector.
     Note that if the Read Without Verify above is changed to Read (RD,256), the
     result is:

       0120: 100047  100047  100047  100047  100047  100047  100047  100047
       0128: 100100  100100  100100  100100  100100  100100  100100  100100

     ...indicating that address verification was done correctly for the first
     sector.

     CAUSE:  The Read Without Verify handler disables address verification for
     the entire transfer.  It should be disabled only until a track switch
     occurs.

     RESOLUTION:  Modify the Read Without Verify command handler in "ds_svc_u"
     (hp2100_ds.c) to begin verifying if a track boundary is crossed.

     STATUS:  Fixed in version 3.9-0.



230. PROBLEM:  The 13037 Request Sector Address command does not check the unit
     number.

     VERSION:  3.8-1

     OBSERVATION:  The Request Sector Address command accepts invalid, unloaded,
     or missing units without reporting status errors.  Also, the specified unit
     number is not reported in the status-1 field of a subsequent Request Status
     command.  Assuming that unit "ds1" is not attached (heads unloaded) and
     unit "ds2" is disabled, the following OPDSN programs illustrate the
     problem:

       SD,1
       RA
       ST
       SC,0001001100000001,1XXXXXX000X00011
       DR,0
       EN

       SD,2
       RA
       ST
       SC,0001001100000010,1XXXXXX000X00010
       DR,0
       EN

       SD,10
       RA
       ST
       SC
       DR,0
       EN

     All of these should return Status-2 but instead return Normal Completion.

       SD,15
       RA
       ST
       SC,0001011100001111,1XXXXXX000X00010
       DR,0
       EN

     This should return Unit Unavailable but instead returns Normal Completion.

     CAUSE:  The Request Sector Address command handler is not checking the unit
     range or status.

     RESOLUTION:  Modify "ds_docmd" (hp2100_ds.c) to set the unit number into
     the status-1 field and to check for invalid units and report Unit
     Unavailable if so.  Modify "ds_svc_u" to check that the heads are loaded on
     the target unit and report Status-2 if not.

     STATUS:  Fixed in version 3.9-0.



231. PROBLEM:  The 13037 Wakeup command does not check the unit number.

     VERSION:  3.8-1

     OBSERVATION:  The Wakeup command accepts invalid units without reporting
     status errors.  Also, the specified unit number is not reported in the
     status-1 field of a subsequent Request Status command.

     CAUSE:  The Wakeup command handler is not checking the unit range.

     RESOLUTION:  Modify "ds_docmd" (hp2100_ds.c) to set the unit number into
     the status-1 field and to check for invalid units and report Unit
     Unavailable if so.

     STATUS:  Fixed in version 3.9-0.



233. ENHANCEMENT:  Add a simulation of the ICD series of disc drives and the
     12821A Disc Interface.

     VERSION:  3.8-1

     OBSERVATION:  The ICD drives were lower-cost versions of the earlier MAC
     drives that incorporated single-drive controllers in the drive chassis.
     This obviated the requirement for the separate 13037 disc controller.  They
     were interfaced via the 12821A HP-IB Disc Interface card; this card was
     also used to interface CS/80 disc and Amigo tape drives, such as the 7912
     and 7974A.

     The addition of an ICD simulation allows preparation and direct exchange of
     image files with the "HPDrive" disc emulator to enable hardware CPUs to run
     with emulated drives.

     RESOLUTION:  Add a simulation of the 12821A Disc Interface (hp2100_di.c
     and hp2100_di.h).  Add the DA device to simulate the ICD disc drives and
     the ICD disc loader ROM (hp2100_di_da.c).  Generalize the controller code
     in the DS simulation into a common disc simulation library (hp_disclib.c
     and hp_disclib.h).  Alter "hp2100_sys.c" and "hp2100_defs.h" to add the
     device structure and default select code assignment.

     STATUS:  Fixed in version 3.9-0.



234. ENHANCEMENT:  Revise the simulator and documentation to use the term
     "select code" instead of "device number."

     VERSION:  3.8-1

     OBSERVATION:  The HP2100 simulator and documentation use the terms "device
     number," "device address," and "DEVNO" to refer to the I/O addresses of the
     CPU interface cards.  These terms are alien to HP users; all of the CPU and
     interface documentation, from the 2116 through the 1000, use the term
     "select code" for this property.

     With the addition of the 12821A disc interface and associated HP-IB drives,
     the terms in use are now confusing as well.  The switches on the drives
     that set the bus addresses are labelled, "HP-IB DEVICE ADDRESS."  Other HP
     disc and tape drive manuals refer to "unit addresses" or "unit numbers" to
     indicate the addresses that differentiate multiple drives on a given
     interface.

     It would be clearer, especially to new users, if the existing terms were
     deprecated in preference to "select code" in the simulator and
     documentation.

     RESOLUTION:  Modify all I/O device simulators to add "SC" as an alias for
     "DEVNO" in the register and modifier tables, retaining "DEVNO" to preserve
     backward compatibility with existing procedures and command files.  Add
     MTAB_NMO to the DEVNO modifier entry so that it does not appear in EXAMINE
     or SHOW lists but can still be displayed or modified if requested
     explicitly.  Add hp_setsc and hp_showsc functions (hp2100_sys.c) to set and
     show the select code, and modify hp_setdev and hp_showdev to call hp_setsc
     and hp_showsc, respectively, and to work around newline suppression for
     MTAB_NMO entries.  Modify the documentation to change device number
     references to select code references.

     STATUS:  Fixed in version 3.9-0.



235. ENHANCEMENT:  Deprecate the device name CLK in favor of TBG.

     VERSION:  3.8-1

     OBSERVATION:  The CLK device provides a simulation of the 12539C Time Base
     Generator interface.  This interface is universally known to HP users as
     the TBG.  It would be clearer for these users if the device were named TBG.

     RESOLUTION:  Modify clk_dev (hp_stddev.c) to add "TBG" as the logical name.
     This still allows use of the CLK name for existing command files.

     STATUS:  Fixed in version 3.9-0.



236. PROBLEM:  The 13037 disc controller indicates a data under/overrun
     incorrectly.

     VERSION:  3.8-1

     OBSERVATION:  The 13037 disc simulator monitors the data transfer during a
     read or write operation.  A data overrun is indicated if SRQ is still set
     when a data transfer is ready, indicating that the previous transfer has
     not been handled yet by DCPC.  However, the interface contains a 16-word
     FIFO, so an overrun should be indicated only if the FIFO is full when a
     read transfer is ready or empty when a write transfer is ready.

     A read transfer writes a word to the FIFO and sets SRQ.  Currently, DCPC
     must remove the word and clear SRQ before the next read transfer occurs,
     even though 15 empty slots still remain in the FIFO.  Similarly, a write
     transfer reads a word from the FIFO and sets SRQ.  DCPC must supply the
     next word and clear SRQ before the next write transfer occurs, even though
     available words may remain in the FIFO.  Effectively, the FIFO doesn't
     exist, as the simulator treats it as a single-word register.

     Moreover, the SRQ generation logic does not attempt to keep the FIFO full
     for a write or empty for a read.  If DCPC activity on the other channel
     delays the DS channel, even by one word, an overrun is indicated, even
     though available space remains in the FIFO.

     CAUSE:  Incomplete FIFO implementation.

     RESOLUTION:  Modify the read and write data transfer logic (hp2100_ds.c) to
     indicate a data overrun when the FIFO is full or empty, respectively, and
     extend the SRQ logic to continue requesting DCPC transfers until the FIFO
     is empty (read) or has five words present (write), as in the hardware.

     STATUS:  Fixed in version 3.9-0.



237. PROBLEM:  The 13037 disc controller Clear command clears too much.

     VERSION:  3.8-1

     OBSERVATION:  In hardware, the Clear command issues a Controller Preset
     (CPS) tag to all connected disc drives.  The description of CPS says that
     it clears drive faults, the drive head and sector registers, the drive
     illegal head and sector address flip-flops, and the seek check, first
     status, drive fault, and attention status bits.  In simulation, the
     "ds_clear" routine clears the drive current cylinder register and all
     status bits.

     CAUSE:  Incorrect implementation.

     RESOLUTION:  Modify "ds_clear" (hp_disclib.c) to clear just the indicated
     drive status.

     STATUS:  Fixed in version 3.9-0.



238. PROBLEM: The 13037 Recalibrate command clears the End-of-Cylinder flag.

     VERSION:  3.8-1

     OBSERVATION:  The 13037 disc controller provides the Recalibrate command to
     recover from Cylinder Compare errors.  Recalibrate does not alter the
     cylinder, head, or sector address in the controller.  This allows a Read to
     follow the Recalibrate directly without requiring an intervening Seek.

     However, the DS simulator clears the EOC flag.  This flag indicates that
     the controller cylinder address must be incremented before it is used by
     the read or write routines.  Therefore, a Read following a Recalibrate will
     begin at the wrong address if the last successful read ended after the
     last sector on a track.

     CAUSE:  Oversight.

     RESOLUTION:  Modify the "ds_opflags" table (hp2100_ds.c) to remove the
     CMF_CLREC flag from the Recalibrate entry.

     STATUS:  Fixed in version 3.9-0.



239. PROBLEM:  The 13037 Request Status command reports Normal Completion for an
     invalid unit.

     VERSION:  3.8-1

     OBSERVATION:  The Request Status command includes a unit number field to
     specify the disc drive whose status is returned in the second word.  The
     unit number is checked for validity, and a "unit not present" status is
     returned if the number is invalid.  However, if the unit number is illegal
     (i.e., > 10), the command sets Normal Completion status instead of Unit
     Unavailable status.

     CAUSE:  The status is set without checking for unit number legality.

     RESOLUTION:  Modify "ds_svc_c" (hp2100_ds.c) to set Unit Unavailable status
     if the supplied unit number is greater than 10.

     STATUS:  Fixed in version 3.9-0.



240. PROBLEM:  The 13037 Cold Load Read and Seek commands do not set Seek Check
     if issued while a seek is in progress.

     VERSION:  3.8-1

     OBSERVATION:  In hardware, the read, write, and recalibrate commands wait
     for seek completion if they are issued while the heads are positioning.
     The Cold Load Read and Seek commands do not; they issue a seek to the drive
     without checking.  The drive rejects a seek while the heads are in motion
     and sets Seek Check status.  In simulation, however, the Cold Load Read and
     Seek commands wait for seek completion before seeking.

     CAUSE:  Oversight.

     RESOLUTION:  Modify the "ds_opflags" table (hp2100_ds.c) to remove the
     CMF_UIDLE flag from the Cold Load Read and Seek entries, and modify
     "ds_docmd" to check for a seek in progress when processing the Cold Load
     Read and Seek commands.

     STATUS:  Fixed in version 3.9-0.



241. PROBLEM:  A 13037 Seek command followed by Read does not set the busy flag.

     VERSION:  3.8-1

     OBSERVATION:  In hardware, a Read command (e.g.) may be issued while a seek
     is in progress.  The controller firmware sets the busy flag to indicate
     that the command was accepted.  In simulation, however, the Read command is
     not started until the seek is complete, so the busy flag is clear.  A
     program checking the busy flag will conclude that the Read was rejected.

     CAUSE:  The busy flag is set after the check for a seek in progress, and
     the firmware wait is modeled by leaving the command pending on the
     interface until the seek completes.

     RESOLUTION:  Modify "ds_docmd" (hp2100_ds.c) to eliminate the command
     holdoff and instead model the wait for seek completion by changing the unit
     function from "seek completion" to "read initiation" (e.g.).

     STATUS:  Fixed in version 3.9-0.



242. ENHANCEMENT:  Modify the 13037 disc simulator to use the common disc
     controller library.

     VERSION:  3.8-1

     OBSERVATION:  The 13037 (MAC) and 13365 (ICD) disc controllers are almost
     identical.  Altering the DS simulator to use the controller library
     introduced with the DA simulator would reduce code size, ease maintenance,
     and ensure that controller bug fixes propagate to both simulators.

     RESOLUTION:  Modify the 13037 simulator (hp2100_ds.c) to call routines in
     the common disc controller library (hp_disclib.c).

     STATUS:  Fixed in version 3.9-0.



243. ENHANCEMENT:  Add debug printout support to the 13037 disc simulator.

     VERSION:  3.8-1

     OBSERVATION:  Debugging the disc controller behavior would be easier if the
     internal state of the simulator was observable and recordable.

     RESOLUTION:  Modify "hp2100_ds.c" to add debug-mode printouts.

     STATUS:  Fixed in version 3.9-0.



244. ENHANCEMENT:  Eliminate the poll for parameters to 13037 disc commands.

     VERSION:  3.8-1

     OBSERVATION:  The DS simulator repeatedly polls the CPU interface for the
     parameters to certain disc commands, such as Seek.  It would be more
     efficient to wait for a parameter to be output by the CPU.

     RESOLUTION:  Modify "ds_io" (hp2100_ds.c) to activate the controller
     service only when a parameter word has been received with an ioIOO signal.

     STATUS:  Fixed in version 3.9-0.



245. PROBLEM:  The EMA diagnostic sometimes aborts with a DM error.

     VERSION:  3.8-1

     OBSERVATION:  Running the RTE-IV EMA diagnostic "#EMA" may abort with a DMS
     violation:

       DM VIOL = 160377
       DM INST = 105257
       ABE 177750      15 1
       XYO 116123   72137 0
       DM    #EMA   16521
       #EMA  ABORTED

     The abort occurs in test 8, which executes the .EMAP instruction and passes
     a negative number of dimensions.

     CAUSE:  The test supplies a dimension count of -32768.  The offset of the
     specified array element is calculated by the "cpu_ema_resolve" routine by
     iterating through the array subscripts.  The 16-bit word containing the
     dimension count is loaded into a 32-bit signed integer variable as an
     unsigned value.  Therefore, +32678 dimensions are assumed.  However, only
     one subscript value is supplied in the call, so subsequent instructions
     after the call are interpreted as subscript addresses, yielding random
     values from memory.  Also, the array descriptor only defines one subscript,
     so subsequent memory values are interpreted as subscript bounds and element
     counts.

     If one of subscript offsets evaluates to a negative value, the routine
     returns FALSE, and the instruction fails.  The diagnostic interprets the
     cause of the failure as the negative dimension count and passes test 8.

     However, if a subscript address points at a protected page of memory, the
     instruction causes a DM violation when the value is retrieved.

     RESOLUTION:  Modify "cpu_ema_resolve" (hp2100_cpu5.c) to sign-extend the
     16-bit dimension count.

     STATUS:  Fixed in version 3.9-0.



246. PROBLEM:  SHOW MTC SHOW lists the FORMAT modifier twice.

     VERSION:  3.8-1

     OBSERVATION:  Entering the planned SHOW MTC SHOW command results in the
     following display:

       sim> SHOW MTC SHOW
       sh{ow} MTC      FORMAT, SC, DEVNO
       sh{ow} MTCn     FORMAT

     FORMAT is listed both as a device and as a unit modifier.

     CAUSE:  The FORMAT entry in the modifier table contains both the MTAB_VDV
     and the MTAB_VUN flags.

     RESOLUTION:  Remove the redundant MTAB_VUN flag from the "mtc_mod" array
     (hp2100_mt.c).

     STATUS:  Fixed in version 3.9-0.



247. PROBLEM:  The ICD disc read end-of-track delay is not optimal.

     VERSION:  3.9-0

     OBSERVATION:  To avoid End of Cylinder errors when reading the last sector
     of a track, the ICD controller must delay more than the usual intersector
     time to allow the OS driver to send an Untalk if a read is to be
     terminated.  Currently, the longer delay is used if an end-of-cylinder
     condition is present.  However, the delay is needed only if the resulting
     seek attempt would cause an error if the read is continued; the normal
     delay should be used if the seek is permitted and would succeed.

     Also, if the host does send an Untalk during this time, the longer delay
     should be cancelled, and command termination should be scheduled for
     immediate processing.

     CAUSE:  Suboptimal implementation.

     RESOLUTION:  Modify "end_read" (hp_disclib.c) to use the longer time only
     if the seek would fail, and modify "complete_read" (hp2100_di_da.c) to
     cancel the intersector delay and schedule the completion phase immediately.

     STATUS:  Fixed in version 4.0-0.



248. PROBLEM:  Calling a VMA routine from a non-VMA program does not MP abort.

     VERSION:  3.9-0

     OBSERVATION:  If a virtual memory routine, such as .LBP, is called from a
     non-VMA program, it should be aborted with a memory protect error.
     Instead, a dynamic mapping error occurs instead:

       ASMB,R
             NAM MAPPR
             EXT EXEC,.LBP
       START CLA
             CLB
             JSB .LBP
             NOP
             JSB EXEC
             DEF *+2
             DEF *+1
             DEC 6
             END START

       DM VIOL = 160377
       DM INST = 105257
       ABE      0       0 0
       XYO      0       0 0
       DM    MAPPR   2014
       MAPPR ABORTED

     CAUSE:  The page mapping routine, "cpu_vma_mapte", returns TRUE if the page
     table is set up and valid and FALSE if not.  If a program is not a VMA
     program, then it has no page table, but "cpu_vma_mapte" is returning TRUE
     erroneously.  That results in a DM error when the invalid page entry is
     used.

     The microcode explicitly tests for a non-VMA program, i.e., one with no ID
     extension, and generates an MP error in this case.

     RESOLUTION:  Modify "cpu_vma_mapte" (hp2100_cpu5.c) to return FALSE if
     called for a non-VMA program.

     STATUS:  Fixed in version 4.0-0.



249. PROBLEM:  RESTORing a previously SAVEd session fails if the 12792C
     multiplexer is attached.

     VERSION:  3.9-0

     OBSERVATION:  If the MPX device has a listening port attached when a
     session is saved, attempting to restore that session results in a "Unit not
     attachable" error.

     CAUSE:  The MPX attach routine only allows attachment to unit 0, i.e.,
     ATTACH MPX <port>, but the actual attachment is made to the Telnet poll
     unit (unit 9).  As SAVE finds the port attached to unit 9, RESTORE attempts
     to reattach it to unit 9.

     RESOLUTION:  Modify "mpx_attach" (hp2100_mpx.c) to allow attachment to unit
     9 only during a RESTORE.

     STATUS:  Fixed in version 4.0-0.



250. PROBLEM:  DEASSIGNing the TBG device generates a debug warning.

     VERSION:  3.9-0

     OBSERVATION:  When running the simulator under a debugger, entering the
     command DEASSIGN TBG prints "warning: Invalid Address specified to
     RtlFreeHeap."

     CAUSE:  The TBG logical name is specified statically in the DEVICE
     structure, but "deassign_device" calls "free" on the pointer.  The
     developer's manual does not state that the logical name must be dynamically
     allocated, but deassigning assumes that it was.

     RESOLUTION:  Modify "clk_reset" (hp2100_stddev.c) to allocate the logical
     name during a power-on reset.

     STATUS:  Fixed in version 4.0-0.



262. ENHANCEMENT:  Add CRCC and LRCC support to the HP 2100 MS simulation.

     VERSION:  3.9-0

     OBSERVATION:  The HP 2100 MS device simulates the HP 7970 B/E magnetic tape
     drives.  The 7970B uses NRZI format, and its associated controller supports
     returning the cyclic redundancy check character and longitudinal redundancy
     check character (CRCC and LRCC) to the CPU.  Typically, these are used only
     by the controller diagnostic, but support is easy to add.

     RESOLUTION:  Modify "hp2100_ms.c" to add a function that calculates CRCC
     and LRCC for reads and writes, and call that function when the CPU requests
     that the controller deliver the values.

     STATUS:  Fixed in version 4.0-0.



265. PROBLEM:  Compiling the HP simulator for 64-bit addressing produces many
     conversion warnings.

     VERSION:  3.9-0

     OBSERVATION:  Compiling the simulator and defining USE_INT64 and USE_ADDR64
     with implicit conversion warnings enabled reveals a number of places where
     assumptions were made that addresses would always be 32 bits.  This is a
     reasonable assumption, as there are no devices (CPU or peripherals) that
     can handle gigabyte addressing.  Still, many of these assumptions are not
     necessary, and some future peripheral simulator may exceed this limit.

     CAUSE:  Future expansion to 64-bit addressing was not envisioned.

     RESOLUTION:  Modify source files to ensure that "t_addr" and "t_value"
     types are used instead of "uint32" and "int32" types where addressing and
     data values may be 64 bits.  Also ensure that valid conversions to smaller
     sizes use explicit casts.

     STATUS:  Fixed in version 4.0-0.



266. PROBLEM:  BOOT devices require a duplicate S-register declaration.

     VERSION:  3.9-0

     OBSERVATION:  All of the peripheral devices that support the BOOT command
     set the select code and other parameters into the S register during the
     boot process.  This direct register access requires an external declaration
     that duplicates the one in the full CPU declarations file (hp2100_cpu.h).
     A better method that avoids the duplicate declaration would be for the
     "ibl_copy" routine to modify the S register on behalf of the caller.

     CAUSE:  Poor original implementation.

     RESOLUTION:  Modify "ibl_copy" (hp2100_cpu.c) to take two additional
     parameters that clear and set bits, respectively, in the S register on
     behalf of the caller.  Modify the boot routines for the CPU, DA, DP, DQ,
     DR, DS, IPL, MS, and PTR devices to use the new parameters instead of
     modifying the S register directly.

     STATUS:  Fixed in version 4.0-0.



267. ENHANCEMENT:  Add a register to the IPLI device to configure the DMA delay.

     VERSION:  3.9-0

     OBSERVATION:  Occasionally, the 2000 Access terminal multiplexer does not
     initialize properly; the problem is more prevalent on multiprocessor
     systems.

     There is a race condition between the system processor (SP) and the I/O
     processor (IOP) during initialization.  The problem occurs if the IOP DMA
     completion interrupt routine finishes before the SP DMA completion
     interrupt routine.  As a workaround, the simulator suspends the IOP process
     for one millisecond before signaling a DMA completion (EDT) interrupt.
     Depending on system loading, this time may be insufficient.

     RESOLUTION:  Modify "ipli_reg" (hp2100_ipl.c) to add a hidden register,
     EDTDELAY, that allows the user to configure the completion delay.  The
     register value is expressed in milliseconds and defaults to one
     millisecond.

     STATUS:  Fixed in version 4.0-0.



270. PROBLEM:  The disc libraries in the HP2100 and HP3000 directories differ.

     VERSION:  4.0-0

     OBSERVATION:  The "hp_disclib.c" and "hp_disclib.h" files appear in both
     the HP2100 and HP3000 subdirectories.  However, the contents of the files
     are different.  If both source sets are compiled to a common object
     subdirectory, one of the two executables will not link, due to unresolved
     externals.

     CAUSE:  The disc library in the HP3000 subdirectory is an extension of the
     one in the HP2100 subdirectory.  It is intended as an eventual replacement
     for the HP2100 version, so that both simulators can share the library.
     Until then, however, they are not interchangeable, as they export different
     routines, leading to link errors if one is accidentally substituted for the
     other.

     RESOLUTION:  Rename "hp_disclib.c/h" in the HP2100 subdirectory to
     "hp2100_disclib.c/h" to indicate that it is HP2100-specific.  Modify
     "hp2100_ds.c" and "hp2100_di_da.c" to use the new include file name.

     STATUS:  Fixed in version 4.0-0.



271. PROBLEM:  The MPX device incorrectly reports a currently filling read
     buffer as complete.

     VERSION:  4.0-0

     OBSERVATION:  Using Kermit to upload a file to RTE and specifying a packet
     size larger than 254 bytes fails with transmission errors.  Uploads with
     packet sizes under 254 bytes work properly.

     CAUSE:  The 12792 multiplexer provides two 254-byte receive buffers per
     line.  A single reception larger than 254 bytes returns "partial buffer"
     status when the initial read terminates because of the buffer full
     condition.  This informs RTE that the reception is incomplete and that it
     should issue additional reads to obtain the remainder of the data.
     Complete reception is indicated by the final read not returning "partial
     buffer" status.

     When Kermit sends a large packet, the multiplexer fills the first 254-byte
     buffer, terminating on the buffer-full condition, and sends an unsolicited
     interrupt to the CPU with "read buffer available" status.  In response, RTE
     sends an "acknowledge" command to the multiplexer, which returns the
     "partial buffer" status and the buffer length.  RTE then follows with a
     "read buffer" command and prepares to receive the first buffer data.
     Concurrently, the multiplexer begins filling the second 254-byte buffer.

     RTE uses DCPC to transfer the data from the multiplexer, which is faster
     than the incoming data rate.  Therefore, the transfer completes while the
     second buffer is still filling.  On DCPC completion, the multiplexer checks
     to see if the other receive buffer is complete, and if it is, issues
     another unsolicited interrupt with "read buffer available" status.

     The buffer completion check incorrectly returns TRUE if the buffer contains
     received data.  It should return TRUE only if the buffer contains data and
     it is not currently being filled.

     For short reads, such as EDIT screen reads, the second buffer fill
     completes before the first buffer DCPC transfer, and the returned "read
     buffer available" status is appropriate.  For long reads, such as Kermit
     transfers, the incorrect buffer check causes RTE to transfer data from the
     second buffer while it is incomplete.  This leads to corrupted data and
     Kermit transmission errors.

     RESOLUTION:  Modify "mpx_cntl_svc" (hp2100_mpx.c) to indicate read buffer
     availability only when filling is complete.

     STATUS:  Fixed in version 4.0-0.



272. PROBLEM:  An MPX binary read larger than 254 bytes never completes.

     VERSION:  4.0-0.

     OBSERVATION:  The MPX device may be configured to terminate a read on
     reception of either a special character (e.g., CR) or a certain character
     count.  Counts up to 64K bytes are permitted, and such reads will succeed
     if the alternating buffers are concurrently transferred to the CPU before
     filling completely.  However, while reads that specify character counts of
     254 or less complete as expected, reads of more than 254 bytes never
     complete.

     CAUSE:  As each character is received, the current character count is
     compared to the termination count, and the read completes if the counts are
     equal.  However, the current character count is determined by the number of
     characters in the current buffer and not the accumulated count of all
     characters received.  As the read buffers are 254 bytes long, the current
     count will never exceed 254.  Therefore, any read terminating on a count
     greater than that will never complete.

     RESOLUTION:  Define a new "mpx_termcnt" array to hold the termination
     counts for the eight lines, and reassign the "mpx_charcnt" array to hold
     the current character counts.  Modify "exec_command" and "mpx_line_svc"
     (hp2100_mpx.c) to set the termination count, compare it against the current
     character count as characters are received, and terminate reception if
     enabled and the values are equal.

     STATUS:  Fixed in version 4.0-0.



273. ENHANCEMENT:  Burst-fill only the first of two MPX receive buffers in
     FASTTIME mode.

     VERSION:  4.0-0.

     OBSERVATION:  When the 8-channel multiplexer is set for "optimized timing"
     mode, buffered characters are transferred in blocks to and from the Telnet
     connection.  That is, the line service routine will send or receive
     characters as long as they are available.  This is more efficient than the
     "realistic timing" mode, which sends or receives one character per service
     invocation.  Effectively, this means that up to 508 characters (two buffers
     of 254 bytes each) may be sent or received between one CPU instruction or
     DCPC cycle and the next.  This works well for sending, but it can cause
     buffer overflows when receiving.

     Consider an application (such as Kermit) that receives large blocks of data
     at high speed from a client.  The multiplexer is designed to handle this
     condition by interrupting the CPU when the first buffer is filled and
     filling the second buffer while the CPU is unloading data from the first.
     In realistic mode at 19,200 baud, the CPU has approximately 800
     instructions or DCPC cycles available per character received.  With a
     second buffer of 254 bytes, the CPU has approximately 203,000 instructions
     available to unload the first buffer after receiving the interrupt
     notification.  Once started, the DCPC transfer takes no more than 508
     instruction times, so the CPU can easily keep up with data arriving at the
     maximum baud rate.

     In fast timing mode, however, the first buffer burst-fills in a single CPU
     instruction time, and, if available from the Telnet connection, the second
     buffer fills in the next instruction time.  At that point, any additional
     characters received will result in a buffer overflow condition.  The
     problem is that the CPU has no time between the first burst and the second
     to empty the first buffer.

     RESOLUTION:  Modify "mpx_line_svc" (hp2100_mpx.c) to shift from burst
     transfers to character-at-a-time transfers when a receive buffer is full
     and awaiting unloading by the CPU.  This allows the CPU and DCPC time to
     read the buffer contents into memory before the second multiplexer buffer
     is full.  Once the completed buffer is freed, the service routine returns
     to burst mode to fill the remainder of the other buffer, permitting the
     efficiency of block transfers while avoiding buffer overruns with large
     data transfers.

     STATUS:  Fixed in version 4.0-0.



274. PROBLEM:  A second connection to the BACI device leaves the client
     unresponsive.

     VERSION:  4.0-0.

     OBSERVATION:  The BACI device supports a single terminal client connection.
     If a second connection is attempted, the client connects but is otherwise
     unresponsive.  It would be better if the client received the "All
     connections busy" message that is reported by the terminal multiplexers
     (MPX and MUX devices) when the number of connections is exceeded.

     CAUSE:  The "baci_poll_svc" is calling the "tmxr_poll_conn" routine only if
     the port is not connected.  The routine should be called unilaterally, so
     that it will report an error and disconnect the client when all lines are
     in use and another connection is attempted.

     RESOLUTION:  Modify "baci_poll_svc" (hp2100_baci.c) to call
     "tmxr_poll_conn" unilaterally, so that a second concurrent connection
     attempt will be rejected with "All connections busy".

     STATUS:  Fixed in version 4.0-0.



275. PROBLEM:  The exported program counter name (PC) clashes with other libraries.

     VERSION:  4.0-0.

     OBSERVATION:  In HP 21xx/1000 systems, the P register is the program
     counter.  In keeping with the naming of the other register variables (e.g.,
     for A register, B register, etc.) in the simulator, the variable used
     should be named "PR".  However, for traditional reasons, the program
     counter in SIMH is named "PC".

     The main CPU module declares its hardware register variables as global, so
     that they may be accessed by other CPU helper modules.  Unfortunately, the
     "curses" library also declares the symbol "PC" as global, leading to
     conflicts when it is loaded by SCP.  A workaround had been implemented that
     renamed "PC" to "PC_Global" in the HP2100 simulator, but that meant that
     the new name had to be used when debugging, which was awkward.

     CAUSE:  A poor choice of global symbol names from the "termcap" library,
     which was inherited by the "curses" library.

     RESOLUTION:  Change the program counter variable name from "PC" to "PR"
     (hp2100_cpu.c, hp2100_cpu1.c, hp2100_cpu2.c, hp2100_cpu3.c, hp2100_cpu4.c,
     hp2100_cpu5.c, hp2100_cpu6.c, hp2100_cpu7.c, hp2100_dr.c, and hp2100_ipl.c)
     to avoid a name clash and for register naming consistency.

     STATUS:  Fixed in version 4.0-0.



276. PROBLEM:  DPC device documentation uses the wrong disc drive model number.

     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.



277. PROBLEM:  The BOOT DRC command does not execute correctly.

     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.



278. PROBLEM:  The valid command "DEPOSIT 2000 JMP 2001" is rejected.

     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.



279. PROBLEM:  The invalid command "DEPOSIT 2000 JMP C 2001" is accepted.

     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.



280. PROBLEM:  Punched output does not appear on TTY devices lacking a paper
     tape punch.

     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.



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



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



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



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



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



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



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



288. ENHANCEMENT:  Add tracing for CPU instruction execution.

     VERSION:  Release 26.

     OBSERVATION:  Attempting to debug OS-level failures with breakpoints,
     single-stepping, and memory and register examinations is tedious at best
     and often misses the point of failure.  It would be easier if a trace of
     execution, memory data, and register accesses were available in a log file
     that could be reviewed after capturing a failure.

     RESOLUTION:  Modify "sim_instr" (hp2100_cpu.c) to add several tracing
     levels and their corresponding logging calls to capture execution to the
     simulator debug log file, and combine the thirteen previously separate
     memory read and write routines into a pair of unified routines that
     incorporate data tracing.  Add the "hp_debug" routine (hp2100_sys.c) from
     the HP 3000 simulator to simplify trace logging.

     STATUS:  Fixed in Release 27.



289. ENHANCEMENT:  Add tracing for DMA/DCPC command, status, and data accesses.

     VERSION:  Release 26.

     OBSERVATION:  It would be helpful if internal DMA/DCPC operations could be
     added to the trace log, so that DMA setup, execution, and termination can
     be evaluated.

     RESOLUTION:  Modify "dmapio" and "dmasio" (hp2100_cpu.c) to add several
     tracing levels and their corresponding logging calls to capture DMA/DCPC
     operation to the simulator debug log file

     STATUS:  Fixed in Release 27.



290. ENHANCEMENT:  Add support for the HP 2613, 2617, and 2618 line printers.

     VERSION:  Release 26.

     OBSERVATION:  The HP 3000 LP implementation contains a more faithful and
     extensive simulation of the HP 2607 line printer than the HP 2100 LPT
     implementation.  Realistic and optimized timing, compact and expanded
     output modes, custom VFU tape images, and tracing of internal operations
     would all benefit the LPT device simulator.

     RESOLUTION:  Modify "hp2100_lpt.c" to incorporate the functionality of the
     HP 3000 LP simulator.  Not only does this provide a more-capable HP 2607
     simulation, but it also adds 2613, 2617, and 2618 simulations.

     STATUS:  Fixed in Release 27.



291. ENHANCEMENT:  Rewrite the LOAD command to load bootstrap loaders.

     VERSION:  Release 26.

     OBSERVATION:  The LOAD command currently loads general absolute binary
     programs into memory, duplicating the functionality of the BOOT PTR
     command.  However, it does not zero the A and B registers on completion,
     and some HP programs depend on this to operate correctly.  Moreover, when
     used to load bootstraps that are not provided with the simulator (e.g., the
     BMDL), one absolute file is required for each of the possible memory
     configurations.  The LOAD command would be more useful if it became a
     dedicated bootstrap loader that could also relocate the program to the
     required memory locations.

     RESOLUTION:  Modify "sim_load" (hp2100_sys.c) to repurpose the LOAD command
     to read and relocate bootstrap loaders.  The absolute file addresses must
     now cover only the last 64 words in an arbitrary memory page, and the
     program will be relocated automatically to the last 64 words of memory.

     STATUS:  Fixed in Release 27.



292. ENHANCEMENT:  Add a DUMP command to write the bootstrap loader to a file.

     VERSION:  Release 26.

     OBSERVATION:  If a bootstrap loader has been entered into memory by hand,
     there is no way to save the loader for use in a subsequent session without
     saving the complete simulator state with the SAVE command.  It would be
     helpful to have a way of writing the current bootstrap loader to a paper
     tape image in absolute binary format.

     RESOLUTION:  Modify "sim_load" (hp2100_sys.c) to add a DUMP command that
     writes the last 64 words of memory into an absolute binary file.

     STATUS:  Fixed in Release 27.



293. ENHANCEMENT:  Install the Basic Binary Loader automatically into 21xx CPUs.

     VERSION:  Release 26.

     OBSERVATION:  The HP 2114, 2115, 2116, and 2100 core-memory machines were
     delivered with the Basic Binary Loader (BBL) preinstalled into the
     protected loader area of memory.  Currently, the simulator preinstalls the
     12992K paper tape ROM bootstrap loader into memory for these machines, but
     that loader is used with the HP 1000 CPUs and does not have the same
     functionality as the BBL.  Installing the BBL would simulate the 21xx
     machines more accurately.

     RESOLUTION:  Modify "cpu_reset" (hp2100_cpu.c) to install the BBL instead
     of the 12992K boot loader ROM if the machine is not a 1000-series CPU.

     STATUS:  Fixed in Release 27.



294. ENHANCEMENT:  Add page/offset parsing for SCP memory address operands.

     VERSION:  Release 26.

     OBSERVATION:  The HP 1000 machines operate with a 32K logical address
     space.  Physical memory above 32K is mapped in pages into the logical
     address space by the Dynamic Mapping System.  The Memory Expansion Module
     maintains page registers that perform the mapping.  Trying to EXAMINE or
     DEPOSIT to memory locations specified by linear addresses above 32K is
     awkward, as one must convert the MEM page number and instruction offset
     into a linear address before accessing.  It would be easier if addresses
     above 32K could be referenced in <page>.<offset> form.

     RESOLUTION:  Add the "parse_addr" and "fprint_addr" routines (hp2100_sys.c)
     to use linear addresses for locations in the first 32K of memory and to use
     <page>.<offset> addresses for locations above 32K.

     STATUS:  Fixed in Release 27.



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



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



297. ENHANCEMENT:  Rewrite the instruction mnemonic printer and parser for
     improved performance.

     VERSION:  Release 26.

     OBSERVATION:  The current mnemonic printer performs a linear search to
     match the opcode.  This is inefficient, especially when instruction tracing
     must print each executed instruction in mnemonic form.  Also, very few of
     the optional firmware instruction sets are implemented.  Full coverage and
     improved performance are desirable.

     RESOLUTION:  Modify "fprint_sym" (hp2100_sys.c) to use indexed lookups for
     instructions where possible, and extend the opcode tables to cover all
     supported instructions.  Modify "parse_sym" (hp2100_sys.c) to use the new
     opcode tables.

     STATUS:  Fixed in Release 27.



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



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



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



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



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



303. ENHANCEMENT:  Revise BOOT to use the correct loader for the CPU model.

     VERSION:  Release 27.

     OBSERVATION:  The HP 21xx and 1000 CPUs use different mechanisms to
     bootstrap the systems.  21xx-series machines use core memory and maintain a
     protected 64-word area at the top of memory to hold one of several hand-
     entered device loaders.  1000 M/E/F-Series CPUs hold up to four separate
     boot loaders in socketed ROMs whose contents are selectively copied into
     semiconductor memory when the front panel IBL button is pressed.

     The 21xx and 1000 boot loaders are different and configure their operations
     differently.  However, the simulator BOOT command for a given device
     executes the associated HP 1000 boot loader ROM program, regardless of the
     configured CPU model.  A user configuring the CPU as a 2100 and expecting
     the paper tape loader to be the standard Basic Binary Loader (BBL) will
     find instead that the HP 12992K Paper Tape Boot Loader ROM has been
     installed.  This is important because BBL features, such as tape
     verification or memory comparison, are not available with the 12992K
     loader.

     RESOLUTION:  Modify the device boot routines for all bootable devices
     (hp2100_di_da.c, hp2100_dp.c, hp2100_dq.c, hp2100_dr.c, hp2100_ds.c,
     hp2100_ipl.c, hp2100_ms.c, and hp2100_stddev.c) to install the correct
     loader for the current CPU configuration.  If no boot loader exists for a
     given CPU/device combination, the associated BOOT command is rejected.

     STATUS:  Fixed in Release 28.



304. ENHANCEMENT:  Revise the LOAD command to copy an internal bootstrap loader
     into memory.

     VERSION:  Release 27.

     OBSERVATION:  The simulator provides no direct analog of the HP 1000
     front-panel IBL button, which copies a boot loader ROM into memory.  The
     BOOT command performs the IBL function but also does a PRESET and RUN.
     This causes problems when booting the I/O Processor of a dual-CPU HP 2000
     Time-Shared BASIC system (e.g., Access).

     For these systems, the System Processor must wait until the IOP has
     initialized in order to prevent data loss.  In practice, this means that
     the IOP must copy the boot loader and then execute until the SFS / JMP *-1
     loop is reached before releasing the SP to execute.

     Because BOOT does an implied RUN, an IOP command file must set a breakpoint
     on the loop to regain control before issuing the command to release the SP.
     Unfortunately, the breakpoint location varies, depending on the specific
     boot loader used (e.g., HP 1000 ROM vs. 2100 BBL).  It would be better if
     the loader could be copied to memory without beginning execution.  Then a
     STEP command could be issued with a step count sufficient to guarantee
     entry into the SFS loop.

     RESOLUTION:  Extend the LOAD command to accept a device name in addition to
     a filename.  Add a new "hp_load_cmd" routine (hp2100_sys.c) to trap LOAD
     command execution and call a device's "boot" routine to copy the loader to
     memory if a device name is specified.

     STATUS:  Fixed in Release 28.



305. ENHANCEMENT:  Allow the user to specify the set of boot loader ROMs
     installed in a 1000 CPU.

     VERSION:  Release 27.

     OBSERVATION:  The 1000 M/E/F-Series CPUs support installation of one to
     four boot loader ROMs from a set of device loaders.  The machines contain
     three (M-Series) or four (E/F-Series) sockets to permit the user to
     customize the ROM selection.  Currently, the simulator has a fixed set of
     ROMs installed that cannot be changed.  The user experience would match the
     hardware more closely if the loaders were "socketed," i.e., could be
     changed by the user.

     RESOLUTION:  Add new SET CPU ROMS and SHOW CPU ROMS commands (hp2100_cpu.c)
     to specify and display the set of boot loader ROMs installed in the four
     available sockets, and modify the "cpu_boot" routine to copy the boot
     loader from the specified socket.

     STATUS:  Fixed in Release 28.



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



307. 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 system operator PHONES 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.



308. ENHANCEMENT:  Eliminate consecutive CLC 0 operations.

     VERSION:  Release 27.

     OBSERVATION:  To guarantee proper initialization, the 12920A terminal
     multiplexer requires that the Control Reset (CRS) I/O signal be asserted
     for a minimum of 100 milliseconds.  In practice, this is achieved by
     executing 131,072 (128K) CLC 0 instructions in a tight loop.  This is not
     necessary in simulation, and in fact is detrimental, as 262,000+ trace
     lines will be written for each device that enables IOBUS tracing.  This
     produces immense trace logs and makes it hard to find the actual traces of
     interest.

     RESOLUTION:  Modify "cpuio" (hp2100_cpu.c) to omit consecutive CLC 0
     operations after the first by checking the select code and signal set of
     the last I/O operation, and modify "io_dispatch" to save the last select
     code dispatched.

     STATUS:  Fixed in Release 28.



309. ENHANCEMENT:  Create full-size disc images if the -N option is specified.

     VERSION:  Release 27.

     OBSERVATION:  Currently, attaching a new file creates an image of zero
     size.  Only when the image is written is the size extended.  Therefore,
     until the last sector of an image is written, the file size will not match
     the expected size of the corresponding disc.  HPDrive will warn if an image
     does not correspond to the hardware size.

     A workaround for MAC/ICD discs is to initialize the last subchannel of a
     drive.  However, this still fails if not all of the drive's tracks are
     mapped.  Also, it may not work for CS/80 drives unless (a) the Initialize
     command is invoked, and (b) the command implementation writes to every disc
     block.

     RESOLUTION:  Modify "da_attach" (hp2100_di_da.c), "dpc_attach"
     (hp2100_dp.c), "dqc_attach" (hp2100_dq.c), and "ds_attach" (hp2100_ds.c) to
     call "sim_fseek" to seek to the last defined byte in the file and then
     "fwrite" to write a zero byte if the -N option is specified to the ATTACH
     command.  The C standard guarantees that the bytes between the initial
     position (byte 0) and the new position are be zeroed.

     STATUS:  Fixed in Release 28.



310. ENHANCEMENT:  Add process synchronization commands to the IPL device.

     VERSION:  Release 27.

     OBSERVATION:  Dual-CPU versions of the HP 2000 Time-Shared BASIC operating
     system are sensitive to the startup order of the System Processor and the
     I/O Processor.  Startup is generally successful if both simulator instances
     are allowed to run unimpeded.  However, if one instance is blocked or
     preempted, system startup may fail.  Fixed delays placed strategically in
     the startup scripts improve matters only somewhat.  A more reliable
     mechanism is needed to hold one instance at a rendezvous point until the
     other instance reaches the same point.

     RESOLUTION:  Add new SIGNAL and WAIT options to the IPL device
     (hp2100_ipl.c) that use a host-system event or semaphore to wait at a
     rendezvous point until the other instance signals that it has reached the
     same point.  The event object is allocated during ATTACH processing and
     released during DETACH processing.

     STATUS:  Fixed in Release 28.



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



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



313. ENHANCEMENT:  Change the I/O interface simulation to match the hardware.

     VERSION:  Release 28.

     OBSERVATION:  The I/O interface simulation has undergone several changes,
     each bringing the simulation more in line with the hardware behavior.
     The current model still has some deviations, however.  For instance, SRQ
     and IRQ assertion are tested after every IOG instruction execution, after
     every device service routine call, and after every DMA cycle.  Also, IOBUS
     tracing shows only a subset of the hardware signals that are actually
     present on the I/O backplane.  For example, interrupt priority is
     maintained outside of the device simulations rather than explicitly with
     PRH and PRL assertions, and SKF is returned as part of the data word rather
     than as an asserted signal.

     It would be more efficient to recognize an interrupt or service request at
     the point of origin, i.e., upon return from a device interface routine,
     rather than polling all devices for these requests later.  In addition,
     modeling the hardware I/O backplane signals fully would allow IOBUS tracing
     to show an accurate picture of the simulated hardware behavior.

     RESOLUTION:  Change the IOG instruction and I/O interface simulations
     (hp2100_cpu.c) to model the hardware backplane more closely.  Change all of
     the peripheral device interface routines to accept and return the full set
     of hardware signals.

     STATUS:  Fixed in Release 29.



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



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



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



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



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



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



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



321. PROBLEM:  2000/Access program 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.



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



323. ENHANCEMENT:  Add instruction execution interlocking to the IPL device.

     VERSION:  Release 29.

     OBSERVATION:  The SIGNAL/WAIT mechanism added in Release 28 improved
     process synchronization over timed execution delays.  However, upon release
     from a rendezvous point, one simulator instance could still be blocked
     while the other proceeded, leading to startup failures.  A more robust
     mechanism is needed.

     RESOLUTION:  Add an INTERLOCK option to the IPL device (hp2100_ipl.c).  It
     controls instruction execution synchronization between the two simulator
     instances in a dual-CPU TSB system.  The option specifies the number of CPU
     instructions to execute before performing a rendezvous with the other
     instance.  With this option enabled, neither CPU can get more than the
     specified number of instructions ahead of the other before waiting for the
     other to catch up.  This improves startup reliability significantly.

     STATUS:  Fixed in Release 30.



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



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



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



327. PROBLEM:  Patch delta values are not simulator-specific.

     VERSION:  Release 30.

     OBSERVATION:  Setting the SIM_DELTA value is a useful way of indicating the
     change level of a development simulator.  Version banners such as "Release
     10 delta 1" and "Release 10 delta 2" serve to identify the specific
     simulator in use and the level of divergence between a released version and
     a development version.  As such, the delta should be reset to 0 after a
     release, e.g., it should go from "Release 10 delta 23" to "Release 11 delta
     0" before any new changes are made.  However, the delta is a global value,
     so a problem arises if one of the HP simulators has a new release while
     another does not.  The latter will see an apparent regression from (e.g.)
     "Release 10 delta 2" to "Release 10 delta 0".

     Moreover, changing the global delta forces a recompilation of every module
     in every simulator, as every module indirectly includes "sim_rev.h".  It
     would be nicer to recompile only the module containing the specific delta
     value that changed.

     We already use "hp_release" to indicate release candidates by appending
     "Candidate" and the number to the current release number (producing, e.g.,
     "Release 30 Candidate 1").  Using "Release 30 delta 1" is no more
     difficult.  With this scheme, the "SIM_DELTA" value reflects the SCP delta,
     while the new release string delta reflects the simulator delta.  "Delta"
     is changed to "Candidate" for release candidates and is removed for
     releases (with appropriate value adjustments).

     CAUSE:  There is no simulator-specific delta value.  This was reasonable
     when all simulators changed together at a given SCP release but is
     inappropriate with separate simulator releases.

     RESOLUTION:  Modify the "hp_release" string (hp2100_sys.c) to include the
     delta indication, and modify the various command scripts to obtain the
     simulator delta from that string rather than the SIM_DELTA global.

     STATUS:  Fixed in Release 31.



328. ENHANCEMENT:  Add commands to power fail/restore devices.

     VERSION:  Release 30.

     OBSERVATION:  Several devices (CPU, LPS, LPT, floppy disk device) have
     observable reactions to power failing.  In the case of the CPU, power
     fail and power restore interrupts occur, and RTE allows user-designated
     programs to run when power is restored.  Currently, there is no way to
     cause a power-fail interrupt.

     The line printers support SET LPx POWEROFF/POWERON commands, as the
     diagnostics test for this.  These could be added to the CPU, but a generic
     method of handling power conditions for all devices is preferable.

     A good choice would be to extend the current HP 3000 simulator commands
     POWER { FAIL | OFF | DOWN } and POWER { RESTORE | ON | UP } to accept an
     optional device name.  For example, POWER FAIL <dev> would turn power off
     to the specified device.  Omitting the device name would power fail all
     devices.

     A new DIB field would hold a pointer to a device's power-handling routine
     or NULL if one was not provided.  The POWER command would call the device's
     power routine, passing a parameter to indicate FAIL/RESTORE.  Each device
     would maintain its own power state.  Receiving a initial RESET -P would set
     the state to "power on."

     RESOLUTION:  Modify "aux_cmds" (hp2100_sys.c) to add a "POWER" command.
     Add a new "hp_power_cmd" routine to process the command and call power
     notification routines in the device simulators.  Add a new "io_power"
     routine pointer to the DIB structure to allow devices to define their power
     notification handlers.  Modify the LPS and LPT devices to remove the
     specialized SET POWEROFF/POWERON commands and use the new POWER OFF/ON
     mechanism instead.

     STATUS:  Fixed in Release 31.



329. ENHANCEMENT:  Add power-fail/auto-restart capability to the CPU.

     VERSION:  Release 30.

     OBSERVATION:  The 1000 and 2100 provide power-fail/auto-restart hardware as
     standard equipment, while the 2116/15/14 offers it as an option.  PFAR is
     not currently simulated, but it would be desirable to do so, as RTE allows
     user-specified programs to run on power restoration.

     Note that power down/up actions occur while the simulator is stopped (i.e.,
     at the SCP command line, even in concurrent mode), so detection would occur
     at "sim_instr" entry.

     RESOLUTION:  Add a new "cpu_power" routine (hp2100_cpu.c) to handle power
     state changes, and register it in "cpu_dib".  Modify "pwr_interface" to
     implement power-fail and auto-restart capability via the power fail/restore
     interrupt request from select code 4.  Add a SET CPU { ARS | NOARS }
     command to "cpu_mod" to allow the user to configure auto-restart.  Modify
     "cpu_reset" to include PON with an operator-preset but not with a power-on
     preset.

     STATUS:  Fixed in Release 31.



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



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



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



333. ENHANCEMENT:  Increase the MPX poll rate when waiting for ACK after ENQ.

     VERSION:  Release 30.

     OBSERVATION:  If an 8-channel multiplexer port is configured for ENQ/ACK
     handshaking, and the MPX device is set to REALTIME mode, an ENQ character
     is sent after writing 80 characters, and output is suspended until the
     attached terminal returns an ACK character.  In simulation, all terminal
     input is obtained by polling the associated devices.  The poll rate is
     selected as a compromise between rapid response and low CPU usage when
     idling.

     Regardless of how quickly the terminal returns the ACK, it won't be seen
     until the next scheduled "tmxr_poll_rx" call, which is performed every ten
     milliseconds of wall-clock time.  Typically, this will be several orders of
     magnitude greater than the Telnet character reception time and is about 2.5
     times slower than the serial time.  Given that a terminal response is
     expected, increasing the poll rate while waiting for the ACK will improve
     response time while not unduly increasing the system overhead.

     RESOLUTION:  Modify "line_service" (hp2100_mpx.c) to call "tmxr_poll_rx"
     and check for ACK reception after one character reception time, thereafter
     doubling the time until reception succeeds or the time exceeds the normal
     poll time.

     STATUS:  Fixed in Release 31.



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



335. ENHANCEMENT:  Increase the BACI poll rate when waiting for ACK after ENQ.

     VERSION:  Release 30.

     OBSERVATION:  The RTE driver for the BACI always uses ENQ/ACK handshaking
     to pace the attached terminal.  During output, an ENQ character is sent
     after writing 33 characters, and output is suspended until the terminal
     returns an ACK character.

     In simulation, all terminal input is obtained by polling the associated
     devices.  The poll rate is selected as a compromise between rapid response
     and low CPU usage when idling.

     Regardless of how quickly the terminal returns the ACK, it won't be seen
     until the next scheduled "tmxr_poll_rx" call, which is performed every ten
     milliseconds of wall-clock time.  Typically, this will be several orders of
     magnitude greater than the Telnet character reception time and is about 2.5
     times slower than the serial time.  Given that a terminal response is
     expected, increasing the poll rate while waiting for the ACK will improve
     response time while not unduly increasing the system overhead.

     RESOLUTION:  Modify "line_service" (hp2100_baci.c) to call "tmxr_poll_rx"
     and check for ACK reception after one character reception time, thereafter
     doubling the time until reception succeeds or the time exceeds the normal
     poll time.

     STATUS:  Fixed in Release 31.



336. ENHANCEMENT:  Add new LOCALACK/REMOTEACK options to the BACI device.

     VERSION:  Release 30.

     OBSERVATION:  Currently, enabling the FASTTIME option changes ENQ/ACK
     handling from remote to local.  In remote mode, driver-issued ENQ
     characters are sent to the attached terminal, and ACK characters from the
     terminal are returned to the driver.  As the driver is always configured
     for ENQ/ACK handshaking, an HP terminal or terminal emulator is required.
     In local mode, the ENQ is discarded, and an ACK is supplied by the
     simulator, allowing non-HP terminals to be used.

     A user may wish to have REALTIME processing with non-HP terminals, but this
     is not allowed with the current implementation.  Selection of local/remote
     handshaking should be independent of the real-time/fast-time selection.

     RESOLUTION:  Modify the "baci_mod" table (hp2100_baci.c) to add a new
     REMOTEACK/LOCALACK unit option, and modify "line_service" to use this
     option instead of the FASTTIME option to determine the handshaking mode.

     STATUS:  Fixed in Release 31.



 337. ENHANCEMENT:  Improve the 2767A printer simulation.

     VERSION:  Release 30.

     OBSERVATION:  The LPS device produces output that is difficult to use as a
     plain text file.  Bare LFs and FFs are embedded in the text stream, and
     overprinting is not simulated.  A more useful output model is that of the
     LPT (2607, etc.) printer.

     RESOLUTION:  Modify "hp2100_lps.c" to incorporate the functionality of the
     LPT device, adding realistic and optimized timing, compact and expanded
     output modes, overprinting simulation, better support for the diagnostic,
     and better tracing of internal operations.

     STATUS:  Fixed in Release 31.



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



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



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



341. PROBLEM:  MC devices have registers with no names on Windows platforms.

     VERSION:  Release 31.

     OBSERVATION:  Displaying the registers for the MC1 and MC2 devices shows
     the first two registers have no names:

       sim> SET MC1 ENABLED
       sim> EXAMINE MC1 STATE
       :       000000
       :       000000
       CTL:    0
       FLG:    1
       FBF:    1
       CMD:    0
       sim>

     If the simulator state is saved with the SAVE command, the state cannot be
     restored:

       sim> RESTORE STATEFILE
       Invalid device name: ?
       Command not completed
       sim>

     This is a result of the missing register names.

     CAUSE:  The missing registers are named IN and OUT and refer to the input
     and output data registers on the microcircuit card.  If the simulator is
     compiled on Windows, the "rpcdce.h" file in the Windows SDK, which is
     included indirectly through the SCP "sim_defs.h" file, has these macro
     definitions:

       #define IN
       #define OUT

     ...which define the names as nothing.  Consequently, the resulting register
     declarations have null names.

     RESOLUTION:  Modify "mc1_reg" and "mc2_reg" (hp2100_mc.c) to change the IN
     and OUT register names to INPUT and OUTPUT, respectively.

     STATUS:  Fixed in Release 32.



342. PROBLEM:  Restoring a state file with a larger memory size fails.

     VERSION:  Release 31.

     OBSERVATION:  Attempting to RESTORE a saved state file that has a larger
     memory size than the current memory size fails.  For example:

       sim> SET CPU 32K
       sim> SAVE STATEFILE
       sim> SET CPU 16K
       sim> RESTORE STATEFILE
       Memory size changed: CPU0 = 32KW
       Address space exceeded
       sim>

     The "Memory size changed" message is a notice that may be ignored.  The
     "Address space exceeded" message is a fatal error that stops the
     restoration.

     CAUSE:  Memory is restored using the "cpu_deposit" routine.  That routing
     checks the memory address to ensure that it is within the defined size.
     The check is made against the "mem_size" variable that is exported by
     "hp2100_mem.c".  It holds the address of the start of undefined memory and
     is set when a SET CPU command specifies a new memory size.  This variable
     is not part of the saved CPU state, but even if it were, register values
     are restored after memory.  So when the RESTORE command restores memory,
     the address check is made against the current memory size, not the restored
     memory size.  When "cpu_deposit" is called to restore the first word beyond
     "mem_size", the check fails, and the address error occurs.

     RESOLUTION:  Modify "cpu_dev" (hp2100_cpu.c) to add the DEV_DYNM flag to
     the device flags and the "set_size" (renamed as "cpu_set_size") routine as
     the memory size check routine.  RESTORE now calls "cpu_set_size" after
     restoring the CPU flags that specify the memory size and before memory
     itself is restored.  The routine sets "mem_size" and "mem_end" properly, so
     that "cpu_deposit" has the correct memory size for its check.

     STATUS:  Fixed in Release 32.



343. PROBLEM:  RESTORE does not restore the loader if SAVE while it is enabled.

     VERSION:  Release 31.

     OBSERVATION:  For 21xx-series CPUs, if a SET CPU LOADERENABLE is done prior
     to a SAVE, the subsequent RESTORE will not restore the loader.  For
     example:

       sim> SET CPU LOADERENABLE
       sim> EXAMINE 77700
       77700:  107700
       sim> SAVE STATEFILE
       sim> SET CPU LOADERDISABLE
       sim> SHOW CPU
       CPU, idle disabled, 32KW, 2116, loader disabled, [...]
       sim> RESTORE STATEFILE
       sim> EXAMINE 77700
       77700:  000000
       sim> SHOW CPU
       CPU, idle disabled, 32KW, 2116, loader enabled, [...]

     At this point, the loader is lost, and all locations between 77700 and
     77777 read as zero, regardless of the loader enabled/disabled setting.

     CAUSE:  During restoration, the protection status of the loader is not
     restored until after memory is restored.  If the loader is protected
     (disabled) when the RESTORE is done, the loader area cannot be written.
     After the RESTORE completes, the loader is enabled, but the loader area is
     blank.

     RESOLUTION:  Modify "mem_deposit" (hp2100_mem.c) to bypass the loader
     protection check if it is called for a RESTORE.

     STATUS:  Fixed in Release 32.



344. ENHANCEMENT:  Add a simulation of the CS/80 series of disc and tape drives.

     VERSION:  Release 31.

     OBSERVATION:  The CS/80 drives obsoleted the earlier MAC drives and were
     quite common on RTE-6/VM systems, which supported the C2203, a 670 MB
     drive.  They were interfaced via the 12821A HP-IB Disc Interface card; this
     card was also used to interface ICD (Amigo) disc and tape drives, such as
     the 7925H and 7974A.  We'd like to support a variety of CS/80 drives, which
     should be easy, given the block addressing employed.  The disc and tape
     image formats should be compatible with Ansgar Kueckes' HPDrive program for
     easy interchange.

     RESOLUTION:  Add a new "DC" device that simulates the CS/80 loader ROM and
     disc and tape drives connected to the 12821A Disc Interface.  Initial
     support is provided for the HP 7933A, 7941A, 7945A, 7957B, 7958B, and 7959B
     disc drives, the HP 9144A and 9145A cartridge tape drives, and the HP
     7908A, 7911A, 7912A, 7914A, 7942A, and 7946A combination disc and cartridge
     tape drives.

     STATUS:  Fixed in Release 32.



345. ENHANCEMENT:  Add a SET MPX CONNECT command to wait for a connection.

     VERSION:  Release 31.

     OBSERVATION:  Terminal multiplexer connections are made when the
     multiplexer polls the listening port while the simulator is executing.
     Typically, this is done at a calibrated rate of 100 Hz.  The listening port
     is set up with a queue depth of one connection, so if multiple terminal
     emulators are to be started before an operating system is booted, each
     connection must be made by running the simulator in a loop for a time long
     enough to cause a poll to occur.  This is awkward, as the CPU memory must
     be loaded with an execution loop, while the poll calibration interval is
     not known to the command file.  What is needed is a command that waits
     until a connection is made before returning.

     RESOLUTION:  Add a new "tmxr_connect" routine (sim_extension.c) that can be
     called as a validation routine.  The routine will wait until a line
     connection is made before returning, or it may be aborted by entering
     CTRL+E.  Add new "CONNECT" device commands to "baci_mod" (hp2100_baci.c),
     "mpx_mod" (hp2100_mpx.c), and "muxu_mod" (hp2100_mux.c) that call
     "tmxr_connect".

     STATUS:  Fixed in Release 32.



346. PROBLEM:  The E/F-Series TIMER instruction executes as NOP on a 2100 CPU.

     VERSION:  Release 31.

     OBSERVATION:  The undocumented E/F-Series TIMER instruction (100060) is
     used in a November 1977 Communicator/1000 article as a means to identify
     the type of CPU on which it is executing.  The table accompanying the
     article shows that the 2100 executes the instruction as LSL 16, while the
     2116/15/14 executes it as NOP.  However, when the test program given in the
     article is run with the simulator configured as a 2100, the instruction
     executes as NOP.

     CAUSE:  The instruction executor correctly handles the 1000 M-, E-, and
     F-Series cases, but it handles all 21xx machines together.  The 2100 should
     be handled as a separate case from the 211x CPUs.

     RESOLUTION:  Modify "cpu_eau" (hp2100_cpu1.c) to separate the 2100 from the
     other 21xx CPUs and execute the TIMER instruction as LSL 16 for that
     machine.

     STATUS:  Fixed in Release 32.



347. ENHANCEMENT:  Add a pre-execution initializer routine pointer to the DIB.

     VERSION:  Release 31.

     OBSERVATION:  Currently, the CPU simulator sends the ENF + SIR + PON
     signals to all device interface routines to indicate execution is about to
     begin.  But some devices, e.g., MEM, do not have a DIB and therefore no
     interface routine.  Moreover, while passing ioRUN would be more natural,
     there is no equivalent I/O signal for the 3000.  A better idea would be to
     have an optional initializer routine pointer in the DIB, much like the
     optional power routine.  This would be generic and would avoid co-opting
     signals for uses other than originally intended (hardware interfaces do not
     actually do initialization in response to the RUN signal).

     RESOLUTION:  Add a new "IO_INITIALIZER" function definition and a new
     "io_initializer" field of type "pointer to IO_INITIALIZER" to the DIB
     definition (hp2100_io.h).  Split the "initialize_io" (hp2100_cpu.c) routine
     into separate "setup_io_table" and "initialize_cpu" routines that are
     called during the instruction prelude.  The former builds the "iot" array,
     and the latter walks the array to call the new device initializer, if
     defined, and the device interface routine to pass ENF + SIR (without the
     added PON).  Change the "show_cage" routine to call "setup_io_table" prior
     to displaying the I/O card cage.

     STATUS:  Fixed in Release 32.



348. ENHANCEMENT:  Add a command to disable or enable all I/O devices together.

     VERSION:  Release 31.

     OBSERVATION:  Currently, a user who wants only a few specific devices in a
     simulation configuration will issue SET <device> DISABLED commands to
     remove all unwanted interfaces.  However, with the proliferation of I/O
     interface simulations, the user must constantly update his command files as
     new devices are added that default to enabled.  It would be more helpful if
     one could disable all devices at once with a new SET ALL DISABLED command.
     A corresponding SET ALL ENABLED command would also be useful, e.g., to set
     up the simulator in preparation to running a diagnostics suite.

     The commands should affect only those devices that install in the CPU's I/O
     card cage, i.e., that have select codes >= 10 octal.  CPU options, such as
     memory protect, would not be affected.

     RESOLUTION:  Add a new "hp_set_cmd" routine and corresponding CTAB entry to
     the "aux_cmds" array (hp2100_sys.c) that implements the new commands or
     calls the prior SET command handler if ALL is not specified.

     STATUS:  Fixed in Release 32.



349. PROBLEM:  The RUN, GO, etc. commands accept physical starting addresses.

     VERSION:  Release 31.

     OBSERVATION:  Several commands that operate on logical addresses, e.g.,
     RUN, GO, BREAK, and NOBREAK, accept physical address forms.  For example,
     the commands "RUN 0.0" and "RUN 37.1777" are accepted, although "RUN 40.0"
     is not.

     The manual says, "The RUN and GO commands accept only logical addresses
     consisting of 15-bit offsets within the 32K logical address space (e.g.,
     77777). If the starting address is supplied, it is stored in the P register
     before execution begins."  Similar wording is present in the manual for the
     BREAK and NOBREAK commands.  While the commands do not accept physical
     addresses outside of the 32K logical range, they should reject physical
     address forms to be consistent with the documentation.

     CAUSE:  The "parse_addr" routine accepts either address form and then
     checks that the result is within the logical address range if the
     "parse_physical" flag is FALSE.  It should instead report a parsing error
     if the flag is FALSE and a physical address is supplied.

     RESOLUTION: Modified "parse_addr" (hp2100_sys.c) to reject physical addresses
     with an "Invalid argument" error if the "parse_physical" flag is FALSE.

     STATUS:  Fixed in Release 32.



350. PROBLEM:  EXAMINE -A prints integers for characters above 127 decimal.

     VERSION:  Release 31.

     OBSERVATION:  When examining data, specifying the -A switch prints 16-bit
     values as single characters from the right-hand byte, and specifying -C
     prints the values as two characters.  For example:

       sim> DEPOSIT 0 101
       sim> EXAMINE 0
       0:      000101
       sim> EXAMINE -A 0
       0:      'A'
       sim> EXAMINE -C 0
       0:      NUL,'A'

     For the -C switch, the manual says, "Alphanumeric, punctuation, and symbol
     characters are displayed within apostrophes, control characters are
     displayed as ASCII name abbreviations, and characters above 128 decimal are
     displayed in escaped numeric form with a leading backslash followed by an
     octal number."  This occurs as expected:

       sim> DEPOSIT 0 100200
       sim> EXAMINE 0
       0:      100200
       sim> EXAMINE -C 0
       0:      \200,\200

     However, it does not work with the -A switch:

       SIM> EXAMINE -A 0
       0:      100200

     The expected result is "\200" to be consistent with the -C formatting
     switch.  However, if the value is between 200 and 377 octal, the switch is
     ignored, and the value is printed as an integer.

     CAUSE:  The "fprint_value" routine is used to print single values in a
     specified radix.  For radix 256, the routine calls "fmt_char" to format the
     value as a printable character, control mnemonic, or octal escape if the
     value fits in a single byte.  However, the value is compared to the signed
     byte maximum (177 octal) rather than to the unsigned byte maximum (377), so
     values greater than 127 decimal are rendered with the integer formatter.

     RESOLUTION:  Modify "fprint_value" (hp2100_sys.c) to use the correct byte
     range comparison value.

     STATUS:  Fixed in Release 32.



351. PROBLEM:  Runaway causes read failures in the 7970 tape drive simulator.

     VERSION:  Release 31.

     OBSERVATION:  When reading or spacing a tape image that contains long erase
     gaps (over 25 feet at the nominal density) with the HP 7970 tape drive
     simulator (MS device), the operation fails with no error reported.  A read
     will return no data but will report successful completion.  Spacing will
     report success without moving past the next record or tape mark.

     Performing the same operations on the same tape image with the HP 3030 tape
     drive simulator (MT device) works properly.

     CAUSE:  To support writing erase gaps, the MS device sets the tape density
     to 800 bpi (13181 interface selected) or 1600 bpi (13183 interface
     selected).  Setting the density also enables checking for tape runaway,
     which occurs if a read does not encounter a record or tape mark within 25
     feet of the initial location.  Tape runaway is indicated by a read or
     spacing routine returning MTSE_RUNAWAY status.  The "ms_map_err" routine
     that maps SIMH status values to 7970 status bits does not handle this
     value and so fails to set any error indication.

     The HP 3030 simulator does not set tape density, so the SIMH tape library
     skips all gaps when reading or spacing, and the routines complete normally.

     RESOLUTION:  Modify "ms_erase_gap" (hp2100_ms.c) to call "sim_tape_errecf"
     instead of "sim_tape_wrgap", as the former does not require that the tape
     density be set.  Add a macro to nullify calls to "sim_tape_set_dens".
     Modify "ms_err_map" routine to catch unmapped tape errors and report an
     Internal error to the console if one is passed.

     (This is an interim solution until the tape library is modified to separate
     the actions of setting the density and returning MTSE_RUNAWAY, at which
     time the call to "sim_tape_wrgap" can be restored.)

     STATUS:  Fixed in Release 32.



352. PROBLEM:  2000A TSB SLEEP command to an HP 3030 drive hangs while writing.

     VERSION:  Release 31.

     OBSERVATION:  When running HP 2000A Time-Shared BASIC with an HP 3030
     magnetic tape drive, entering a SLEEP command hangs execution.  Examination
     of the tape image shows that only the first record is being written.

     CAUSE:  The TSB mag tape driver calls a common routine to issue a tape
     command and then wait for the command channel flag to set.  After the data
     for a Write Record command has been sent to the drive, the driver calls the
     common routine to wait for the command channel flag to set, indicating that
     the drive has completed the write, and passes a command byte of zero.  This
     is an undefined command, and in response the interface handler sets the
     Reject status bit and exits without setting the flag.  The driver then
     waits forever in a SFS CC / JMP *-1 loop.

     However, the 12559A interface schematic shows that IOO is gated with IOBO0
     (the Motion bit), so commands without bit 0 set are ignored (Clear
     Controller, octal 300, is decoded separately).  Also, the schematic shows
     that Reject status is not set for an invalid command; it sets only for
     motion while the card is busy, backward motion with the tape at the load
     point, or a Write Record command when no write ring is present.

     RESOLUTION: Modify the IOO handler in "mtc_interface" (hp2100_mt.c) to
     ignore commands that do not have the Motion bit set, unless except for the
     Clear Controller command.

     STATUS:  Fixed in Release 32.



353. PROBLEM:  2000A TSB SLEEP command to an HP 3030 drive hangs during verify.

     VERSION:  Release 31.

     OBSERVATION:  When running HP 2000A Time-Shared BASIC with an HP 3030
     magnetic tape drive, responding "YES" to the "VERIFY ?" question during a
     SLEEP command hangs execution.  Examination of the tape image shows that
     it is being written correctly and is complete prior to the verify.

     CAUSE:  The hang occurs in the mag tape driver when a Read Record command
     encounters the first tape mark.  The driver is expecting a data flag,
     because an NRZI tape mark is a single byte with value 23 octal, followed by
     seven byte spaces, and ending with the LRCC byte.  The service routine
     reacts to the MTSE_TMK status return from the read record routine by
     scheduling the command flag to indicate completion, but it never sets the
     data flag.

     RESOLUTION:  Modify "mtc_svc" (hp2100_mt.c) to set EOF status and deliver
     the tape mark data byte along with the data flag before setting the command
     flag.

     STATUS:  Fixed in Release 32.



354. ENHANCEMENT:  Add AUTO/LOCAL commands to the HP 3030 simulator.

     VERSION:  Release 31.

     OBSERVATION:  The HP 3030 drive has an online/offline switch, labeled AUTO
     and LOCAL, respectively.  The simulator does not offer these commands, so
     the Rewind and Standby command detaches the image instead of merely setting
     the drive to local mode.  This differs from all other simulations of
     devices that have online/offline switches.

     RESOLUTION:  Modify "mtc_mod" (hp2100_mt.c) to add modifier entries for
     AUTO and LOCAL, and add a new "mtc_online" routine to validate the AUTO
     command to ensure that a tape is mounted.  Adjust other routines that used
     the attachment state to define the Local status bit to use the AUTO/LOCAL
     setting instead.

     STATUS:  Fixed in Release 32.



355. ENHANCEMENT:  Add erase gap support to the HP 3030 simulator.

     VERSION:  Release 31.

     OBSERVATION:  The HP 3030 has a Write Gap command, but the simulator
     currently ignores it.  All other tape drives support writing gaps.  This
     one should also.

     RESOLUTION:  Modify "mtc_svc" (hp2100_mt.c) to add a call to the tape
     library to erase three inches of tape in response to a Write Gap command.

     STATUS:  Fixed in Release 32.



356. PROBLEM:  Paper tape reader/punch EXAMINE/DEPOSIT do not work correctly.

     VERSION:  Release 32.

     OBSERVATION:  Given a text file containing "ABCD", attaching it to the
     paper tape reader and then attempting to examine the contents prints the
     wrong values:

       sim> attach ptr abcd.txt
       sim> examine -a ptr 0-3
       0:      'B'
       1:      'B'
       2:      'D'
       3:      'D'
       sim> examine -c ptr 0-3
       0:      'B','A'
       2:      'D','C'

     CAUSE:  The PTR and PTP devices use the default examine and deposit
     routines instead of the "hp_word_examine" and "hp_word_deposit" routines
     that handle the byte/word conversions properly.

     RESOLUTION:  Modify "ptr_dev" and "ptp_dev" (hp2100_pt.c) to specify
     "hp_word_examine" and "hp_word_deposit" as the examine and deposit
     routines, respectively.

     STATUS:  Fixed in Release 33.



357. PROBLEM:  Image file EXAMINE of a byte within one byte of the EOF fails.

     VERSION:  Release 32.

     OBSERVATION:  Given a text file containing the single character "A",
     attaching it to the paper tape reader and then attempting to examine the
     contents prints an error:
     
       sim> attach ptr a.txt
       sim> examine -a ptr 0
       End of file

     CAUSE:  For byte-oriented devices, the "hp_word_examine" routine is called
     to read a 16-bit value from the device.  It issues a "sim_fread" for two
     bytes, assembles them into a 16-bit word, and returns the word.  However,
     it does not check the number of bytes read, instead relying on the "feof"
     routine to determine if the read was successful.  When the file is
     positioned one byte from the end, the two-byte read returns a count of one
     and sets the EOF indicator.  This causes the routine to assume that the
     read had failed.

     RESOLUTION:  Modify "hp_word_examine" (hp2100_sys.c) to check the count
     returned from "sim_fread" before checking for EOF, in case only one of the
     two bytes is returned.

     STATUS:  Fixed in Release 33.



覧覧覧覧覧覧覧覧覧覧覧覧覧覧覧覧覧覧覧覧覧覧覧覧覧覧覧覧覧覧覧覧覧覧覧覧覧覧覧覧



xxx. PROBLEM:

     VERSION:  Release .

     OBSERVATION:

     CAUSE:

     RESOLUTION:

     STATUS:  Fixed in Release .



xxx. ENHANCEMENT:

     VERSION:  Release .

     OBSERVATION:

     RESOLUTION:

     STATUS:  Fixed in Release .