Chess

[NostAlgae37]

42 minutes ago, Andrew Davie said:

Wow, that looks amazing, Andrew.  I love it, nice work with the pawn redesign.   

[+Andrew Davie]

I now have the board drawing hopefully glitch-free, and without any time overflows.

This binary is randomly moving pieces around the board (NOT legal chess moves - just teleports) to give some visuals of a cluttered screen with pieces everywhere. Basically it's a quick hack to see if the display system works, which it does. So, the draw is complete.

Note: update/refresh of the board is about every second. It redraws all 64 squares every time. This doesn't need to be a quick system - it just needs to be able to display a valid board. I have a double-buffer system in place, so drawing is done in the background while the previous board is displayed.

I could be more efficient, but I really didn't need to be. 

The next step, I think, is to install a chess engine.

 

 

 

chess_20200112.bin

Edited January 12, 2020 by Andrew Davie
minor update to binary

[+Andrew Davie]

"EOR" drawing takes me back, way back, to my very first attempts at graphics programming. It works particularly well for 1-bit (i.e., 2-colour) graphics. The principle is that if you EOR something (say, A eor B) and then you do the same operation, you end up with A again. That is, (A EOR B) EOR B . == A.  Now that may not be very exciting, until you replace A with "what you see now", and B with "the new shape".  And you get a way to draw/erase "B" with the same function.  More particularly in the case of Chess, if you have a blank square, and you EOR-draw a pawn on it, you have a visible pawn. And if you then EOR-draw a pawn on it, you have a blank square again. Now this is useful because it means you don't have to do any masking to remove the pawn (or, for that matter place the pawn in the first place).
So, I've switched to an EOR draw for the chessboard. I've ditched the double-buffering. And now, instead of having to redraw the entire board every single time there's a change in position, or having to fiddle about with masking bits in an out, I just do multiple EOR-draws, as required.

This has taken my board redraw time from just over a second, to about 10x quicker.  Not that it needed to be quicker, but I halve the RAM usage by ditching double-buffering, and also I can now (potentially) do animations of move without the dreadful frame rate of <1Hz.
Here's a bit of a video and binary to show it working... just completely random from/to moves.
It's also, by and by, a good visualisation into the random function and its operation.

 

 

 

Edit: Well, after reviewing that so-called "randomness", I changed the random routine a fraction, and the following is the new version. MUCH more random-y feeling. Good-o.
 

 

 

 

chess_20200113.bin

 

 

 

Edited January 13, 2020 by Andrew Davie

[+Andrew Davie]

Now I have the EOR-draw, I can move things over the top of other things.

This is pretty cool. A bit flickery - I can probably improve that - but I think I could watch this for hours...

Edit: OK, the flicker is partly delays when the piece is drawn/undrawn, but also mostly because the pieces are changing colour black/white/black/white as they move. That's a bug. Will fix soon  . I've slowed down the movement here to about 1/3 speed just to make it a little more follow-able.
 

 

Edited January 13, 2020 by Andrew Davie

[spspspsp]

I like how this has evolved over time. I think the latest piece design looks especially nice. The "animated" EOR display is a nice improvement too.

 

Out of the engine options you listed, I would be most interested in either of the two local chess engine options, with a slight preference for the nanochess engine or similar.

 

I realize you probably have not even thought about compatibility yet, but to see how it looked on a CRT monitor I loaded it up on a Harmony Encore. I thought you might like to see some pictures.

 

Except, it crashes in an interesting manner. I get a flash and then static color bars.

[+Andrew Davie]

1 minute ago, spspspsp said:

I like how this has evolved over time. I think the latest piece design looks especially nice. The "animated" EOR display is a nice improvement too.

 

Out of the engine options you listed, I would be most interested in either of the two local chess engine options, with a slight preference for the nanochess engine or similar.

 

I realize you probably have not even thought about compatibility yet, but to see how it looked on a CRT monitor I loaded it up on a Harmony Encore. I thought you might like to see some pictures.

 

Except, it crashes in an interesting manner. I get a flash and then static color bars.

Is it running as a 3E bin?

Also, could be this particular version is using more RAM than the Harmony provides.

I'll do a new version with the RAM used for double-buffering removed....

 

Edited January 14, 2020 by Andrew Davie

[spspspsp]

Re: 3E--That I am not sure of. It probably matters that I have NTSC hardware too.

[+Andrew Davie]

I mostly fixed up the issues with the "animation" of moves. Two vids, one showing it with significant delay so you can clearly see the pieces/moves/changes. The other running quickly, so the moves are a blur. Binary included.

Well, having done all that work - and it was fun so no biggie - I wonder if there's a suitable 8-sprite/line routine that I could use instead.
I'd want something that could exactly position 8 double-width sprites exactly 16 pixels apart, starting at an exact pixel #. Each sprite must have selectable colour. Beyond me - maybe someone who is good at '2600 programming could help
 

 

 

 

 

 

chess_20120114.bin

Edited January 14, 2020 by Andrew Davie

[Mr SQL]

8 hours ago, Andrew Davie said:

I mostly fixed up the issues with the "animation" of moves. Two vids, one showing it with significant delay so you can clearly see the pieces/moves/changes. The other running quickly, so the moves are a blur. Binary included.

Well, having done all that work - and it was fun so no biggie - I wonder if there's a suitable 8-sprite/line routine that I could use instead.
I'd want something that could exactly position 8 double-width sprites exactly 16 pixels apart, starting at an exact pixel #. Each sprite must have selectable colour. Beyond me - maybe someone who is good at '2600 programming could help

 

The display has improved a lot, it would be great to have another Chess program for the VCS with an even stronger engine than Video Chess, something closer to Chessmaster 2000.

 

imo this would be more fun than network Chess, I only want to play against the VCS or Player 2.

 

I was playing Chessmaster 2000 on my 800Xl the other day and noticed it did not compare to Chessmaster 2000 on the PC or even to VCS Video Chess on level 4; likely it just has a beginner setting as the default. There were several other A8 Chess programs to choose from though and some were pretty challenging, so far on the VCS we only have Video Chess, likely this is because the display rendering requirements were so difficult with 8 pieces and no flicker, and because Chess engines are so challenging to program!

 

[+Karl G]

8 hours ago, Andrew Davie said:

I wonder if there's a suitable 8-sprite/line routine that I could use instead.
I'd want something that could exactly position 8 double-width sprites exactly 16 pixels apart, starting at an exact pixel #. Each sprite must have selectable colour.

I'm nowhere near your level of experience with 2600 programming, but I almost have to assume that you are kidding here. With double-width sprites, couldn't multiplex the sprites, so presumably you would have to do mid-scanline repositioning, which would leave no time to change either the colors or the contents of the graphics registers. If you're serious, I'd be curious how you imagine that working.

[+Andrew Davie]

I'm leaning towards implementing a chess engine in ARM. That would give me something new to learn and approach the sort of processing power that a decent chess game needs.  But it got me to thinking - say I did it via PlusCart connection to the internet, running a really powerful chess engine like Stockfish on a server. Just farm the moves to and from stockfish. Is it still an Atari 2600 game? 
Anyway, while I dally and tinker, I had a bit of a play with the movement of pieces - this version leaves a very brief "snail trail" as pieces move. I'm not sure if I like it that much, but at least now I know what it looks like. I was trying to make moving pieces feel more solid, less transient.  Looks OK when bishops/rooks/queen move a fair distance.  Video also shows en-passant and castling, just so we can see how it would look in the real thing.

It's now using a "playback" of a game rather than random movement, so the piece movement is realistic.

 

 

 

chess_20200115.bin

Edited January 15, 2020 by Andrew Davie
i don't need no stinking reasons

[Mr SQL]

12 hours ago, Andrew Davie said:

I'm leaning towards implementing a chess engine in ARM. That would give me something new to learn and approach the sort of processing power that a decent chess game needs.  But it got me to thinking - say I did it via PlusCart connection to the internet, running a really powerful chess engine like Stockfish on a server. Just farm the moves to and from stockfish. Is it still an Atari 2600 game? 
Anyway, while I dally and tinker, I had a bit of a play with the movement of pieces - this version leaves a very brief "snail trail" as pieces move. I'm not sure if I like it that much, but at least now I know what it looks like. I was trying to make moving pieces feel more solid, less transient.  Looks OK when bishops/rooks/queen move a fair distance.  Video also shows en-passant and castling, just so we can see how it would look in the real thing.

It's now using a "playback" of a game rather than random movement, so the piece movement is realistic.

 

That would be awesome, you wouldn't have to blank the screen between moves to get the computer to move in a reasonable amount of time.

You could also create a Video Chess tribute mode with demo visuals displaying between moves.

 

I would think of it as a distributed computing Atari game if the Chess engine was running on a server like Stockfish.

 

[Keatah]

15 hours ago, Andrew Davie said:

I'm leaning towards implementing a chess engine in ARM. That would give me something new to learn and approach the sort of processing power that a decent chess game needs.  But it got me to thinking - say I did it via PlusCart connection to the internet, running a really powerful chess engine like Stockfish on a server. Just farm the moves to and from stockfish. Is it still an Atari 2600 game? 

Nope. Now it's a Stockfish (never heard of them) online game. The VCS is now a terminal. Good for as long as the server thing is operational or morphs over time into something the cartridge can no longer communicate with. I dislike games that depend on remote servers for their operation.

 

Many people don't care for Atari's VideoChess for a multitude of reasons; from blanking the display to suspected illegal moves to even choice of colors. And some complain about the style of game it plays and lack of options. But whatever. It can still be played 40 years later.

As far as an ARM engine goes. It's as much a VCS game as Scramble and Draconian. And that's a good thing. If it fits in the slot it's a VCS game.

[+Nathan Strum]

16 hours ago, Andrew Davie said:

But it got me to thinking - say I did it via PlusCart connection to the internet, running a really powerful chess engine like Stockfish on a server. Just farm the moves to and from stockfish. Is it still an Atari 2600 game? 

Probably. But it might end up as usable as the GameLine is today.

 

Any game that relies on the internet to be functional, is doomed to not be functional at some point.

[Omegamatrix]

On 1/13/2020 at 10:49 PM, Andrew Davie said:

Well, having done all that work - and it was fun so no biggie - I wonder if there's a suitable 8-sprite/line routine that I could use instead.
I'd want something that could exactly position 8 double-width sprites exactly 16 pixels apart, starting at an exact pixel #. Each sprite must have selectable colour. Beyond me - maybe someone who is good at '2600 programming could help
 

Double wide sprites might be doable, but I would consider using multiple copies of single wide instead.

 

If double wide, than consider how Meltdown did it. Meltdown drew P0 and P1 double wide, and then at a certain cycle switched to 2 copies wides and then immediately changed it back to double wide. The end effect was double wide copy was drawn for each sprite. The cycles are very specific and might not align to 16 pixels.

 

It's conceivable to simply flicker two frames of offset sprites like this to get 8 copies. Changing all the colors though and updating the graphics might require a ram kernel. Meltdown used a ram kernel.

 

The real crux of the problem is still having a playfield for the checkerboard. This is where I really wish the 2600 had additional PF registers and accompanying modes in CTRLPF which allowed the entire playfield to be set with no sharing of Left/Right side. I think the only way around it for using these double wide sprites would be to offset the checker board so that reflect PF could be used. Even then there would still be some clean up to do with adding/removing the extra PF patterns.

 

On 1/14/2020 at 7:32 AM, Karl G said:

I'm nowhere near your level of experience with 2600 programming, but I almost have to assume that you are kidding here. With double-width sprites, couldn't multiplex the sprites, so presumably you would have to do mid-scanline repositioning, which would leave no time to change either the colors or the contents of the graphics registers. If you're serious, I'd be curious how you imagine that working.

Two roms you should check out are Meltdown, and the Care Bears prototype. Meltdown is explained above. Care Bears does a trick with Reflect to produce a huge detailed sprite.

[R. Jones]

On 1/14/2020 at 12:49 AM, Andrew Davie said:

I mostly fixed up the issues with the "animation" of moves. Two vids, one showing it with significant delay so you can clearly see the pieces/moves/changes. The other running quickly, so the moves are a blur. Binary included.

[ . . . ]

 Oh, that's awesome. Fast looks more fluid to me, but even the slow one is quite nice. Also, the new pieces are all much cleaner.

[+Andrew Davie]

47 minutes ago, Omegamatrix said:

 

The real crux of the problem is still having a playfield for the checkerboard. This is where I really wish the 2600 had additional PF registers and accompanying modes in CTRLPF which allowed the entire playfield to be set with no sharing of Left/Right side. I think the only way around it for using these double wide sprites would be to offset the checker board so that reflect PF could be used. Even then there would still be some clean up to do with adding/removing the extra PF patterns.

 

Thanks for the considered response.

IF I used full-screen width, still, then I use non-reflected PF, with the squares still being the same as they are now. But I don't need to modify PF on-the-fly (just one write of PF0/PF1/PF2 values at the start of each board row). Then the sprite requirements would be to fit onto those squares. The squares being 5 PF wide, that would be 20 sprite pixels - a double-wide sprite being 16, so the spacing would still be excellent (two pixels spare each side of the chesspiece). That would mean I'd need 8 sprites, independently coloured, double-wide, spaced 20 pixels apart.
I still have no idea if it's do-able.  But at least, no PF writes required while sprites are being manipulated.

 

[Omegamatrix]

Ah, okay I tried your rom and see that each checker is 5 PF blocks long. For some reason I thought you would be doing 4. 

 

If you don't need to update the playfield then it might be doable. The big question will be if the timing is there for updates. 

[+Andrew Davie]

1 minute ago, Omegamatrix said:

