1978 Sargon available as uci

[Tibono2]

Hi Michael,
Nice, thanks for sharing.
Warm regards,
Eric

[BillForster]

Indeed there's a castling bug in the included SARGON.COM, I finally found it and fixed it.

Andre Adrian's code:

Code: Select all

CP10:	BIT	1,B 		; King side castle ?
	JRZ	.+11 		; No - jump
	PRTBLK	O.O,5 		; Output "O-O"
	JMPR	CP1C 		; Jump
	BIT	2,B 		; Queen side castle ?
	JRZ	.+11 		; No - jump
;X p74	
	PRTBLK	O.O.O,5		;  Output "O-O-O"
	JMPR	CP1C		; Jump
	PRTBLK	P.PEP,5		; Output "PxPep" - En passant

It's a relative jump bug. Bill Forster seems to have found the bug too, converting the relative value to absolute adresses:

Code: Select all

CP10:   BIT     1,b             ; King side castle ?
        JR      Z,rel020        ; No - jump
        PRTBLK  O_O,5           ; Output "O-O"
        JR      CP1C            ; Jump
rel020: BIT     2,b             ; Queen side castle ?
        JR      Z,rel021        ; No - jump
        PRTBLK  O_O_O,5         ; Output "O-O-O"
        JR      CP1C            ; Jump
rel021: PRTBLK  P_PEP,5         ; Output "PxPep" - En passant

To fix it, just use a hex-editor and change the 2 bytes of SARGON.COM, or get the attached version.

Code: Select all

Offset:	Was:	Should Be:
1CAF	09	0E
1CC1	09	0E

Sargon Jupiter Regards
Michael

I am obviously very late to this, I just discovered it the other day while wondering whether I should do any more with my Sargon 1978 project. Anyway, I couldn't quite follow the explanation above, so I dug into it to satisfactorily explain it to myself, and for completeness sake I will share my findings here. I should warn up front that if you have no interest in Z80 assembly language programming this won't be very interesting!

Here is the code under discussion above after I converted it to standard Z80 assembly language and assembled it, from the complete listing on my Github repository at https://github.com/billforsternz/retro- ... on-z80.lst;

Code: Select all

1B57  CB48    	CP10:   BIT     1,b             ; King side castle ?
1B59  2809    	        JR      Z,rel020        ; No - jump
1B5B  FFB31AB6	        PRTBLK  O_O,5           ; Output "O-O"
      180500
1B62  1814    	        JR      CP1C            ; Jump
1B64  CB50    	rel020: BIT     2,b             ; Queen side castle ?
1B66  2809    	        JR      Z,rel021        ; No - jump
1B68  FFB31ABB	        PRTBLK  O_O_O,5         ; Output "O-O-O"
      180500
1B6F  1807    	        JR      CP1C            ; Jump
1B71  FFB31A3F	rel021: PRTBLK  P_PEP,5         ; Output "PxPep" - En passant
      190500
1B78  3A2100  	CP1C:   LD      a,(COLOR)       ; Should computer call check ?

What is this purpose of this code? It is part of the routine that translates a chess move from internal machine representation into something human readable. This code runs only if the move concerned is definitely either castling or en-passant. So the code first checks for the most common case, king side castling. If it's not king side castling it jumps, otherwise it prints "O-O" and jumps to the next stage of the process (testing whether the move is a check). If it's not king side castling, it checks for queen side castling. If it's not queenside castling it jumps, otherwise it prints "O-O-O" and jumps to the next stage of the process. If it's not either type of castling then it must be en-passant, so it prints "PxPep" without further ado (this is actually ambiguous in very rare cases [two different pawns can take en-passant sometimes], but we won't worry about that).

In my project I had no use for the two jump destinations ".+11" in the Spracklen's original code. I don't know why they chose to express the jumps that way, it's just a very retro, very awkward and mistake prone approach. As a jump destination this means "go 11 bytes forward". The first time this is used we are jumping from 1b59 to 1b64, and if you can do hex arithmetic you'll be able to see this really is +11 (decimal - i.e eleven) bytes. In the machine code the number is not actually expressed as 11, it's 9 because the Z80 discounts the two bytes used by the jump instruction itself (we are really getting into the weeds!). This is important - ultimately in bataais's patch it is the two instances of 09 (each encoding +11) that are patched to something else.

Andre Adrian could afford to continue using this retro ".+11" approach throughout, because he was still running Z80 machine code. But I wanted to translate to Intel x86 code, and these absolute fixed numbers are useless to me as they are going to be different for the Intel processor. So I eyeballed every instance like this in the Spracklens' code and converted it to a more conventional, modern, dare I say sensible approach. I worked out where I thought the jump was going, by trying to understand the code and also by using my knowledge of how many bytes each Z80 instruction actually took. Then I put a label at the destination and jumped to the destination instead of some absolute number of bytes. Note these are still relative jumps, not absolute jumps as implied in the post I am responding to. I didn't craft fancy labels, I just used rel001, rel002, rel003 etc. In the code snippet above you can see rel020 and rel021.

Actually, once I had the Z80 code assembling successfully I went back and methodically checked each instance to make sure I had eyeballed everything correctly.

Perhaps if you have been following along carefully you will see what has happened, why there was a problem in Andre Adrian's Sargon.com that needed to be patched. The retro ".+11" works well enough for the original Z80 code, and for the emulated code as long as nothing changes between the jump and the jump destination. But for the two jumps in this code Andre Adrian is jumping around the PRTBLK macro and clearly his PRTBLK macro has been adjusted to serve the needs of his project. He needed to adjust the jump destinations appropriately and he didn't do that. The two patches from 09 -> 0e (hex) stretch out the jumps from 9 to 14 bytes, so we can infer that Andre's PRTBLK macro is 5 bytes longer than the Spracklens' PRTBLK macro. Note that I didn't fix a bug in the Spracklens' code (as implied by the post I am replying to). The bug was introduced in the Sargon.com emulation.

Without the patches, all is well until either O-O-O or PxPep is played. If O-O is played neither of the problematic jumps occur. In my test game Black did play O-O-O and Sargon.com crashed, because JRZ .+11 did jump right into the middle of the PRTBLK macro rather than around it as intended.

Phew! I hope this is of interest to someone, sometime.

[RollingRook]

It seems to run Sargon Engine you need to have installed the Visual BASIC runtime?

For some reason I was able to run it from Fritz 12 on one computer and not on another two. I am not sure if I installed the VB runtime on the first one.

[BillForster]

It seems to run Sargon Engine you need to have installed the Visual BASIC runtime?

For some reason I was able to run it from Fritz 12 on one computer and not on another two. I am not sure if I installed the VB runtime on the first one.

Sorry I never thought about this possible problem. It's the Visual C++ runtime (not the Visual Basic runtime). Anyway, I've just added a static link version as a Github release here -> https://github.com/billforsternz/retro- ... c-link.exe

Basically this version is self contained and doesn't rely on any Visual C++ DLLs. I've always built my Tarrasch GUI .exe that way, I wish I'd thought about the issue earlier.

[RollingRook]

Oh thank you Bill!

I only just saw this message.

Many thanks for your great efforts on this!