Chess

[+Andrew Davie]

Here's a binary, setup to allow you to quickly test the promotion UI. Feedback welcome, good or bad. I'm aware of a "show available moves" bug when you're in the penultimate rank. Testbeds like this with hardwired positions setup are great for testing stuff like this.

 

chess_PROMOTE_TESTBED_20200224.bin

[+Andrew Davie]

I've added a second video showing pawn promotion - here, promotion during a capture, which has to deal with the opposition piece...  Just turning it off and then on again seems to work fine...

 

[+Karl G]

I gave it a try, and I would say the UI for selecting a piece for promotion works well.

[Keatah]

The only thing I can think of (in wanting a lesser piece) is that the opponent's attention could be drawn to a stronger piece - while the weaker pieces covertly gang-up for the checkmate.

 

That, and upsetting programmers.

[root42]

5 minutes ago, Keatah said:

The only thing I can think of (in wanting a lesser piece) is that the opponent's attention could be drawn to a stronger piece - while the weaker pieces covertly gang-up for the checkmate.

 

That, and upsetting programmers.

I think there are VERY rare occasions where promotion to a knight might be advantageous due to its possible movements. 
But other than that a queen is always the way to go. 

[root42]

I wonder if there is any possibility to render the board in higher resolution? But probably not without massive flicker

[+Andrew Davie]

1 hour ago, root42 said:

I wonder if there is any possibility to render the board in higher resolution? But probably not without massive flicker

I expect it would be possible using ARM. I did post an ICC version earlier in the thread which looked OK.

But for now, this is the best I have.

 

[+Andrew Davie]

I've finally got all the moves happening correctly, I think.

The video shows castling, en-passant, piece promotion, and "show me my moves" -  all "in the wild" so to speak.

I have quite a few "screen goes black" diagnostics in there, which of course should never be seen. If you run the binary and that happens, let me know, and what happened just before. I'm not totally sure black will behave when doing these moves - still needs more testing.

En-passant was a bit of a nightmare to get working.

 

Next, I'm not sure... I'm a bit burned out.

 

 

chess_20200228.bin

[Voxel]

7 hours ago, Andrew Davie said:

Next, I'm not sure... I'm a bit burned out.

Maybe you deserve a rest...

[+Karl G]

I played the latest binary on Stella, and here are my observations. I'm not sure what issues you are aware of, and which you are not:

 

• The bottom lines get chopped off in Stella. I'm not sure if that also happens on a real TV, as I can't test that at the moment.
• When holding down a button to see possible moves, I was expecting the piece to then be selected, but it was not.  I'm sure personal expectations/preferences would vary on this, though.
• The black king put himself in check by moving in attack range of a pawn.
• My pawn was able to capture the king.

 

 

[+stephena]

5 minutes ago, Karl G said:

The bottom lines get chopped off in Stella.

This only happens in the currently released versions of Stella, and is fixed in the RC's (soon to be 6.1).  I believe Andrew is using a 6.1rc version, so this isn't actually a bug.

[Keatah]

Both versions 3.9.3 and 6.1_rc1 don't chop off the bottom.

Don't mind the extra color saturation I'm experimenting with a camera.

 

3.9.3

 

6.1_rc1

 

[+Andrew Davie]

4 hours ago, Karl G said:

I played the latest binary on Stella, and here are my observations. I'm not sure what issues you are aware of, and which you are not:

 

• The bottom lines get chopped off in Stella. I'm not sure if that also happens on a real TV, as I can't test that at the moment.
• When holding down a button to see possible moves, I was expecting the piece to then be selected, but it was not.  I'm sure personal expectations/preferences would vary on this, though.
• The black king put himself in check by moving in attack range of a pawn.
• My pawn was able to capture the king.

 

Thank you for the report. I can confirm that the bottom being chopped of is just a Stella bug. It won't happen on a real TV, and doesn't happen in the latest release candidates of Stella. I needed just a fraction more time in the vertical blank and this is the result.

 

Regarding holding/selecting, the way you described was the initial way I implemented it, but I found it annoying.

 

There are a few check-related issues, basically because there is no tree-search implemented yet. In short, the capture of a king is only detected one level deeper than the one in which all possible moves are generated. It's far easier to assume a move is legal and then when the next guy moves (and captures a king) to go "oh, whoops that move wasn't legal after all". So, that's not in yet.

I do detect check for the human player, though.  I just don't cull the movelist to prevent checks.

 

This functionality will come when there's a proper "list all moves, then for each.. make the move (A), list all opponent moves, then for each, make a move and if it's capturing a king then mark move (A) as illegal". This is effectively a 2-ply tree search and that has to happen at the start of the human's turn just to be able to cull out those moves which let you leave yourself in check.  It's coming soon.

 

