Chess - test-drb@ccmp.vtda.org

15 Apr 2008

Date: Tue, 15 Apr 2008 12:08:06 -0700
...
  From: "Rick Bensene"  

...
  I played this a lot on weekends when I was the Cyber
73 weekend operator
 at Tektronix. This was under KRONOS rather than SCOPE.  I believe that the
 console command was X.CHESS It used both CRT's, the left for a nice vector
 display of the game board, and the right for a listing of the moves made
 thus far, elapsed time, and for entering moves.  I believe that the main
 program ran all of the chess processing, and that a PPU program
 communicated with the main program.   
When I got the Chess bootleg release tape from a friendly site 
analyst (they always got the good stuff first), I had to rework the 
display driver to work with our own OS, which used much of the PP 
code from Scope 3.1.6.  It wasn't difficult, but the presence of a 
dedicated display driver required that one EDITLIB the driver into 
the system library--something you weren't likely to be able to do on 
someone else's system.  I can't say for sure, but I believe that I 
was the one to modify the code to use the "T" display, so that Chess 
could be run without any special system modifications.  I had to give 
up one or two fancy display features, but generally, it worked pretty 
well.

...
  The Cyber 73 had two main CPUs, and 20 PPUs (10 for
each CPU).  The
 CPUs were essentially 6600-design, with some enhancements for certain
 types of vector operations, as well as dealing with shared main memory.  
Small nit, Rick.  Depending on the model, the 73 was either a 6400 or 
6500 (2 CPU) machine.  It was the Cyber 74 that was the 6600 10-
functional-unit system.  You can check Bitsavers for the docs, but 
I'm certain of it.

The "vector extension" wasn't really one--it was called the 
"Compare/Move Unit" or CMU.  It really didn't do much other than give 
one the ability to perform non-word aligned moves and compares.  It 
had no arithmetic capabilities (other than the compare).  Really, no 
practical performance benefit on the 6600/74, but it made a 
difference on the serial-issue 6400/73. 

The fly in the ointment was that while it was standard on the 73, it 
was not available on the 74.  In the COBOL run-time library, we had 
some fancy code worked out by Rick James that would check for the CMU 
(which was triggered by a no-op (46 opcode) with some nonzero bits in 
the normally-zero operand field.  Detecting the thing was 
interesting.  You couldn't say that "if it's not a Cyber 74/6600, 
then there's a CMU", since you still had the issue that the 6400 and 
6500 didn't have it either.  The technique was to code a word so that 
the first parcel was a CMU instruction (didn't matter what flavor), 
the second parcel was a no-op (46000) and the third and fourth 
parcels contained an uncondition jump.  If a CMU was present, the 
next instruction would be taken from the next word; if not present, 
...
 from the succeeding parcels, which would cause the jump
to be taken.   Worked just fine until some idiot at Arden Hills decided to work up 
an FCO to the Cyber 74 to trap "CMU not present".  Sigh--after that, 
it was determined as part of deadstart.  

Cheers,
Chuck