Updating picochess to latest python chess module

[Johan Sjöblom]

Hi all.

Regarding the porting of picochess to the latest python and newest libraries.

I now have a baseline where all playing modes should work. There is no image based on this version yet, and it will take some testing and more development before there is any point to create one. But anyone who is able to test is welcome to do so. You need to have the ability to set up picochess without an image in order to test.

If you do test, please post problems found in this thread.

Code can be found in: https://github.com/JohanSjoblom/picochess.git

BR, Johan

[Dirk Mollmann]

Thanks Johan!

Am 27.11.2024 um 19:30 schrieb Johan Sjöblom <messi...@gmail.com>:

Hi all.

--
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/2470f4bf-6268-4abc-a8cf-42860a9a1a9an%40googlegroups.com.

[Johan Sjöblom]

I am going to update the installation script so that it would be easy to get going on a standard PI image… 

BR, Johan

[RandyR]

Here are the steps I used to create an image for testing Johan's updates. I'm hoping just switching to /opt/picochess and executing 'git pull' will allow any new code to be downloaded and tested going forward. But, I'm no git expert.

Randy

[Johan Sjöblom]

Thanks. I will have a look at it. Attached are two initial shell scripts. The first one is a first draft of an installation... the second one is how to run.

The challenge with the new standard Python 3.11 and higher is that all python packages have to be installed in a "virtual environment" which in my case is /opt/picochess/venv

The second challenge is that in order to run a python program you have to run "source venv/bin/activate" in the picochess folder. Therefore I did a short 2 row shell script to run picochess from that virtual environment.

As said these are very draft.

Installation requires sudo, running does not. You need to edit a working picochess.ini, or use this new example that I have not yet uploaded so it does not set it correctly yet.

My idea was that we have a fully working picochess.ini.example and my install script copies that to a picochess.ini... So in theory you just run install (with sudo) and then run the start script.

On a blank bookworm you would need to change to PulseAudio using raspi-config... and to X11 is also recommended. Without the change to pulseaudio the audio will lag.

My next step is to update my fork repo with these files... and then test all steps from start using a "blank" image file made by pi image creator... I am sure there are still libraries missing that needs to be added to the install script but this is the draft start.

BR; Johan

[Johan Sjöblom]

I have now committed the previously attached files to my repo. So again, in theory, downloading install-picochess.sh and running it should do everything except set PulseAudio and X11. I am sure I made some mistakes so please note that I have not tested it from scratch myself yet. We started celebrating ”small Christmas” here now in the North so maybe I can blame mistakes on that?

I tried to align the installation script with your Picochess_Build attachment… Might need more work.

The goal is to be able to just run the install-picochess.sh on a standard PI image, and then start playing in a web browser without any tailoring needed.

I also updated the readme file with these instructions on how to get going.

BR, Johan

[Johan Sjöblom]

Randy, when you have time, there is absolutely no hurry, I have some questions.

in your build instruction file you have this section:

16. (Optional) If you want to use the opening book and games database servers in the web browser interface, replace /opt/picochess/obooksrv/obooksrv and /opt/picochess/gamesdb/tcscid with a 64-bit aarch64 versions or add support for 32-bit armhf programs by running the following commands

Question1: Where can I find aarch64 versions of book and game servers. Maybe I missed something obvious? For 64bit PI systems I would like to avoid using a 32 bit extension if we can…

Question2: Do we have the sources to rebuild and or change the so files if we would need to?

BR, Johan

[Randy Reade]

Hi Johan,

You can get aarch64 versions of obooksrv and tcscid from my images. If you want to compile them yourself, obooksrv can be found on Gerhard's repo. Gerhard also modified the PolyGlot v1.4 source code to allow creation of an opening book file compatible with the obooksrv called obookmkr. For tcscid you will need to download and compile SCID vs PC source code and follow Gerhard's instructions in the gamesdb folder.

The 64-bit source code for the dgtpicom/dgtpicom.so for use in the DGTPi or DGT3000 mod (Pi4 and older) can be found on Ghislain's repo.

Randy

[Johan Sjöblom]

Update.

The install script works on a clean PI 4 64bit os. The only thing I had to do manually was to set PulseAudio and X11. I only tested web browser play so far.

I have not yet had time to fix obooksrv and tcscid, and thanks for the info on how I can proceed with that.

I would need to make or get better uci files for stockfish and lco, especially on how to set the elo level differently in the 20 difficulty levels…

And greetings from the North, just passed the polar circle, 66 degrees, 33 minutes North. Here it’s now only 2 hours between sunrise and sunset. / Johan

[Johan Sjöblom]

Update.

PI4 64bit installation seems to work ok now. I have not given pi user rights to git (sudo needed to either rerun installation as sudo which does a git pull or pi user can do a sudo git pull to update. Pi user by default only have rights to edit ini file and run the program which means logs directory is also owned by pi. That seems to be enough to run the program. I have tried to design the install shell script so that it can be rerun to update everything.

PI 64 should work with both web play and DGT. I have included stockfish 17 and lc0 out of the box. Just start playing after installation. At least ”working out of the box” should be the vision and goal.

I have tested latest Debian 64 on a intel processor. Web play works after installation. I think I will update the bluetooth library before testing Debian and DGT. A peculiar thing I found was that I had to comment out synthesized speech in the java web pages jsp. Before commenting it out I got computer announcements from both the web code and the picotalker.py.

BR, Johan

[Johan Sjöblom]

Question: What was the engines/x86_64 folder intended for? I am now using it for Debian 64bit (testing on Intel i5). I have so far only replaced stockfish with a newly compiled Debian 64bit stockfish.

And: I compiled the obooksrv on Debian 64 and it works with picochess there now... Have not committed the compile yet I was thinking that I need to have architecture folders in /opt/picochess/etc as I am going to need differently compiled versions of obooksrv (and gamedb).

[RandyR]

As you know, PicoChess runs on different architectures. It will look in the engines/<architecture> folder for engines, where architecture is found using the command 'uname -m'. In the PicoChess code it is found using the platform.machine() function of the platform module (see uci/read.py).

As for the different architectures, it's up to you but I would just stick with the aarch64 version. It's principal use case is the Raspberry Pi after all.

Randy

[Johan Sjöblom]

Thanks. Yes I noticed uname -m in the install-picochess shell script for the installation of the correct dgt so libraries (inherited from your repo).

I now added the same uname -m for installing the obooksrv... but as I am travelling I could only fix x86_64 (Debian 64 bit)... on my travel laptop and a mobile connection in a bus :-)

