Sargon 1978 - Bringing it back to life

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

BlueStar
Posts: 30
Joined: Fri Apr 10, 2020 2:41 am
Full name: Craig Hoibakk

Re: Sargon 1978 - Bringing it back to life

Post by BlueStar »

This is so amazingly cool! I remember Sargon! I remember drooling over a z80 "Kaypro" (I think I have that right?) suitcase computer. I think I was in the 9th or 10th grade. I ended up settling for a Commodore 128. At the time, I owned David Levy's "Computer Gamesmanship" (I still have it stored somewhere). Anyways, when I come up to breath from working on my Prolog based chess engine, NADYA2.0, I can't wait to take a look at the code and reminisce. Great Job!
MOBMAT
Posts: 385
Joined: Sat Feb 04, 2017 11:57 pm
Location: USA

Re: Sargon 1978 - Bringing it back to life

Post by MOBMAT »

BlueStar wrote: Fri Jun 19, 2020 1:27 am This is so amazingly cool! I remember Sargon! I remember drooling over a z80 "Kaypro" (I think I have that right?) suitcase computer. I think I was in the 9th or 10th grade. I ended up settling for a Commodore 128. At the time, I owned David Levy's "Computer Gamesmanship" (I still have it stored somewhere). Anyways, when I come up to breath from working on my Prolog based chess engine, NADYA2.0, I can't wait to take a look at the code and reminisce. Great Job!
Prolog, Prolog. Now, that's a name I've not heard in a long time. A long time.
You must be a Jedi!!
You'll have to explain what you did, once you get something working. I had thought about using Prolog a long time ago as an exercise in how to solve endgames, but never thought to create an entire working engine out of it.
i7-6700K @ 4.00Ghz 32Gb, Win 10 Home, EGTBs on PCI SSD
Benchmark: Stockfish15.1 NNUE x64 bmi2 (nps): 1277K
BlueStar
Posts: 30
Joined: Fri Apr 10, 2020 2:41 am
Full name: Craig Hoibakk

Re: Sargon 1978 - Bringing it back to life

Post by BlueStar »

MOBMAT wrote: Fri Jun 19, 2020 1:39 am Prolog, Prolog. Now, that's a name I've not heard in a long time. A long time.
You must be a Jedi!!
You'll have to explain what you did, once you get something working. I had thought about using Prolog a long time ago as an exercise in how to solve endgames, but never thought to create an entire working engine out of it.
Love Star Wars--waited in Seattle (5th and Pike in 1978?) standing in the rain for almost six hours to see it on opening day! But alas... no, as you will see by looking at my code, I am only but a Padowan... But the force is with me and my ELO will eventually one day improve....

But seriously, I did just post about NADYA2.0, and added some source-code snips (more available on request), and a couple of screenshots.

Cheers,
C. Hoibakk
Bill Forster
Posts: 76
Joined: Mon Sep 21, 2015 7:47 am
Location: New Zealand

Re: Sargon 1978 - Bringing it back to life

Post by Bill Forster »

Essay wrote: Wed Jun 17, 2020 4:25 pm Hi Bill,
What an excellent project to revive Sargon and so well implemented by you, many thanks for all your efforts.
Many years ago I attempted to get Sargon running on my Sinclair Spectrum using HiSoft's DevPac assembler and a copy of the Spracklen's Book, I did get it to run without crashing and playing decent chess, however it always played the odd illegal move which was very annoying. Despite my best efforts I never did get it to run without that issue. It may well have been due to the unusual hybrid Z80 code utilized by the Spracklen's and my inability to correctly convert the listed code to pure Zilog Z80.
One thing that always nagged me was whether there might have been an error in the original listing printed in the Hayden publication, it's unlikely I know, but did you find any errors or anomalies as you worked on your project?
Once again, many thanks for such an interesting project, I've played a few games against the UCI Sargon and it plays a surprisingly decent game!
Thanks for your kind words. I didn't find anything in the Spracklens' code I had to change. I have preserved the conversion pipeline for posterity in the "stages" directory. The starting point is sargon1.asm and this is as close to the book as I can make it, I'd like to think it is character by character the same. Then step 2 is sargon2.asm where I fix typos and spelling errors I noticed (that bothered me). Step 3 is very important, for some reason the Spracklens chose to code many short jumps with magic numbers relative to the current location, JR $+4 etc (actually .+4 due to the quirky assembler they used). I thought I could hand replace these accurately with proper symbolic locations by eye, using my knowledge of the Z80 architecture (and so the number of bytes/instruction) but it turned out I was quite wrong and I made several mistakes that I had to correct one by one with painful debugging sessions. I was only really confident I had this step 2 to 3 stage perfect when I confirmed some round trip conversions and could assemble a real Z80 version of the assembly language with a cross compiler and compare. That's probably a bit unclear so I'll try to clarify. As well as a 8080-x86 converter, I also wrote a 8080-Z80 converter and a Z80-x86 converter. With all three in place I was able to verify my 8080->x86 converter produced the same code as my 8080->Z80 converter followed by the Z80->x86 converter. This increased my confidence in both my x86 and Z80 versions. With the Z80 version in hand I could produce a listing with a real Z80 cross assembler and go back and check that each of the magic number conversions from step 2 to step 3 was correct. I preserve a record of the checks in file stages/sargon2-to-3.txt.

Actually after writing all that I now realise that you could skip that annoying stage because you could keep the magic numbers because you had a real Z80. Still, I can only imagine debugging this thing on a Sinclair Spectrum, so all power to you!

I said earlier I didn't have to change anything in the Spracklens' code. But I did find at least one apparent bug. Variable MLPTRJ is not explicitly initialised by Sargon CPTRMV(). The score (MLVAL) of the root node is stored early in the calculation at the MLVAL offset from MLPTRJ. If MLPTRJ has its initial default value of 0, this means MLVAL is poked into fixed address 5. I controlled this behaviour rather than changed it. Basically I don't use the first page in my emulation of the 64K Z80 memory at all. I don't know, maybe the Spectrum wouldn't be so forgiving. Another possible bug I found is that I don't believe the "out of memory" check Sargon does would really work. But I never dug deep into this and I could even be wrong. For my version there's definitely no way it can run out of memory and it's a non-issue.

In a thread on the other section of this forum someone demonstrated that the X86 version runs around 6000 times faster than it would on a real Z80. This made me very happy and explains to some extent why it plays surprisingly decently. But on the other hand the Shannon Type A strategy doesn't respond as well to a 6000 times speed up as a Type B strategy would, so there's sadness mixed in with the happiness (because in an ideal world a 6000 x speedup would have gained a lot more Elo!).