oldie but goody

[Dann Corbit]

This is exciting news.
History is unfolding in our very eyes

[mhull]

This is exciting news.
History is unfolding in our very eyes

One more thing to solve is a book file.

Code: Select all

book.f c     ******************************************************************
book.f c     *                                                                *
book.f c     *      book search the chess library of book moves for a         *
book.f c     *  response to the opponent's last move.  in most cases, there   *
book.f c     *  will be severalmoves to choose from.  the program will choose *
book.f c     *  a random move ignoring any 'poor' or '?' type moves that may  *
book.f c     *  be present.  this feature provides variety so that it is      *
book.f c     *  more difficult to find an area of weak play and captitalize   *
book.f c     *  on it over and over.  due to the structure of the book data   *
book.f c     *  base, this routine will never require over two i/o operations *
book.f c     *  to find a response making it very effective as a time-saver.  *
book.f c     *     a seperate program is used to construct the library of     *
book.f c     *  moves to keep unnecessary programming code out of the prime   *
book.f c     *  chess playing program.                                        *
book.f c     *                                                                *
book.f c     ******************************************************************

It would be nice if the original book building program mentioned in the comments could be located, or a book file that was created by it. Looks like the Cray Blitz book system is incompatible, having evolved a fair distance beyond this version.

[Rebel]

Speaking about old times, found this on my HD - http://rebel13.nl/old_photo's.pdf

[mhull]

The Sigma 9 Fortran had extensions for the built-in functions, IAND and IEOR, both utilized in Blitz. Since none of the period IBM compilers include them, appropriate assembler subroutines have been built and linked-in.

BOOK: It may be possible to retro-fit the book from Cray Blitz included with Jim Ablett's port. The compressed move structures are similar.

BLITZ6

Code: Select all

C     *          XXXXCCCC PPPPTTTT DDDDDDDD SSSSSSSS                   *
C     *                                                                *
C     *      XXXX = UNUSED                                             *
C     *                                                                *
C     *      CCCC = CAPTURED PIECE (0=NONE)                            *
C     *                                                                *
C     *      PPPP = PROMOTION PIECE FOR PAWN PROMOTIONS (0=NONE)       *
C     *                                                                *
C     *      TTTT = MOVE TYPE AS FOWLOWS:                              *
C     *             1 = NORMAL MOVE                                    *
C     *             2 = CA8TLE KING-SIDE                               *
C     *             3 = CASTLE QUEEN-SIDE                              *
C     *             4 = ENPASSANT PAWN CAPTURE                         *
C     *             5 = PAWN PROMOTION (USING PPPP)                    *
C     *                                                                *
C     *      DDDDDDDD = DESTINATION SQUARE                             *
C     *                                                                *
C     *      SSSSSSSS = SOURCE SQUARE                                  *
C     *                                                                *
C     ******************************************************************

CRAY BLITZ

Code: Select all

c     ******************************************************************
c     *                                                                *
c     *      extrct is used to decode the compressed move that is      *
c     *  generated by the various move generators.  the move is kept   *
c     *  in the following 23-bit form except when being analyzed:      *
c     *                                                                *
c     *        mmmcc ctttdd ddddds ssssss                              *
c     *                                                                *
c     *      mmm  = moving piece                                       *
c     *                                                                *
c     *      ccc  = captured piece (0=none)                            *
c     *                                                                *
c     *      ttt  = move type as follows:                              *
c     *             0 = normal move                                    *
c     *             1 = castle king-side                               *
c     *             2 = castle queen-side                              *
c     *             3 = en passant pawn capture                        *
c     *             4 = pawn promotion to knight                       *
c     *             5 = pawn promotion to bishop                       *
c     *             6 = pawn promotion to rook                         *
c     *             7 = pawn promotion to queen                        *
c     *                                                                *
c     *      ddddddd  = destination square                             *
c     *                                                                *
c     *      sssssss  = source square                                  *
c     *                                                                *
c     ******************************************************************

[mhull]

It is playing legal chess at the moment (at least through the first several moves), but not all the features are working. This example is computing at a fixed depth setting of 7. The computation times are accurate and I assume the node counts are also.

Code: Select all

 COMPUTATION TIME WAS    3:13
  
 YOUR MOVE, HERC03
S
  
 MOVE:  3  BOOK:  0  EXPECTED:  1
 DEPTH:  7  TIME: -24:36  RATIO: 2.4  EVAL:      74
 NODES:  632835  EVALS:  334647  LOOKUPS   2X  TABLE 100X
 RF8-B4 RC1-G5 RB4:C3 RB2:C3 RH7-H6 RG5:F6 RD8:F6
  
 YOUR MOVE, HERC03
D
  
                BLACK
  
   (R) (N) (B) (Q) (K)  *   +  (R)
  
   (P) (P) (P) (P)  *  (P) (P) (P)
  
    +   *   +   *  (P) (N)  +   *
  
    *   +   *   +   *   +   *   +
  
    +  (B)  +  :P: :P:  *   +   *
  
    *   +  :N:  +   *   +   *   +
  
   :P: :P: :P:  *   +  :P: :P: :P:
  
   :R:  +  :B: :Q: :K: :B: :N: :R:
  
  
                WHITE
  
 YOUR MOVE, HERC03
