- Kermit/telnet negotiations work now: fd var was not being set, so
write() was not actually working
- with many controllers, Primos would halt with tumble table overflow:
you can't do read processing until lines are enabled
- only look for new connections when handling the clock line
controller; there is no sense doing this more than 10x per second, and
it probably should still have a timer in case polls are being sped up
- use buf[] for tty message, not another static buf
- when a new connection occurs, set devpoll for the controller. The
first connection to a controller was taking 5 seconds when more than 1
controller was present
- when status is read and an eor occurred, do read processing again
rather than waiting for the next poll
- divide tumble table space up by # of connected lines. The old way
read MAXREAD (64) chars from each line until the tumble table was
full. But with 8 AMLC boards configured, there is only 53 words of TT
space in each double buffer. A select() on connected fd's would be
better.
- allow # as first character of amlc.cfg for comment lines
- turn on TCP/IP NODELAY (disable Nagle) to improve character echo
for serial device servers connected to a serial printer for example,
where the SDS initiates the telnet connect to the Prime when the
printer is turned on.
This happens for example if a node is configured with a 1024-word
packet size and sends to a node with a 256-word packet size. In the
emulator PNC design, the packet has already been ACK'd at the sending
side, so there is no way to indicate a transmission error other than
taking down the connection. Since the error will just occur again,
the best course is to disable the node until the next reboot.
Primenet will disconnect the sending and receive nodes from each other
in about 30 seconds.
Also removed pnchexuid: useful in the beginning, not so much now.
1. Need 32-bit integer for dma address so newer Primos can use I/O
segments other than 0.
2. Ignore interrupted select()
3. Set fd to -1 after closing when not connected, to avoid bad
file descriptor error
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.
