Main Menu

QProbe - Idle Patterns

Details
Written by: Administrator
Parent Category: Tools
Category: QProbe - a QBUS signal adapter

As you know, some DEC Operating Systems show a distinct pattern on the Blinkenlight panels, when the operating system is "idle".

"Idle" means: it is an multi-process OS, like RSX11M, RSTS, or some UNIX, and no process is running.
Typically the CPU is halted then on a WAIT instruction, and just some process scheduler is called on the periodical 50Hz/60Hz "Line Time CLock" interrupt.

This Process Scheduler then writes a regular pattern onto the DATA LEDs of these Lamp&Switch UNIBUS consoles, as PDP-11/40/45/70 have it.

The patterns are quite creative ... you see "snakes", "bouncing balls" or "pulsing bars".

BUT: they're not visible on any QBUS machine ... as these never have the Blinkenlights.

Until now!

QBUS idle patterns

By accident I learned, that a QProbe can show the idle pattern of the RSX11M operating system. WHOA!

See here (Time index 6:40)

Later tests should: also 2.11 BSD UNIX has the patterns.

This is a lucky coincidence of a few factors.

How RSX11M displays the idle pattern

Lets explore the phenomenon for RSX11M.

 Even if RSX11M was SYSGENed for a QBUS machine, the code to write the idle pattern is still active.
Normally the pattern is shown the 16 DATA LEDs of a Blinkenlight panel:

qprobe top big

Here is the code inside RSX11M for the pattern:

; RSX11M idle pattern loop
IDLE:   CACHE$ RESTOR      ;RESTORE CACHE TO NON-BYPASS
        MOV (R1)+,(R1)     ;RESTORE IDLE PATTERN
        DECB $IDLCT        ;TIME TO MOVE PATTERN?
        BGE 45$            ;IF GE NO
        MOVB #2,$IDLCT     ;RESET COUNT
        ASLB (R1)+         ;MOVE PATTERN ($IDLPT)
        RORB (R1)          ;($IDLPT+1)
        ADCB -(R1)         ;($IDLPT)
45$:    MOV (R1),R0        ;PUT IT WHERE IT CAN BE SEEN ($IDLPT)
        MOV R0,-(R1)       ;SAVE IT FOR NEXT TIME
        WAIT

It function blocks are:

  1. load a pointer to the 16bit pattern into register R1 : ("RESTORE IDLE PATTERN")
  2. use a prescaler to reduce 50/60Hz LTC clock to more convenient display frequency ("IDLCT")
  3. if update needed: calc the next pattern phase (wild ASLB/RORB/ADCB sequence working on the pattern-pointer with "(R1)" address mode)
  4. copy the pattern into R0 ("MOV (R1),R0 ; PUT IT WHERE IT CAN BE SEEN")
  5. save the current pattern back into a memory word for furhter use ("SAVE IT FOR NEXT TIME")
  6. WAIT halts the CPU until another interrupt occurs (by periodic LTC timer or device activity)
    The pattern gets visible, because  a side effect of WAIT is to show R0 in the DATA LEDs.
    And WAIT is long active, until the next interrupt.

Why QProbe shows the pattern

QProbe (and all QBUS-cycle monitors) fetches all read-DATI and write-DATO QBUS cycles and displays them.

Repeat: Normally, QProbe shows all QBUS traffic, meaning a wild mix of opcode fetches via DATI cycles as well as data accesses via DATI and DATO.
So the idle pattern DATOs are barely visible, as they are mixed with lots of other bus traffic.

Unless: you run a CPU which uses a memory cache. Then the short idle loop-code is executed totally from cache only and causes no QBUS memory DATIs. Only the DATOs of the idle patterns remain visible, as DATOs are written through the cache to QBUS memory.
So with cache, the last DATO before the long WAIT is what the naked eyes sees.
And that's the "MOV R0,-(R1) ;SAVE IT FOR NEXT TIME" ... writing of the pattern to memory.

Summary of Conditions