BD3
  
 ELAPSED TIME WAS    1:22
  
  
  
 MY MOVE IS C5
  
  
  
 COMPUTATION TIME WAS    5:27
  
 YOUR MOVE, HERC03

S
  
 MOVE:  4  BOOK:  0  EXPECTED:  1
 DEPTH:  7  TIME: -16:22  RATIO: 1.9  EVAL:      80
 NODES: 1220128  EVALS:  561760  LOOKUPS   1X  TABLE 100X
 RC7-C5 RD4:C5 RB4:C3+ RB2:C3 .....
  
 YOUR MOVE, HERC03
D
                BLACK
  
   (R) (N) (B) (Q) (K)  *   +  (R)
  
   (P) (P)  *  (P)  *  (P) (P) (P)
  
    +   *   +   *  (P) (N)  +   *
  
    *   +  (P)  +   *   +   *   +
  
    +  (B)  +  :P: :P:  *   +   *
  
    *   +  :N: :B:  *   +   *   +
  
   :P: :P: :P:  *   +  :P: :P: :P:
  
   :R:  +  :B: :Q: :K:  +  :N: :R:
  
  
                WHITE
  
 YOUR MOVE, HERC03

This emulator is running an IBM 3033. Back in the day it was rated about 1.5 MIPS (I think). It was a bit faster than the Xerox Sigma 9. On my dated AMD Machine (AMD Phenom II X4 830, 2.8 Ghz), it's clocking around 181 MIPS on one CPU.

The PV seems to have an R in front of each move for some reason.

[mhull]

I discovered that the TK4- mainframe distribution (MVS3.8j on IBM 3033 virtual hardware) includes Duchess , the very strong (for the day) Duke University chess project and a contemporary of BLITZ 6.

Blitz should soon be in a state to hold a match between these two programs on the same hardware. The performance of the hardware simulation might be comparable to running both programs on a period CRAY-1.

The biggest obstacle at the moment seems to be with 3270 emulation, which on the x3270-family of emulators is preventing the intended use of the vital ATTN exit. The PA1 key-press is languishing in the type-ahead buffer instead of being sent to the program. I'm not sure this is the correct behavior on a native 3270 terminal. A query is in to the x3270 code maintainer about this issue.

[mhull]

It is playing legal chess at the moment (at least through the first several moves), but not all the features are working. This example is computing at a fixed depth setting of 7. The computation times are accurate and I assume the node counts are also.

Code: Select all

 COMPUTATION TIME WAS    3:13
  
 YOUR MOVE, HERC03
S
  
 MOVE:  3  BOOK:  0  EXPECTED:  1
 DEPTH:  7  TIME: -24:36  RATIO: 2.4  EVAL:      74
 NODES:  632835  EVALS:  334647  LOOKUPS   2X  TABLE 100X
 RF8-B4 RC1-G5 RB4:C3 RB2:C3 RH7-H6 RG5:F6 RD8:F6
  
 YOUR MOVE, HERC03
D
  
                BLACK
  
   (R) (N) (B) (Q) (K)  *   +  (R)
  
   (P) (P) (P) (P)  *  (P) (P) (P)
  
    +   *   +   *  (P) (N)  +   *
  
    *   +   *   +   *   +   *   +
  
    +  (B)  +  :P: :P:  *   +   *
  
    *   +  :N:  +   *   +   *   +
  
   :P: :P: :P:  *   +  :P: :P: :P:
  
   :R:  +  :B: :Q: :K: :B: :N: :R:
  
  
                WHITE
  
 YOUR MOVE, HERC03
BD3
  
 ELAPSED TIME WAS    1:22
  
  
  
 MY MOVE IS C5
  
  
  
 COMPUTATION TIME WAS    5:27
  
 YOUR MOVE, HERC03

S
  
 MOVE:  4  BOOK:  0  EXPECTED:  1
 DEPTH:  7  TIME: -16:22  RATIO: 1.9  EVAL:      80
 NODES: 1220128  EVALS:  561760  LOOKUPS   1X  TABLE 100X
 RC7-C5 RD4:C5 RB4:C3+ RB2:C3 .....
  
 YOUR MOVE, HERC03
D
                BLACK
  
   (R) (N) (B) (Q) (K)  *   +  (R)
  
   (P) (P)  *  (P)  *  (P) (P) (P)
  
    +   *   +   *  (P) (N)  +   *
  
    *   +  (P)  +   *   +   *   +
  
    +  (B)  +  :P: :P:  *   +   *
  
    *   +  :N: :B:  *   +   *   +
  
   :P: :P: :P:  *   +  :P: :P: :P:
  
   :R:  +  :B: :Q: :K:  +  :N: :R:
  
  
                WHITE
  
 YOUR MOVE, HERC03

This emulator is running an IBM 3033. Back in the day it was rated about 1.5 MIPS (I think). It was a bit faster than the Xerox Sigma 9. On my dated AMD Machine (AMD Phenom II X4 830, 2.8 Ghz), it's clocking around 181 MIPS on one CPU.

