Brave testers needed for the Picochess V4

[Johan Sjöblom]

Hello Pico users.

To be able to complete Picochess V4 we would need brave testers. Thanks goes out to all that have already taken time to test and report issues.

There is no image yet for picochess V4. You need the basic skill to use the Raspberry Pi Imager to crete a PI operating system on your SD card. The step-by-step instructions can be found in the readme file on the github page:

https://github.com/JohanSjoblom/picochess

I have now created a possibility to update the Pico system from within the menu so that you can get corrections as you report problems. You can also set the system to update to the latest pico version on every boot in the ini file. See the readme. I fixed the automatic update. Now it should be easier to stay updated. Yes, you have to run a new install using this version 4.1.0, but after that it should auto-update whenever you want.

The repository includes only Stockfish, LC0, and pgn_engine. I will try to make all the engines in the existing image available as a resource and try to figure out how to automatically add them during the installation process.

The new Pico V4 does not have a kiosk mode yet. I would need instructions on how the current kiosk mode is set up. I saw the recent posts, and I can probably find out something in the existing image. I could probably automate that installation as well?

Finally a small mention of a new feature that exists in this V4:

- You can use picotutor to analyse a game, tutor will analyse both sides in "Hint On" mode.

- If you declare a game end, or save the game, the picotutor evaluations will be written to the PGN file.

- You can upload a PGN game from you mobile, ipad, or laptop to localhost/upload. You can of course also load the latest PGN game from the existing Pico menu. Pico will start a completed game in the starting position. You can step through the PGN game using the pause button. I recommend to let the DEPTH go up to almost 17 or higher before making the next move. That makes the picotutor evaluations more correct.

If anyone knows a frontend developer with javascript/typescript and html/css knowledge please contact me :-) We would need to modernise the frontend. I can talk to our friend Claude, ChatGPT, or Co-Pilot, but a real human frontend developer would be nice.

best regards, Johan

[RandyR]

Hi Johan,

Issue #57 opened.

Randy

[Johan Sjöblom]

Good that you found this one. The new /upload function needed more for the authentication to work. I fixed it today along with some other bugs that I found in my own testing.

There is one thing I would like to get opinions on. If I analyse a game in Eval mode I will always see the latest depth and score on the web or clock. If I play the engine it shows the score from my own point of view. But what would we like to have when we are analyzing a game. Currently it shows the score according to who's turn it is. So if you made a move for White the score starts to show the centipawn points from Blacks point of view. It is is Blacks position that is being analysed, and it's Blacks turn.

Usually when I play through a game I am more interested in the colour I played, or if I am analyzing a Kasparov game I would like to see the score from Kasparov's colour point of view. It would feel more stable if the score would stay the same from one point of view regardless of who's turn it is. So there could be a concept of users colour even though I am not playing any engine. If I want to switch the score, maybe "switching the sides" would not do anything more than just switch the score point of view?

Opinions?

[Randy Reade]

I think the score should always be from White's point of view. But that's just me. 😁

Randy

[DJ Dekker]

Hoi Johan,

I'd prefer a positive score if White is better and a negative score when Black is better. So absolute scores from White's point of view instead of scores relative to the player whose turn it is. That's what most of today's engines seem to do. It's also the most logical if you would graph the evaluation over the course of the game: above the horizontal axis means advantage for White, below the horizontal axis means advantage for Black.

Greetings,

DJ

Op vrijdag 9 mei 2025 om 18:29:54 UTC+2 schreef messi...@gmail.com:

[Peter Eggen]

Hi, is there a specific reason to limit the Hardware to a Raspberry 3 or 4 while RPI5 is the latest version (and most performant as well). Just courious - I do have an RPI4 for testing but would be eager to test with RPI5

Regards Peter

[Johan Sjöblom]

No reason at all :-) Please test!

You can use any Raspberry or Debian hardware. It also works on Debian laptops for example, I use the DGT board with my Debian laptop.

All 64bit Debian/Raspbian (aarch64 or x86_64) should work.

Yours, Johan

--
You received this message because you are subscribed to the Google Groups "PicoChess" group.
To unsubscribe from this group and stop receiving emails from it, send an email to picochess+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/picochess/0b4fd0b4-9a57-4ad9-b96e-0496fa4ea64fn%40googlegroups.com.

[Johan Sjöblom]

I changed the evaluation scores to be from White's perspective. I changed both on the display, and the stored score per commented move in the PGN result file.

I also noticed that due to history the Pico display code is dividing centipawns with 100... When White is better by "roughly two pawns" 200 centipawns is shown on screen as 2.00. In the PGN its saves as score 200 (and also lost centpawns CPL is written this way).

Any opinions or thoughts on which way we should have it? Do we want to have centipawns also on screen, ie, do we want to show 200 on screen also? Or would we like to have 2.00 in the PGN file. What is more standard?

yours, Johan

[Randy Reade]

I vote for the score in +/- pawns to 2 decimal points (centipawns/100). I believe that's pretty standard. 😊

Randy

To view this discussion visit https://groups.google.com/d/msgid/picochess/a9298076-ad54-4773-a607-ab935e449971n%40googlegroups.com.

[Danny Abdellatif]

As much as i would prefer pawns I’d still stick with centipawns in the PGN as most tools expect that format. If you use pawnscore, some stuff might break. For example, SCID, pgn-extract, or Lichess’s study importer might misread it or just ignore the eval. Displaying pawnscore on screen is standard and more readable. So my vote is centipawns in PGN, pawns on screen. Never really thought about it before, but I guess there’s a different standard for tools vs people on this one.

Op zaterdag 24 mei 2025 om 17:18:55 UTC+2 schreef RandyR:

[Randy Reade]

Good point. I didn't realize the pgn needed to be centipawns for certain programs. So I guess no change is required.

Randy

To view this discussion visit https://groups.google.com/d/msgid/picochess/ff069068-4ada-4964-bac7-7ab873607b8bn%40googlegroups.com.

[Johan Sjöblom]

On the topic of how to write score and centipawn loss in the PGN file. I did not find any standard to follow for the centipawn scores. For the nag codes I think I follow a standard, but for the centipawn loss and score I did not find any standard. They are written in the comment field. Is there a way to write that comment string (text) structure so that programs like SCID would recognize score and centipawn loss… And maybe also the best move (the move you should have made).

Yours, Johan

[Danny Abdellatif]

There’s no official PGN standard for eval as far as i know, but there are some common conventions that tools like SCID, pgn-extract, and Lichess understand:

[%eval 50] — for eval score (in centipawns)

[%eval #3] — for mate scores

[%bestmove Nf3] — for best move suggestions

[%cpl 40] — centipawn loss (some tools support this)

These go inside the comment field after a move. Keeping the evals in centipawns in integers helps with compatibility. Think this would be the closest thing we have to a standard.

Op zondag 25 mei 2025 om 08:58:16 UTC+2 schreef messi...@gmail.com: