HP 3000 Simulator Project Status ================================ -------------- Overall Status -------------- - All devices are feature-complete. - Diagnostics generally pass with some expected failures in tape simulations due to unimplemented features (e.g., NRZI CRCC/LRCC handling). - MPE can be RELOADed to generate a new disc-based system from the FOS tape. - MPE can be COOLSTARTed to run from a previously generated disc. - The operator and system manager can be logged in and out, and MPE can be SHUTDOWN through to a HALT 17. - MPE FOS programs (EDITOR, QUERY) and SUBSYS programs (SPL, BASIC, BASICOMP) appear to run OK. - The CPU is a hybrid of the Series II instruction set microcode and the Series III memory size and hardware behavior, because the Series III microcode is not available. - The CPU is currently missing a few "difficult" instructions (e.g., the entire EIS, CMD, and LOCK). ---------------------------------- Work Remaining Before Next Release ---------------------------------- ----------------- Blocking Problems ----------------- - The COBOLII "CLOSE" statement calls IO'CLOSE'FILES, which is present in the COBLIB18 segment of the system SL for V/E but not for V/R. Note that the COBOL/II product is 32233A, the COBOL/II firmware is 32234A, and there is a "COBOL LIB" product 32232A listed in the HPSWINFO.PUB.SYS file on V/E. - The SUBSYS file for E.01.00 lists COBCNV.PUB.SYS as part of the COBOL/II product, but it's not included in the MPE kit. --------------------- Non-Blocking Problems --------------------- (none) ----------------------- Bugs in MPE V/R E.01.00 ----------------------- - After a cold load from tape (COLDSTART/RELOAD/UPDATE), if a non-HP terminal, such as the simulation console, is used as the system console, MPE prints DATE (M/D/Y)? and then WED, NOV 1, 1972, 12:00 AM, as though RETURN had been entered, but it wasn't. The problem in in procedure SPEEDSENSE in module INITIAL: BEGIN << GOT A CARRIAGE RETURN >> X := IF UNIT = 0 THEN 0 ELSE UNIT-15; BAUDRATE := BRPARAM(X); CONSPEED := SPEEDS(X); END; The X register is overwritten with the address for the PSTA instruction that sets BAUDRATE, so CONSPEED gets an invalid value. Procedure INITDATETIME in module PROGEN subsequently calls READ to get the user's response to the DATE? question, but READ fails due to the invalid speed value. The resulting zero-length read is interpreted as though RETURN had been entered. If an HP terminal is used as the system console, SPEEDSENSE uses different code that uses a local variable as the array index, so the absolute locations are set correctly. Although the "Console Operator's Guide" (32002-90004) for the Series II/III says to "Press RETURN on the system console" after cold loading, procedure SPEEDSENSE first tries to "auto-speed-sense" at rates of 240, 120, 60, 30, 15, and 10 characters per second by sending an ENQ and waiting an appropriate time for an ACK. If an ACK is not returned, then speed sense is performed by configuring channel 0 and the auxiliary channels (16-20) to the set of rates and then waiting until RETURN is pressed. The channel on which a CR is read is used to set the terminal speed. This is MPE V/R SSB KPR Number 5000187104, "Foreign devices as SIII system consoles do not work correctly on V/R." HP issued a patch for this, but it does not seem to have survived. A simple workaround is to set local ENQ/ACK processing on ATC channel 0 (SET ATCD0 LOCALACK) when the system console is not an HP terminal. This is the default setting, so the bug only manifests itself when SET ATCD0 REMOTEACK is done before booting. An alternate workaround is to patch location 01.112247 containing LOAD P+22,I,X with the value 021360 (LDI 360). This sets the terminal speed to 240 cps always, but speed sensing is faked in the ATC simulation anyway. The patch can be applied after the cold load completes and before the COLDSTART/RELOAD/UPDATE is run. Once patched, subsequent WARMSTARTs and COOLSTARTs will get the correct speed value, so patching when booting from the disc is not necessary. - If a SHUTDOWN is performed while a logon read is pending on the system console, e.g., by pressing RETURN to obtain the colon prompt after logging OPERATOR.SYS off, the expected "ALL JOBS LOGGED OFF" message does not print. Instead, a single digit (0, 1, or 2) is printed on a line by itself, followed as expected by SHUT and a HALT %17. The digit is the leading digit of the time of the expected message. The problem is in procedure CONSSHUTDOWN in module PROGEN. GENMSG is called to print the "ALL JOBS LOGGED OFF" message. While the message is being sent to the ATC character-by-character, CONSSHUTDOWN loops through the Process Stop Table to stop each of the system processes in turn. The first process in the table is DEVREC, which is responsible for issuing the logon read. As part of stopping, DEVREC checks for outstanding reads and calls ABORTIO to terminate the read on the system console. Unfortunately, ABORTIO aborts all I/O requests on the specified device, including PROGEN's output request for the "ALL JOBS LOGGED OFF" message. The timing is such that only the first character or two of the message is printed before the rest of the output is cancelled. No SSB KPR has been located, but a later MPE version inserted an ABORTIO call for the system console immediately before logging all sessions off. This is before the call to GENMSG, so the logon read will not exist, and therefore DEVREC will not call ABORTIO, allowing output of the "ALL JOBS LOGGED OFF" message to run to completion. It is impossible to patch memory to add this call, so the only workarounds when shutting down are to avoid requesting the logon prompt, wait until the logon timeout expires (nominally two minutes), log on and then back off again, enter "=ABORTIO 20" to abort the read, or accept that the message will be truncated. The only consequence of this bug is the partial message; MPE shuts down properly otherwise, so it may be safely ignored. - After a RELOAD, running DPAN4.PUB.SYS produces a "CODE SEGMENT TOO LARGE (LOAD ERR 33)" error. This is because MPE defaults to an 8K code segment size limit, and DPAN4 has three segments between 8K and 12K in size. If the limit is subsequently raised via a SYSDUMP and COLDSTART reconfiguration, running DPAN4 produces a "FILE IS NOT A VALID PROGRAM FILE" error. However, if the reconfiguration is done before running DPAN4, it will run properly thereafter. The problem is in procedure LOADPROGRAM in module LOAD. After constructing an old-to-new Code Segment Table map, a loop is executed to load the program's segments. Each pass of the loop checks the segment's size and then calls procedure LOADSEGMENT to patch the Segment Transfer Table using the new CST map and then rewrite the STT to the program's file on disc. DPAN4 consists of 12 segments. Segment 4 is 8.4K in size, so with the default 8K limit, the loop exits with error code 33. However, the STTs of segments 1-3 have already been changed and rewritten to the program file. This leaves the file in an inconsistent state. After reconfiguration to raise the segment size limit, the size check on segment 4 passes, but LOADSEGMENT fails when attempting to locate externals referenced by the STT, leading to the "NOT A VALID PROGRAM FILE" message. If the limit is raised before running DPAN4, the file is internally consistent when the STTs are patched, and each segment's load succeeds, allowing the program to run. Note that the loop may exit with error code 39 ("ILLEGAL CAPABILITY") if a user without PM capability attempts to run a program containing a privileged segment. If the segment is not segment 1, the same file inconsistency will occur. No SSB KPR has been located, but a later MPE version moves the size and capability tests into a second loop that executes before the LOADSEGMENT loop. This ensures that aborts occur before any of the STTs are modified, so the program file remains internally consistent. A memory patch is impossible, but workarounds are to increase the code segment limit before running DPAN4 and to RESTORE DPAN4.PUB.SYS from the FOS tape if it has been damaged. ----- Notes ----- - MPE has a firmware simulation module that implements the Extended Instruction Set, so programs using EADD, etc. will work correctly if the firmware is not installed. Although the EIS was an option for the 3000 CX, it appears to have been standard equipment for the Series II and later. Simulation is therefore desirable, but priority is low, as MPE will run without it. - Although fault-control memory was standard on the Series II and later, the memory fault logger is smart enough to realize that the FLI is not there, so MPE will run without it. As with the EIS, it would be desirable to simulate the FLI, although memory errors cannot occur. - It's not clear whether PCLK should default to calibrated or real-time mode. The problem is the disparity between simulated and real instruction execution times -- the simulator is on the order of 30 times faster than a real 3000. If PCLK is calibrated to wall clock time, the CPU time reported by MPE will be far too low. For example, a compilation that reported taking 60 CPU seconds on a real HP 3000 would report taking 2 CPU seconds under simulation. With PCLK set to real-time mode, the compiler would report 60 CPU seconds. However, if PCLK set to real-time mode, a SHOWME for a compute-bound process (e.g., a BASIC "10 GOTO 10" program) interrupted after 10 seconds of real time would report running for 300 CPU seconds and 1 minute of connect time. With PCLK set to calibrated mode, SHOWME would report 10 CPU seconds. Also, for idling to work, PCLK would have to be stopped, not just count-inhibited, when on the ICS, as otherwise the very short real-time PCLK interval would preclude idling. - The I/O diagnostics load from tape and then wait for a before starting. Currently, we have to STEP some large number of instructions to accommodate the load and then the mux setup. That's because a reply of will be issued immediately upon resuming, i.e., before the tape load is done. It might be OK to recast the console delay from a halt delay to a reply delay, as I don't know of anything that depends explicitly on the delay occurring before the halt occurs. Implementation would have the reply setting rptr to NULL and activating the halt delay timer, which sets rptr to point at rbuf when the timer expires. Alternately, adding a -q (quiet) option to the STEP command to suppress the "Step expired" message would seem to work equivalently. --------------------------- Downloads of hp3000_doc.pdf --------------------------- Mar 2016: 59 (1st release 3/7/16) Apr 2016: 10 May 2016: 8 Jun 2016: 4 Jul 2016: 78 (2nd release 7/5/16) Aug 2016: 21 Sep 2016: 12 (before 3rd release) 95 (after 3rd release 9/21/16) Oct 2016: 51 Nov 2016: 47 Dec 2016: 20 Jan 2017: 3 (before 4th release) 66 (after 4th release 1/26/17) Feb 2017: 7 (through 2/18/17)