Page 2 of 4

Re: ChesSkelet: micro chess program - 363 Bytes

Posted: Mon Jun 03, 2019 9:01 am
by arkannoyed
reeagbo wrote: Sun Jun 02, 2019 10:51 am
reeagbo wrote: Fri May 31, 2019 10:59 pm Let me look into it. I'll let you know. Any help is more than welcome. :-)
I took your idea and with a little tuning it seems to make things even smaller:

Code: Select all

	; compensate + prioritize piece valuation(6B)
skiato	ld h, $20		; prepare H for later rotation and use for A
	add a, h		; A: 00pppppp, compensate=K+1, pih				      					       
	rlca			; leave space for square weight
	rlca			; A: pppppp00, piece addition is 5 bits
	ld b, a			; B: piece addition value
evacol	ld a, e			; A: 0rrr0ccc
	; these two values below can be tuned for different opening schemes
	if feamod>0
		add a, 2		; A: 0rrr0ccc
		and 5			; A: 00000ccc
	else
		inc a			; A: 0rrr0ccc
		and 4			; A: 00000cc0 (weight: 0,0,0,4,4,4,4,0)
	endif

	; ranks weight (ranks weight is 8..1, aiming for board's end)
evarnk	add hl, hl		; HL: 00100000 0rrr0ccc (before)
	add hl, hl		; 
	add hl, hl		; HL: 000000rr r0ccc000 (after)
	sub h			; A:  00000cww (w=r+c)
	add a, b		; total value: pieces + weight
Many thanks! This is from now on the arkannoyed patch!

:-)

That’s awesome!!!

Re: ChesSkelet: micro chess program - 363 Bytes

Posted: Mon Jun 03, 2019 9:02 am
by arkannoyed
reeagbo wrote: Sun Jun 02, 2019 10:55 am Maybe we can still cross the 350 bytes line! :P

One general question. I´m sure some of the folks in the forum can help: how do I get ChesSkelet included in ZXDB?
Twist R-tapes arm, he’ll get you in!!

Re: ChesSkelet: micro chess program - 363 Bytes

Posted: Mon Jun 03, 2019 10:19 am
by arkannoyed
So Alex, what size is it down to now for the super small version?

Re: ChesSkelet: micro chess program - 363 Bytes

Posted: Mon Jun 03, 2019 2:48 pm
by reeagbo
Chapter 7: Move list generation (II)

Here comes the very announced "movlis" routine, which is the longest and more complex routine in the program. What does it do? Independently of the side moving, "movlis" generates a list with all the potential moves the side moving can make. Once again, remember that the program is reversing the board after every move so that white pieces are always moving. Making every routine to work for both sides would be a nightmare and reversing the board takes only a few bytes.

When human side moves, the list generated is optionally used to determine if the move typed is valid or not. When black pieces move, the list is used to evaluate each and every move and decide which one is best.

All of the above was implemented since the beginning. When I introduced the idea of having the attacked squares board I noticed that I could reuse all the code with a minimum change, so in parallel to generating the candidate move list it updates the attacked squares board.

Now, fasten your seat belts and let's dive into "genlis".

Code: Select all

genlis
bacata	; backup attack board in reverse order, used in evaluation (13B)
	ld l, $FF		; (H)L = $80FF (boaata-1), H always $80 
	ld de, boaopo + $78	; DE: same thing, 1B passed end of board
bacloo	inc hl			; HL: increase 16b counter to hop to next page
	dec e			; E:  decrease 8b counter to hit Z flag
	ld a, (hl)		; load attack status
	ld (hl), 0		; clear attack status, no alternative!
	ld (de), a		; backup attack status
	jr nz, bacloo		; loop down to square $00
				; exit values: DE=$8200, HL=$8177