The PV seems to have an R in front of each move for some reason.

The R in front of PV moves is an actual bug in the program. It occurs in the OUTPUT subroutine (converts internal data into text for display) where the piece type is retrieved from the BOARD array by using the FROM$ index that is itself extracted from the compressed move. OUTPUT is called by two different subroutines, STATUS and INFORM. STATUS passes a saved copy of the BOARD array where the piece is still located at FROM$. But INFORM passes the live BOARD, where the PV moves are made in turn and so reside at the TO$ index. OUTPUT was only using FROM$ as an index. So the lookup would find a 0 at the FROM$ location because the piece wasn't actually there. In the piece type lookup table, there is no zero index, so I don't know where it was getting the 4, which is the number for the rook (R).

CRAY BLITZ changed this so that the piece type is included in the compressed move structure, avoiding the need for a BOARD array lookup.

Another issue that was solved is platform specific (IBM s/370 with MVS), which is the ATTN key program interrupt. You need this to tell the pondering program that you want to make a move or issue a command. Long story short, if you are using the public domain operating system, MVS-3.8j, you have to activate ATTN by the key sequence RESET, then PA1. You can configure a keyboard shortcut for this in modern emulators. Back in the day, 3270 terminals didn't have ATTN keys. You used PA (Program Access) keys instead, PA1-PA3. These keys are still available but if you're using a modern version of MVS (z/OS), the PA keys don't provide ATTN but rather the ATTN key itself. Confusing, eh? The ATTN key became standard in the mid-1980s starting with the 3278 model of terminals. MVS3.8j predates these terminals and doesn't recognize the ATTN key.

The next bug to track down is that the program will not operate using time-per-move. You use the ST command to tell the program how much time to use per move. This seems intended as a non-pondering mode. But it doesn't work. If you start the program and type GO, it does a two-ply search and coughs up a move. If you tell it to take a minute, e.g. ST:60 command, it sets up the time but then doesn't use it. It still does only a two-ply search.

This seems to be a transitional version of BLITZ (aren't they all?) because it doesn't use the Xerox subroutine calling convention (according to the Xerox Fortran IV manual). This version might have been prepared for a UNIVAC platform that was used in tournaments after 1977. I don't think it matters much, though.

[mhull]

I have some questions about the book structure in Blitz.

The book file structure is setup with uniform records of 40, 32-bit words each. Each record is padded with words initialized to zero. Words 1-20 contain up-to 20 moves in compressed move format. For each move, a corresponding hash value is also created. For example, a move in word 4 would have a corresponding position hash in word 24. Unused words remain padded with values of zero.

I have included the relevant code segments from BOOK.F. A book record is loaded into the array MOVES. The first KEY value is 1 on move 1 of the game. Subsequent KEY values replace 1 with the corresponding hash value from MOVES(which+20) where WHICH is the nth compressed move.

Code: Select all

      define file 3(5000,40,u,iav)
       .
       .
c------------------------------< get the pointer to the record with
c------------------------------< the computer's possible replies.
      key=mod(key,10000)
      ...
      read(3'key)(moves(i),i=1,40)
      .
      .
c------------------------------< set-up for the next match.
      key=key*10000+moves(which+20)

1) Am I understanding the book file correctly?

2) Shouldn't the record count in the "define file" statement (5000) be the same as the modulus parameter (10000)? (The DEFINE FILE statement was actually commented out. It was reactivated for testing.)

3) The original book-maker code isn't available. Would it have used the same hashing function used for the transposition table?

[mhull]

I have some questions about the book structure in Blitz.

The book file structure is setup with uniform records of 40, 32-bit words each. Each record is padded with words initialized to zero. Words 1-20 contain up-to 20 moves in compressed move format. For each move, a corresponding hash value is also created. For example, a move in word 4 would have a corresponding position hash in word 24. Unused words remain padded with values of zero.

I have included the relevant code segments from BOOK.F. A book record is loaded into the array MOVES. The first KEY value is 1 on move 1 of the game. Subsequent KEY values replace 1 with the corresponding hash value from MOVES(which+20) where WHICH is the nth compressed move.

Code: Select all

      define file 3(5000,40,u,iav)
       .
       .
c------------------------------< get the pointer to the record with
c------------------------------< the computer's possible replies.
      key=mod(key,10000)
      ...
      read(3'key)(moves(i),i=1,40)
      .
      .
c------------------------------< set-up for the next match.
      key=key*10000+moves(which+20)

1) Am I understanding the book file correctly?

2) Shouldn't the record count in the "define file" statement (5000) be the same as the modulus parameter (10000)? (The DEFINE FILE statement was actually commented out. It was reactivated for testing.)

3) The original book-maker code isn't available. Would it have used the same hashing function used for the transposition table?

Argh. Also, in the middle of this code:

Code: Select all

      key=moves(i+20)
      if(key .eq. 0) go to 3
c
c------------------------------< read in the record with the program's
c------------------------------< possible replise to the last human
c------------------------------< move and chose one of them. the

5     continue
      read(3'key)(moves(i),i=1,40)

So words 21-40 contain keys. How are the keys computed?