How to set Level for Sargon using Tarrasch

[phillipeaton]

Hello Bill,

For a personal project I'm working on (Sargon chess running on 6809 CPU), I would like to recreate the sample games you commented on, on TalkChess.com (Sargon playing at Level 2 and 3).

I've downloaded Tarrasch Chess GUI V3.12b and the Sargon engine and it all seems to work, but when I look at the engine analysis, the depth is somewhere between 2 and 7 or so.

I see it written that there is a FixedDepth parameter I can set, but using Tarrasch, setting the engine to Sargon and putting "FixedDepth" into Custom parameter 1, with a 2 in the box to the right doesn't seem to work.

Do you have any clues how I could fix the depth and so recreate the sample games?

Thank in advance!

[billforsternz]

I've checked and it works as I intended (although it may not be exactly as you want it).

I would suggest the best way to understand what's happening is to first set FixedDepth to 5 or 6, as then there is enough delay that you can more readily observe what is going on.

Firstly, the FixedDepth only applies when playing human v engine games, it does not apply to kibitzing (analysis).

Here's a suggested series of steps to clearly understand what's going on.

1) Set FixedDepth to 5 in exactly the way you describe (except 5 instead of 2). 2) Turn off the Tarrasch Book (Options > Opening Book > Enabled unticked) 3) Play "White against Engine" 4) Play a move, eg 1.f4 5) Sargon will reply instantaneously with 1...d5 because it has a one ply "book" of 1.e4 or 1.d4 randomly as white, and 1...e5 against 1.e4 and 1...d5 against any other as Black 6) Play another move, eg 2.Nf3 7) Now Sargon will think for a while

If you turn on Kibitzing during this game, Sargon will show incrementing depth 3,4.5... when White is to play - but will go straight to depth 5 when Black is to play (the Sargon engine goes straight to the FixedDepth in these circumstance). Unfortunately an unintended side effect of this is that the only Black to play output (depth 5) is immediately overwritten by instantaneous depth 3 output for White.

If you really want to be convinced, run Tarrasch from the command line with a -? parameter. It then shows debug info, including its interaction with the engine.

Here is an extract from this test game after 1.f4 d5 2. Nf3

in: position startpos moves f2f4 d7d5 g1f3 in: go wtime 1488984 btime 179491 winc 5000 binc 1000 out: info depth 5 score cp 50 hashfull 0 time 2855 nodes 53766 nps 18000 pv d8d6 d2d4 b8c6 b1c3 d6b4 out: bestmove d8d6

The "in" and "out" are relative to the engine. This shows that Sargon eventually responds with 2...Qd6

Your experiment sounds really fun, I hope you keep me informed of progress and that it all works out!

[phillipeaton]

Following your instructions and hints about how the analysis works, I was able to get Tarrasch to replicate the sample game. (BTW, I've never used Tarrasch before, or any chess engine or standard GUI, it's all a bit new to me. Tarrasch seems like a really nice program!)

Perhaps the most important setting update was to turn off the opening book. Not sure, but once that was turned off and the depth was set to 2, the moves followed as per the talkchess sample game.

From the debug log at the 20th and final move: out: info depth 2 score cp -112 hashfull 0 time 16 nodes 429 nps 26000 pv h8e8 b2b3

So why am I interested in this?

I have a Vectrex video game console from 1982, which has a thriving homebrew software scene these days, but has never had a chess game released for it, so I thought I'd look into it.

The Vectrex has a 1.5MHz 6809 CPU, easy to make EPROM cartridges and some good emulation software. It also has downsides, such as a vector monitor with no screen buffer and only 1KiB of RAM, but each of these limitations I can get round.

From my teenage years, I had a VIC-20 and the Sargon II chess game on cartridge, which I remember well. Ideally then, I'd convert Sargon II, but then I came across the original Sargon book and that seemed like a good place to start. Maybe Sargon II comes later.

When finding out about Sargon, I found a comment that Sargon II had been translated to 6809 and I found that in an emulator for the 6809 FLEX OS called ReFLEX.

With ReFLEX, I found a binary file that does play a game of chess on ReFLEX that I have disassembled with the help of a partial/similar assembly source code file that was with it. (Which clearly looks like a translation of Sargon, not Sargon II.)