When I get home later this week I will compile an obooksrv also for the main target aarch64...  And I dont need to change any Python code for different obooksrv compiles so its only the installation that is affected.

I guess armv7l is for 32bit PI3 Is that the target I should test on my DGT PI clock (that has a built in PI3)?

[Randy Reade]

The 64-bit OS runs on the DGTPi. No need to use 32-bit any more.

--

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/7b042698-e233-4f90-bf20-819b493e3bcan%40googlegroups.com.

[Johan Sjöblom]

ah, great stuff... so I can go "all in" for aarch64 and there is  no point supporting armv7l any more?

I was thinking there might exist some old precious chess engine that does not run in 64bit and that there might be some nostalgic reason to maintain 32bit PI for that reason... :-) 

[Randy Reade]

If there are any armv7l engines that you want to run, they'll run under aarch64. You just need to install any needed armhf libraries.

To view this discussion visit https://groups.google.com/d/msgid/picochess/ebe7d278-066a-49c1-bcb3-3a7d9c33eadbn%40googlegroups.com.

[Johan Sjöblom]

Hi. Sorry for all the basic questions. I built the tcsid from source but I dont know where it is supposed to fetch a gaming database? Do I need to copy a gaming database onto my local disc in opt/picochess/gamesdb something or is the code trying to fetch some online source... I am guessing that I am missing a scid game database that I would need to download or pick up from some image? I tried to look for instructions in Gerhards repo but I did not manage to find anything to help me on this gaming database issue... All hints and pointers appreciated :-)

BR, Johan

[Johan Sjöblom]

I went out looking for scid databases online and tested using OTB https://sourceforge.net/projects/codekiddy-chess/ It worked, so I can use it to test during my development testing.

I did not find any copies of the caissabase online, obviously that one is often recommended.

Now that I know how it works I rephrase my question as: have you included any scid games databases on your images, and if so, which one?

BR, Johan

[Randy Reade]

Yes. But I don't remember which PGN file I used. It was a while ago. Also, there's a limit to how large a file you can use, if I recall correctly.

Randy

[Johan Sjöblom]

Update.

Now engine switching works. I had to move almost all picochess.py functions into the new MainLoop class but I have tried to keep all the functions as close to what they were, includin molli comments and changes :-) This means you should recognize everything in picochess.py, but the functions are not necessarily in the same order (line numbers).

Debian 64bit also works, but as I have not yet compiled the so files from source I cannot say anything about using DGT boards from Debian laptops, but I can say that currently only web play will work. Debian is easier to develop on as one can have a faster processor! Main target is of course Pi 3 and 4, and DGT hardware.

I have not tested Picotutor yet, but now that I finally got engine switching to work I will just test it hoping that it works out of the box.

I also need to fix the book and gamesdb for webplay on Pi. They now work on my Debian, thanx to the instructions I received. The install script automatically installs them.

Other stuff still on my todo list is to update at least pygame and bluepy libraries. I expect pygame to improve the sound handling and bluepy is important for our DGT connection.

So still stuff to do, but now the worst part is done, web and chess uci renewals. I expect the rest to be easier and ”just to do it” when I have time. I am playing Stockfish and LC0 when I test… so they are included. On the todo is also to start adding more chess engines… retros would be fun to have, but I have to complete the basics mentioned above first. And another long term architecture goal is to get rid of all the threads and make everything asynchronous… but thats not on the ”just do it” list. Python does not support multithreading so well and I would expect more async to give a performance boost and smoother execution with as small delays as possible.

Oh, and I am currently forcing the chess engines to think max 2 seconds, so that I can test faster. They still beat me anyway…

BR, Johan

[Johan Sjöblom]

Strategic question on PicoTutors future.

Background: I had a short look at the PicoTutor code. Unfortunately it is not using the UciEngine class, instead its directly calling the python chess.engine module itself, which means it needs the same redesign as the UciEngine. It also seems to start 2 more PicoTutor chess engines in addition to the one used by player.

The obvious strategic question is why do we need three engine instances? And I dont quite understand why picotutor uses 2… Does anyone know? We could use 2 engines in total (instead of 3) if we want a ”second opinion”, but we could also just use the same (1 only) chess instance that is already being used by normal playing modes (PONDER, ANALYSIS, etc)

i guess we need two chess engines due to skill level or lowered elo setting?  The PicoTutor engine should be running on highest (20) level, while the one you play can be reduced by skillset or ucielo. But why would we need a third one? Another fact: The new chess uci interface no longer includes the position in the engine. So even if we need a 3rd it can just be 2 threads asking the picotutor for analysis.

Does anyone know any reason or hints to why picotutor now has 2 engines starting (in addition to the one being played)

And if we have a reduced skillset engine that we are playing against, why would we take the move hint and ponder rolling infos from that weakened engine? Shouldnt we take those then from the picotutor engine? And if the engine is just watching the game, shouldnt we use the picotutor engine then if available? Or make picotutor the analysing one always started and available…. User could just make it silent by an ini option.

So the picotutor design is a strategic question, or at least an architecture question. What do we want to have? I would for instance want to give only 1 thread to the engine I am playing, and 3 threads to the picotutor and analysing/watching engine. So I would need to have 2 uci files for each engine. One for playing against, and one to analyse. Simpler would be to always give 3 threads to the analysing one and recommend 1 for the uci file.

Opinions or thoughts anyone?

[Johan Sjöblom]

Update: Investigated the Picotutor python code a little more and I found that Picotutor starts the two engines a little differently. One with less depth, and one with more deep search. I will try to manage for now with using only one Picotutor engine instance.

I also found out that Picotutor sends its own uci options to the tutor engine, so there is no need to have 2 uci files.

Lets see if I can fix the tutor easily into a first working version…

BR, Johan

[Dirk Mollmann]

Johann,

The tutor has been developed way before the PicochessWeb version which allows you to add independent analysis engines  for a game.

The tutor engine is a different from the main playing engine because not all engines do provide analysis information (eg none of the engines nor most of the old historic engines). 

It does not use the usi file settings but  specific internal settings.

And the tutor uses two short engine instance runs with different depths settings for more complex evaluations (like ? !  ??  !! (that’s the theory).

And it allows additional features like taking back moves in case of blunders for retro engines (retro engine don’t fulfill the complete icing protocol so normally take back is not possible)….

But it could and should be optimized 😉

 

Very impressed by your rework of picochess in order to support the newest libs and standards!

Big thanks!

Dirk 

Am 19.12.2024 um 16:02 schrieb Johan Sjöblom <messi...@gmail.com>:

Update: Investigated the Picotutor python code a little more and I found that Picotutor starts the two engines a little differently. One with less depth, and one with more deep search. I will try to manage for now with using only one Picotutor engine instance.

--

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/1494f470-08c7-4b18-be73-47cdbd567ad6n%40googlegroups.com.

[Johan Sjöblom]

Yes I found the complex analysis when it compares the deep and shallow engine results… I guess its easiest to just port the Tutor first, and then optimize later… I would think that one engine could be enough if we would just use the difference in centipawns between the user chosen move and the best move found by the engine, but maybe thats a too simple approach? Another simple one could be that if you manage to chose one of the top three moves (with acceptable difference in centipawns, whatever that is) it would also beconsidered good. Maybe there exists some chess research on the subject.

I guess the strategic question is what we want the tutor to be and do. Inform us of blunders, dubious moves, and really good ones would seem nice. Instant feedback on how much centipawns ”you lost” could also be nice…. 

So I have to decide if I go for the one-engine centipaw comparison, or port the old logic as is…

BR, Johan

[Johan Sjöblom]

I asked chatgpt, and centipawn loss and how often you chose the best move is a reasonable help to develop your game. It also gave a list on what grandmasters, strong club players, etc should have. So maybe I hofor the future and try to make just one tutor engine. I think it must be different as the engine you are playing could have skill or elo strength limitations.

[Johan Sjöblom]

I investigated the existing picoTutor a little more and its quite clever design. I will try to reuse the calculations formulas but I have to rearrange all the data coming from the new python chess uci engine

I had an idea on how to keep the double analysis info using just one engine instance instead of two; I will simply make the first analysis call restricted (time or nodes) and that first call then represents the shallow engine (min ply). The shallow info gives the ”obvious” moves. After that the rest of the analysis is considered as deep (max ply). In the long term I think this deep engine should be the one giving the rolling analysis currently seen from the playing engine. Whenever picotutor is enabled maybe all analysis info would come from that one. Especially if we can limit the number of multipv root moves to only top 3-5. For some reason the old code seems to use 200! but maybe thats because its using the same info as legal moves… but we dont need the engine to give us the legal moves, the chess python library is capable of that…

Interesting enough the picotutor calculation is based on a Cambridge user home page, but I could not find that info online any more. It would be nice to find the original ”research” that gave the base formulas for picochess engine. Good stuff anyway… nice way to determine excellent, good, dubious, and blunder moves.

Its a little bit of a tricky change, so lets see when I get it done. It might take a while…

BR, Johan

[gkalab]

Hi Johan,

Great work taking on the task of porting the code to the latest library versions!

I managed to track down the original Cambridge page via the Wayback Machine: https://web.archive.org/web/20210727122543/http://www2.eng.cam.ac.uk/~tpl/chess/annotation.html
Good luck with the implementation, and thanks for your efforts!

BR,
Gerhard

[Dirk]

Yes, that was the Page and information I used for the evaluation/annotation  of same moves in PicoTutor although I never was able to fully implement the suggestions because of my restricted python knoledge (and no ChatGPT at that time ;-)

I am sure the code / logic can be optimized, simplified and improved…

Maybe it is easier when starting from the scratch when trying to implement a better version of the tutorial later after porting the original version first.

And the information in the rolling display or by pressing the corresponding button of the clock is always the evaluation of the chosen opponent engine and not the tutor at the moment and I think that makes sense because you want to see the opponents thinking in most cases. (Although the retro engines don’t provide this information)

But we could make this configurable so that the user can choose if he wants to see the opponents or the evaluation of strong tutor engine like stockfish…

Dirk

Von meinem iPad gesendet

Am 22.12.2024 um 23:19 schrieb gkalab <gerhar...@gmail.com>:



To view this discussion visit https://groups.google.com/d/msgid/picochess/c871f776-7a09-4cc8-a315-9659eae06c08n%40googlegroups.com.

[Johan Sjöblom]

Thank you again gentlemen.

Great to have access to the principles used.

The new InfoDict structure is different to the InfoHandler used before so I more or less have to go line by line and try to guess what it is doing. I am also checking the "flow" from Picochess.py. When done I will step by step debug and see that I get corresponding information as the existing did from the old libraries. I figured out that we collect the "legal moves" which are basically the "best moves" sorted by score. And the pv_best_move is the best multipv/root-moves line. Yesterday evening after taking in the Christmas tree I was trying to figure out what the pv_user_move is used for... I assume it's the selection from the possible multipv/root-moves that the user has selected but that's where I had to stop yesterday...

I am changing the engine.py UciEngine class so that I can get multipv support AND support for always getting the first quick/shallow analysis result whenever I need it for the picotutor or other needs. The current engine.py in the repository only sends one InfoDict instance back at the moment so multipv support means that I will send a list of InfoDicts back... And I have to make the PicoTutor understand that data... I am making PicoTutor use the same UciEngine class as the main Picochess.py is using. I am trying to preserve as much as possible but in practice I have to change a little here and there as the data is now coming in a slightly different format.  I do not really use chatgpt or co-pilot for much more than basic assistance, I let it generate utility classes for me, but I want to take care of the "orchestration" and logical flow myself.  I am happy that I can use the AIs whenever I need help. 

I just have to go step-by-step, it will still take a while to check and understand the PicoTutor... Cambridge game theory definitely made it more interesting but the main struggle is to try to arrange data from InfoDict instead of InfoHandler... They seem to have the matrixes organised in different orders.... I no longer get a list of all the pv moves, each InfoDict contains one pv move in the new chess library (something I need to debug to confirm).

Yes, the engine user is playing against is still going to send the new pv, scores etc... Something I already completed earlier and it's already in the repository. I will just change that one so that it only catches the first pv move as the new engine will now send multipv.  Let's think about how to deal with the two engines in the long term.

And Merry Holidays... We have a white Christmas here in Vaasa, Finland. Some 20cm of snow so it feels like a real Christmas.

BR, Johan

To view this discussion visit https://groups.google.com/d/msgid/picochess/B1157195-2D27-416F-BCFE-DE6967D94E4B%40googlemail.com.

[Johan Sjöblom]

Research update: Figured out what pv_user_move was... I was confused as the pv_user_move[1] was assigned as the threat move. But now I see. pv_user_move is move list from the analysis.The user done move is pv_user_move[0] and if that move is a blunder "??" then obviously the response/countermove is the next one which is pv_user_move[1] and that is why it tells PicoTutor to say "the threat is ....". I was kind of wondering how a user move could be a treat move but its all clear now. The user move list is not only user moves! Its the entire pv move list.

Another confusing thing is that the old chess library uses InfoHandler and the new is InfoDict. What makes it confusing is that they have reversed the matrixes so what used to be move["pv"][index][ in InfoHandler is now move[index]["pv"] ... index is pv_no or pv_key depending on where in the picotutor code one looks. Anyway I have to "reverse" all the matrix referenses when fetching information from the chess engine... Not a problem, but confused me for a while...

I can preserve main part of the structure in Picotutor and optimise more later... So most things should be recognizable after this change... but I am removing all stuff that is not used at all, and I will rename legal_moves to best_moves as that is what it is.

[Randy Reade]

Great stuff, Johan!

Happy holidays to you as well.

Randy

[Johan Sjöblom]

Update on porting to new chess library.

I have committed the first baseline port of PicoTutor to use the new UciEngine class instead of using the old python-chess module. There was a suprising amount of work to be done to get the best and obvious moves out of the UciEngine class. I also made an effort to optimise so that only one engine is used. It calls analysis twice; first for low (depth = 6 as it was for the old PicoTutor first engine, and then for higher/deep it will analyse as much as time allows when user is "pondering" his move. Currently both are set by constant to 50. So if you are outside of the 50 best moves you will not get an evaluation, which might happen if the move is really bad. I am thinking that I could change the logic so that if the move is not found amongst the best moves it assumes a centipawn loss of the diffeence in the list... with that update you would get a blunder comment for being outside of the 50 best moves?! 

The score is now in centipawns from the user perspective (also for normal play). I had to edit the constants in picotutor_constants file that define the thresholds. The old constants had values like 4, and 2,5 etc. The first thing that happened to me in testing was that I lost 4 centipawns in a move and PicoTutor said it was a blunder ??. After adjusting the constants I got it to work. Constants can be further edited once I have tested more. I put the blunder threshold at 150 and bad move at 50 centipawns. I will still optimise a little bit by reducing the number of obvious moves from 50 ... I dont see why we would ever need to have more than say 5-10 obvious moves... but that may require me to change a little bit in the old logic.

After obtimising the Picotutor a little bit more I guess I will continue with the webplay book and gamesdb for PI 64bit... And then to upgrade the other libraries...

If anyone has time to test Picotutor comments are more than welcome, especially if there are crashes or freezes or strange behaviour in situations that could be easily be repeated, for instance by posting the PGN play file or something similar.

BR, Johan

[Johan Sjöblom]

Changed the logic so that if a user selected move is not found within the best moves it will assign the minimum score (score of the last best move on the list). That allows us to reduce the number of good moves so that we get a more deep analysis on the 20 top moves. I also added the capability to adjust how many obvious moves that are listed and I have set them to only 3. So the current setting is 20 best moves and 3 obvious moves. You can adjust them in picotutor_constants file: VALID_ROOT_MOVES and LOW_ROOT_MOVES respectively. 

The picotutor now gives interesting comments about opening moves... maybe it should be changed so that while in book  picotutor is not commenting... but its a little bit fun and good for testing.

If you run in debug mode you will get a nice listing of the 20 top best moves and their scores followed by the 3 top moves. It will also print how many centipawns you missed in your move.... Something we should bring to the display at some point as it gives a hint on how well you chose your moves. If we collect the entire history then it could print the average loss of centipawns at the end of the game...

We need to test play some to find reasonable values for best moves and obvious moves...  And of course it also depends if you are a high ELO, club player, or just playing for fun... The logic by which it is giving the evaluation is still the same... I am only trying to adjust what information to give the existing evaluation. I think that It would be possible to add more information to the best_moves tuples like best_score and min_score etc which would make it possible to evaluate the entire history during or after the game... including move takebacks... 

The comments start to sound a little bit fun now... The challenge is that it can miss a bad move if the 20th best move is not "bad enough" as that is assigned as score when you miss the top 20. On the other hand, if you miss the top 20 the move is at best questionable and maybe bad, so I could just change the logic a little bit to assign questionable move if you miss the top 20... Regardless of the difference in the centipawns...

PS. I have testplayed now on a Debian i5 computer so I will need to move to PI4 to see if that 20-3 adjustment is way off... as it does not compute as fast as my i5 Debian DS.

BR, Johan

[Johan Sjöblom]

Small update. I have learnt more about the existing logic. My chosen optimisation to have only some 5-10 obvious move and only 20 deep evaluated moves requires a bit more logic to be added to the evaluation, but I can still maintain the old logic… I will be back shortly with an update…

So I was not done with picotutor porting yet… BR Johan

[Johan Sjöblom]

Update. Picotutor is now ported. It needs some test playing to see if some tresholds need to be fine tuned. If debug logging is on it logs all the best deep and obvious move lists… it also logs how many centipawns you lost on your move…

And a happy new 2025. BR, Johan

[RandyR]

Hi Johan,

Perhaps you could enable the Issues and Discussions tabs on your GitHub repo.

I just started testing your latest code and one thing I notice is that if you run out of time you don't hear the "Lost on Time" announcement, and you can also not continue the game after you run out of time, whereas in v3 you can.

Randy

On Wednesday, November 27, 2024 at 12:30:22 PM UTC-6 messi...@gmail.com wrote:

Hi all.

Regarding the porting of picochess to the latest python and newest libraries.

I now have a baseline where all playing modes should work. There is no image based on this version yet, and it will take some testing and more development before there is any point to create one. But anyone who is able to test is welcome to do so. You need to have the ability to set up picochess without an image in order to test.

If you do test, please post problems found in this thread.

Code can be found in: https://github.com/JohanSjoblom/picochess.git

BR, Johan

[RandyR]

Actually, PicoChess stops responding - you can't access the menu via the web browser. Systemctl shows the service is still running.

Also seeing lots of these errors in the log: 

ERROR  picotutor - start: engine was never started in picotutor

Possibly because tutor-watcher and tutor-coach are OFF?

Randy

P.S. I'm testing on a Pi5 with a Millennium (Chesslink) board.

[RandyR]

Another issue I see is the write access when using BLE boards for the configuration file:

ERROR chess_link - write_configuration: Failed to save default configuration {'transport': 'eboard.chesslink.chess_link_bluepy', 'address': 'aa:bb:cc:dd:ee:ff', 'orientation': True, 'btle_iface': 0, 'autodetect': True} to chess_link_config.json: [Errno 13] Permission denied

Perhaps it would be best to give the pi user ownership of the entire picochess folder:

sudo chown -R pi /opt/picochess

Randy

[Johan Sjöblom]

Really great that you have time to test. I will try to figure out how to open the issues and discussion so that we can collect errors.

This evening I finally found some time to test the new picotutor on PI 4... and I think I need to find out how to increase capacity on the tutor engine analysis... on my Debian laptop it had enough capacity, but not on PI. The deep analysis in practice only goes to depths 5-9... and the shallow/low is set for 5. And I must have something wrong with the new eternal analysis, ... because if I think longer the deep depth should increase, but I don't see a clear such effect yet.

The timeout you mentioned I had not yet tested so good catch...

BR, 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/777bb650-2ba6-47df-b2bc-d4472480365dn%40googlegroups.com.

[Johan Sjöblom]

Discussion and Issues should be open now.

As an example I created one ticket, the simplest one, to give user full ownership in /opt/picochess

BR, Johan

[Johan Sjöblom]

Hello.

Mentioned issues should be fixed. They were quite easy fixes. Thanks again for taking time to test.

A more challenging fix was that I added a new experimental setting:

coach-analyser = True

If you have the watcher and coach active and add this setting above the PicoTutor will be used to give user hints for instance in Ponder mode. I did not add any menu option for this yet... its just a startup option. Its experimental and I am not sure if anyone would find it useful.

Normally the engine you are playing gives the hint. I am using this setting above to learn more on how to improve capacity for PicoTutor...  but there could be a possibility that some user wants to play against an engine that either is not so good, or has very low level setting. In this case you will get full strong hints from PicoTutor. Imagine you want to play against one engine A and you would like to get hints from the PicoTutor engine B... Now you can make the engines almost play against each other.

Not sure how the new chess uci API works though... It might be that the engine you are playing against is providing full strength analysis, and it only reduces playing strength when selecting from its own analysis. In that case this has no meaning.... But it was an interesting experimental feature to implement. It took more than 10 times longer than to fix the issues you mentioned.

BR, Johan

[Dirk Mollmann]

Hi Johan,

Eben of a modern uci engine  would always provide full strength analysis while playing on a lower level your new tutor feature would make sense for the retro mame engines which don’t provide this information at the moment.

Maybe we can have an additional option to provide inks the tutor information only in case of retro engines and for all other engine get the information from the playing engine as it is today!? Just a thought…

Dirk

Am 10.01.2025 um 18:59 schrieb Johan Sjöblom <messi...@gmail.com>:

Hello.

To view this discussion visit https://groups.google.com/d/msgid/picochess/391448b8-69ed-4609-a2ed-85f10711a86an%40googlegroups.com.

[Johan Sjöblom]

Hi.

Thanks for confirming. I have indeed noticed that tutor and main engine (both stockfish) does seem to provide the same best moves even though playing engine is on lower level. It was an experiment I wanted to do to make sure tutor engine and main engines produces the same info, and I had to study the picotutor in more detail. Normally the picotutor info is ”available too late” as its evaluating the result after a user move is a fact. Now I have made it so that picotutor can give information while the user is thinking… Just a learning experiment then, and a brain challenge. Tutor is now also using same UciEngine class as main picochess.py, and its only starting one tutor engine. That should be ieasier to maintain when new chess library versions come.

Later I was thinking that the picotutor could support also modes where the engine is only watching… Then the option to use only picotutor analysis would save memory and cpu because the ”playing/watching” engine would not be needed. Maybe more interestingly you could play through a real chess game, maybe your own games, and get picotutor comments while doing so (user playing both sides).

Anyway… still things to do on the basic porting… Next up I will try to compile DGT libraries from source and that might change the installation script slightly as I want to test if my Debian laptop could use my DGT board. After that there are still some libraries that are old, and I will just have to step through them and update them one by one and hopefully not find any big architecture changes like the chess and tornado caused.

BR, Johan

[Randy Reade]

I don't think the tutor and engine will always provide the same moves when the engine is set to a lower level, unless I'm misunderstanding you. Also, if by DGT libraries you mean dgtpicom and the shared library, those are only used by the Pi which is directly wired to the DGT 3000 clock. Your laptop can use a DGT board as long as serial TTY is enabled in the kernel.

Randy

To view this discussion visit https://groups.google.com/d/msgid/picochess/57a78fed-8f16-4bd1-8a32-0040f80659f7n%40googlegroups.com.

[Johan Sjöblom]

Hi.

Again I am learning something new about this. Thanks. First: yes sorry if my text was misleading. I also think the playing and tutor engine will provide the same moves. Yes I meant dgtpicom... I thought they were needed for generic DGT communication but now I understand more. Its only needed for DGTPi (and DGT3000 mod). I have a DGTPi myself, so before trying my ported code on it for the first time I will recompile a 64bit version. So just to see if I understand: This library is only needed when you have wired a PI to DGT, which is what DGTPi has internally?

I had a look a the python source code in dgt/pi.py and it seems to load this library using "etc/dgtpicom.so". If I now understand correctly it means two things:

1) I need to recompile a pi 64bit and the name shall be this dgtpicom.so

This one 64bit library file should then be enough for Pi3, Pi4 hardwired connections to a DGT clock hardware such as the DGT3000.

This code is only activated if you give the following option. I know you for sure already knew this, I just wanted to write this out "loud" so that you can comment if my assumptions here are wrong.

dgtpi = True

2) the following two lines in the install shell script (also in your repo) are not needed for anything at least not in my repo, as the code uses /etc/dgtpicom without any aarch64 or armv7l in the name.

ln -sf /opt/picochess/etc/dgtpicom_$(uname -m) /opt/picochess/etc/dgtpicom
ln -sf /opt/picochess/etc/dgtpicom.$(uname -m).so /opt/picochess/etc/dgtpicom.so

BR, Johan

[Johan Sjöblom]

Oh, and 3) I assume that the dgtpi.service is to be installed if and only if its on a DGTPi or DGT3000 mod.  I dont know what is best for the install script to do... Probably one should take an argument like "dgtpi" and if that argument is given in the install script then it installs this service, and also uses a ini file example with dgtpi=True... For now these steps would be manual when making an image for DGTPi clocks...? Or maybe you have a suggestion on how to deal with this?

