work okay and not have the 30-second delay problem.
Over netlink, a prirun, l, displays a couple of medium-sized packets,
then '55' from PR0055 in a tiny packet, then one more reasonable-size
packet. The tiny packet seems odd, but I'm guessing it's a window
size or buffer size thing inside Primos / Primenet.
interrupts are enabled. This fixes the 30-second lag problem, but
also causes PNCDIM to get notified too many times. After an xmit,
devpnc causes an immediate interrupt. This is handled by the SEG4
phantom interrupt code by disabling PNC interrupts, then notifying
PNCDIM. (Remember, PNCDIM is still in the xmit OTA, or shortly
following). PNCDIM finishes its loop, enables interrupts, and does a
WAIT. When it enables interrupts before the WAIT, devpnc doesn't
remember that it has already interrupted, and interrupts again. I
think this is a bug - the other emulator controllers have a state
variable to remember whether they have already interrupted. But,
if I fix this "bug", we'll probably have 30-second delays again.
Hmmm...
problem with remote terminal sessions:
1. netlink to remote Prime
2. a prirun
3. l (list directory)
4. displays a little, then a longish pause up to 30 seconds, then the rest
Does a similar thing with stat us. Hitting Enter will cause it to
finish, while typing characters does not. I suspect this is a problem
with Prime's networking code, but not sure.
Also, if async I/O is used, the QUIT. OK, message doesn't appear after
ctrl-p. I think they are getting wiped out by Primenet's buffer
flushes.
All of this might be subtle timing problems because I changed the
default clock rate from 250/330/500/whatever times per sec to 20 times
per second in this rev 19 version of Primos.
this case, bitno was specified in the EAFA instruction itself. The
emulator was setting the E-bit in the returned ea because there was a
non-zero bit offset. This extra test of bitno & setting of E-bit was
removed from apea to pass CPUT4 at 10001.
Issues like this, might be why DIAG was developed to surpass T&M: many
of these CPUT4 tests are testing the implementation of an instruction
rather than just the architectural feature of the instruction.
at 7753 and 10061. At 7753, CPUT4 loads -1L into the SB register,
EAFA 1,SB%, then LDLR '12 to get the FAR1 register value. It expects
it to be -1. For the test at 10061, EAFA was clearing the E-bit in
FAR1, but the test expected it to be set. The emulator never uses the
E-bit in the FAR (it only looks at bitno), so it doesn't matter how the
E-bit is set in the register.
emulator seg fault after LPSW near label RXM in CPUT4.
CPUT4 activates Ring 3 by loading the ring bits of the program
counter. However, it does not enable segmentation, so we're still
accessing memory by physical location - no address mapping occurs.
mapva used the entire 32-bit program counter as an offset in the MEM
array (physical memory), and because of the ring bits, this caused a
Unix seg fault.
mapva was changed to only use 28 bits of the address when VA mapping
is disabled (28 bits matches the size of the MEM array). Technically,
a more accurate mask should be applied based on the CPU model. For
example, a P750 could only access 8MB of memory.
This is an unsigned int, so will overflow after 4B instructions, but
it's impractical to trace that many instructions anyway. This feature
is used for debugging the emulator, getting diags to work, etc., so
instruction counts tend to be low.
NOTE: ea would only be set for mem. ref. instructions, but we use the
same code at label d_uii: for generics too. Not sure what the ea should
be for a generic UII fault where there is no ea computed.
don't load registers and keys from the runfile unless the 'regs'
option is used. Old T&M's were normally loaded into memory, followed
by a master clear, then run. The Prime runfiles on disk (at rev 18)
had the wrong mode in the key field of the rvec file header, so the
test did not execute properly. Also expanded the boot help for data
switches.
test how magrst behaves. It treats this just like a real tape error,
which is good. If mtwrite is used to re-create a physical tape from a
.tap file, it cannot re-create tape errors, so writes a 4-byte zero
record instead. Prime magrst will still see this as an error record
since it isn't long enough to be a real magsav record.