But as to the computer pieces, and moving out of check etc... that will come with the full computer AI, and that's a bit further down the track.

I'm thinking of releasing a "human vs human" alpha version, perhaps on cart, perhaps not, with all the "show me legal moves" because I think it would actually be quite useful for anyone wanting to learn chess and/or play with a friend. Maybe.

[+Andrew Davie]

Here's some reading material for you to brush up on evaluation of a board.

https://www.chessprogramming.org/Simplified_Evaluation_Function

I'm taking the positional tables and piece values verbatim.

I'd like to have an engine that plays "OK" chess. I'm not looking to actually beat anything. Well, maybe "Video Chess". I'd like to beat that.

 

 

[Voxel]

Thanks for the Algebra lesson.

[+Andrew Davie]

Well I've been working on and off on stuff, but the program appears to have approached that complexity threshold which always seems to hit me - the point at which you can no longer remember the whole thing, and some of your old code starts to look... unfathomable.  And at that point I tend to start making mistakes and things just don't work as I expect they should. There should be a name for it. Programmer event horizon or something.

I started to work on the evaluation routine - both material and positional. That's in there but not being called at the moment. It started to become complex and ugly and my brain just wasn't working properly. And it used a lot of the fixed bank... and inevitably...

 

I ran out of free-space in the fixed bank. Well, 7 bytes left. Unfortunately in the 3E scheme, the fixed bank is THE most precious resource, as it's required to do just about all communication between any switched banks/RAM. So, 7 bytes is a major crisis. I played briefly with a weirdo idea about switching/communicating between switched banks and bypassing the fixed bank - and although that worked, it was just too weird for me to go with. There's one function call left using that weirdo scheme, although not called. Here's how it looked...
 

    DEF .GetBoard
                    ds 4                ; dummy to switch here
                    ldx savedBank
                    lda Board,y
                    stx SET_BANK_RAM
                    ds 1

So, basically to call this, you'd have a duplicate of this function in whatever bank you wanted to call it from, in exactly the same address space, which would have a bankswitch (lda #BANK / sta $3E), and the control would then be IN the bank where the above function was, so it would execute those 3 lines you see there, but the last of them switches back the bank to the caller, which then executes a RTS. Hence the "ds 1" at the end. I had multiple of these "stubs" one for each function. It totally worked, but I just couldn't bring myself to go with this scheme.

 

Here's the corresponding caller-function...

 

    DEF XGetBoard
                    ldx #RAMBANK_MOVES_RAM
                    stx SET_BANK_RAM                ; now executing in other bank
                    ds 7
                    rts

 

That's pretty ... weird... code that appears to run straight into an undefined section... but terminated by a 'rts'. And it runs, of course. So that was a bit too weird for my liking - although it totally worked, as I said.

So, I spent some time - a lot of time - refactoring the fixed bank code.  I'm happy with the result - now I have about 500 634 bytes free.  I have worked things so that there are a bunch of "access functions" in the fixed bank, which save state appropriately and then vector to other banks with the guts of the code.

I also took the time to correct a few "mistakes" that I'd made along the way. One of those was to have dual board-numbering. Originally I thought 0-63 made sense for numbering, and all the UI used this. But then I switched to X12 numbering (10x12 board, so X=10.... hence X12). That meant that I had tables and code to convert between the square numbering, and duplication. That's all gone, and now it's pure X12. A little less efficient here and there, but good in the long run.

I've also modified the screen area so that the two "blanking areas" - that is, where I have available processing time - are approximately equal in size. And now I can call the state-machine code in both of those (they are both *just* big enough to draw a piece). That means everything in the UI runs about twice as quick, and of course when I get to the computer move search, perhaps I can get a "dumb" version working without switching off the screen.

Anyway, about time I shared my code again - lots of refactoring and I know basically nobody ever looks at this. Just think of AtariAge as my backup server where I dump my code occasionally and we'll be good.  Much of it is to my satisfaction, and to me at least it's very readable.  I have no doubt it's gibberish to others, though.

 

So, there are a few things not working. Promotions for black are a bit wonky. I think en-passant has some issues again.

But next I'm going to get that evaluation code up to scratch, and at that point I'll be able to do a decent stab at the alpha-beta routine.
 

 

 

 

chess20200311.bin

 

chess20200311c.zip

Edited March 11, 2020 by Andrew Davie
Showstopper bug in source code - new zip uploaded

[Thomas Jentzsch]

Sounds like you had forgotten the problems we had with Boulder Dash and the bankswitching limits.  

[+Andrew Davie]

18 minutes ago, Thomas Jentzsch said:

Sounds like you had forgotten the problems we had with Boulder Dash and the bankswitching limits.  

