[pdp7-unix] Testing ttt, and also p

Phil Budne phil at ultimate.com
Mon Oct 28 03:14:22 AEST 2019


> Neither game do well with input; i.e. I randomly tried some things and
> not much happened.  I added simulation code for the light pen and push
> buttons, but it seems some of my guesses were wrong.

> I'm not sure if the push buttons should raise an interrupt, and if
> so for what kind of events.

I think they do, but I can't tell you on what conditions.

at src/sys/s7.s line 259, in the PI service code:

checks the push button flag with spb, then clears it (if set) with
cpb.  For most devices "flag" means a PI request flag.

It then does an lpb to get a mask of buttons pushed,
and saves that at pbsflgs+1

AND on every 60Hz "tick" interrupt, the lpb value is saved at pbsflgs.

> Clearly both dttt and p read the push buttons from sysloc 13.

sysloc 13 returns the address of the pair of words at pbsflgs (see above)

The pool program (p) only ever looks at pbsflgs (via "lac .pb i")

But psych.s looks at both pbsflgs (via .pbp) and pbsflgs+1 (via .pbp1)
and zeroes pbsflgs+1 as well!

dttt only looks at pbsflgs (the value polled at 60Hz).

Seems like dttt exits (in getpb) if a certain button is pushed.

getpb does a "sys time", and then crushes AC, but MQ will still be
loaded with the low order bits of (60Hz) time (I haven't spotted
where/if that's used).  It may not be used: the system is
non-preemptive-- you can only be swapped out when you make a system
call.. Since getpb (see below) is called in tight loops, this may be
to ensure that dttt doesn't lock out other processes.

At src/cmd/ttt1.s line 56 there is a loop waiting for getpb to return
zero, then another waiting for it to return non-zero.

And a similar pair of loops at line 262.

At dspmove there's a check for getpb returning zero.

P.S.
There are a couple of state machines in the display code I've never
figured out, one with .dsptm, and another with .dspb.

In the PI service, location .dsptm is incremented on every tick, and
it branches to dsprestart when it reaches zero (and .dsptm gets reset
to -10, and .dspb is reset to 1), otherwise .dspb is incremented, and
if IT reaches zero, then it ALSO branches to dsprestart.

movdsp (called when a process is swapped in) sets .dspb to -1, which
means dspinit will be reached on the next tick.  When a process is
swapped out (quantum expired, or I/O wait) the default display list is
used-- I wonder if this is/was noticeable if someone was using the
console?  The scheduling quantum is 30 ticks: if the program on the
console didn't block for I/O, the display could switch back to the
"glass TTY" for half a second at a time.

P.P.S.
ANY of the display related system code might have remaining
"misinterpretations"!


More information about the pdp7-unix mailing list