[Randy Reade]

Correct. dgtpicom and dgtpicom.so are only needed when using a DGTPi or modded DGT3000.

For your point #1, you don't necessarily need to recompile the 2 files as the aarch64 version is provided by Ghislain. For point #2, the links created by Ghislain's install script will point to the correct version depending if your system is 64-bit or 32-bit. And, your point #3 is correct - the dgtpi.service is only needed when using a DGTPi (it's not really needed as all it does is write 'DGT P|' on the clock and produce a beep sound but it's nice to see/hear when booting up so you know something is happening).

Finally, just to clarify, I don't think the engine and tutor will provide the same 'best move' when the engine is set to an easier level. That wouldn't make sense.

Randy

[Johan Sjöblom]

Thanks to a suggestion from Randy my repo now works also on the DgtPi clock with Pi3. And as before on a Pi4, both are 64bit aarch64.

The latest lite image you get from pi imaging software only needed running my install script followed by an extra install script for dgtpi clock. The only manual thing I needed to do on the lite image was to install and configure pulseaudio. I think I will make a small install script for that also.

On the desktop image I used raspiconfig to change into pulseaudio and X11. Maybe that can be automated as well… My vision was that making an image could be fully automated.

To test, download the install-picochess script (using wget -L), do a chmod a+x to make it executable and then run it with sudo on a new image. You can run it in your home dir or anywhere. It will do git clone first time to /opt/picochess. You can rerun the installation script anytime and it will bring in updates with git pull. If you have used an old version of the install script you might need to download the new script as I have done some folder changes… when fixing the gamesdb, obooksrv, and dgtpicom. 

