Commit graph

5 commits

Author SHA1 Message Date
Mark Pizzolato
6bbbc19e01 HP3000: Update to early Release 8 which is still simh V4.x API compatible
Dave Bryan has migrated support for this simulator to http://simh.trailing-edge.com/hp
2020-02-16 22:24:16 -08:00
Mark Pizzolato
629f0f0c07 HP3000: Fourth HP 3000 release
See HP3000/hp3000_release.txt for details of the release
2017-01-10 12:32:23 -08:00
Mark Pizzolato
e370b9e78e HP3000: Third HP 3000 release from Dave Bryan 2016-09-20 20:34:22 -07:00
Mark Pizzolato
07f99bb8c3 HP3000, HP2100: Updated simulators from Dave Bryan
- This release of the HP 3000 simulator adds the following device simulation:

  - 30209A Line Printer Controller with One 2607/13/17/18 Line Printer

The simulation supports the use of custom VFU tape images, as well as the
built-in HP-standard VFU tape.  The simulated device name is "LP".  The full set
of configurable options is detailed in a new section of the HP 3000 Simulator
User's Guide.

In addition, the preconfigured MPE-V/R disc image has been updated to add the
following features:

  - The MPE cold load command files attach the line printer to the "lp.txt"
    output file and specify the "-n" option to clear the file before use.

  - Preinstalled User-Defined Commands (UDCs) provide access to the COBOL 74
    compiler with the MPE-V/E :COBOLII, :COBOLIIPREP, and :COBOLIIGO commands,
    and to the COBOL 85 compiler with :COBOLIIX, :COBOLIIXPREP, and :COBOLIIXGO.
    However, see the implementation note below.

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

 - MPE requires a line printer, so it is recommended that the MPE startup
   simulator command file include an ATTACH LP <filename> command to load paper
   into the printer before cold loading.  If the printer is not attached, it
   will appear to MPE to be out of paper.

 - The line printer terminates each print line with an HP-standard CR/LF pair.
   If the output file is to be retained as a text file on a Unix system, removal
   of the carriage returns, e.g., via the "dos2unix" utility, may be desirable.

 - The simulator currently does not provide the HP 32234A COBOL II firmware
   instructions, so programs generated by the COBOLII compiler will abort at run
   time with an "ILLEGAL INSTRUCTION" error.  Programs generated by the COBOL
   compiler do not use these instructions and therefore are not affected.

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

  1. PROBLEM:  The effective address of a byte pointer with a negative index is
     calculated incorrectly.

     VERSION:  Release 1

     OBSERVATION:  Defining a :WELCOME message in MPE appears to work, but when
     the next logon attempts to print the message, an infinite number of CRLFs
     are printed instead.

     CAUSE:  The welcome message is stored in an extra data segment.  The format
     for each message line is a line length stored in the lower byte of the word
     preceding the message string.  The code defines BYTE POINTER NEXTLINE and
     points NEXTLINE to the first message character.  The line length is set
     with NEXTLINE(-1) := IOCOUNT.  This generates a LOAD <IOCOUNT> ; LDXN 1 ;
     STB <NEXTLINE>,I,X sequence.

     In the "cpu_ea" routine, the indexing adds the X register value (-1) to the
     byte pointer (NEXTLINE).  This causes an overflow that is not masked to 16
     bits.  For a word access, this displacement is added to the base register
     and then masked to 16 bits, which gives the correct value.  However, for
     byte accesses, the displacement is divided by 2 and then added, and the sum
     is masked.  Dividing by 2 shifts the overflow bit into the MSB, causing the
     addition result to be off by 32K.  The STB goes to the wrong location, the
     original zero in the length byte location is retained, and when the welcome
     message is printed, a zero-length line is printed, and the byte pointer is
     incremented by zero, so the null line is printed forever.

     RESOLUTION:  Modify "cpu_ea" (hp3000_cpu.c) to mask indexed displacements
     to 16 bits after adding the X register value.

     STATUS:  Fixed in Release 2.

  2. PROBLEM:  An SMSK instruction may clear the interrupt mask flip-flop of a
     device that specifies that it is should be "always enabled."

     VERSION:  Release 1

     OBSERVATION:  If the TOS word is zero, an SMSK instruction will clear the
     interrupt mask flip-flop of a device whose mask jumper is set to "E"
     (always enabled).

     CAUSE:  In response to a DSETMASK signal, device interfaces set their
     interrupt mask flip-flops by "anding" the incoming data word with the
     interrupt mask jumper setting.  The jumper setting value for "always
     enabled" is %177777, which sets the mask flip-flop in all cases, except
     when the data word is zero.

     RESOLUTION:  Modify hp3000_atc.c, hp3000_ds.c, and hp3000_ms.c to set their
     mask flip-flops unconditionally if the jumper setting is "E".

     STATUS:  Fixed in Release 2.

  3. PROBLEM:  The "SET <dev> INTMASK=<n>" command sets the wrong bit in the
     device interface's interrupt mask jumper setting.

     VERSION:  Release 1

     OBSERVATION:  The interrupt mask jumper on a device interface is set by
     specifying the mask bit number in a "SET <dev> INTMASK=<n>" command.  This
     sets a bit in the device's interrupt mask jumper word corresponding to the
     bit number requested.  However, the bit numbering is incorrect; setting the
     jumper for bit 15, for example, sets bit 0 of the jumper word.  Therefore,
     the interface's mask flip-flop is not set as expected when an SMSK
     instruction is executed.

     CAUSE:  The bit numbers were counted from the wrong end of the word.

     RESOLUTION:  Modify "hp_set_dib" and "hp_show_dib" (hp3000_sys.c) to number
     the bits from the MSB instead of the LSB.

     STATUS:  Fixed in Release 2.

  4. PROBLEM:  The Multiplexer Channel is not generating the ACKSR signal
     correctly.

     VERSION:  Release 1

     OBSERVATION:  The line printer controller hangs when an SIO chained write
     is performed.  The first programmed write completes normally, but the
     second does not start.  The channel is waiting for a service request that
     does not occur.

     CAUSE:  The service request from the last write of the first block transfer
     is being cleared by an ACKSR generated by the Multiplexer Channel when it
     performs the IOCW fetch in State A for the second write request.  The
     channel should omit this ACKSR when the previous I/O order was a chained
     read or write.  However, the simulator is testing the order just fetched
     (Write) instead of the order that has just completed (Write Chained).

     RESOLUTION:  Modify "mpx_service" (hp3000_mpx.c) to test the correct I/O
     order in State A.

     STATUS:  Fixed in Release 2.
2016-07-05 22:09:21 -07:00
Mark Pizzolato
3a4e879c07 HP3000: Initial release of the HP 3000 Series III simulator (from Dave Bryan) 2016-03-07 20:47:57 -08:00