Not so much. It's just that I had SOOOOO much space in the fixed bank.

Until I didn't.

 

[Voxel]

7 hours ago, Andrew Davie said:

Just think of AtariAge as my backup server where I dump my code occasionally and we'll be good. 

Keep backing up on this very public server and we'll be good!

[+Andrew Davie]

Some fixes. The last version, as noted, used both available "processing" areas but because timing wasn't adjusted (more things happening, less time available for individual actions), the screen occasionally juddered when things were happening. For example, move selection/flashing, or showing available moves. I've now put in time checks for this stuff and it appears to be working OK.  Also, the pawn promotion (human) was buggered. Again. This is fixed. Again. I hate unstable/fragile code like this. Well, it wasn't so much "unstable" code as things not behaving as designed when moved ot a different bank. So, perhaps "not robust" would be a better word.  So, a bit more robust now.  I'm at 615 bytes free in the fixed bank.
 

chess20200312.bin

[Voxel]

This just keeps getting better!

[+Andrew Davie]

Well, I think I may have been the only person in the entire world to be using "Atom" as an IDE for '2600 development. I liked it. A lot. But, nonetheless, I recently saw a post on AtariAge talking about "Atari Dev Studio" (ADS)
 

 and thought well, let's have a look-see.

First impressions were good, but it seemed to lack a few things I really wanted/needed. The most important of those was being able to "build" my project using a makefile. ADS was kind of hardwired for single-file and/or bB development. But it had some really nice stuff in there. I posted a message in the thread, and within a day my "must have" items were done.  I'm impressed.

There are some great things, as I said - like you hover over an opcode and you get all of the info about it....

 

Now that's super-dooper handy. I'm getting old enough now that I don't instinctively know all that information. I used to - but now I get some of the cycle counts incorrect by one. So, that's super-handy.  It's all colour-highlighted, too.  But best of all you get the responsiveness of the Visual Studio Code IDE - and I'll be the first to admit Atom was a little slow.

So, now I'm all setup - I have the same keyboard shortcuts. The fonts I like are configured. It's all working smoothly, and best of all there's a direct line here at AtariAge to the developer (@mksmith) who has been extremely helpful.

As I said, I like it a lot - and I've already switched over to this new IDE as my platform of choice. I recommend you give it a look-see.

Many thanks to @mksmith for the excellent work and making my life easier.
 

[+mksmith]

Pleasure mate ? 

[+Andrew Davie]

Just while I'm spreading the word... if you have an interest in getting the most out of "dasm" then I suggest joining the club at https://atariage.com/forums/forum/294-general/ where there are already a few programming gems.

 

[+Andrew Davie]

Bit of a full-screen video for this update.

 

I now have the material and positional evaluation of the board working. At least, this first pass seems to be doing OK.  Each piece has a value, of course. How "precious" it is. I add to the "evaluation" when there's a promotion. I subtract from it when there's a capture.  Or rather, for a given side, I sum its material value and subtract the opponent's material value.

 

Likewise, each piece has a positional value. There are a number of tables giving the "value" or desirability of a particular piece being on a particular square of the board. As pieces move around, the position value of the old square is subtracted, and the value of the new square is added.  These tables are used to encourage pawns to move down the board, get pieces to occupy the middle squares, keep rooks at the back rank, and all sorts of stuff. So the variable "evaluation" is a running view of what the computer thinks the "value" of the current position is.  That is, the value of the material + the value of the position of the pieces - the value of the opponent's material - the value of the opponent's piece positions. At the start, then, we have an evaluation of zero. All things the same.  But then I start moving pieces, taking pieces, and you see the value changing.

You see the evaluation BEFORE the movie is visible on the screen.

 

So, select your from/to. Then you see the evaluation. Then exit debugger, then you see the move. Then you get the debugger again, and you see the evaluation for the computer move. Exit debugger, then you see the computer make the move.  Repeat. This is just to help you understand what you're seeing in the video. You don't need to remember/do any of this
 

Now this video shows the debugger in use. Not sophisticated debugging, but just watching a particular memory location. I put a breakpoint ("stop the code and bring up the debugger") at the end of the routine that updates the material/positional values after a move, giving a new "evaluation".  Now that "evaluation" currently sits in zero page as a 16-bit value sitting at location $90.  So at the beginning of the vid when the debugger pops up, I move the mouse to those two locations just so YOU can see what the value is, and how it's changing as the board changes. The low byte is first, so you read those two locations right to left.  As I said, it appears to be working OK.  Towards the end you can see how valuable a king is

So, this evaluation routine is pretty much ALL I need to be able to implement the alpha-beta search. I'm really close to starting work on that now.

 

Edited March 17, 2020 by Andrew Davie