If you already have my repo a git pull followed by running the installation script will do the same.

On the todo list: update the other libraries also (now only chess and tornado web server are up to date to alllow latest python 3.11). Also on the todo list is to check the 5 commits I am behind and see if those fixes can be merged into also into my repo. Third and finally… more testing! And playing some fun games.

BR, Johan

[Johan Sjöblom]

Hi.

If I want to test a MAME engine on the picochess code that I am porting to new chess uci library, can you give me an example of a popular MAME engine that I can compile for aarch64?

And do I need to install some extra Raspbian package to support it? This questioncame up based on your recent post Randy where you referred to a MAME package.

Is there already aarch64 compiled engines in your repo Randy or in someone elses? I have only compiled Stockfish 17, and LeelaChessZero so far. I would like to add more engines and test.

BR, Johan

[Randy Reade]

You can copy the engines/mame_emulation folder, aarch64/mame folder, and aarch64/retro.ini file from my images to your setup and select a retro machine in the Engines/Retro Engines menu.

Randy

--

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/4e53792d-386c-4438-a130-08c366884a89n%40googlegroups.com.

[Johan Sjöblom]

Status update on the porting of picochess.

I have not yet tested the mame engines since I decided to make one more architectural change first. I am working to make a larger part of the picochess program asynchronous. Basically I am replacing Threads one by one with async. I have now reduced nr of threads by half. For this I have created a git branch, so that I dont ”disturb” the working main branch. The branch name is threads-to-async. If you specify a -b option this is what you get. One peculiar side effect of my first async tests is that speach comes before the web display updates… maybe that is just a good thing when playing on a DGT or other physical board?