That's as far as I've got. I have some challenges here, I haven't done much assembly programming and I know hardly anything about chess engines, so there's a lot to learn.

On the other hand, I was a Forth programmer in the 90s and was able to port CamelForth to the Vectrex, so anything is possible. (Github "VecForth")

My reason for working with Tarrasch to verify the sample game is that the version on ReFLEX does not appear to follow the sample, so as part of my conversion to the Vectrex, I'm going to have to find out why.

Nonetheless, it's great to have a model to follow and the explanations of how it all works that are in your GitHub repository, so thanks for publishing them.

ReFLEX "Sargon" 2nd black move appears wrong, it moves a Queen instead of a Nc6:

[billforsternz]

Goodness me, you've set yourself a challenge. To step through Sargon x86 code while it is playing the test game, I would suggest replaying the UCI commands you've already observed in std::vector test_sequence within sargon-engine.cpp. Or you could adapt sargon_whole_game_tests() in sargon-tests.cpp.

Having said that, I think that it is probably unrealistic to expect to get your 6809 version playing this exact sequence of moves. The Spracklens changed their program all the time. I was unable to source any historic games I could reproduce exactly from the various websites that have historic Sargon information. The exact match you are referencing here is to an independent platform port of the exact same source code that was frozen in time in the form of a paper book! But the Spracklens were in business and were tweaking their product all the time. There's a couple of Byte magazine articles from 1978 referencing Sargon code at about the time of the book, but the code discussed in one of them already has subtle differences. I imagine the 6809 code was derivative of the 6502 version (closer family resemblance than the Z80 right?) which was pretty much a rewrite as I understand it.

You might have to be satisfied with simply getting the 6809 to play legal chess at about the standard expected. You could put your hand on your heart and say if it does that then the code is very likely to be running as expected. This would already be a huge accomplishment in my view, seeing as you are working from disassembled binaries with no source code!

(Incidentally I have a soft spot for the 6809 - I worked on a commercial small business telephone switch written in 6809 assembly language back in the late 1980s).

[phillipeaton]

Well, there's no point doing it if it's not a challenge 🙂

Thank for the x86 test info...right now that's going a bit over my head, but I'll get there and I'm sure they'll make sense.

Yes, I suspected the code would be somewhat of a moving target, but the paper book isn't, so I'll use that as the model. I also assumed there would be some kind of random function involved for mixing play up a bit, but after seeing the comparison of your implementation vs the TRS-80 version, I guess there isn't, which makes testing easier.

The 6809 port was made to work from the book so the difference in Level 2 play of the 6809 binary I'm seeing must be due to a coding error or some other anomaly, which I'll have to track down and resolve. Really, I just want to know what the reference model is to prove what I'm working on is correct before I really commit to doing this, so making it play the same sequence of moves as a known reference, I think, is realistic and necessary.

I do have the (apparently non-working) source code that the working 6809 binary was based on, so I'm not completely in the dark, I can see the similarities in it to the book version.

The 6809 seems a nice CPU for programmers, I'm enjoying working with it, even with my lack of experience in assembler. All the systems I programmed in Forth in the 90s were Z80 based, but I never worked at assembler level, I was the front-end and interfaces guy, so no advantage their either.

I'll let you know how I get on...could take a while, porting Forth took two years, as I have two young children!

[billforsternz]

