Zach's Projects

I have played chess for a long time and only seen the 3 move repetition rule used once.  As long as people know it's not part of the game's makeup I don't think it's a huge deal if you leave it out.  Maybe you could spit out notation as you go along (not to be stored) that a serious player could write down and refer back to if they cared that much.

 

I suppose one could also argue that unless time pressure is a factor the triple-repetition rule won't generally matter if the 50 move rule is enforced. If a position kept recurring, the 50-move rule will eventually kick in even if the repetition rule did not. If either player could expect to win by breaking the repetition he would do so; if neither player has such an expectation the game draws.

Any further development here?

I'm pleasantly surprised to see growing interest in this project, since this thread was dormant for a while at the beginning. Chess is #6 on my to-do list. When I need a break from my current projects, I might get the cursor working.

 

BTW I don't think it's worth worrying about the repetition rule.

I suppose one could also argue that unless time pressure is a factor the triple-repetition rule won't generally matter if the 50 move rule is enforced.  If a position kept recurring, the 50-move rule will eventually kick in even if the repetition rule did not.  If either player could expect to win by breaking the repetition he would do so; if neither player has such an expectation the game draws.

 

Actually, yes... and this may not even be that hard to do. Just have a small subroutine where you track a variable (such as Fifty_Move_Check). Each time white (or black) makes a move, you incriment this by one. If a pawn moves or a piece is captured, this number is set back to zero. You could even make another subroutine where if the variable reaches say 46 or 47, the game could decide whether it was ahead, even, or behind in value and make a "decision" whether or not to accept/play for a draw based on cost of forcing this this variable to be reset. If this doesn't make sense (as I often don't), I'd be happy to explain further.

 

-JD

(Bump)

 

I added a cursor and made the pieces movable this week. Be sure to hold down the trigger while moving a piece.

 

Because the RAM is basically max'd out I had to do a lot of bit manipulation to squeeze everything in. It took careful planning to organize everything:

• 32 bytes for the board position (1 nybble for each square)
  42 bytes of self-modifying code (includes temp variable)
  52 bytes for temporary storage of playfield data
  1 byte: 4 bits for cursor shape and color, 4 bits for piece underneath cursor
  1 byte: 5 bits cursor position plus 3 bits for row counter
   
  1 bit from SM code, STA PF2-15,X or STA PF2,Y for 6th bit of cursor position
   
  4 bits from SM code for joystick speed control:
  • 1 bit stx PF0,Y or sta PF0+64,Y
    1 bit stx COLUPF or sta COLUPF+64
    1 bit sta PF0 or sta PF0+64
    1 bit stx COLUPF or sta COLUPF+64
    

8 bits from timer for cursor blinking

I am confident that enough memory can be dug out to store the rest of the data needed to define the game state. It won't exactly be fun to code all the rules of chess, but I hate to see this kernel go to waste. I'll just keep working on it from time to time.