Any brave testers are welcome to try it out.

BR, Johan

[Johan Sjöblom]

Small status update on porting picochess to the latest chess module.

I can finally see the end of the journey towards a asynchronous setup. Today (after w few weeks of other preparations) I finally turned the chess engine usage into async and I could see the potential of getting more calculations done by the engine. I have set the ground work so that I can prioritize whatever we want to prioritize in the execution. For instance I now have a higher priority on the web page move update than the talker and pgn update. I can add more message optimisations later like giving priority to move handling (both engine and human move messaging). It looks like the proof of concept I now have in a git branch shows that going async will allow us to make picochess more responsive on Raspberry Pi than before. And of course all new libraries are also going async, both tornado web and chess modules. I have left a few threads in the solution, especially on the board hardware so that we dont risk their functionality. When executing you can see that the number of threads have gone down from about 12 to just about 4. And the engine gets out more juice which I can see in the depth.

The async solution is still in a separate branch called threads-to-async, and if you want to test it you need to do git checkout -b threads-to-async. When I have time to test more, especially  on my DGT 3000 clock and a Pi4 with DGT board. After testing I can merge this branch as my main development and then start to stabilize the solution.

BR, Johan

[Dirk]

Sounds really impressive Johan!

Looking really forward to test/use your new branch/main development. Unfortunately I have to time and no hardware at the moment where I stay

Dirk

Am 02.02.2025 um 20:26 schrieb Johan Sjöblom <messi...@gmail.com>:

Small status update on porting picochess to the latest chess module.

To view this discussion visit https://groups.google.com/d/msgid/picochess/d6f4bba1-5ec9-44e4-985a-10ddead5e302n%40googlegroups.com.

[Johan Sjöblom]

Small update to last message.

I am now testing the threads-to-async on my DGT board.... I had to fix 2 issues and I still have at least one bug I need to find before the physical board work with async... Debugging it now. The fen_timer seems to expire twice... It plays as long as you don't move too slow!.. So yes its playing on the board but I have some problem with the async version of the fen timer.

BR, Johan

To view this discussion visit https://groups.google.com/d/msgid/picochess/4CB33637-DAA6-4AE2-8494-36419A582666%40googlemail.com.

[Johan Sjöblom]

Small update.