Before looking into this section, I need to explain how the reverse squares board works. I had to do it in two steps: there is a attacked squares board, but this board is not reversed simultaneously with the game board. Not only that. It has to be reversed so that it can be used during move evaluation, but also it has to be reset so that I can generate a new one for the next side moving. It would make sense to do it sequentially, but it would take more code, so we actually have two attacked square boards: the one which is generated and the reverse one used for move evaluation.

In the code above, I'm copying the first one reversed into the second and resetting the first board, so that "genlis" can fill it again during the new list of moves generation. It is actually a simple loop. This would be again a show-off for programmers trying to find the shortest way to implement it. In my case, I take advantage of the fact that the two attacked square boards live in contiguous mini pages, so setting HL and DE properly becomes very simple.

Code: Select all

	; prepare environment (4B)
	inc d			; D= $83= canlih
	xor a			; reset
	ld (de), a		; cantot= 0
	ld b, l			; B= L = 77, SQUARE COUNT
We are now in the preparations area. DE will point at the mini page where the candidate moves will be stored and the number of them is set to 0. It's the first byte in the page. We also load B with the last square in the board (77H = 01110111b). The main loop (outer loop) will use B and will countdown through the board.

I´m going to use an example with a Bishop in A1. We´ll follow the code with it.

Code: Select all

	; read piece from board (4B)
squloo	ld h, boasth		; H: board base ++
	ld l, b			; point at current loop square
	ld a, (hl)		; read piece from board
	
	; get move type and pointer to move list (6B)
squgon	dec h			; H(L)= movlih, moves vector base ++
	add a, a		; x4, each piece vector is 4B long
	add a, a		;	
	ld l, a			; (H)L points at the move vector now
We are entering the main loop. We will see that the register usage is pretty tight. This is why I'm pushing registers all the time to free them for use in inner loops.

As we did in previous chapters we´ll discuss the special moves separately, to avoid distractions from the main routine.

We'll start by reading the piece from the board. With the piece value we are ready to see in which directions the piece can move, as we saw when discussing the static data associated to this. We´ll multiply the piece value by four and that will leave HL pointing at the "move type" linked to the piece. This move type contains: the special Pawn move flags, the move radius and a pointer to the direction the piece can go.

I know this is becoming a little tricky...

Bishop: the big loop will count down reading all the squares to 70h (A1 is rank 7, column 0, therefore byte 70h in memory). It will find our white Bishop in 70h. This is 24h (reminder: 20h is white and 04h is the piece value for the Bishop).

Code: Select all

	ld d, 2			; 2 submoves per piece
subloo		; byte 1 - move type (5B)
		ld a, (hl)		; move type loaded
		or a			; =cp 0, 2nd move type not used case
					; black/empty: move type=0 leads here
		jr z, squexi		; ---v exit: square is done
		ld e, a			; E: MOVE TYPE (B,C,D used here)
	
		; byte 2 - movlis delta (3B)
		inc hl			; next piece sub-entry
		push hl			; Save HL for 2nd loop	
		ld l, (hl)		; pointer to move delta
For each piece in each square we have a two iterations loop (middle loop), as each piece may have one or two types of moves. Rooks, Bishops, Pawns, and Knight have one type of move (meaning 1 direction). King, Queen and Pawns have two (they combine straight and diagonal). In the first place, the exit condition: if the move type is 0 it means that we are done with the piece, either with one or two types of moves. Also, code for empty sqaures ends up here, so the same code is used for both exit conditions.

We load the move type in E. Then we jump to the next byte in the move type which is the pointer to the move delta (second block of data described in the previous chapter).

Bishop: this is the data block corresponding to the Bishop:

Code: Select all

