Problem: Currently when viewing the Nova CPU history the carry flag is always
displayed as 0 regardless of it's actual value at the time.
Cause: The carry bit is stored in bit 17 and is lost when stored into the
int16 carry member of struct Hist_entry
Solution: Shift carry into bit 0 before storing it in the CPU history.
Improve code for displaying carry bit.
Originally, the VAX allowed immediate operands (8F) to be used without
restrictions in address mode instructions, either standalone or indexed.
Starting with MicroVAX II, immediate indexed became reserved. This
remained true for all subsequent chip implementations. The SRM was
ECOed in March, 1985 to make immediate indexed unpredictable.
In MicroVAX II, immediate g-floating operands didn't work correctly. The
problem was found a couple of months after tape-out. While the index
flows could be fixed, and were fixed according to the microcode revision
history:
; 7-May-84 [RMS] Fixed FD problem in index flows (JLR)
the problem in indexed immediate could only be fixed by a significant
hardware change in an area that was already packed full. The VAX
Architecture Team, which had always been very sympathetic to the
VAX chip efforts, proposed a much simpler solution: make immediate
indexed unpredictable. It was useless, in any case.
I'm rather surprised that this wasn't flagged by the 780 diagnostics.
Maybe it was never tested. It was tested in HCORE (the original MicroVAX I
core diagnostic that is failing), but I removed it subsequently:
; 8-may-85 rms removed indexed immediate tests
Bottom line - the simulator is right for the chip VAXes (including, I think,
V11) and wrong for MicroVAX I and probably the 8600, 780, 750, and 730.
As originally specified, both MTPR and MFPR set N,Z based on the
transmitted/received longword data, cleared V, and left C untouched. The
simulator hardwired this (except for the standardized TBCHK register)
based on the CVAX microcode.
In the 8200, accessing the RXCD register sets V for character
sent/received. (The VAX vector MxPRs also return non-standard values
for the condition codes.) This is one of the reasons that, in 1986, the
VAX architecture spec was changed to make the condition codes
UNPREDICTABLE following MTPR or MFPR.
Accordingly, I've added a "hook" to support the 8200 and other
non-standard MxPRs: global variable mxpr_cc_vc.
At the start of MTPR or MFPR (only), this variable is set to
000<current C bit>. MTPR will set N and Z based on the transmitted
operand and clear V and C. MFPR will set N and Z based on the received
data and clear V and C. Then, at the end, mxpr_cc_vc, masked down to
V & C, is ORed into the condition codes.
Thus, if an IPR write or read does nothing special, MTPR and MFPR will
get the canonical results. N,Z set, V cleared, C preserved. However, an
IPR routine can now specify a non-standard value for V and/or C by
modifying mxpr_cc_vc.
This tweak required changes only in vax_cpu.c. None of the model-
specific IPR routines need to be changed, except for Matt's 8200 RXCD
code. Anyone attempting implementation of further models (or VAX
vectors) should be aware of this new capability.
3.10 is mostly an attempt to get aligned with the current head of the
GitHub 4.0 sources. While the core libraries and SCP have diverged too
far for real forward and backward compatibility, enough 4.0 workalikes
have been added to allow much closer convergence of the two streams.
3.10 will provide the basis for my future simulation work.