Oh the irony, to get the DGT board to work with async I replaced the fen timer in picochess.py with a class I have written and used a lot. The name of my new class is AsyncRepeatingTimer. I must have been tired. What did I expect? That the repeating timer would not repeat?? Not only did it expire once, but 2 or 3 times etc… Anyway, now that I DONT repeat the fen timer the DGT board play works nicely in the threads-to-async branch… And yes I get more depth than before which means picotutor also works a lot better. For sure there are still bugs with async, but again one step forward. Now it plays on the DGT!

To test this async branch you need to git checkout -b threads-to-async. Once I am happy with this new branch I will merge it into the main branch…

BR, Johan

[Johan Sjöblom]

Small update.

I rebased and merged the threads-to-async branch into master. So now there is only the normal master branch meaning that there is only one version to test. A normal git checkout or git pull now takes the ”full async” version as that is now the master.

BR, Johan

[Johan Sjöblom]

Hi Dirk (and others)

Thanks for testing using a Mame engine. I wonder which Mame engine would be easiest for me to install... I would of course prefer to use it on a Debian as I am developing on Debian.

I guess there arent any Mame engine that can be built from source any more? Could you recommend one mame engine from this list here that I could use as a Mame test: https://github.com/well69/Chess-Engines-for-Raspberry-Pi-by-Al/tree/master/x86_64

I tried looking for Boris online, but could not find any binary or source code. I guess the best place is to try to copy files from your latest image and test on my Pi4.

BR, Johan

[Dirk]

Hi Johan,

yes I would recommend using the mame installation from Randy’s images.

Indeed we can compile all the mame engines by ourself and from the scratch/ their sources and Randy does this when updating and adding new emulations.

As long as you can compile the standard mame project (although we use some very small modifications of the standard mame source

code) you will be able to add mame chess engines to PicoChess.

That being said mame engines are of cource a totally differentthing  than a standard uci engines which we normally use in PicoChess (besides other very old WB engines by using eg a WB-to-UCI converter etc.)

 

You can think of a working mame engines in PicoChess somehow like….

1. The mame emulator itself https://github.com/mamedev/mame

    Modifications which we normally use (Randy could explain in detail): 

a) only drivers of chess computers are included (so you can’t play Galaga and Donkey Kong with PicoChess at the moment ;-) 

b) we use a specific No-Nag version which disables all Nag-Screens/PopUps  (earrings and error messages which pops up at the start of a game and must be dismissed by the user - which we can’t when using no screen etc.). Don’t use these older precompiled mame engines entries from the github link you provided as they are outdated and mame itself and lua code is missing.

I really would recommend that you install one image from Randy and extract the mame folder where you just need to replace the platform specific  mame executable (called „mess" for historic reasons ;-) Maybe Randy will provide just the mame installations via a download link if we ask nicely  (I also just replace the mame folder in my own Picochess installations after an update provided by Randy).

This can be found eg under /picochess/engines/mame_emulator

2. The mame emulators „only" emulates the machine itself (which is already incredible) but in order to communicate with PicoChess we must use the „lua“ framework of mame (which originally was introduced among other things for allowing external softwares (eg AI so that they can play and learn winning against the aliens in space invaders etc. ;-). The lua frameworks allows us to „simulate“ an uci interface so we can play against these old emulated chess computers like (almost) using a real uci engine. The lua source code is not maintained in a central place except for Franz („fhub“) (author of his incredible (Windows) CBEmu project. He is adding new lua interfaces for the specific engines when there is a new engine and we can use it (unfortunately also by adding some modification because he either uses an older mame version (which has different lua syntax) or picochess uses some special handling because of the python-chess lib which has a specific "position fen“ or "position startpos" handling etc. Our lua source code (which is only interpreted) comes along with Randys mame installation in his images. /picochess/engines/mame_emulator/plugins/chessengine/interfaces

3. The rom files (we added just a few in the images which have no longer possible copyright issues or are offered by the authors free to use). These must be put for a specific mame version in the corresponding rom folder of the mame installation (meaning they could change from version to version which they sometimes do)  /picochess/engines/mame_emulator/roms

4. Finally we just add the needed retro.ini and possible *.uci entries for PicoChess. That’s it, eg. /picochess/engines/aarch64/mame

Dirk

Am 17.02.2025 um 09:18 schrieb Johan Sjöblom <messi...@gmail.com>:

Hi Dirk (and others)

[Johan Sjöblom]

Great help again, thanks.

I suppose it is time to explore the world of MAME. I was born the late 1960s, and although I am not yet 60 years I am close :-) I began using computers in the early 1980s, so I may find some nostalgia on this journey. Thank you for instructions; let's see if I can get them to work.I am currently downloading the latest worm images to get going...

I assume that I now have to install the armhf architecture to support 32 bit on my 64bit Pi OS. The obvious way to do it is

> sudo dpkg --add-architecture armhf

> sudo apt update

> sudo apt install libc6:armhf libstdc++6:armhf

Would you immediately know of any other armhf libraries that I need to install to have enough 32bit support for MAME engines?

BR, Johan

[Dirk]

We are already on 64Bit with most of our engines and of course mame….

Von meinem iPad gesendet

Am 17.02.2025 um 12:31 schrieb Johan Sjöblom <messi...@gmail.com>:

Great help again, thanks.

--
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/99c009fd-d88d-4113-8a18-47384425eb7dn%40googlegroups.com.

[Dirk]

... and yes playing against and seeing the artwork of these old chess computers is really fun and I enjoy it very much!

[RandyR]

Just be aware that there are alot of moving parts in the mame emulation and errors may not necessarily be a problem with the PicoChess code. The stock/included roms should be ok, though, for testing.

Randy

[Johan Sjöblom]

I might need some help or hints.

I copied the entire engines/aarch64 and mame_emulation content from the Desktop image onto my development Pi4. I tried to start playing Mephisto IV, it seemed to load correctly, but it threw an Exception when attempting to ask for a computer move (go). My question is: do I need to build mame myself even though I copied the desktop image folders mentioned. Do I need to copy more, or install some service, or start something else for Mame support?

And I guess the Boris engine was not on the image, or is the name something else?

I will continue to test in the weekend or next week, any hints would be appreciated.

BR, Johan

[Randy Reade]

No. The executable will be OK. It could be that you are missing some libraries needed for MAME. I would suggest running it outside of PicoChess. Via SSH:

cd /opt/picochess/engines/mame_emulation

DISPLAY=:0 ./mess -plugin chessengine mm4

Then either use a mouse on the artwork or enter UCI commands in the terminal:

uci
isready
position startpos moves e2e4

and so on...

If that works, it must be something in the PicoChess code that's not working.

If it doesn't work, paste the output here.

Randy

--

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/32026f20-c654-4925-91a4-a788dfd37521n%40googlegroups.com.

[Dirk]

Some OS releases ago these were the necessary lins that I had to install if I remember correctly to run mame:

sudo apt install libsdl2-2.0-0 libsdl2-ttf-2.0-0 libqt5widgets5

Dirk

To view this discussion visit https://groups.google.com/d/msgid/picochess/CAE5Wduv-hsH46BvAjJMJmy1hRp0U_K4A_DbgOFh_oGuS%2B6HZOw%40mail.gmail.com.

[Dirk]

Trrying Johan's updated PicoChess 4 version for the fist time ...

First impressions: 

- easy and quick installation starting with a stock Raspian Image (according to Johan's quick installation manual)

- very responsive and lightning fast responsive - especially with my Revelation iI which always has been very sluggish

Well done, Johan!

More intensive  testing must be done...

Thanks

Dirk

Greetings from BORIS ;-)

[Johan Sjöblom]

O wow. Thanks for testing. Yes, it definitely needs more (testing). Issues can be opened in the github, kind of like a todo list.
Async is supposed to be faster and more responsive than threads. There are still ways to make it faster but I think what is needed now is to stabilise the current version.
I have tried to keep the main picochess.py logic the same so that all contributors would still recognise and find everything in the code.
I have also avoided changes I'm menu.py and all the boards python. The boards are intentionally left as threads still to keep them the same as before.
I would also need to test Boris chess engine, I am not sure where to find it though...
BR, 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/507f2221-29c8-42af-91f5-3bf659853b0cn%40googlegroups.com.

[Dirk]

Johan,

I think for testing purpose it is  use the machines which are ready to use in Randy’s in

Images.
Regarding Boris: we supply all files needed in Randy’s images as well except for the rom. Have a look at the earlier mentioned CBEmu project by Franz (“fhub) - a search and you find what is missing ;-) Be sure you use the newest rims as we use newer mame version.

Dirk

[Johan Sjöblom]

One mame error fixed in picochess code. I test played Mephisto IV and it worked. I did not test the artwork yet… I guess I need to activate the artwork in the pico menu?

BR, Johan

[Johan Sjöblom]

OK, now I am playing Mephisto IV with artwork on the ported Picochess. What a nostalgic moment :-)

BR, Johan

[Dirk]

Cool - if you play with fullscreen artwork display you can switch to the picochess gui by lifting a piece and putting it back.

To view this discussion visit https://groups.google.com/d/msgid/picochess/c97a4b5d-7264-4a71-9834-7cc25903fc6en%40googlegroups.com.

[Johan Sjöblom]

Hi.

I have sent out invites to a few persons to allow code development for anyone who wants to contribute. So if you got a message with an invite, its authentic, I sent them. And we have the first contribution as a branch in the code already :-)

Anyone who wants to join, just reach out and I will send out an invite.

You need to have a github user, and you need to go through the steps of the github authentication which is well described on github get started:

https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent

Many of you have already done this...

We would definitely need to find a JSP frontend developer who can fix the layout of the web page :-)

[Johan Sjöblom]

Hi.

And thanks to all that are testing and creating issues.

Not sure if this is of help to anyone, but if you want to add all Pi engines from Randy's latest image to a setup where you are testing my fork you need to copy all the files from the /opt/picochess/engines directory on the image onto your new setup. I do it by inserting the image SD card in a USB reader on the Pi4 and copying from the mounted card.

I have created 2 files of 0,5G each, one for engines, and one for mame support from the image, but they are too large to upload as attachments to this group, at least I was not allowed to do that.

BR, Johan

[Amp]

I'm having a lot of problems adding the folders for version 3.
At first it was a permissions issue, but once it was resolved, none of the historical engines folders work, neither does the mame one, although I consider that "normal", I don't know what it could be...
I have a Raspberry Pi 3b+

[Johan Sjöblom]

Yes. I can confirm that I cannot run a mame engine like Mephisto IV on my DGT Pi 3000 clock (which is a Pi3). I started to try to get it to work step by step and the first errors went away with the following libraries that you seem to need (someone mentioned them earlier and I have not tested step by step that the error message actually change as you add more libraries). I wonder if its even possible to run a mame engine (without artwork of course) on a Pi3… Has anyone succeeded with the existing Picochess version 3.x?

Anyway, a list of libraries you have to sudo apt install (at least):

- libsdl2-2.0-0

- qt5ct (this is what makes me question this, why would I need QT on a lite image without x-window?)

- libsdl2-ttf-2.0-0

Now I no longer get a specific library error when loading Mephisto IV but it does not load… Not sure yet what exactly goes wrong…

Could someone with more picochess experience comment if its possible to run mame engines on a lite image?

Yours, Johan

[Johan Sjöblom]

if you Antonio have a Pi3 with x-windows and display attached to Pi3 then you could test after installing the libraries listed in previous post… I do have some extra Pi3 somewhere on my old 3D printer, if I can find it I could try to install a Pi3 standard image with x-window on that one.

[Johan Sjöblom]

Mephisto IV mame now works on my DGT PI 3000 clock… It was only the 3 libraries listed above that was needed AND a reboot. After the reboot it worked nicely…. It took a while to test after reboot since I had an intence chess game against Patricia on the Clock… It went into a rook endgame before I could win.

Mephisto IV now plays also on a light image… but I would need to add the above mentioned libraries to some installation script… If you install them yourself it will work with mame engines on Pi3.

I need to test on a Pi4 first if its ok to add those libraries to a standard Pi4 desktop image. If it is then I will add mentioned libraries to the main installation script. Otherwise I will just add it to the dgt-clock installation script.

BR, Johan

[Amp]

Special & Historical Engines     ==   Error all engines

[Johan Sjöblom]

Correct, I agree. The special and historical engines have not been fixed yet in picochess 4.

https://github.com/JohanSjoblom/picochess/issues

In the issue list above we have listed at least pgn_engine and fics listed as issues. I will have a look at the pgn_engine at some point, but not necessarily today. I had a short look yesterday but I need to learn more about the expected functionality.

All modern and most retro should work… But not all yet. I have played against Patricia and Mephisto IV. They seem ok.

Yours, Johan