bisgen	defb	$0E, $E5	; bishop
0Eh means: 0xh non special move, xEh is the radius, meaning it can reach 7 moves in each direction (remember I add 7 to the radius for code economy, that's why we have 0Eh=14d).
E5h is the pointer to the move vectors, the deltas applied to calculate moves in each direction. Don't abandon yet, we´ll see how it goes in a minute.

Code: Select all

vecloo			; vector read (8B)
			ld c, b		; TARGET SQUARE init
			ld a, (hl)	; vector delta
			or a		; =cp 0
			jr z, vecexi	; ---v exit: vectors end with 0, next sq.
			push hl		; save current delta
			push de		; save move type + radius
					; E: variable radius within loop
			ld d, a		; D: store delta within loop
Now we take the current square (remember, squares are covered by the big loop) and add the delta that goes to the next square the piece can move to. The exit condition here is again having a delta=0. We push all DE and HL to free them and we store the new square calculated in D. We are going to use it on every iteration to calculate the new target.

Bishop: The Bishop can only move in one direction. We'll see how the OOB moves are detected in a minute.

Code: Select all

org $7FE5
diavec	defb   	$0F, $11	; +5, diagonal vectors
	defb  	$EF, $F1	; +7, diagonal pawn
From A1 it can only go in the B2 direction. This is from 70h to 61h. If you see 70h + F1h= (1)61h. Bit 9 is lost so we keep 61h. The other three vectors will give us out of the board squares.

Code: Select all

celloo				; prepare x88 check (7B)
				ld a, d		; delta loaded
				add a, c	; current target (sq. + delta)
				ld c, a		; current target
				and $88		; 0x88, famous OOB trick
				jr nz, vecnex	; ---v exit: OOB, next vector
			
				; read target square (3B)
				inc h		; H(L)= $80 = boasth ++
				ld l, c		; point at target square			
				ld a, (hl)	; read target square content

				; mark attacked ### str. pawn marked attacked
					inc h		; H(L)= $81 = boaath ++
					ld (hl), h	; mark attacked ($81)
					dec h		; H(L)= $80 = boasth ++
					
				dec h		; H(L)= $79= movlih ++
Here we start the inner loop, that will visit all the squares a piece can move to in a particular direction. There is no specific exit condition for this loop, as it can be exited fir different reasons that we´ll explore later.

Now we add the delta plus the current square into A. If we have either bit3 or bit7 set to one, it means that the calculated target square is OOB. You can try at home but it works. The logic here is that any board square has ranks and columns between 0 and 7. Therefore, valid ranks can go from 0000xxxx to 0111xxxx, and valid columns can go from xxxx0000 to xxxx0111. AND 88h will detect that for us. Incredibly simple. If it's not a valid target square to move to, we´ll jump to the next vector for that type of move.

If it is a valid move, we´ll read the target square to see what's in there. And we also mark that square as attacked in the attacked squares board. This introduced a little inconsistency, since straight pawn moves have the target squares I did not marked as attacked although the Pawn cannot capture going straight. It does not result in illegal moves, but makes the computer a little shy since it won´t move in front of Pawns as those squares are not safe. I did not find a simple solution to this, so there it is.

Code: Select all

				dec h		; H(L)= $79= movlih ++
				; target is white (4B)
				bit 5, a	; is it white?, pih
				jr nz, vecnex	; ---v exit: WHITE b4=1, next vector

				; target not white (3B)
				or a		; =cp 0, is it empty?, pih
				jr z, taremp	; if not 0, it's black: legal, no go on
					
tarbla				; target is black (7B)
				bit 5, e	; special move: pawn straight check
				jr nz, vecnex	; ---v exit: no straight capture, next vector
				ld e, a		; make radius=0 (=<8 in code, canonical: ld e, 0)
				call legadd	;
				
taremp				; target is empty (14B)
				bit 4, e	; special move: pawn on capture check
				jr nz, vecnex	; ---v exit: no diagonal without capture, next vector	  
				dec e		; decrease radius
legadj
				bit 3, e	; if radius < 8 (Cb3=0), radius limit
				jr nz, celloo	; ---^ cell loop

This is an interesting part. Depending on the target square content, we´ll do different things. Following the sequence:
  • if the target is white we cannot move there and we cannot move in this direction anymore, so we skip to the next vector, to test other directions.
  • if the target is black, we stop moving in that direction (by making radius <8) and we add the move to the legal move list. There is a special case: if it's a pawn moving straight, as it cannot capture we skip adding the move and we go to the next vector.
  • if the target is empty, we will add the move to the legal move list, and we´ll decrease the radius by one (E register), so that we can go on testing squares in this direction. There is also a special case: if it's a pawn moving diagonal we´ll skip addition since it cannot move without capturing.
Last thing we do is to check radius: if it's still positive (bigger that 7 in the code) we can week moving in that direction, so we go back to "cello" tag.

Bishop: in the case of the Bishop in A1 moving to B2 (empty), we´ll add the move to the list, the original 0Eh radius will be decreased, and the inner cell loop will be run again, but now with radius one square smaller, and the base square will be B2 (61h) instead of A1.

Code: Select all

		
vecnex			; next vector preparation (5B)
			pop de		; DE: recover move type + radius
			pop hl		; HL: recover current vector
			inc hl		; HL: next vector
			jr vecloo	; ---^ vector loop
This is the boring part of the code where not much happens. We recover old values from the stack that we need to use at this point. Theoretically, this inner loop is repeated forever until one of the many exit conditions occurs.

Code: Select all

vecexi	; next square preparation (5B)
	pop hl			; HL: recover pointer to sub-move list
	inc hl			; HL: next byte, point at 2nd sub-move
	dec d			; 2 sub-move iterations loop control
	jr nz, subloo		; if not 2nd iteration, repeat loop
	; end of loop (2B)		
squexi	djnz squloo		; ---^ squares loop
	ret
We keep on recovering data from the stack as we leave the inner loop.

We go to the 2nd sub-move, which in the case of the bishop does not exist. After the second iteration we would exit the middle loop.

Finally we decrease the global square counter, which count down to 0 (DJNZ). For those who noticed it, the outer loop will go through the unused help of the 16x8 board too, but since these squares are empty, nothing will happen for them.

Here ends the main code. There are two optional sections for special moves. In both cases, this routine was the best place to implement it as here is where the legal moves are identified.

Code: Select all

	kincas	ld l, a		; save A (can't use push AF, flags lost)
		add a, b	; A: 0rrr0xxx + 000ppppp (uncolored white p.)
		cp $AA		; king($36) at E1($74)= $AA, pih
		ld a, l		; recover A
		jr nz, kinend	; if no match, skip adding legal move
	
		ld c, $72	; E1-C1 move, rook's move missing
		call legadd	; add king's move
		ld c, $76	; E1-G1 move, rook's move missing
		call legadd	; add king's move and go on with king's moves
	kinend
The first one is covering castling. It's a big cheat, but I combine the current square and the piece in the square. If it is a white king (36h) in E1 (74h) we´ll add the two possible king moves for castling to the legal move list (E1-C1, E1-G1). We already was the Rook's part, which is executed only if one of these King's moves is made.

Code: Select all

		genpw2	add a, b	; piece square + move type
			and %11111000	; masked with relevant bits
			cp $88		; $28(str.pawn)+$60(rnk 6) ### univocal
			jr nz, skppw2	; if not, skip
			inc e		; increase radius: 1 -> 2
		skppw2
For the pawn moving 2 squares forward. Same process I typically use: in this case I will combine the rank (it has to be in rank 6, therefore 60h) and the move type (28h, for straight pawn). If it's a match, I just increase the radius for this straight move to 2. Simple, isn't it?

Still alive? Anybody there? As I said this part is pretty heavy.

One general request, if you have the time. I'm planning to put all the chapters together and add them to the website, so if you think any of the sections or paragraphs is particularly cryptic, let me know and I will re-write it.

Thanks very much if you managed to read it all!

Re: ChesSkelet: micro chess program - 363 Bytes

Posted: Mon Jun 03, 2019 3:49 pm
by arkannoyed
Intense!! :o

Re: ChesSkelet: micro chess program - 363 Bytes

Posted: Mon Jun 03, 2019 4:09 pm
by reeagbo
arkannoyed wrote: Mon Jun 03, 2019 3:49 pmIntense!! :o
There is no other way, I guess. :D

Re: ChesSkelet: micro chess program - 363 Bytes

Posted: Mon Jun 03, 2019 9:00 pm
by Pegaz
I cant follow this, but I can admire you and arkannoyed. :)

Re: ChesSkelet: micro chess program - 363 Bytes

Posted: Tue Jun 04, 2019 9:35 am
by arkannoyed
It may seem incredibly difficult, but its nothing more than a case of carefully going through parts of any routine and working out the mechanics of whatevers going on. Then armed with that info its possible to find more efficient ways of achieving the same goal.

Re: ChesSkelet: micro chess program - 363 Bytes

Posted: Tue Jun 04, 2019 1:34 pm
by Morkin
arkannoyed wrote: Tue Jun 04, 2019 9:35 am It may seem incredibly difficult, but its nothing more than a case of carefully going through parts of any routine and working out the mechanics of whatevers going on. Then armed with that info its possible to find more efficient ways of achieving the same goal
...you missed out the "with a maniacal obsession" part... :lol:

Just joking obviously, it'll be great to see the eventual collision between graphics and code. 8-)

Re: ChesSkelet: micro chess program - 363 Bytes

Posted: Tue Jun 04, 2019 1:43 pm
by arkannoyed
Morkin wrote: Tue Jun 04, 2019 1:34 pm
arkannoyed wrote: Tue Jun 04, 2019 9:35 am It may seem incredibly difficult, but its nothing more than a case of carefully going through parts of any routine and working out the mechanics of whatevers going on. Then armed with that info its possible to find more efficient ways of achieving the same goal
...you missed out the "with a maniacal obsession" part... :lol:

Just joking obviously, it'll be great to see the eventual collision between graphics and code. 8-)
Well, yeah, that too. Best avoided, but I know only too well that if I obsess over saving a byte somewhere, when the code just looks 'wrong' it can become a bowel shatteringly intense experience :lol:

Re: ChesSkelet: micro chess program - 363 Bytes

Posted: Thu Jun 06, 2019 11:26 am
by arkannoyed
Just wondering if it needs to be the case in this routine that you don't apply the result into L directly as opposed to C then L. Does it need to be saved into C for use elsewhere, as I can't find it.

Code: Select all

celloo				; prepare x88 check (7B)
				ld a, d		; delta loaded
				add a, c	; current target (sq. + delta)
				ld c, a		; current target [does the result need to go into C?]
				and $88		; 0x88, famous OOB trick
				jr nz, vecnex	; ---v exit: OOB, next vector
			
				; read target square (3B)
				inc h		; H(L)= $80 = boasth ++
				ld l, c		; point at target square [could the result of ld a,d, add a,c go straight into L?]		
				ld a, (hl)	; read target square content

				; mark attacked ### str. pawn marked attacked
					inc h		; H(L)= $81 = boaath ++
					ld (hl), h	; mark attacked ($81)
					dec h		; H(L)= $80 = boasth ++
					
				dec h		; H(L)= $79= movlih ++
Might be missing something though, as is often the case. :?

Re: ChesSkelet: micro chess program - 363 Bytes

Posted: Thu Jun 06, 2019 2:59 pm
by reeagbo
arkannoyed wrote: Thu Jun 06, 2019 11:26 am Just wondering if it needs to be the case in this routine that you don't apply the result into L directly as opposed to C then L. Does it need to be saved into C for use elsewhere, as I can't find it.

Code: Select all

celloo				; prepare x88 check (7B)
				ld a, d		; delta loaded
				add a, c	; current target (sq. + delta)
				ld c, a		; current target [does the result need to go into C?]
				and $88		; 0x88, famous OOB trick
				jr nz, vecnex	; ---v exit: OOB, next vector
			
				; read target square (3B)
				inc h		; H(L)= $80 = boasth ++
				ld l, c		; point at target square [could the result of ld a,d, add a,c go straight into L?]		
				ld a, (hl)	; read target square content

				; mark attacked ### str. pawn marked attacked
					inc h		; H(L)= $81 = boaath ++
					ld (hl), h	; mark attacked ($81)
					dec h		; H(L)= $80 = boasth ++
					
				dec h		; H(L)= $79= movlih ++
Might be missing something though, as is often the case. :?
Very good one. I had a quick glance and it seems like we could save a byte there. As you say we could (in theory) use L directly instead of C. Let me test it and I´ll get back early next week. We would need to start changing thing ever before, from celloo tag and on.

Alex

Re: ChesSkelet: micro chess program - 363 Bytes

Posted: Thu Jun 06, 2019 3:20 pm
by arkannoyed
Do you have any projection yet as to what sort of size its going to be down to now? Sub 350 bytes?

Re: ChesSkelet: micro chess program - 363 Bytes

Posted: Thu Jun 06, 2019 8:37 pm
by reeagbo
arkannoyed wrote: Thu Jun 06, 2019 3:20 pm Do you have any projection yet as to what sort of size its going to be down to now? Sub 350 bytes?
Best case would be 351,but I need to verify this last change. "genmov" is very sensitive to changes. It took me ages to make it work.

Re: ChesSkelet: micro chess program - 363 Bytes

Posted: Sat Jun 08, 2019 7:09 am
by hitm4n
Do it gently and it'll slide in...

Re: ChesSkelet: micro chess program - 363 Bytes

Posted: Tue Jun 11, 2019 9:01 am
by reeagbo
reeagbo wrote: Thu Jun 06, 2019 2:59 pm
arkannoyed wrote: Thu Jun 06, 2019 11:26 am Just wondering if it needs to be the case in this routine that you don't apply the result into L directly as opposed to C then L. Does it need to be saved into C for use elsewhere, as I can't find it.

Code: Select all

celloo				; prepare x88 check (7B)
				ld a, d		; delta loaded
				add a, c	; current target (sq. + delta)
				ld c, a		; current target [does the result need to go into C?]
				and $88		; 0x88, famous OOB trick
				jr nz, vecnex	; ---v exit: OOB, next vector
			
				; read target square (3B)
				inc h		; H(L)= $80 = boasth ++
				ld l, c		; point at target square [could the result of ld a,d, add a,c go straight into L?]		
				ld a, (hl)	; read target square content

				; mark attacked ### str. pawn marked attacked
					inc h		; H(L)= $81 = boaath ++
					ld (hl), h	; mark attacked ($81)
					dec h		; H(L)= $80 = boasth ++
					
				dec h		; H(L)= $79= movlih ++
Might be missing something though, as is often the case. :?
Very good one. I had a quick glance and it seems like we could save a byte there. As you say we could (in theory) use L directly instead of C. Let me test it and I´ll get back early next week. We would need to start changing thing ever before, from celloo tag and on.

Alex
Hi,

I was looking into your proposition, and unfortunately it won't fly. C is used to store the target square and it's used later:

Code: Select all

				; add candidate (B: current square, C: target square) (9B)
					push hl
					ld hl, canlis	; HL: start of candidate list. No H reuse ++
					inc (hl)	; +2 to candidate counter to move to next
					inc (hl)	; first free position in list
					ld l, (hl)	; point at free position
	
					ld (hl), b	; 1) save origin square
					inc hl		; move to next byte
					ld (hl), c	; 2) save dest square					
