Chess

[AW127]

In the last hour, i let the version "20200911 4PQ7" play against "Grandmaster" on the C-64. That's a chess-programm by Kingsoft from 1982. It's not one of the strongest chess-programs on the C-64, but not a bad player either.

 

Todo this, i let BitChess play in STELLA with 500% speed and Grandmaster in VICE with 200% speed. I choose level-1 in Grandmaster, which means, that the program has 5 seconds per move. This easier play-strength i chose, because i thought it's only fair. The C-64 is a stronger system than the Atari-2600 and i wanted to make it not to unfair for BitChess, therefore.

 

At first the game was pretty even. I made some screenshots from the game, but didn't write down all the moves. Maybe next time i also do this.

 

Here some screenshots. BitChess played with white and Grandmaster with black pieces.

 

 

 

 

 

Then it came to this situation, in which Grandmaster was very close, to bring some pawns to the white side.

 

 

 

In the next move this happens, when the black pawn on G2 kills the white knight (jumper) on H1 and then BitChess ran into a bug-problem. I must choose a new piece then for this black pawn and, of course, choose a Queen. But right after i had chosen, BitChess shows me this here:

 

 

The queen, which i had chosen, now strangly is a white figure (i have marked it) and not a black one and also it still stands on the field, from which i had moved the black pawn (G2) and not into the lower right field (H1), where it should stay. And this H1-field is now red all the time.

 

I tried around to go on playing, but could not, because i could not make a move anymore. So there seems to be a bug in Bitchess, after a new figure is chosen by the human player. How it should be and how the figures should stand correctly, can be seen on the chessboard of Grandmaster on the left. The new black Queen should be in the field H1 and of course no figure should be on field G2.

 

All in all, it was a close match until then, but after Grandmaster could get a new Queen, it's clear that Grandmaster would have won the match. But sadly, i could not play it to the end, because of this bug in BitChess.

 

Nevertheless not a bad performance from BitChess up to this point. It needed alot longer to move than Grandmaster, even with 500% speed in STELLA, but that was not really a problem. It would have been maybe, when i had used a real Atari-2600 because of the long waiting-times, but in emulators, when the speed can be set higher, it's not really problematic.

 

Now only this bug in BitChess after choosing a new figure, must be found and hopefully wiped out.

 

Edited September 12, 2020 by AW127

[+Andrew Davie]

29 minutes ago, AW127 said:

Now only this bug in BitChess after choosing a new figure, must be found and hopefully wiped out.

 

Yes. Thanks for the report.

 

There are three major opportunities for speedup which are yet to come....

 

1) sort the moves - this will give maybe 5x speed

3) cull the moves - this will allow the search to be stopped at any time and still have a good move

4) search a subset of the moves after (1).  Perhaps another 2x.

 

I expect to be able to get the program roughly 10x faster -- in the long run.

 

[+Andrew Davie]

As a bit of an experiment for using a PlusCart set into autoboot mode, so it can be a Chess PlusCart, I thought I'd make up some "homebrew" PlusCarts of my own. I've had pretty much nothing to do with this awesome creation from @Al_Nafuur, except in the board shown here, where I couldn't resist rerouting the traces so they look pretty. I spend literally hours and hours on this sort of minituae.  Unfortunately I put the logos on the wrong side of the board, but that's what prototypes are for, right?  I'll have to wait a month or two for the board components to arrive, so these go in a drawer for now.

 

 

In case you're wondering what this is about, you're looking at the light shining off the tracks on the board and noting how neat and pretty they are.

 

[zbyti]

@Andrew Davie ping :]

[AW127]

Andrew, could you solve the problem, that i reported in post #1151, when a human player make it to the other side and wants to change this figure then in a queen (or whatever)?

 

I ask, because i wanted to let BitChess play against some other computer-chessprograms and also against my real chesscomputer. But this makes only real sense, when this problem is fixed, otherwise any game would always be falsified or ended, every time when such a "changing-figures problem" would appear again.

[+Andrew Davie]

On 12/21/2020 at 10:33 AM, AW127 said:

Andrew, could you solve the problem, that i reported in post #1151, when a human player make it to the other side and wants to change this figure then in a queen (or whatever)?

 