For the the idle pattern of an OS beeing visible on QProbe, these conditions must be fulfilled:

  1. The OS must use the R0/WAIT mechanisms to display the pattern.
  2. Even on QBUS platforms.
  3. And the last DATI/DATO before the WAIT must move the 16 bit pattern word from R0 to memory.
  4. The CPU uses cache
  5. QProbe shows DATO cycles for memory accesses, meaning the CPU is not using "Private Memory", but operates on QBUS memory.

Operqatiing Systems without idle loop pattern

Sadly, the popular RT11 and XXDP have no pattern display.

Idle Loop in 2.11BSD UNIX

The idle loop for 2.11BSD is found in source file sys/machine/mch_xx.s (on a running 2.11BSD with compilable kernel).

/*
 * idle()
 *
 * Sit and wait for something to happen ...
 */

/*
 * If you have a console display it's amusing to see a slowly rotating
 * sequence of lights in the display. If the system is very active the display
 * will appear blurred.
 */
INT(LOCAL, rdisply, 0377)              / idle pattern
INT(LOCAL, wcount, 2)                  / rotate rdisply every wcount calls
ENTRY(idle)
        mov PS,-(sp)                   / save current SPL, indicate that no
        mov $1,_noproc                 / process is running
        dec wcount                     / if (--wcount <= 0) {
        bgt 1f
        mov $2,wcount                  / wcount = 2
        clc / rdisply <<= 1
        rol rdisply
        bpl 1f                         / if (``one shifted out'')
        bis $1,rdisply                 / rdisply |= 1
1:                                     / }
        mov rdisply,r0                 / wait displays contents of r0
        SPLLOW                         / set SPL low so we can be interrupted
        wait                           / wait for something to happen
        mov (sp)+,PS                   / restore previous SPL
        rts pc                         / and return

The last DATO to memory before "wait" is "mov rdisply,r0 / wait displays contents of r0" ...
The following  "SPLLOW" could be a show stopper, but luckily affects the CPU internal PSW register, not memory.
So: fully entertainment on 2.11BSD too.

TODO: Idle Loop research

Further research is need for RSTS, and other UNIX variants.

CPU cache use

I know of no LSI11 or F11 CPUs with cache, only J11s like 11/73/83/93 do. Also the upgrade-CPU M8192.
The low-end 11/53 M7554 CPU has no cache!
If a CPU has no cache, the last QBUS activity before executing WAIT is the DATI-fetch of WAIT opcode itself. So you should see a constant "00001" on the display then ... boring.

Private Memory use

CPU accessible memory must reside on the same QBUS as the QProbe is plugged in.
This excludes high-end PDP11s with a separate memory bus, so-called PMI - "Private Memory Interconnect".
There memory is either on-board, like on the PDP-11/53, or connected to CPU via the "C/D slot interconnect", as provided on H9276, H9278 backplanes.
QProbe monitors only I/O activity on the QBUS then.

The most simple cases are 11/23 systems updated with the dual-width M8192 KDJ11-A CPU board. These system don't have PMI, and the M8192 has cache ... check!

You can disable the private memory in a 11/73/83/93, and add some QBUS memory (done automatically with a QBone emulation). Disabling PMI can be done by swapping the CPU into slot 1, above all memory cards. The system will run slower then, but you have the lightshow. Citing Mark Matlock (thanks, Mark!):

"With regard to M8190-AE or KDJ11-BF boards (11/83), if the PMI memory boards are above the CPU then the CPU uses the PMI bus to access memory and the RSX idle pattern is not visible on the QProbe. Move the CPU above the PMI memory and the CPU uses the Q22 bus to access memory and since the CPU has cache memory the instruction fetches that would disrupt the idle pattern don’t occur. The Q22 memory is only updated by writes to the idle pattern location in memory. The wait instruction in the idle loop then provides the time that one needs to see the idle pattern. If you disable cache, the idle pattern disappears, if you utilize PMI memory the pattern is not transferred via Q22. My BA123 PDP-11/83 runs a bit slower than it could because I love seeing the RSX11M idle pattern on the QProbe display. It is an acceptable trade off for me."

 

So you trade performance for entertainment ... typical for the 21th century?