legend					pop hl		; recover HL=pointer to vector list
As you can see it's not possible to use L instead, as L is already used down here. I thought of using DE, but DE is not an option to replace HL, since some of the instructions do not exist. :-( Thanks for trying anyway. It looked very good.

Alex

Re: ChesSkelet: micro chess program - 363 Bytes

Posted: Tue Jun 11, 2019 9:46 am
by arkannoyed
Back to the Drawing Board eh? Never mind. When everything is so tightly stressed, you have to explore even the most abstract concepts to try and achieve a smaller size. Obsessing over saving even one byte becomes the norm.

Re: ChesSkelet: micro chess program - 363 Bytes

Posted: Thu Jun 13, 2019 7:07 pm
by reeagbo
After some lazy days, I've managed to put together all the dissection entries and create a single article with the whole thing, revised and cleaned up a bit. Those who need to get depressed, look here:
http://chesskelet.x10host.com/dissection.html

It's like a 50 page word document for a bunch of bytes. It can't get more ridiculous.

I was watching this documentary on how AlphaGo was developed and managed to beat the World Champion. It reminds me so much of what we do here that thought "I have to post this":
https://www.netflix.com/title/80190844

:lol: :lol: :lol: :lol:

Re: ChesSkelet: micro chess program - 363 Bytes

