Rivoreo Source Code Repositories
src.rivoreo.one / emulators / simh / 1c4a1ed87141e5586d590bb28832b9081e477bb5 / . / HP2100 / hp2100_bugfixes.txt
blob: 9978bf2295febf39b65edefcb8bbd29d2e1311e9 [file] [log] [blame] [raw]
HP 2100 SIMULATOR BUG FIX WRITEUPS
==================================
Last update: 2016-07-28
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.
22. PROBLEM: Doing an EDIT pending line character insert with CTRL+S doesn't
work.
VERSION: 3.2-1
OBSERVATION: CTRL+S is not passed through to the simulated program.
Instead, pressing CTRL+S and typing simply absorbs the first character, and
the editor stays in "replace" mode for the succeeding characters.
CAUSE: The keyboard "peek" routine that checks for a pending input
character does not operate in "raw" mode. The simulator calls "_kbhit" to
determine if an input character is pending and "_getch" to retrieve that
character. "_getch" calls the Windows routine "SetConsoleMode" to set the
input mode to "raw" (i.e., no processing of the input characters). However,
"_kbhit" does not, and so the CTRL+S is intercepted and processed by
Windows.
RESOLUTION: Modify "sim_ttrun" and "sim_ttcmd" (sim_console.c) to switch
the console into and out of "raw" mode. This inhibits "_kbhit" from
interpreting the input character stream. As an added benefit, CTRL+C is no
longer interpreted as SIGINT, so all of the associated signal-handling code
("win_handler", etc.) may be removed.
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.
25. PROBLEM: Logging console output to a file produces CR CR LF as line
terminators.
VERSION: 3.2-1
OBSERVATION: When console logging is enabled, simulator messages as well as
the console output from the simulated system are written to the log file.
The former outputs CR LF at the end of each line. The latter outputs CR CR
LF.
CAUSE: The log file is opened in "text mode" by default, which translates
LFs (C newlines) to CR LF sequences. Simulator messages terminate with
newlines, and these are translated to CR LF sequences. When the simulated
system writes characters to the console, they are also written to the log
file. When the simulated system outputs a CR, it is output verbatim. When
it follows that with an LF, however, that gets translated into a CR LF, so
the log file then has CR CR LF as the end of line sequence.
RESOLUTION: Flush the accumulated file stream buffer and change the file
mode from TEXT to BINARY in "sim_ttrun" (sim_console.c) when the simulation
starts, and then back to TEXT in "sim_ttcmd" when the simulation ends.
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.
27. ENHANCEMENT: Add an "echo" command to print arbitrary strings on the
simulation console for use in simulation command files.
VERSION: 3.2-2
OBSERVATION: Simulation command files allow automation of complex or
tedious simulator setups. Because of the potentially lengthy sequence, it
would be helpful if the command file had a way to inform the user where it
was in the process. Providing a command to do this allows messages such as
"Loading diagnostic," "Configuring diagnostic," etc., to be printed during
command file execution.
RESOLUTION: Implement an "echo <string>" command (scp.c).
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.
32. PROBLEM: Running the 7970 diagnostic reports "Magtape library I/O error:
Invalid argument" when executing Test 4.
VERSION: 3.2-2
OBSERVATION: The error occurs when a write is aborted with a clear command.
CAUSE: If a CLR command is issued with a write in progress, the simulator
attempts to mark the record as bad on the tape by adding the "MTR_ERF" flag
to the "sim_tape_wrrecf" call. Unfortunately, that function does not remove
the flag before calling "sim_fwrite", and so the eventual OS call sees the
equivalent of a very large record length and therefore returns EINVAL.
RESOLUTION: Modify "sim_tape_wrrecf" (sim_tape.c) to mask off the "MTR_ERF"
flag when determining the record length.
STATUS: Fixed in version 3.2-3.
OBSERVATION: The library error is not stopping the simulator, even though
the STOP_IOE variable is set.
CAUSE: "sim_tape_ioerr" is returning "SCPE_IOERR" instead of "MTSE_IOERR",
and "ms_map_err" maps this to "SCPE_OK", so the simulator isn't halted.
RESOLUTION: Modify "sim_tape_ioerr" (sim_tape.c) to return "MTSE_IOERR"
instead of "SCPE_IOERR".
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.
49. PROBLEM: The "do" command does not obey the "-v" ("verbose") option switch
when console logging is in effect.
VERSION: 3.2-2
OBSERVATION: Command file commands are always written to the console log
file, regardless of the setting of the "-v" switch. Commands are only
displayed on the console when "-v" is specified. The console log file,
therefore, is not a copy of what appeared on the console.
CAUSE: Output of the file commands is not conditional on the "-v" switch.
RESOLUTION: Modify "do_cmd" (scp.c) to condition writing file commands to
the console log on the "-v" switch.
STATUS: Fixed in version 3.2-3.
50. PROBLEM: The "echo" command does not echo to the console log file.
VERSION: 3.2-2
OBSERVATION: The "echo" command writes its argument only to the console.
If logging is in effect, the echoed strings will not appear in the file.
CAUSE: This action was omitted.
RESOLUTION: Modify "echo_cmd" (scp.c) to copy the echoed argument string to
the console log file if logging is in effect.
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.
58. PROBLEM: According to the HELP display, SET <dev>, SET <unit>, and SET
CONSOLE should allow a comma-separated list of parameters, but such commands
are rejected with "Non-existent parameter."
VERSION: 3.2-3
OBSERVATION: Doing HELP SET lists the following syntax for the above
commands:
set console arg{,arg...} set console options
set <dev> arg{,arg...} set device parameters
set <unit> arg{,arg...} set unit parameters
None of these work, however, as each accepts only a single argument. Note
that the corresponding SHOWs do accept multiple arguments.
CAUSE: The "get_glyph" routines that parse the command parameters are
missing the option to indicate that commas are glyph separators.
RESOLUTION: Modify the appropriate calls to "get_glyph" (scp.c,
sim_console.c) to specify ',' as the "optional end of glyph character"
parameter.
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.
68. PROBLEM: Attached device output files and debug log files cannot be
examined after a simulation stop.
VERSION: 3.2-3
OBSERVATION: After stopping simulation, either via a breakpoint or CTRL+E,
viewing attached device output files or the device debug log file reveals
incomplete data, limiting the ability to determine what has been output at
the point of interruption.
CAUSE: All files are buffered, and the last bytes output haven't been
flushed to disk.
RESOLUTION: Modify "run_cmd" (scp.c) to flush the console log file, the
debug log file, and any attached output files before returning.
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.
91. PROBLEM: The DO command does not report errors to the log file.
VERSION: 3.3-0
OBSERVATION: Commands contained in a DO file that cause errors do not
report the errors to the console log file. They are reported to the
console. For example:
sim> set console log=wibble.log
Logging to file "wibble.log"
sim> wibble
Unknown command
sim> do wibble.sim (contains "wibble" as a command)
Unknown command
sim> quit
Goodbye
Log file closed
But wibble.log contains:
Logging to file "wibble.log"
sim> wibble
Unknown command
sim> do wibble.sim
sim> quit
Goodbye
Log file closed
Note that the second "Unknown command" message is missing from the log file.
CAUSE: "do_cmd" reports errors "stdout" only.
RESOLUTION: Modify "do_cmd" to report errors to "sim_log" if it is not
null.
STATUS: Fixed in version 3.3-1.
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.
104. ENHANCEMENT: Add a command to abort command file execution if a specified
simulator condition is not met.
VERSION: 3.3-1
OBSERVATION: Command files need a means of reacting to unexpected program
behavior. Currently, if a program deviates from expected behavior, e.g.,
if a diagnostic fails, the command file will become unsynchronized with the
program, leading to nonsensical operation.
To provide an escape mechanism for this situation, a command that tests
assertions of the simulator state and aborts a running command file if the
assertion fails is needed. The syntax is:
ASSERT {<dev>} <reg>{<logical-op><value>}<conditional-op><value>
If <dev> is not specified, CPU is assumed. <reg> is a register (scalar or
subscripted) belonging to the indicated device. The <conditional-op> and
optional <logical-op> are the same as those provided by the "examine" and
"deposit" commands. The <value>s are expressed in the radix specified for
<reg>, not in the radix for the device.
If the <logical-op> and <value> are specified, the target register value is
first altered as indicated. The result is then compared to the <value> via
the <conditional-op>. If the result is false, an "Assertion failed"
message is printed, and any running command file is aborted. Otherwise,
the command has no effect.
RESOLUTION: Modify "scp.c" to add "assert_cmd" and associated command
table entries.
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.
109. ENHANCEMENT: Allow the DO command to nest to some finite level.
VERSION: 3.3-2
OBSERVATION: Allowing a limited depth of nested DO invocations is useful
for modularizing simulator command files. The current prohibition is not
necessary, as "do_cmd" is reentrant.
RESOLUTION: Modify "do_cmd" (scp.c) to allow DO command nesting, provide a
recursion counter to disallow infinite nesting, and alter the text of the
SCPE_NEST error to reflect allowed nesting.
STATUS: Fixed in version 3.4-0.
110. PROBLEM: SET <device> DEBUG=n1,n2,... doesn't work.
VERSION: 3.3-2
OBSERVATION: For devices with multiple debug flags, trying to set more
than one with the above command fails with "Non-existent parameter."
Setting the flags one at a time with separate commands works as expected.
CAUSE: The command parser breaks SET commands at commas, so "n2" is
interpreted as the next top-level SET command, rather than as another debug
flag.
RESOLUTION: Alter the debug flag separator from "," to ";".
STATUS: Fixed in version 3.4-0.
111. ENHANCEMENT: Allow SET <device> DEBUG to mean "set all debug flags."
VERSION: 3.3-2
OBSERVATION: Currently, if a device has multiple debug flags, SET <device>
DEBUG is rejected. To set all flags, they must be specified individually.
RESOLUTION: Alter "set_dev_debug" (scp.c) to set all debug flags if none
are specified in the SET <device> DEBUG command.
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.
113. PROBLEM: "SET CONSOLE DEBUG" with no parameter crashes the simulator.
VERSION: 3.6-0
OBSERVATION: Entering "SET CONSOLE DEBUG" without the "=<parameter>"
causes the simulator to crash with an access error.
CAUSE: Null pointer dereferenced in "sim_set_debon".
RESOLUTION: Return SCPE_2FARG if "cptr" is null (no parameter supplied) or
points to a null character (empty parameter supplied).
STATUS: Fixed in version 3.6-1.
114. PROBLEM: Nested command files do not abort on assertion failure.
VERSION: 3.6-0
OBSERVATION: While a failed assertion will abort a running command file,
it will not abort if the assertion is in a nested command file invocation.
CAUSE: "do_cmd" is always passing back SCPE_OK, regardless of whether an
invoked command returns an error status. This is apparently an attempt to
avoid duplicate error messages if the last command in a command file fails
(the error is printed within "do_cmd" and then again in the main command
loop).
RESOLUTION: Modify "do_cmd" (scp.c) to return all command error codes and
to return SCPE_OK on command file EOF.
STATUS: Fixed in version 3.7-0.
115. ENHANCEMENT: Provide an -E switch to DO to abort a command file on any
error.
VERSION: 3.6-0
OBSERVATION: Current DO processing ignores command errors. That is, if a
command returns an error, the error message is printed, but processing
continues with the next command in the file. This is inherently risky, as
command files must be written with the expectation that every command will
succeed (because there is no error trapping or conditional execution).
RESOLUTION: Add a new -E switch to cause command file execution to be
aborted at the first error encountered. Note that SCPE_STEP is not
considered an error, and simulator-specific errors, e.g., "infinite
indirect loop," does not cause an error abort (simulator limitation).
STATUS: Fixed in version 3.7-0.
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.
131. PROBLEM: Errors in nested command files give no indication where the error
occurred.
VERSION: 3.6-1
OBSERVATION: Unless the -V switch is specified, errors in command files
report the error message but not the offending command. With the advent of
nested command files, the problem becomes more acute, as there is no
indication in which of perhaps several nested command files the offending
command is located, nor even which command is causing the error. And
because -V is not transitive, each DO command appearing in each command
file must be edited to add the -V switch if the error is to be located.
CAUSE: The implication of errors in nested command files was overlooked
when nesting was enabled.
RESOLUTION: Modify "do_cmd" (scp.c) to echo commands causing errors,
regardless of the -V switch, unless -Q (quiet) is supplied when starting
SIMH. Also, report the name of the file containing an offending command.
Note: because commands returning error status are now displayed, error
message processing for the ASSERT command is simplified. In particular,
the extra code that merged the assertion into the error message is no
longer required.
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.
156. PROBLEM: Breakpoint actions aren't executed properly if the breakpoint
occurs in a DO file.
VERSION: 3.7-0
OBSERVATION: Breakpoint actions are not reliably executed if they appear
in a DO file. Given this "t.sim" command file:
break 100; e 0-1
go
break 200; e 2-3
go
e 4-5
...then entering "do t.sim" at the command prompt produces this output:
Breakpoint, P: 00100 (NOP)
Breakpoint, P: 00200 (NOP)
4: 000000
5: 000000
sim> e 2-3
2: 000000
3: 000000
Note that the "e 0-1" is not executed at all, and the "e 2-3" is executed
after the "e 4-5".
CAUSE: Breakpoint actions are executed by a call to "sim_brk_getact" in
the main execution loop. The call is missing from the execution loop in
"do_cmd".
In the test case, the "e 2-3" is being executed by the "sim_brk_getact" in
the main execution loop after command file execution terminates. This
out-of-sequence execution could have serious consequences, e.g. if the
command were intended to clear a log file prior to a debug run ("! del
big.log") but instead deleted it at the end of the run when the DO file
terminated.
RESOLUTION: Modify "do_cmd" (scp.c) to incorporate a call to
"sim_brk_getact" to process breakpoint commands as they occur.
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.
167. ENHANCEMENT: NOBR with no argument clears breakpoint at the current PC.
VERSION: 3.7-0
OBSERVATION: Breakpoints are often required only once, e.g., when
establishing which of several paths through a routine is taken. In this
case, when a breakpoint is reached, it is immediately removed.
The existing breakpoint clear syntax requires specification of the address.
It would be helpful if the address defaulted to the current PC, i.e., the
location of the breakpoint just hit.
RESOLUTION: Modify "ssh_break" (scp.c) to allow omission of the address
argument and, if omitted, to clear the breakpoint corresponding to the
current PC.
STATUS: Fixed in version 3.8-0.
168. ENHANCEMENT: The SHOW VERSION command now reports the patch level.
VERSION: 3.3-2
OBSERVATION: Having multiple patched versions of SIMH that report the
same version number leads to confusion. But official releases often
increment the minor version only.
RESOLUTION: Modify "show_version" (scp.c) and "sim_rev.h" to add a
reported "patch delta" version number.
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.
176. PROBLEM: The DEPOSIT <dev> <reg> <value> command will change <reg> in some
other device if the name is unique to that other device.
VERSION: 3.7-3
OBSERVATION: Entering "deposit ptr ppos 0" actually changes the "ppos"
register in the "tty" device. It should give an error that "ppos" does not
exist in the "ptr" device.
CAUSE: The "exdep_cmd" routine is calling "find_reg_glob" if the
"find_reg" routine returns a not-found error for the selected device.
"find_reg_glob" searches for a unique name among all devices and returns it
if found.
RESOLUTION: Modify "exdep_cmd" (scp.c) to search for a global register
name only if the device was not explicitly specified.
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.
178. PROBLEM: The free HP 700/92 terminal emulator, QCTERM from AICS, does not
work with SIMH.
VERSION: 3.7-0
OBSERVATION: Attempting to run QCTERM as a Telnet client with SIMH loses
characters. Specifically, the first character typed after a CR is lost.
CAUSE: QCTERM is sending "bare" carriage-return characters to SIMH. SIMH
presumes that CR will always be followed by LF or NUL in text mode, so it
simply drops the next character. For QCTERM, this is the first character
of the subsequent transmission.
Examination of the Telnet connection initiation code shows that SIMH is
sending several command sequences but is not checking the client replies
(except for binary mode). A correct negotiation mechanism must be
implemented to handle the variety of Telnet clients properly.
RESOLUTION: Modify the TNS_SKIP case in "tmxr_poll_rx" (sim_txmxr.c) to
skip only LF or NUL following CR. Any other character is processed as is.
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.
187. ENHANCEMENT: Report the device and line number for Telnet connections.
VERSION: 3.8-0
OBSERVATION: When connecting a Telnet client to a simulator device via the
multiplexer library, the client receives a "welcome" message of the format:
Connected to the HP2100 simulator
It would be helpful if the user knew to which device and line the client
had connected. For example:
Connected to the HP2100 simulator MUX device, line 3
The report for single-line devices, e.g., additional terminal devices,
would suppress the line number:
Connected to the HP2100 simulator BACI device
RESOLUTION: Modify sim_tmxr.h to add a "DEVICE *dptr" field at the end of
the TMXR structure. Change tmxr_attach() to look up the device from the
unit via find_dev_from_unit() and set "dptr" to point at the device.
Change tmxr_poll_conn() to print the device name and line number (if more
than one line defined) in the greeting message.
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.
189. ENHANCEMENT: Add a mechanism to provide a device-specified connection
order for terminal multiplexers.
VERSION: 3.8-0
OBSERVATION: Some operating systems allow per-line device drivers for
multiplexers (e.g., the HP 12792 and 12920 under RTE). These change the
line behavior, so that the existing model of multiplexers as pools of
identical lines is no longer valid. A method of specifying line connection
order is needed, so that connection to specific device drivers is possible.
RESOLUTION: Modify the TMXR structure (sim_tmxr.h) to add an "int32
*lnorder" field that points at an array specifying the line connection
order. Modify "tmxr_poll_conn" (sim_tmxr.c) to connect in the order given
by *lnorder, if defined, else to connect in ascending port number order.
Add "tmxr_set_lnorder" and "tmxr_show_lnorder" routines to provide support
for SET <dev> LINEORDER=<range> and SHOW <dev> LINEORDER commands.
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.
192. PROBLEM: Escaping backslashes in DO commands does not work.
VERSION: 3.8-0
OBSERVATION: The SIMH User's Guide says in Section 3.13, "Executing
Command Files:"
The string %n is recognized as meaning argument n from the DO command
line. The character \ has the usual UNIX meaning of an escape character;
the next character is interpreted literally, even if it is % or \.
The sequence "\%" is recognized as a literal "%" character. The sequence
"\\" is not recognized as a literal "\" character; instead, it is left
unaltered. In fact, "\%" is the only recognized escape; "\" followed by
any other character will not be processed, i.e., the "\" and that character
will remain. This makes using parameters in Windows file paths
impossible, as this:
attach dev c:\path\to\\%1
substitutes for "%1" but leaves the double-backslashes, and this:
attach dev c:\path\to\%1
...does not substitute for "%1" and parses as "c:\path\to%1".
Actually, the documented behavior (escaping every character) is
undesirable, as it will invalidate every current command file that uses
Windows path names. Were it implemented as documented, then a path such as
"c:\path\to\file" would be parsed as "c:pathtofile". Even restricting the
change to escaping just "\" and "%" will still invalidate current command
files that use network paths (e.g., "\\server\\share\\path\to\file" will
become "\server\share\path\to\file", which is a local path. This at least
is fixable, whereas there is no workaround for the current situation.
CAUSE: The argument substituter is checking only for the "\%" case.
RESOLUTION: Modify "sub_args" (scp.c) to accept "\\" as a literal
backslash, in addition to "\%" as a literal percent sign.
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.
194. PROBLEM: Omitted parameters to DO command files do not substitute null
strings for the corresponding arguments.
VERSION: 3.8-0
OBSERVATION: Given a command file "cmdfile" containing "echo %1 and %2",
the command "do cmdfile a b" results in:
a and b
...which is as expected. However, "do cmdfile a" results in:
a and %2
...which is unexpected; the expected response is:
a and
...i.e., the null string is substituted for "%2". This would be consistent
with argument substitution in operating system command shells.
CAUSE: Arguments for omitted parameters are not being considered for
substitution.
RESOLUTION: Modify "do_cmd" (scp.c) to initialize omitted arguments to
NULL and modify "sub_args" to skip null arguments during substitution.
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.
208. PROBLEM: Exiting the simulator does not report "Disconnected from the HP
2100 simulator" on MUX sessions.
VERSION: 3.8-0
OBSERVATION: Exiting the simulator detaches all devices. Detaching
multiplexer-type devices, such as BACI and MPX, reports "Disconnected from
the <sss> simulator" on each connected Telnet session. However, no such
report appears on MUX sessions. Doing a DETACH ALL does report the
disconnection on MUX sessions.
CAUSE: As part of simulator shutdown, "detach_all" is called with the
"shutdown" parameter set to TRUE. This causes the detach routines for
non-attachable units to be called. "ds_detach" calls "detach_unit", which
returns SCPE_NOATT for unit 8 (the controller unit). "detach_all" exits on
a non-zero status return from a device detach routine, so the devices after
DS in the device array are never detached.
Doing a DETACH ALL calls "detach_all" with the "shutdown" parameter set to
FALSE. This calls device detach routines only for attached units. All of
these return SCPE_OK, so MUX is eventually detached, and the disconnection
reports are sent to the MUX sessions.
Note that the same problem would arise if an attached unit fails to detach
cleanly, e.g., due to a file write error. The remaining devices would not
be detached before simulator exit.
RESOLUTION: Modify "detach_all" (scp.c) to ignore errors from device
detach routines during shutdown, so that all devices will be detached.
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.
213. PROBLEM: A DO command without a filename prints the wrong error message.
VERSION: 3.8-1
OBSERVATION: The DO command requires a file argument and zero or more
parameter arguments. Entering DO without the file argument should print
"Too few arguments," as other commands that require arguments do (e.g.,
ATTACH, BOOT, etc.). Instead, it prints "File open error."
CAUSE: A test in "do_cmd" attempts to detect when no arguments are passed
and return SCPE_2FARG in response, but the test always fails. As a result,
"fopen" is called with a NULL filename parameter. The call fails,
resulting in the "File open error" message.
The test follows the initialization of the "do_arg" array and depends on
initialization stopping when a null argument is encountered. The bug fix
of 25-Jul-2008 ("DO cmd missing params now default to null string")
modified "do_arg" initialization to cover the entire array. Therefore, the
test to determine if "do_arg" was not initialized (which implies that the
file argument was not passed) never trips.
RESOLUTION: Modify "do_arg" (scp.c) to test "do_arg[0]" for NULL and to
return SCPE_2FARG if so.
STATUS: Fixed in version 3.9-0.
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.
232. PROBLEM: SHOW <dev> doesn't show the unit number when all but one unit are
disabled.
VERSION: 3.8-1
OBSERVATION: For multi-unit devices, the SHOW <dev> command prints device
information on the first line and then prints each unit's information on
succeeding lines. For single-unit devices, the device and unit information
are combined on one line, as the device name is allowed as a synonym for
unit 0. However, if a multi-unit device has all but one unit disabled, the
SHOW <dev> command reports the remaining unit as though the device had only
one unit, implying that the enabled unit is unit 0.
For example, HP device DQC has two units. Attaching a file to unit 1 and
disabling unit 0 produces this output for the SHOW DQC command:
DQC, devno=24/25, 11MW, attached to file.tmp, heads loaded, write enabled
There is no indication that the file is attached to unit 1, and indeed if
the attachment and disabled units are reversed, the command output is the
same as above.
CAUSE: Routine "show_device" (scp.c) combines the device and unit display
when a device has only one enabled unit. This is intended to hide the
implementation detail of single-unit devices, e.g., paper tape readers,
while allowing additional permanently-disabled units to be used by the
device for scheduling. However, it should not combine the device and units
when user-disabled units exist.
RESOLUTION: Modify "show_device" (scp.c) to count units that have been
disabled by the user instead of units that may be disabled by the user, and
to report the unit number if user-disabled units are present. Also change
the count of reported units from the number of enabled units to the sum of
the enabled and user-disabled units.
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 indicted
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.
251. PROBLEM: Constants required for exdep_cmd and brk_cmd aren't in scp.h.
VERSION: 3.9-0
OBSERVATION: The scp.h header file exports the exdep_cmd and brk_cmd
functions, but the constants that must be passed in the "flag" parameters
for proper operation are not present. The run_cmd function also requires
constants for the "flag" parameter, but these are present.
CAUSE: Oversight.
RESOLUTION: Move the EX_D, EX_E, EX_I, SSH_ST, SSH_CL, and SSH_SH
constants from scp.c to scp.h.
STATUS: Fixed in version 4.0-0.
252. PROBLEM: Stop calls VM-provided address printer for PC without REG_VMAD.
VERSION: 3.9-0
OBSERVATION: For a simulator stop, sim_vm_fprint_addr (if defined) is
called to print the value of the program counter, regardless of whether or
not the register was defined with REG_VMAD. However, displaying the PC
value with "examine" calls sim_vm_fprint_addr only if the REG_VMAD flag is
present. The displayed value of the PC should be the same in both cases.
CAUSE: The call to sim_vm_fprint_addr in fprint_stopped_gen is not
conditional on the PC register having the REG_VMAD flag.
RESOLUTION: Modify "fprint_stopped_gen" (scp.c) to require REG_VMAD before
calling the VM-specific address printer for the program counter value.
STATUS: Fixed in version 4.0-0.
253. PROBLEM: Cannot show radix, etc. for a device that has no modifiers.
VERSION: 3.9-0
OBSERVATION: The default data radix for a device may be set with the SET
<dev> OCT|DEC|HEX command. However, if the device does not have a modifier
table, SHOW <dev> RADIX is rejected with "No settable parameters".
The same problem occurs for SHOW <dev> DEBUG and SHOW <dev> NAMES. For a
device that provides debug printouts, SHOW <dev> MOD will list "DEBUG,
NODEBUG" among the modifiers, and the SHOW <dev> DEBUG command will display
the current debug status. However, if the device does not contain a
modifier table, SHOW <dev> MOD and SHOW <dev> DEBUG will report "No
settable parameters", even though SET <dev> DEBUG is accepted and works as
expected. For such a device, SHOW MOD will show "DEBUG, NODEBUG" as
acceptable modifiers.
CAUSE: The "show_cmd_fi" routine checks for a modifier table and returns
an error without checking for global actions.
RESOLUTION: Modify "show_cmd_fi" (scp.c) to continue to process global
actions if the modifier table is not defined.
STATUS: Fixed in version 4.0-0.
254. PROBLEM: SET and SHOW responses for invalid entry are inconsistent.
VERSION: 3.9-0
OBSERVATION: Entering SET <dev> <mod> where <mod> is not defined in the
device's modifier table displays "Non-existent parameter." Entering SHOW
with the same parameters displays "Invalid argument."
Similarly, entering SET <dev> DEBUG for a device that does not have
debugging capability displays "Command not allowed." Entering SHOW with
the same parameters displays nothing.
In both cases, the messages displayed should be the same for the same
error.
CAUSE: Oversight.
RESOLUTION: Modify "show_cmd_fi" (scp.c) to return the same status codes
as "set_cmd" does.
STATUS: Fixed in version 4.0-0.
255. ENHANCEMENT: Add a "-N" (new file) option to the SET CONSOLE LOG and SET
CONSOLE DEBUG commands.
VERSION: 3.9-0
OBSERVATION: These commands normally append to their respective log files.
If the user wants to recreate the log file instead, it must be deleted
first with OS-specific commands. Adding a "-N" option to perform the
delete removes commands dependent on a specific OS.
RESOLUTION: Modify "sim_set_logon" and "sim_set_debon" (sim_console.c) to
check for a "-N" option and to open for writing instead of appending if
detected.
STATUS: Fixed in version 4.0-0.
256. ENHANCEMENT: Add tape runaway support to the simulator tape library.
VERSION: 3.9-0
OBSERVATION: The ANSI specifications for NRZI, PE, and GCR tape recording
mandate a maximum length of 25 feet for erase gaps. Currently, an erase
gap of any length is ignored when reading or spacing. To allow detection
of non-compliant tape images, the simulator tape library is enhanced to
halt positioning and return tape runaway status if a gap of 25 feet or more
is encountered.
Runaway detection is enabled by calling the tape library to set the tape
density in bits per inch. If this call is not made, erase gaps present in
a tape image are effectively ignored. Also, with the addition of a
separate "set density" call, it is no longer necessary to supply the
density when writing erase gaps.
RESOLUTION: Modify "sim_tape_rdlntf" and "sim_tape_rdlntr" (sim_tape.c) to
detect tape runaway, and add a new MTSE_RUNAWAY status to sim_tape.h. Add
new "sim_tape_set_dens" and "sim_tape_show_dens" functions to set and show
the bits per inch for a unit, respectively, and eliminate the "bpi"
parameter to "sim_tape_wrgap" in preference to using the density
established by a previous "sim_tape_set_dens" call. Add named constants
to "sim_tape.h" that specify the density.
STATUS: Fixed in version 4.0-0.
257. ENHANCEMENT: Improve performance when reading or spacing over erase gaps.
VERSION: 3.9-0
OBSERVATION: Performance when reading or spacing over erase gaps is poor,
especially in the reverse direction. Currently, each 4-byte gap marker is
read individually, and in the reverse direction, each read is preceded by a
seek to move the file pointer backward. This combination causes stream
cache invalidation and a physical disc access for each gap marker. As a
single gap consists of over 1000 markers, performance is far worse than if
a gap was read as a block.
RESOLUTION: Modify "sim_tape_rdlntf" and "sim_tape_rdlntr" (sim_tape.c) to
buffer reads of gap markers. Using a 128-element buffer, performance
improves about thirty-fold.
STATUS: Fixed in version 4.0-0.
258. PROBLEM: Writing an end-of-medium positions the tape image after the mark.
VERSION: 3.9-0
OBSERVATION: The "sim_tape_wreom" simulator tape library function writes
an end-of-medium marker on the tape image. The intent is to erase the
remainder of the tape. The "SIMH Magtape Representation and Handling"
document states that the tape position is not updated by this function.
However, the function leaves the tape positioned after the marker.
A subsequent read would stop at the EOM marker. However, writing a new
marker over that one would then allow reading of the data following the EOM
that supposedly had been erased by the original "sim_tape_wreom" call.
CAUSE: The tape position is updated by the internal "sim_tape_wrdata" call
that is used to write the EOM marker, but it is not reset afterward by the
function.
RESOLUTION: Modify "sim_tape_wreom" (sim_tape.c) to reset the tape
position to point at the EOM marker before returning. This prevents
reading past an EOM marker, and a subsequent write will overwrite the
marker rather than embed it between data records.
STATUS: Fixed in version 4.0-0.
259. PROBLEM: Reading through an erase gap in reverse may return EOM status.
VERSION: 3.9-0
OBSERVATION: A reverse read or spacing operation through an erase gap may
return end-of-medium status. Reading or spacing forward through the same
gap works properly.
CAUSE: Writing an erase gap over existing records may produce a gap that
is longer than requested. This occurs when truncating the last record to
be overlaid by the gap would leave a record that is shorter than the
minimum size allowed (eight bytes for the length words plus two bytes for
the data). In this case, the gap is lengthened to overlay the entire
record. If the new gap size is not evenly divisible by four, a half-gap is
metadata marker of value 0xFFFF added to the beginning of the gap.
If a gap that begins with a half-gap marker is written immediately after
a previous gap, the "seam" between gaps will contain the bytes FE FF FF FF
( FF FF ) FE FF FF FF.... Reading forward across this seam will yield a
metadata value of 0xFFFEFFFF, which is recognized and handled by seeking
two bytes back to resynchronize reading. However, reading in reverse will
yield the value 0xFFFFFFFF, which is interpreted as end-of-medium.
RESOLUTION: Modify "sim_tape_rdlntr" (sim_tape.c) to recognize 0xFFFFFFFF
as a half-gap marker and resynchronize in response. End of medium cannot
occur when reading in reverse, as it is impossible to position the tape
image beyond an EOM marker. Therefore, any 0xFFFFFFFF value encountered
must be a half-gap "seam" originating as above.
STATUS: Fixed in version 4.0-0.
260. PROBLEM: sim_tape_wrgap fails when format is changed from SIMH format.
VERSION: 3.9-0
OBSERVATION: The HP 2100 magnetic tape simulator supports erase gaps and
calls sim_tape_wrgap when commanded to write a gap. However, if a tape
format other than SIMH format is selected, the call fails with MTSE_FMT.
CAUSE: Erase gaps are not supported in formats other than SIMH, but the
call should not fail. Instead, the call should be a "no-operation" if the
underlying format does not support gaps.
RESOLUTION: Modify "sim_tape_wrgap" (sim_tape.c) to return MTSE_OK with no
action performed if a tape format other than SIMH is selected.
STATUS: Fixed in version 4.0-0.
261. PROBLEM: The magnetic tape format of an attached unit may be changed.
VERSION: 3.9-0
OBSERVATION: The magnetic tape library supports several tape image
formats. The format to use may be specified either by an "ATTACH -F"
command or by a "SET <unit> FORMAT" command. The latter calls the
"sim_tape_set_fmt" function, which allows the format of a file currently
attached to be changed. However, the format is an intrinsic property of
the tape image file, so changing it once the file has been attached makes
no sense.
CAUSE: Oversight.
RESOLUTION: Modify "sim_tape_set_fmt" (sim_tape.c) to return an error
(SCPE_ALATT, "Unit already attached") if the unit is attached.
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.
263. ENHANCEMENT: Allow the VM to print simulator stop message information in
lieu of, or in addition to, the default message.
VERSION: 3.9-0
OBSERVATION: The current implementation of "run_cmd" in scp.c calls
"fprint_stopped_gen" (via "fprint_stopped") to print the message associated
with the "sim_instr" return status. Messages associated with VM stops must
be provided to the SCP via the "sim_stop_messages" array.
"fprint_stopped_gen" prints the status message in a rigid format: the
message string, a comma, the program counter register name, a colon, the
current PC value, and the instruction at that address in symbolic format.
For example:
HALT instruction, P: 24713 (LDA 1)
Only the message string is under the control of the VM. If additional
information is needed, it can only be added before the first comma.
The HP2100 simulator does this for halt instructions, which contain device
select code and flag hold/clear bit fields that, in practice, are used to
communicate to the operator the significance of the particular halt
encountered, rather than to affect the device interface:
HALT instruction 102077, P: 24713 (LDA 1)
To implement this, the simulator must define the message as a variable and
then copy the formatted octal value into the buffer at the appropriate
location before returning from "sim_instr".
However, if the VM wants to display a different register value, e.g.:
Self test #13 complete, STAT: 000020
...this cannot be done without also displaying the program counter, which
may be irrelevant for the given stop condition.
RESOLUTION: Modify "fprint_stopped_gen" (scp.c) to check a VM-specific
simulation stop printer pointer ("sim_vm_fprint_stopped") that is
initialized to NULL and can be overridden by the VM, and, if overridden,
call it after printing the message string and before printing the program
counter. If the VM printer returns TRUE, print the comma and the program
counter as before. If the VM routine returns FALSE, print just the
terminating newline.
STATUS: Fixed in version 4.0-0.
264. ENHANCEMENT: Indicate that "examine" is being called for a simulator stop.
VERSION: 3.9-0
OBSERVATION: As part of the simulator stop message, the fprint_stopped_gen
routine prints the instruction pointed to by the program counter. In
addition to the "M" (mnemonic) switch, it passes the SIM_SW_STOP flag to
the fprint_sym routine to indicate that it is being called for a simulator
stop. This allows the VM-defined routine to take any action specifically
appropriate to the stop.
To get the instruction value, fprint_stopped_gen calls the CPU's "examine"
routine and passes the program counter value as the address. However,
interpretation of addresses may differ, depending on context. For example,
a given address may be relative to a code, data, or stack space pointer.
To attempt to address this, the "examine" call includes the "V" (virtual)
switch. However, "virtual" (and the associated "-v" command line switch)
may have a different meaning assigned by a given VM. What is needed is an
unequivocal indication that a machine instruction value is being retrieved.
RESOLUTION: Modify "fprint_stopped_gen" (scp.c) to pass SIM_SW_STOP to
"examine" as well as "fprint_sym", so that these routines have unambiguous
indications that they are being called in the context of a simulator stop.
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.
268. ENHANCEMENT: Provide "fprint_sym" and "parse_sym" with register-specific
information when a register is being examined or deposited.
VERSION: 3.9-0
OBSERVATION: When EXAMINE or DEPOSIT specifies a register that has the
REG_VMIO flag, "fprint_sym" or "parse_sym", respectively, is called in lieu
of "fprint_val" or "get_uint". This allows VM-specific interpretations,
such as symbolic display of a status or current instruction register value,
by specifying a switch with the command:
sim> examine STAT-CIR
STAT: 060001
CIR: 030020
sim> examine -s STAT
STAT: mITroc CCG 001
sim> examine -m CIR
CIR: PAUS 0
The REG definition contains a radix field that allows a register to have a
default radix that is different than that of the device. This is
particularly helpful in connection with the EXAMINE STATE command, as
different registers may have different preferred radices:
sim> examine state
P: 012077 (defaults to octal)
CNTR: 9 (defaults to decimal)
MASK: FFF0 (defaults to hex)
However, there is no way to specify that the preferred display or input is
symbolic. So a CPU state that contains such registers would have to be
displayed multiple times -- once to get most of the values in their default
forms, and again to display those registers whose preferred form is
symbolic:
sim> examine state
PB: 000100
P: 012077
PL: 023000
STAT: 060001
CIR: 030020
sim> examine -s STAT
STAT: mITroc CCG 001
sim> examine -m CIR
CIR: PAUS 0
It would be useful if a default symbolic interpretation could be specified
in the REG structure and passed to "fprint_sym" and "parse_sym" to be used
in the absence of overriding command-line switches. Currently, no
information is provided to these routines to indicate which register is
being manipulated, so there is no way to provide register-specific default
interpretations within the routines.
RESOLUTION: Reserve space for register-specific flags in the "flags" field
of the REG structure (sim_defs.h) starting at REG_V_UF. Modify "ex_reg"
and "dep_reg" (scp.c) to merge the register-specific flags into the radix
value passed as the "addr" parameter to "fprint_sym" and "parse_sym".
A VM that defines register-specific flags will know to separate them from
the passed radix value by the presence of the SIM_SW_REG value in the
"switch" parameter. VMs that do not define register-specific flags are not
affected by this change.
STATUS: Fixed in version 4.0-0.
269. PROBLEM: Tape read reports "end of medium" even if a gap precedes it.
VERSION: 4.0-0
OBSERVATION: Calling "sim_tape_rdrecf" to read a tape record sometimes
returns MTSE_EOM and sets the "position not updated" (PNU) flag, even when
an erase gap precedes the EOM. The correct response should be to return
MTSE_RUNAWAY to indicate that spacing over a gap did not end with a data
record or tape mark. Moreover, PNU should not be set, as the position has
been updated.
CAUSE: The routine attempts to handle this case by returning MTSE_RUNAWAY
if the EOF was detected while reading a buffer of gap markers. However, if
a buffer read ends immediately before an EOM marker or the physical EOF,
the next read attempt will return a zero buffer length. The routine
misinterprets this to mean that no gap was present and returns MTSE_EOM and
sets the PNU flag.
RESOLUTION: Modify "sim_tape_rdlntf" (sim_tape.c) to determine whether the
EOM marker or physical EOF was seen on the first or a subsequent buffer
read, and to return MTSE_EOM with PNU or MTSE_RUNAWAY without PNU,
respectively.
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. Alter
"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.