I ask, because i wanted to let BitChess play against some other computer-chessprograms and also against my real chesscomputer. But this makes only real sense, when this problem is fixed, otherwise any game would always be falsified or ended, every time when such a "changing-figures problem" would appear again.

 

I have not spent any time working on BitChess for some time.

I do not anticipate working on it for some time to come; my attention is elsewhere at the moment.

I am also reviewing some choices I made regarding platform/implementation.

 

[+Andrew Davie]

Recently I decided to get up to speed on the CDFJ bankswitching scheme. I really don't understand much about it yet, but I've used the learning experience to write a new display engine for Chess.  I haven't done all the pieces yet, and this is just a display engine - not tied to the chess engine (which is 3E+ bankswitching format).  There's "shimmer" compared to the original, but the pieces are more solid and vibrant.  I think it looks OK.
 

 

Note: this is captured from Stella with phosphor emulation turned on. Then it's down-converted to 30fps for the video. The shimmer is really quite visible in the video, but much less so to the eye -- I've hit a bit of a "reasonance" between the phosphor effect, the screen capture speed, and the downsampling.  The real proof of the pudding will be what it looks like on a TV. But hey, I thought I'd put the first one up here for posterity...

 

 

Edited January 19, 2021 by Andrew Davie

[+Andrew Davie]

I think, currently, the original looks much, much better though. Even with the low contrast of the two sides.

 

[+Andrew Davie]

I completed the pieces (and sundries) for the test CDFJ display engine.

Here's a video of it in action...

 

 