Posted: Fri Jun 14, 2019 8:38 am
by arkannoyed
The lengthy write up is actually much easier to read than what you posted on here, mostly I think because the code snippets are clearer to read. Having it all in one go is much nicer to read. Thanks for the mention too! ;)

Really good read.

Re: ChesSkelet: micro chess program - 363 Bytes

Posted: Sat Jun 15, 2019 10:19 am
by reeagbo
ChesSkelet v0.811 released. 352 bytes for the smallest version!

All details in http://chesskelet.x10host.com/

Have a good weekend.
Alex

Re: ChesSkelet: micro chess program - 363 Bytes

Posted: Thu Dec 05, 2019 8:12 am
by reeagbo
Hi all,

I know it's kind of unorthodox, but I need to contact Arkannoyed and he's not responding private messages or tweets. Anybody who know any other way to contact him?

Thank you!
Alex

Re: ChesSkelet: micro chess program - 363 Bytes

Posted: Thu Dec 05, 2019 10:30 am
by Ast A. Moore
Life’s complicated. We’ve had plenty of people in the community going off the grid for a while. I don’t have any of his contacts, but it won’t hurt tagging him in a post like so: [mention]arkannoyed[/mention].

Who knows what his forum settings are; maybe he doesn’t receive notifications for private messages but does when he’s mentioned directly.

