oldie but goody

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Dann Corbit
Posts: 11510
Joined: Wed Mar 08, 2006 7:57 pm
Location: Redmond, WA USA
Contact:

Re: oldie but goody

Post by Dann Corbit » Sat Jun 13, 2020 3:36 pm

This is exciting news.
History is unfolding in our very eyes
Taking ideas is not a vice, it is a virtue. We have another word for this. It is called learning.
But sharing ideas is an even greater virtue. We have another word for this. It is called teaching.

User avatar
mhull
Posts: 13059
Joined: Wed Mar 08, 2006 8:02 pm
Location: Dallas, Texas
Full name: Matthew Hull

Re: oldie but goody

Post by mhull » Sat Jun 13, 2020 10:27 pm

Dann Corbit wrote:
Sat Jun 13, 2020 3:36 pm
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.
Matthew Hull

User avatar
Rebel
Posts: 5485
Joined: Thu Aug 18, 2011 10:04 am

Re: oldie but goody

Post by Rebel » Sun Jun 14, 2020 7:06 pm

Speaking about old times, found this on my HD - http://rebel13.nl/old_photo's.pdf
90% of coding is debugging, the other 10% is writing bugs.

User avatar
mhull
Posts: 13059
Joined: Wed Mar 08, 2006 8:02 pm
Location: Dallas, Texas
Full name: Matthew Hull

Re: oldie but goody

Post by mhull » Sat Jul 18, 2020 10:20 pm

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     ******************************************************************
Matthew Hull

User avatar
mhull
Posts: 13059
Joined: Wed Mar 08, 2006 8:02 pm
Location: Dallas, Texas
Full name: Matthew Hull

Re: oldie but goody

Post by mhull » Tue Jul 28, 2020 5:03 am

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.
Matthew Hull

User avatar
mhull
Posts: 13059
Joined: Wed Mar 08, 2006 8:02 pm
Location: Dallas, Texas
Full name: Matthew Hull

Re: oldie but goody

Post by mhull » Fri Aug 07, 2020 7:57 pm

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.
Matthew Hull

User avatar
mhull
Posts: 13059
Joined: Wed Mar 08, 2006 8:02 pm
Location: Dallas, Texas
Full name: Matthew Hull

Re: oldie but goody

Post by mhull » Fri Aug 28, 2020 11:12 pm

mhull wrote:
Tue Jul 28, 2020 5:03 am
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.
Matthew Hull

User avatar
mhull
Posts: 13059
Joined: Wed Mar 08, 2006 8:02 pm
Location: Dallas, Texas
Full name: Matthew Hull

Re: oldie but goody

Post by mhull » Tue Sep 15, 2020 5:21 pm

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?
Matthew Hull

User avatar
mhull
Posts: 13059
Joined: Wed Mar 08, 2006 8:02 pm
Location: Dallas, Texas
Full name: Matthew Hull

Re: oldie but goody

Post by mhull » Tue Sep 15, 2020 6:44 pm

mhull wrote:
Tue Sep 15, 2020 5:21 pm
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?
Matthew Hull

Post Reply