Good luck. (I also have a soft spot for Forth https://web.archive.org/web/20161130035955/http://stackoverflow.hewgill.com/questions/122/292.html )

[phillipeaton]

I see you're still working occasionally on your modern Sargon, it's great to see you still have interest in it.

I'm still plugging away with my Vectrex port in any spare hours I find, I now have dasmfw disassembling the FLEX binary into very readable source code, which a09 can then assemble back to an identical binary.

That source code I also have assembling to the Vectrex memory map and I have combined it with my Forth implementation into a binary, so I can call the various Sargon subroutines from the Vectrex Forth command line.

It still includes a bunch of FLEX custom graphics code that I need to strip out, but at least now the fun part begins - iterative testing and code tweaking/clean-up to get something that runs and plays from the Forth command line terminal.

Then, I need to fix it so it plays the correct moves and then to build the Vectrex interface. It's a long journey, but still fun!

[phillipeaton]

I now have something that assembles and runs interactively from my Forth command line on the 6809 Vectrex hardware, I'm calling the Sargon subroutines directly.

It plays the same different moves as the ReFLEX version! And it's not an improvement, it doesn't seem to defend it's pieces, for example.

So now the difficult part begins, fixing the move logic to match the TRS-80 reference. Wish me luck...

[phillipeaton]

In case you're interested, I managed to get the 6809 Sargon engine working. Simple tweaks didn't work, that was poking the elephant with a stick. I had to hack into the code iteratively ever deeper and eventually needed to create a merged source code for reference and run two MAME debuggers in parallel to find the problem why 6809 was making incorrect moves. So awkward was using MAME debugger, I was almost at the point of recoding the POINTS code tree in Forth Assembly and debugging that. But then, after ~6 weeks of fruitless debugging, I struck gold. The fix was literally to add "STB RD" into XCHNG.

Merged source code snippet:

Debugging TRS-80 Z80 and Vectrex 6809 in parallel (screen shot taken later, representative only, move lists etc. don't line up). This was a nightmare, MAME debugger save states don't work for the Vectrex and both debuggers close all the open memory view windows on a reset. Note I used the @billforsternz Z80 alternative assembly language source, which is what MAME shows in the debugger - very handy!

Once I'd found the problem in the debugger, I ran the fixed code on the Vectrex and stepped through the test game from the talkchess thread (Ply 2) using the Forth interactive prompt, this shows the end position:

These are the timings. The Vectrex @1.5MHz is twice as fast as the TRS-80 @ 1.77Mhz.

Goodness me, you've set yourself a challenge. ..........

Yes!

Having said that, I think that it is probably unrealistic to expect to get your 6809 version playing this exact sequence of moves. ........ The exact match you are referencing here is to an independent platform port of the exact same source code that was frozen in time in the form of a paper book! .......... I imagine the 6809 code was derivative of the 6502 version (closer family resemblance than the Z80 right?) which was pretty much a rewrite as I understand it.

Nope! I reckon it was based on the book. I'm curious about the 6502 version, though, as the 6809 version doesn't use the U register apart from once, so it could almost be 6502.

You might have to be satisfied with simply getting the 6809 to play legal chess at about the standard expected. You could put your hand on your heart and say if it does that then the code is very likely to be running as expected. This would already be a huge accomplishment in my view, seeing as you are working from disassembled binaries with no source code!

Nope! Works the same as the TRS-80, which appears to be the same code as in the book.

But it's not finished yet, now I need to convert it to a ROM/RAM game instead of RAM only and rewrite the I/O completely for Vectrex joystick and Vector monitor etc. With the engine working, that'll the fun part.

In the meantime, many thanks for your previous art, inspiring words and encouragement, they gave me lots of determination! 😉

[billforsternz]

I am very happy for you and very impressed and surprised that the 6809 version plays the same moves as the Z80 version. I have had an extraordinary few days and am exhausted beyond measure, so I can't dig in to the details right now, but I would love to collaborate about publishing results etc. when appropriate. I am working with a German guy who has just managed to get reproducibility too, on his vintage Z80, using my Z80 mnemonics version. A much lower barrier to cross than you admittedly! With him I want to publish a nice generic Z80 version that is maximally easy to port to random Z80 hardware, which is a long way from the Spracklen's priorities (they used a weird assembler and annoyingly platform specific tricks etc.). We should pull everything together with timing info Z80 vs 6809 vs x86. Sorry prattling using a phone and a non functioning brain at the moment.

Bill.

On Sun, 4 Apr 2021, 11:56 Phillip Eaton, @.***> wrote:

In case you're interested, I managed to get the 6809 Sargon engine working. Simple tweaks didn't work, that was poking the elephant with a stick. I had to hack into the code iteratively ever deeper and eventually needed to create a merged source code for reference and run two MAME debuggers in parallel to find the problem why 6809 was making incorrect moves. So awkward was using MAME debugger, I was almost at the point of recoding the POINTS code tree in Forth Assembly and debugging that. But then, after ~6 weeks of fruitless debugging, I struck gold. The fix was literally to add "STB RD" into XCHNG.

Merged source code snippet: [image: image] https://user-images.githubusercontent.com/44277038/113493837-605b1100-94e3-11eb-9a14-931b3fa2db84.png

Debugging TRS-80 Z80 and Vectrex 6809 in parallel (screen shot taken later, representative only, move lists etc. don't line up). This was a nightmare, MAME debugger save states don't work for the Vectrex and both debuggers close all the open memory view windows on a reset. Note I used the @billforsternz https://github.com/billforsternz Z80 alternative assembly language source, which is what MAME shows in the debugger - very handy! [image: Major Debug] https://user-images.githubusercontent.com/44277038/113493790-e88ce680-94e2-11eb-89b1-6017bbd9c8d6.png

Once I'd found the problem in the debugger, I ran the fixed code on the Vectrex and stepped through the test game from the talkchess thread (Ply 2) using the Forth interactive prompt, this shows the end position: [image: End Position] https://user-images.githubusercontent.com/44277038/113493798-f478a880-94e2-11eb-90a5-4981262974bd.png

These are the timings. The Vectrex @1.5MHz is twice as fast as the TRS-80 @ 1.77Mhz. [image: Timings] https://user-images.githubusercontent.com/44277038/113493800-f80c2f80-94e2-11eb-8f87-bf0e4bf0d112.png

Goodness me, you've set yourself a challenge. ..........

Yes!

Having said that, I think that it is probably unrealistic to expect to get your 6809 version playing this exact sequence of moves. ........ The exact match you are referencing here is to an independent platform port of the exact same source code that was frozen in time in the form of a paper book! .......... I imagine the 6809 code was derivative of the 6502 version (closer family resemblance than the Z80 right?) which was pretty much a rewrite as I understand it.

Nope! I reckon it was based on the book. I'm curious about the 6502 version, though, as the 6809 version doesn't use the U register apart from once, so it could almost be 6502.

You might have to be satisfied with simply getting the 6809 to play legal chess at about the standard expected. You could put your hand on your heart and say if it does that then the code is very likely to be running as expected. This would already be a huge accomplishment in my view, seeing as you are working from disassembled binaries with no source code!

Nope! Works the same as the TRS-80, which appears to be the same code as in the book.

But it's not finished yet, now I need to convert it to a ROM/RAM game instead of RAM only and rewrite the I/O completely for Vectrex joystick and Vector monitor etc. With the engine working, that'll the fun part.

In the meantime, many thanks for your previous art, inspiring words and encouragement, they gave me lots of determination! 😉

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/billforsternz/retro-sargon/issues/1#issuecomment-812943275, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSQYSW3W66UPHV6TELNNL3TG6TJVANCNFSM4RVBS5UA .

[phillipeaton]

but I would love to collaborate about publishing results etc. when appropriate

Yes, that should be possible. I literally have bare bones code at the moment, called from the command line, but now I can start to pull all the code together (all sorts of hacked files at the moment) and git commit it.

This my current 6809 UI code, super basic...

\ Sargon subroutine vectors
$7FE0 equ cptrmv
$7FE2 equ fndmov
$7FE4 equ inchk
$7FE6 equ initbd
$7FE8 equ move
$7FEA equ plyrmv
$7FEC equ points
$7FEE equ valmov

code _points  UY__D # PSHS,   points [] JSR,   UY__D # PULS,   next ;c \ -- ;
code _attack  UY__D # PSHS,   attack [] JSR,   UY__D # PULS,   next ;c \ -- ;
code _fndmov  UY__D # PSHS,   fndmov [] JSR,   UY__D # PULS,   next ;c \ -- ;
code _initbd  UY__D # PSHS,   initbd [] JSR,   UY__D # PULS,   next ;c \ -- ;
code _move    UY__D # PSHS,   move   [] JSR,   UY__D # PULS,   next ;c \ -- ;
code _valmov  ____D # PSHS,
              UY___ # PSHS,   valmov [] JSR,   UY___ # PULS,
                                            A B TFR,   CLRA,   next ;c \ -- n ; 0=valid 1=invalid

: (.bd) \ n -- ;
   ?dup if
      dup $FF = if
         ." __" drop
      else
         dup $80 and if $42 else $57 then emit
         %0111 and
         dup 1 = if $50 else
         dup 2 = if $4E else
         dup 3 = if $42 else
         dup 4 = if $52 else
         dup 5 = if $51 else
         dup 6 = if $4B
         then then then then then then
         emit drop
      then
   else ." .."
   then space \ Display row
;

: .bd
   0 #110 do
      cr
      i BOARD + H. space \ Display row address
      i #10 / 1 - dup 1 9 within if . else drop 2 spaces then \ Display Rank
      #10 0 do
         j BOARD + i + c@ (.bd)
      loop
   -#10 +loop
   cr #11 spaces ." A  B  C  D  E  F  G  H" \ Display File
   cr
;

: init \ -- ;
   $80 KOLOR c! \ Computer's colour
   1 PLYMAX c! \ Maximum ply
   _initbd
   0 MOVENO c!
   .bd
;

: get-square \ -- n ; Address of square
   key dup EMIT toupper $40 -
   key dup EMIT         $30 - 1+ #10 *
   +
;

: pmv
   MOVENO c@ 1+ MOVENO c!
   cr ." Move number:" MOVENO c@ .
   cr ." Enter From:" get-square cr dup . MVEFRM c!
   cr ." Enter To  :" get-square cr dup . MVETO  c!
   cr ." valmov:" _valmov .
\   _execmv
   .bd
;

: cmv
\   cr ." fndmov"
   _fndmov
   bestm @ mlptrj !
   cr mlptrj @ 2 + dup c@ ." from:" .
                    1+ c@ ." to:"    .
   _move
\   _execmv
   .bd
;

: play
   cr ." plyrmv" pmv
   cr ." cptrmv" cmv
;

[phillipeaton]

Updated timings table for Level 2 and 3.

This time it was scripted from interactive Forth running real-time on the Vectrex with timings captured using TeraTerm log and manipulated with Excel.

                Sargon I UCI lv2        Sargon I TRS-80 lv2     Sargon I Vectrex lv2
                move    time(s)         move    time(s)         move    time(s) Vec/TRS
1.e2e4          e7e5    0,000           e7e5    0               e7e5      0.4    
2.g1f3          Nb8c6   0,006           Nb8c6   27,5            Nb8c6    17.0   62%
3.Bf1c4         Ng8f6   0,014           Ng8f6   58              Ng8f6    29.9   52%
4.Nf3g5         d7d5    0,014           d7d5    67              d7d5     36.0   54%
5.e4xd5         Nf6xd5  0,004           Nf6xd5  89              Nf6xd5   46.1   52%
6.Nb1c3         Qd8xg5  0,025           Qd8xg5  163,5           Qd8xg5   82.7   51%
7.Bc4xd5        Bc8g4   0,005           Bc8g4   70              Bc8g4    34.1   49%
8.Bd5xc6        b7xc6   0,006           b7xc6   25,5            b7xc6    11.8   46%
9.f2f3          Bg4e6   0,005           Bg4e6   63              Bg4e6    30.5   48%
10.Qd1e2        0-0-0   0,014           0-0-0   83              0-0-0    40.8   49%
11.Qe2a6        Kc8b8   0,000           Kc8b8   22              Kc8b8     9.6   44%
12.0-0          Bf8e7   0,016           Bf8e7   98              Bf8e7    47.6   49%
13.d2d4         Qg5f5   0,016           Qg5f5   82              Qg5f5    40.6   49%
14.d4xe5        Be7c5+  0,015           Be7c5+  85              Be7c5+   42.4   50%
15.Kg1h1        Qf5xe5  0,032           Qf5xe5  233             Qf5xe5  117.5   50%
16.Qa6xc6       Qe5d6   0,046           Qe5d6   247             Qe5d6   127.7   52%
17.Qc6xd6       Bc5xd6  0,004           Bc5xd6  45              Bc5xd6   21.4   48%
18.Bc1e3        Kb8b7   0,004           Kb8b7   55              Kb8b7    26.7   49%
19.Ra1d1        Be6c4   0,025           Be6c4   162             Be6c4    82.7   51%
20.Rf1e1        Rh8e8   0,014           Rh8e8   157,5           Rh8e8    80.2   51%
Total time              0,265                   1833                    925.6   50%
Average time            0,013                   91,7                     46.3    
Speed ratio                     6917                     1.98

                Sargon I UCI lv3        Sargon I TRS-80 lv3     Sargon I Vectrex lv3
                move    time(s)         move    time(s)         move    time(s) Vec/TRS
1.e2e4          e7e5    0,000           e7e5    0               e7e5      0.4    
2.g1f3          Nb8c6   0,095           Nb8c6   646             Nb8c6   333.7   52%
3.Bf1c4         d7d6    0,135           d7d6    904             d7d6    469.1   52%
4.Nb1c3         Bc8e6   0,187           Bc8e6   1063            Bc8e6   502.2   47%
5.Bc4xe6        f7xe6   0,114           f7xe6   722             f7xe6   374.6   52%
6.0-0           Ng8f6   0,125           Ng8f6   766             Ng8f6   399.5   52%
7.d2d3          d6d5    0,116           d6d5    729             d6d5    379.0   52%
8.Nf3g5         Qd8d6   0,154           Qd8d6   909             Qd8d6   474.9   52%
9.Nc3b5         Qd6e7   0,105           Qd6e7   629             Qd6e7   327.1   52%
10.Bc1e3        d5d4    0,135           d5d4    861             d5d4    451.7   52%
11.Be3d2        0-0-0   0,145           0-0-0   854             0-0-0   449.0   53%
12.a2a4         a7a6    0,157           a7a6    912             a7a6    477.5   52%
13.Nb5a3        h7h6    0,125           h7h6    809             h7h6    421.7   52%
14.Ng5f3        Qe7c5   0,145           Qe7c5   876             Qe7c5   457.5   52%
15.Qd1e2        Bf8d6   0,205           Bf8d6   1235            Bf8d6   647.0   52%
16.Na3c4        Kc8d7   0,185           Kc8d7   1184            Kc8d7   623.0   53%
17.b2b3         Rd8b8   0,254           Rd8b8   1547            Rd8b8   815.4   53%
18.c2c3         d4xc3   0,216           d4xc3   1349            d4xc3   711.3   53%
19.Bd2xc3       b7b5    0,455           b7b5    2718            b7b5    823.1   30%
20.a4xb5        a6xb5   0,236           a6xb5   1431            a6xb5   745.4   52%
Total time              3,289           20144                         9,883.1   
Average time            0,164           1007,2                          494.2  
Speed ratio                     6125                     2.04

[billforsternz]

Brilliant work. I have replied on Talkchess here http://talkchess.com/forum3/viewtopic.php?f=2&t=74027&p=889219#p889219

Bill.

On Thu, 8 Apr 2021 at 09:45, Phillip Eaton @.***> wrote:

Updated timings table for Level 2 and 3.

This time it was scripted from interactive Forth running real-time on the Vectrex with timings captured using TeraTerm log and manipulated with Excel.

            Sargon I UCI lv2        Sargon I TRS-80 lv2     Sargon I Vectrex lv2
            move    time(s)         move    time(s)         move    time(s) Vec/TRS

1.e2e4 e7e5 0,000 e7e5 0 e7e5 0.4 2.g1f3 Nb8c6 0,006 Nb8c6 27,5 Nb8c6 17.0 62% 3.Bf1c4 Ng8f6 0,014 Ng8f6 58 Ng8f6 29.9 52% 4.Nf3g5 d7d5 0,014 d7d5 67 d7d5 36.0 54% 5.e4xd5 Nf6xd5 0,004 Nf6xd5 89 Nf6xd5 46.1 52% 6.Nb1c3 Qd8xg5 0,025 Qd8xg5 163,5 Qd8xg5 82.7 51% 7.Bc4xd5 Bc8g4 0,005 Bc8g4 70 Bc8g4 34.1 49% 8.Bd5xc6 b7xc6 0,006 b7xc6 25,5 b7xc6 11.8 46% 9.f2f3 Bg4e6 0,005 Bg4e6 63 Bg4e6 30.5 48% 10.Qd1e2 0-0-0 0,014 0-0-0 83 0-0-0 40.8 49% 11.Qe2a6 Kc8b8 0,000 Kc8b8 22 Kc8b8 9.6 44% 12.0-0 Bf8e7 0,016 Bf8e7 98 Bf8e7 47.6 49% 13.d2d4 Qg5f5 0,016 Qg5f5 82 Qg5f5 40.6 49% 14.d4xe5 Be7c5+ 0,015 Be7c5+ 85 Be7c5+ 42.4 50% 15.Kg1h1 Qf5xe5 0,032 Qf5xe5 233 Qf5xe5 117.5 50% 16.Qa6xc6 Qe5d6 0,046 Qe5d6 247 Qe5d6 127.7 52% 17.Qc6xd6 Bc5xd6 0,004 Bc5xd6 45 Bc5xd6 21.4 48% 18.Bc1e3 Kb8b7 0,004 Kb8b7 55 Kb8b7 26.7 49% 19.Ra1d1 Be6c4 0,025 Be6c4 162 Be6c4 82.7 51% 20.Rf1e1 Rh8e8 0,014 Rh8e8 157,5 Rh8e8 80.2 51% Total time 0,265 1833 925.6 50% Average time 0,013 91,7 46.3 Speed ratio 6917 1.98

            Sargon I UCI lv3        Sargon I TRS-80 lv3     Sargon I Vectrex lv3
            move    time(s)         move    time(s)         move    time(s) Vec/TRS

1.e2e4 e7e5 0,000 e7e5 0 e7e5 0.4 2.g1f3 Nb8c6 0,095 Nb8c6 646 Nb8c6 333.7 52% 3.Bf1c4 d7d6 0,135 d7d6 904 d7d6 469.1 52% 4.Nb1c3 Bc8e6 0,187 Bc8e6 1063 Bc8e6 502.2 47% 5.Bc4xe6 f7xe6 0,114 f7xe6 722 f7xe6 374.6 52% 6.0-0 Ng8f6 0,125 Ng8f6 766 Ng8f6 399.5 52% 7.d2d3 d6d5 0,116 d6d5 729 d6d5 379.0 52% 8.Nf3g5 Qd8d6 0,154 Qd8d6 909 Qd8d6 474.9 52% 9.Nc3b5 Qd6e7 0,105 Qd6e7 629 Qd6e7 327.1 52% 10.Bc1e3 d5d4 0,135 d5d4 861 d5d4 451.7 52% 11.Be3d2 0-0-0 0,145 0-0-0 854 0-0-0 449.0 53% 12.a2a4 a7a6 0,157 a7a6 912 a7a6 477.5 52% 13.Nb5a3 h7h6 0,125 h7h6 809 h7h6 421.7 52% 14.Ng5f3 Qe7c5 0,145 Qe7c5 876 Qe7c5 457.5 52% 15.Qd1e2 Bf8d6 0,205 Bf8d6 1235 Bf8d6 647.0 52% 16.Na3c4 Kc8d7 0,185 Kc8d7 1184 Kc8d7 623.0 53% 17.b2b3 Rd8b8 0,254 Rd8b8 1547 Rd8b8 815.4 53% 18.c2c3 d4xc3 0,216 d4xc3 1349 d4xc3 711.3 53% 19.Bd2xc3 b7b5 0,455 b7b5 2718 b7b5 823.1 30% 20.a4xb5 a6xb5 0,236 a6xb5 1431 a6xb5 745.4 52% Total time 3,289 20144 9,883.1 Average time 0,164 1007,2 494.2 Speed ratio 6125 2.04

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/billforsternz/retro-sargon/issues/1#issuecomment-815284696, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSQYSW6QK2PKK35DLRBZZDTHTHABANCNFSM4RVBS5UA .

-- Bill Forster 15A Boundary Road Kelburn Wellington 6012 New Zealand +64 21 357 371 @.***

[phillipeaton]

Hi Bill,

I'm still plugging away on my 6809 Vectrex Sargon. I noticed that the original Z80 code prints O-O or O-O-O when the computer castles, but it doesn't when the player castles. (Same for en passant.) I looked at the code and EXECMV actions these 'double moves' on the screen. It sets flags in the B register for O-O/O-O-O, then CPTRMV uses B to display as necessary, but PLYRMV ignores B. I confirmed this using TRS-80 MAME.

I was wondering if you'd come across this and if you did anything about it, in your reimplemenation?

Additionally, I noticed that there is no recognition of stalemate, so I looked again at the review of Sargon II in Byte Magazine December 1980 and, sure enough, it's one of the things they implemented.

Another query...I'm finding hard to make Sargon take a pawn using en passant, do you have a test cases for this I could try? EDIT: I've worked out how to make Sargon 6809 play an en passant move now, but the taken pawn doesn't disappear from the board, I guess I have yet more debugging to do. I will also attempt to replicate on the TRS-80 version.

Regards, Phil