Re: ChesSkelet: micro chess program - 363 Bytes

Posted: Thu Dec 05, 2019 6:42 pm
by arkannoyed
Ello?!

Sorry, seems I’ve been very uncommunicative of late. Been busy with new job and don’t get time to do what I love with speccy things any more. I’m at your service Sir! :)

Re: ChesSkelet: micro chess program - 363 Bytes

Posted: Fri Jan 03, 2020 10:09 am
by Alone Coder
Any chance to port this to Spectrum? https://habr.com/ru/post/478240/
https://github.com/leanchess/leanchess/ ... ter/LC.ASM
It searches moves in depth.

Re: ChesSkelet: micro chess program - 363 Bytes

Posted: Thu Apr 16, 2020 7:19 pm
by reeagbo
Hi Alone Coder,

Arriving like 4 months late. Sorry, I´ve been away for a while. Ok, I know about Leanchess, and it did not occur to me the idea of porting it to Spectrum. That would be a super piece of work. Leanchess is made for 8086 and that is really a great advantage vs. Spectrum program. THe guy who did it really took the best of both worlds.It´s 8 bits, which is perfect for microchess, but the instruction set is way bigger than the Z80's. Imagine, there is one instruction to push all registers to the stack. How many instructions takes to do that in Z80? 8 minimum.

Part of the porting may not be so difficult, but I´m sure that some segments need many more instructions than in the 8086. Also,I don´t feel like getting into the guts of this other program. If you know someone who takes this, let me know.

Alex