-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to set Level for Sargon using Tarrasch #1
Comments
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.
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 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! |
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::vectorstd::string 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). |
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! |
Good luck. (I also have a soft spot for Forth https://web.archive.org/web/20161130035955/http://stackoverflow.hewgill.com/questions/122/292.html |
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! |
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... |
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. 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.
Yes!
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.
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! 😉 |
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
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABSQYSW3W66UPHV6TELNNL3TG6TJVANCNFSM4RVBS5UA>
.
|
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...
|
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.
|
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
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABSQYSW6QK2PKK35DLRBZZDTHTHABANCNFSM4RVBS5UA>
.
--
Bill Forster
15A Boundary Road
Kelburn
Wellington 6012
New Zealand
+64 21 357 371
***@***.***
|
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, |
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!
The text was updated successfully, but these errors were encountered: