Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Smallest(?) 6502 chess program
2020-09-12 09:58
Rastah Bar

Registered: Oct 2012
Posts: 336
Smallest(?) 6502 chess program

A friend of mine pointed me out to https://nanochess.org/chess6.html

There is also a 6502 version https://github.com/nanochess/Atomchess-6502/blob/master/toledo_..

No unitended opcodes are used. Surely this can be further optimized.
F.e. lines 178+178 can be replaced by LAX #0, lines 189-191 by LAX #0, DEX, TXS

The loop in lines 193-196 can be replaced by
        ldx #$8b     ; ...copy in X
sr0:    sta 0,X      ; Save in address 0 plus X
        dex          ; Increment X
        bmi sr0      

So if you have some spare time and are looking for a nice little challenge ...
2020-09-12 10:50
iAN CooG

Registered: May 2002
Posts: 3132
> dex ; Increment X

now I'm confused =)
2020-09-12 11:03
Rastah Bar

Registered: Oct 2012
Posts: 336
Quote: > dex ; Increment X

now I'm confused =)


Sorry, i copied the original comments.
2020-09-12 14:12
JackAsser

Registered: Jun 2002
Posts: 1989
Quote: > dex ; Increment X

now I'm confused =)


Only valid if x=0. :)
2020-09-28 00:17
wil

Registered: Jan 2019
Posts: 42
The program looks interesting, is there known how well (ELO equivalent) it would play on a C64?


Replacing the original code lines
        ldx #$80     ; ...copy in X
sr0:    sta 0,X      ; Save in address 0 plus X
        inx          ; Increment X
        cpx #$8c
        bne sr0      ; Repeat until X is zero.

by the suggested version in the post should work, since there is this line afterwards
        tax          ; x is zero

thus the state of X and the NZ flags at the end of the loop do not matter because they get overwritten by the tax command. Carry could still be an issue, but it does not look like the program is counting on the carry being set after the loop.

Referring to the invalidated copied comment, the code can be shortened much further...




...by removing a lot of unnecessary comments. The program seems to be severely overcommented, probably addressing readers who are not familiar with the 6502 architecture.
2020-09-28 03:53
ChristopherJam

Registered: Aug 2004
Posts: 1378
TAX doesn't affect flags, but that's ok because the following code doesn't care what N or Z are anyway.

If we broaden the fill to cover the 80 bytes of board, then the loop in lines 200-212 only needs to set two bytes of every ten to '7', the rest will already be cleared. Hence, we can instead use something like
    ldx#80
:   lda#7
    sta board-10+8,x
    sta board-10+9,x
    txa
    sbx#10
    bne :-

- a reduction from 22 to 13 bytes.

Sadly the next routine then grows by a byte, as we no longer have 7 in A to use to initialise X.

But yes, plenty of scope for optimization in this one :)
2020-09-28 10:27
Rastah Bar

Registered: Oct 2012
Posts: 336
To be fair, the author is an x86 specialist and that version was ported to 6502.

@wil: Playing strength will be very weak. Nowhere near the strength of Colossus Chess. The program only allows promotion to a queen, so it is not even complete.

He has written as small chess program in C as well that is estimated to have a strength "something around 1400 (level 1) to 1600 ELO (level 3)."
https://nanochess.org/chess2.html
2020-09-28 11:07
ChristopherJam

Registered: Aug 2004
Posts: 1378
Oh no shade intended against the author. It's an impressive feat that it even exists, especially given the author's background.
2020-09-28 11:38
Rastah Bar

Registered: Oct 2012
Posts: 336
Yes, very impressive! But I could have stressed that a bit more in my original post. The author has won several IOCCC competitions, so definitely a top-knotch coder.
2020-09-28 15:45
wil

Registered: Jan 2019
Posts: 42
Quote: TAX doesn't affect flags, but that's ok because the following code doesn't care what N or Z are anyway.

If we broaden the fill to cover the 80 bytes of board, then the loop in lines 200-212 only needs to set two bytes of every ten to '7', the rest will already be cleared. Hence, we can instead use something like
    ldx#80
:   lda#7
    sta board-10+8,x
    sta board-10+9,x
    txa
    sbx#10
    bne :-

- a reduction from 22 to 13 bytes.

Sadly the next routine then grows by a byte, as we no longer have 7 in A to use to initialise X.

But yes, plenty of scope for optimization in this one :)


TAX (and the other transfer commands) affect the N and Z flags.

For example:

   lda #00 ;Z flag is set after this command
   ldy #01 ;Z flag is cleared after this 
   tax     ;Z flag is set again
2020-09-28 18:21
ChristopherJam

Registered: Aug 2004
Posts: 1378
*checks reference guides.. writes test code too..*

Wait, I do apologize, you are indeed correct.

How embarrassing. Not sure how that misapprehension on my part hasn't bitten me in the past 30 years, but anyway. Still, hopefully some new code optimization opportunities now lie in my future, thank you :)
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
DjS/Silicon Ltd
kbs/Pht/Lxt
Dymo/G★P
katon/Lepsi De
Smasher/F4CG
Peiselulli/tRSi
Airwolf/F4CG
Honesty/Covenant/Ons..
K-reator/CMS/F4CG
megasoftargentina
Exile/Anubis
Guests online: 161
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 The Ghost  (9.6)
9 Wonderland XIV  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 It's More Fun to Com..  (9.8)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 Rainbow Connection  (9.5)
6 TRSAC, Gabber & Pebe..  (9.5)
7 Onscreen 5k  (9.5)
8 Wafer Demo  (9.5)
9 Dawnfall V1.1  (9.5)
10 Quadrants  (9.5)
Top Groups
1 Oxyron  (9.3)
2 Nostalgia  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top NTSC-Fixers
1 Pudwerx  (10)
2 Booze  (9.7)
3 Stormbringer  (9.7)
4 Fungus  (9.6)
5 Grim Reaper  (9.3)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.045 sec.