Ah, okay I tried your rom and see that each checker is 5 PF blocks long. For some reason I thought you would be doing 4. 

 

If you don't need to update the playfield then it might be doable. The big question will be if the timing is there for updates. 

No, you were right. I considered 4. But your comments about PF gave me reason to switch to NOT updating PF, and the only way I can see to do that is to revert to full-screen 5-pixel-wide squares.

 

[+Andrew Davie]

Right. I've started working on implementing an ARM engine, insofar as I've set myself up with the UnoCart source code and tools, and I'm able to build that OK. Thanks to @DirtyHairy for the assistance there!  I understand the bankswitching support well enough, and have a reasonable idea of what I'm going to need to do to get it working. Basically the ARM sits there in an endless while() loop looking for address changes on the buss. It then figures out what to put on the data buss. Simple enough. Somehow, inside that while loop, I'm going to have to implement a chess engine too. It's probably not as hard as it sounds, but I want to try and do a good job. Effectively, when the 6507 is at the end of a frame, have it signal somehow (through a memory write) to the ARM code that the 6507 is waiting, end of frame. Then the ARM code will give a timeslice to the chess engine - perhaps interrupt-based so we always return to the while() loop at the appropriate time. Meanwhile I have to make sure the 6507 isn't marching off into the wilderness. That's the basic gist of it.

Soooo... I think my first step is to just work with the UnoCart code - I note it is GPL'd and I wonder if this effectively means that any code written using the basic bankswitching/shell of the ARM support (which seems to be included in the UnoCart code) is also by inclusion GPL'd. Does that affect any of the ARM games out there. I wonder.  Anyway, just to start with... use that code and see if I can hack in a) 6507 signalling to the ARM that it's time to do a chess timeslice, and b) the ARM going away for a set amount of time, returning and continuing the while() loop. That shouldn't be TOOO hard. And after that I'll need to get a chess engine that I can compile on the ARM (C-source almost certainly), and start the process of hooking in to control the ARM chess from the 6507 GUI. Should be daunting fun.

Meanwhile, I've made a small but very effective change to the move/display engine. I'm toggling the piece rapidly before it starts a move - this draws your eye to it very effectively. I think it's really pretty. Just saying. And I have worked on the timing of piece moves so it's now quite nice. To my eye, at least.  I added a "reset" on button press so you can restart the "game" at any point.
 

chess_20200116.bin

[+Karl G]

The attention-getting trick is good to be able to more easily track movement of pieces, but I'm wondering if you have tried doing it by changing colors instead of blinking it off and on? Like back and forth between the two piece colors, perhaps?

[+Karl G]

Here's another unsolicited thought: if you are sticking with your playfield graphics-based engine, I wonder how it would look if you used the sprite graphics just for the currently active piece, when that piece is selected by the player, or is making its move? That would certainly make it visually distinct to follow the action, and allow for smoother animation when making the move.  Just a thought.  ?

[iesposta]

I would rather play Andrew’s 2600 chess. 

[DirtyHairy]

6 hours ago, Andrew Davie said:

I note it is GPL'd and I wonder if this effectively means that any code written using the basic bankswitching/shell of the ARM support (which seems to be included in the UnoCart code) is also by inclusion GPL'd. Does that affect any of the ARM games out there. I wonder.

Yes, that's true, if you modify the firmware code, the result needs to be licensed under GPL. However, you could (and this probably should be the goal for distribution anyway) build your code as an ACE binary. This can be loaded by the unmodified GPLed firmware at runtime and, to my understanding, could be licensed under different terms. However, I am not 100% clear how the bootstrap code for ACE is licensed. It is derived from Atollic code, which is licensed under the MIT, and @ZackAttack did not specify any particular license.

 

We should ask him and clarify the licensing termns. If the ACE code were indeed licensed under the MIT, then that you could basically choose on how to license your own code based off it.

Edited January 16, 2020 by DirtyHairy

[NostAlgae37]

14 hours ago, Andrew Davie said:

 

Meanwhile, I've made a small but very effective change to the move/display engine. I'm toggling the piece rapidly before it starts a move - this draws your eye to it very effectively. I think it's really pretty. Just saying. And I have worked on the timing of piece moves so it's now quite nice. To my eye, at least.  I added a "reset" on button press so you can restart the "game" at any point.
 

chess_20200116.bin 32 kB · 6 downloads

 

This gimmick is the best yet, and makes playing the game feel very natural.  It also has a very "VCS-innovative" quality to it, if that makes any sense at all (it seems like a trick that the programmers of that era might have actually utilized back in the day).  Oh wait Andrew, you are actually one of the programmers of that era, aren't you?