Here is a still-shot showing 1 of the 3 colour-rolling frames (if you look closely, you'll see the alternating Red/Green/Blue lines. These lines "roll" over 3 frames so that every line has red 1/3 frames, blue 1/3 frames, green 1/3 frames).  It creates a slight shimmer/flicker depending on your CRT's phosphor.

 

Edited January 20, 2021 by Andrew Davie

[+Nathan Strum]

That really looks nice! Would love to see it on real hardware.

[+Andrew Davie]

14 minutes ago, Nathan Strum said:

That really looks nice! Would love to see it on real hardware.

Me, too. I think it won't run on real hardware at the moment, but what would I know.

It's to do with how much work the ARM is doing. I just brute-forced it, rather than doing in smaller packets of work.

I have no real idea right now how to run on hardware. I think I need a Harmony Cart...?

The PlusCart doesn't support CDFJ, I think. Yet.  And in any case, as I said, I think I'm not doing things properly.

But at least it's a good idea of what's possible. The technique is definitely possible - just brute-forcing redraw every single frame may be beyond the capabilities. It's a test/demo so I'm not concerned about that.

[+Andrew Davie]

There's more colour leeway in the new display engine. It does not rely so heavily on colour blending; I can have one colour for black piece, one colour for white pieces, and another colour for squares. The blending of those gives other available colours for target indicators, etc.  In the original system, white pieces were all three colours blended, and black pieces were two of the three colours blended, and squares were one colour. That made things really tricky.  Still very hard to get good colours, because each colour is displayed only one out of every 3 frames for any given pixel.  But as I said, there's more leeway. Example...

[JetSetIlly]

19 hours ago, Andrew Davie said:

Recently I decided to get up to speed on the CDFJ bankswitching scheme. I really don't understand much about it yet, but I've used the learning experience to write a new display engine for Chess.  I haven't done all the pieces yet, and this is just a display engine - not tied to the chess engine (which is 3E+ bankswitching format).  There's "shimmer" compared to the original, but the pieces are more solid and vibrant.  I think it looks OK.
 

 

It looks excellent. Do you fancy giving this a spin on the new version of Gopher2600? It now supports ARM, CDFJ and has a basic phosphor effect. It also support PlusROM so it theoretically supports CDFJ+PlusROM but we haven't tried that yet.

 

Speed is always an issue with Gopher2600 but I can get a solid 60fps on my i3-3225.

[JasperAK]

3 hours ago, Andrew Davie said:

There's more colour leeway in the new display engine. It does not rely so heavily on colour blending; I can have one colour for black piece, one colour for white pieces, and another colour for squares. The blending of those gives other available colours for target indicators, etc.  In the original system, white pieces were all three colours blended, and black pieces were two of the three colours blended, and squares were one colour. That made things really tricky.  Still very hard to get good colours, because each colour is displayed only one out of every 3 frames for any given pixel.  But as I said, there's more leeway. Example...

I love the CGA look. Now if only white, black, magenta, and cyan...

[+Andrew Davie]

2 minutes ago, JasperAK said:

I love the CGA look. Now if only white, black, magenta, and cyan...

Review the colours in post #1159; they're all there.

 

[JasperAK]

16 minutes ago, Andrew Davie said:

Review the colours in post #1159; they're all there.

 

Yes they are, but the effect looks more like an Apple 2e.

Edited January 20, 2021 by JasperAK
This is what I meant

[JasperAK]

Don't get me wrong, I love your work on project. I was just struck by how the last pics looked like something I would have had on my original 286.

[+Andrew Davie]

32 minutes ago, JasperAK said:

Don't get me wrong, I love your work on project. I was just struck by how the last pics looked like something I would have had on my original 286.

I doubt I can get those colour combinations but I'll have a play soon

[+Andrew Davie]

I've spent all afternoon looking at and tweaking ones and zeroes. Why couldn't the inventors of 0 and 1 arabic numerals have chosen a dense solid block shape for 1 and a really faint hard-to-see shape for 0?  Lack of foresight, I reckon.

So, piece refinement/redesign, and colour tweaking has allowed me to make an attempt at highlights/shading. It's not perfect, but I'm happy with this...

 

[+Andrew Davie]

2 hours ago, JetSetIlly said:

 

It looks excellent. Do you fancy giving this a spin on the new version of Gopher2600? It now supports ARM, CDFJ and has a basic phosphor effect. It also support PlusROM so it theoretically supports CDFJ+PlusROM but we haven't tried that yet.

 

Speed is always an issue with Gopher2600 but I can get a solid 60fps on my i3-3225.

Appears to be working fine!  Well done.

I'm on a MacBook Pro 2012 and speed appears to be a little slow -- screen is quite annoying/wobbly with the interlacing.

 

Image is a bit dodgy because of scaline, slow update rate, and effects not fiddled with.

But... it works!

 

 

 

 

[JetSetIlly]

1 minute ago, Andrew Davie said:

Appears to be working fine!  Well done.

I'm on a MacBook Pro 2012 and speed appears to be a little slow -- screen is quite annoying/wobbly with the interlacing.

 

Image is a bit dodgy because of scaline, slow update rate, and effects not fiddled with.

But... it works!

 

 

Cool ? My ARM emulation is not optimised at all and from what you're saying you're hitting the ARM pretty hard. Do you plan on releasing a binary?

 

[+Andrew Davie]

1 hour ago, JasperAK said:

Yes they are, but the effect looks more like an Apple 2e.

Can't get much closer than this without lots of work, and basically I'm not gunna.

Just thought I'd share the effort since you were interested enough to ask.

 

[+Andrew Davie]

Just now, JetSetIlly said:

 

Cool ? My ARM emulation is not optimised at all and from what you're saying you're hitting the ARM pretty hard. Do you plan on releasing a binary?

 

Not to the public, but you're welcome to one if it will help you with emulation and you don't distribute it.

 

[Mr SQL]

16 hours ago, Andrew Davie said:

I completed the pieces (and sundries) for the test CDFJ display engine.

Here's a video of it in action...

 

 

 

Here is a still-shot showing 1 of the 3 colour-rolling frames (if you look closely, you'll see the alternating Red/Green/Blue lines. These lines "roll" over 3 frames so that every line has red 1/3 frames, blue 1/3 frames, green 1/3 frames).  It creates a slight shimmer/flicker depending on your CRT's phosphor.

Interesting effects! I'd have to try the ROM on my CRT but I think from your description the eye is left color blending at 20 Hz to "assemble" the shimmer Fx.

[+SpiceWare]

15 hours ago, Andrew Davie said:

I have no real idea right now how to run on hardware. I think I need a Harmony Cart...?

 

Correct.

 

6 hours ago, Andrew Davie said:

I've spent all afternoon looking at and tweaking ones and zeroes. Why couldn't the inventors of 0 and 1 arabic numerals have chosen a dense solid block shape for 1 and a really faint hard-to-see shape for 0?

 

my custom mode file (syntax highlighting rules) for jEdit colorizes binary, which really makes graphics in source code stand out. Since the categories went away I created a jEdit index for my blog entries related to it.