New Picochess v0.9n base image

[mvanthoor]

Hi :)

A small update on the progression of a new 0.9n base image. As Dirk has requested that I don't develop on top of his personal version 2.01+ version (due to 'poor code quality', according to himself), I've started on setting up a new 0.9n only image, on Buster.

I've tried several things: starting with the minimal Buster image and adding what I need, or starting with Buster Lite and removing what I don't need. In the end, the result is about the same, but the latter is much faster.

I now have an image that can do the following:

- Buster, latest version

- It has the Pixel GUI (but stripped of everything not needed for Picochess)

- Can be accessed through SSH

- Can be accessed through VNC (I replaced the proprietary RealVNC with TightVNC)

- It exposes the Pi Home folder as a readable/writable share on Samba

- It exposes /opt/picochess as a readable/writable share on Samba (the picochess folder is owned by "pi", so no sudo necessary in there)

The image is now down to 2600 MB from the original 3250, and Picochess is already on there. As this is a Raspberry image, I'm going to remove the x86 engines, which will make the image another 90MB smaller. After dd-ing the image from the card and compressing it, this would be about 1500 MB.

I'm now at the point where I can actually install Picochess. If I have time to do so, I'll do so this weekend, and I'll try to take dgtpicom and dgtpicom.so updates into account. I'll also take the updated requirements.txt into account, and try to add the bluetooth fix script.

I'd be great if people could help test this, because I don't own a bluetooth board nor a Revelation, so I cannot test these things.

I'll post an update after I finish installing the services and such, and the image becomes playable.

Questions: Who is now the owner of the jromang Picochess repo? Is it Shiv, or Jürgen, or still Jean-Francois? In other words, if I make a pull request there to include the updates I'm adding (dgitpicom, etc...), will the pull request ever be accepted?

If this image is finished, what version would it be?

Version 1.0 and 2.0 are already taken.

I'm thinking about version Picochess 10 (instead of 1.0), and then just going by 11, 12, 13, 14... with each new update.

Could this image become the 'new' base for new development (possibly backporting some of the 1.0 and 2.01+ functions in due time), downloadable from Jromang's picochess.org website?

After this image is finished and tested, I'll extend it into a development image, and I'll try and start upgrading requirements to newer versions. As far as I've been able to see, this will take... some... time. Most of that stuff is REALLY far behind.

[Shivkumar Shivaji]

Hi,

Answering your question: Who is now the owner of the jromang Picochess repo? Is it Shiv, or Jürgen, or still Jean-Francois? In other words, if I make a pull request there to include the updates I'm adding (dgitpicom, etc...), will the pull request ever be accepted?

Please send your pull request. I will review and accept it. Once you are able to manage the code, you can also be a collaborator. All the collaborators of Picochess are looking to simplify this load, and anyone can accept the pull request. I personally got busier to help Picochess. I also lost some interest in Chess in general but would love to see more contributions. My chess strength has sort of plateaued at the Fide Master level. However, I am still playing chess online and maybe I can raise my chess level. I find chess boring to study, to be honest, that's the main reason for my stagnation. However, this can change with exciting new releases in Picochess?!

Putting on a software developer hat, the image size reduction is FANTASTIC! Congrats. Would love to have your image be the base image for all future dev! You can choose any version number you desire, greater than 1.0. I do have plans to support another board with the Picochess image, the King Chess Element, which I now own. However, a lot will depend on my availability and my motivation level for chess in general. :)

Shiv

--
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 on the web visit https://groups.google.com/d/msgid/picochess/2d4876ec-c40a-4b71-bbeb-8c57338cabcbn%40googlegroups.com.

[mvanthoor]

Thanks Shiv :)

I see I made two mistakes already. The three images are:

1. Raspberry Pi OS with Desktop and recommended software
2. Raspbery Pi OS with Desktop
3. Rasbperry Pi OS Lite

I preferred the old names: Raspbian Full, Lite, and Minimal; and I made a mixup there.

I started my image from version 2, the one with the desktop but no original software. This original Buster image as provided by the Raspberry Pi Foundation is about 3725 MB after download and unzipping it. If I compress the img-file using 7-zip at Maximum setting, it becomes about 790MB. The originally provided ZIP file, is 1128MB. Compressing the raw IMG with 7-zip is a reduction of roughly 79% (!). (My earlier calculation was with standard ZIP-settings.) This 7-zip version of the image is 30% smaller than the original ZIP-version.

After stripping this image, and adding PicoChess, the data partition is 2600 MB, but I need to add another 250 MB for the boot partition. This makes the image a raw 2850 MB, assuming GPARTED can shrink the data partition as close as possible to 2600 MB. If I can also achieve 79% compression on this image, the 7-zipped download size would become about 2850 * 0.21 = ~600 MB; much smaller than I just posted, even when the previously omitted boot partition is added in.

I've downloaded the 0.9n image from Jürgen's site. It is 1.4GB. After I unzip it, the image becomes almost 8 GB. This is an 8 GB card which has been imaged and then compressed, so it contains a lot of empty / zero space. It could take a lot of time to write to another card, and it won't fit all 8 GB cards. They're not all exactly the same size.

I'm going to first shrink the data partition with GPARTED to avoid this. If I can keep the raw IMG under 3800 MB or thereabouts, it should fit on any 4GB card. The only 'catch' is that the data partition needs to be resized to full size with raspi-config again.

I could have stripped X and the desktop (-400 MB), didn't need to use VNC (-45 MB), and could have left SAMBA out (-39 MB). I left the desktop and VNC in on purpose. That way, people can easily configure WIFI and Bluetooth by connecting the Raspberry to a screen, or by connecting it with Ethernet first and then logging in over VNC to activate Wifi and set up the bluetooth connection. I added SAMBA so one could add engines and other stuff, and/or (re)configure picochess without even having to log in. The shares make it very easy to get stuff onto the Raspberry.

My first pull request won't contain any changes to the code. It will only be updates:

- Update dgtpicom and dgtpicom.so to the last versions as found in this group, provided by DGT.

- Add the Bluetooth fix from this group, as provided by (I think... don't know for sure on top of my head), Eric.

- Add the latest requirements.txt as provided by Al.

Of course, I'll look up who provided what, and give credit where credit is due.

After everything is tested, the version number would be PicoChess 10 (instead of 1.0), and as said, newer versions would then be 11, 12, 13, 14... After all is done, I'd be happy to see this new image  become the new base for new development.

Then, I'll see how hard it's going to be to actually change PicoChess to be compatible with newer versions of Tornado (5.x breaks the webserver, I've seen), and python-chess (problems after version 22.x). I'm going to try and upgrade all the requirements one release at a time: Tornado 4.5.1 -> 4.5.2 -> 4.5.3 -> 5.0... fix where necessary during upgrades, until I get to the latest version, and then do the next requirement. As said: this is going to take some time.

Thanks in advance for anyone who wants to help and test all of this stuff.

[Scally]

Hi Marcel,

I’m always available for testing ....,


Al.

[RandyR]

As am I. 😊

Randy

[mvanthoor]

Thanks Al and RandyR :) The Picochess group has been somewhat quiet as of late.

Today I've created a new image. I removed too much from the first image, and extending it into a development image became rather hard. (I removed some stuff that apt wouldn't replace on re-installation.) So, I made a new one. This time, I left the help files, the Debian Reference, and stuff such as the Chromium browser installed. I also added the wsdd script (see attachment), so Windows-computers can now see the Rasperry Pi in their Network folder.

This image will be the basis for a development system; even possibly developing directly on a Raspberry Pi if someone wants to do that.

Tomorrow I''ll finish installing the first version of Picochess, after which I'll update some of the files and requirements. After I get everything to work, on my USB board, I'll copy the SD-card and strip more stuff from it. (Browser, Reference, GPARTED, etc....), leaving only Picochess, the GUI, VNC server, SSH access, and Samba. (It will be smaller than "Raspberry Pi OS with Desktop", but a bit bigger than "Raspberry Pi OS Lite.")

So in the end, there will be two images. One big image that can be used for development (extending it with compilers, editors, and so on), and one smaller image that would be used by people who only want to create an SD-card, and use Picochess to play against.

BTW... I'm contemplating to get another DGT board. My current one is 13 years old, and functioning fine, but it uses the very old Hirose 4-pin USB connector. This connector is getting a bit wobbly (it pulls out about 2mm when I remove the cable.) It seems to be a known issue, as DGT has a video on Youtube, posted 10 years ago, on how to replace this connector. I'm thinking to e-mail DGT to send me such a connector (assuming they can still do so), and then get a new wooden board. They have a mini-USB connection. (That will also have the benefit of using a 50-70cm cable, instead of the 1.5m Hirose cable I have now; I have not been able to find anything shorter in the Netherlands.)

I won't be purchasing the Bluetooth board because it's about €150 more expensive than the USB-board, and the Raspberry and the board will be right next to each other. (And I've got some bad experiences with Bluetooth in general.)

After I finish the two images, I'll post them to Google Drive. For now... maybe I'll upgrade my webspace which I've created for my Rustic chess engine. (Obviously, my own engine will end up in the Picochess images I create, replacing one of the default ones. Rustic is going to be GPL v3 open source, after I finish it, by the way.)

[Shivkumar Shivaji]

Just FYI, anything that works on the USB board will overall work faster on the bluetooth board. Thus, if it works well on the USB board, it will def work on the Bluetooth board.

Glad to have more developers on board. I heard of Rust quite a bit but dabbled in Golang instead. Good to have more choices!

In terms of web hosting. Github now supports large files, but there is a limit of 100MB per file. If the file is open source however, you can use Jfrog - https://jfrog.com/open-source/ via bintray and it should be free hosting.

FYI, I started a docker build for the Picochess image a while back. Now that is not being used, but it would simplify the image building a lot. Maybe I can revive it someday. Then all base image management is easy too via Dockerfiles.

If you have a dockerhub image, you can upload this to dockerhub.com for free as well.

Shiv

--

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 on the web visit https://groups.google.com/d/msgid/picochess/1241809c-0c8c-46bc-9825-3b88dd6b9914n%40googlegroups.com.

[Shivkumar Shivaji]

Wow,

Thats amazing! If you are optimizing so many things, maybe its worth considering a Docker image actually. Should work fine for the USB board, using root privileges for kernel space. I have to dig for my old attempts - but here is one in some form - https://github.com/jromang/picochess/blob/d75caf9bc74a20ad73a16d75cedcfdc63a8a3870/test/Dockerfile

Happy to try to help on a docker image actually. This would simplify so much of the whole build process. Additional engines, publishing images etc would be easier.

Shiv

To view this discussion on the web visit https://groups.google.com/d/msgid/picochess/b1d247c4-849c-4df2-bad8-32fd44f25057n%40googlegroups.com.

[mvanthoor]

Hi Shiv,

The one thing I'm worried about with the BT-board is the battery. DGT doesn't seem to sell it. I've only found one place in Europe that sells it. ( https://www.niggemann.com/en/bluetooth-accupack-assembled.html ) I don't feel like dealing with a rechargeable battery if the board is right next to the Raspberry. And I tend to use these things for a LONG time. If the connector on my current USB hadn't gotten a bit wobbly (I hope DGT can still send me a replacement, before the connector actually starts failling), and it would have been mini or micro, I wouldn't have even thought of getting a different board.

With regard to docker: I have no experience with it. To some extent, it's just another layer of abstraction I don't care for. I can add engines and .uci-files easily enough using the Samba share over the network. At least, I think so. I'll have to test it.

Tomorrow, or monday, I hope to have the first versions of these images finished.

[Steven Strange]

If I remember, the battery is exactly like this. A very common type for little drones.

https://www.ebay.it/itm/3-7V-380-1200mAh-Lipo-Battery-For-Syma-X5C-X5SW-X5C-1-Hubsan-H107-Quadcopter-8D/202991427479?hash=item2f433b5f97:g:s-YAAOSwGPdevZ4X

[mvanthoor]

Hi :) Thanks, I'll look into that... but I doubt I find the BT-board worth the extra  €150 or so, because the raspberry is going to be right next to it. A 50cm cable would suffice.

[mvanthoor]

The new development base image is coming along as planned. I've cloned PicoChess from jromang's repository to my own, and set up all the security stuff on Github and the RPi, so I can now push and pull to my own repository. I still have to actually install and then test PicoChess.

After testing and verifying that it works, I'll copy the SD-card and strip all development stuff from it to create the "play only" image.

I've already pushed  draft roadmap to my repository on how to reach PicoChess version 10. (It's basically 1.0, with the dot removed... because both 1.0 and 2.0 are already taken and well known as personal versions.)

The roadmap / plan is here. If someone has some input regarding it, I'd love to hear it.

https://raw.githubusercontent.com/mvanthoor/picochess/4e6f012ae357c62673b1f361bf4b1a2841907439/roadmap_version_10_beta_1.txt

[RandyR]

Hi Marcel.

I like the roadmap but am not sure it's correct saying picochess doesn't work on the RPi 4. I think the main issue with the RPi 4 is when you are wiring it directly into the DGT 3000 clock. I built a picochess version using the latest RPi OS on both the DGTPi and RPi4 which are functioning. I get some Warnings but I don't know if it's software or hardware. Also, I'm dealing with some ghosting issues that I'm waiting for DGT Support to help sort out. 

I'm looking forward to helping test whatever you come up with. 😊

Randy

[mvanthoor]

Hi Randy,

You misread that, about not working on the Pi4.

PicoChess will run on it. I'm talking about the last official image as provided on Jürgen's site (which contains 0.9n). That won't run on the Pi4.

Read it again :)

I'll create new threads for the developer and player images after they are done, and bump the threads when the images get updated.

[RandyR]

Ah, yes. My bad. The image is built on Stretch which doesn't run on the RPi 4. I was thinking Picochess 0.9n itself.

https://github.com/tosca07/picochess/releases/tag/v0.9n  

Randy

[mvanthoor]

The new PicoChess 10 Beta 1 images are basically finished. I stripped my dev image from everything that's unneeded. Partition usage by the OS and PicoChess is 2.5 GB, but because of file system stuff, I can't shrink further than 3610 MB.

This image will fit on a 4GB card. A 7zip-compressed version has a download size of 985 MB (Compared to the previous base image, which ks 1.4GB to download and expands to 7.6 GB.)

After I finish the dev-image (woth git in there and so on), and testing them to see if they actually write and boot correctly, I'll open a new thread to describe the features and for downloading them.

[mvanthoor]

Hi :) Is it (still) necessary to replace the original hciuart.service in /lib/systemd/system with the version that comes with PicoChess? After PicoChess has started, it already sees the BT-interface:

pi@picodev:~ $ systemctl status picochess.service
● picochess.service - PicoChess stand alone chess computer based on DGT board
   Loaded: loaded (/opt/picochess/etc/picochess.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2020-08-03 21:43:56 CEST; 23min ago
 Main PID: 347 (python3)
    Tasks: 19 (limit: 3890)
   CGroup: /system.slice/picochess.service
           ├─347 /usr/bin/python3 /opt/picochess/picochess.py -w
           ├─527 /bin/sh -c /usr/bin/bluetoothctl
           ├─528 /usr/bin/bluetoothctl
           └─540 engines/armv7l/a-stockf

There is a difference; the PicoChess version directly attaches "serial1" to BT. Is this necessary because the DGT Boards use a virtual com port? (At least they do on Windows.) I can't test if BT will actually work with a DGT board if using the original hciuart.service that comes with the OS because I don't have a BT board.

I tried to set up BT audio on a different SD-card, but it was quite hard to set up, and resulted in poor and choppy sound quality, even after trying  a gazillion different fixes. Connecting to the same BT speaker from Windows 10 produced audio as good as if it came from the sound card, and pairing and setup was not an issuue. It doesn't inspire confidence in the Linux BT capabilities, to be honest.

I was trying BT audio, because the voice output from PicoChess was very choppy and "bubbly" when I tested it yesterday. I seem to have fixed the audio, at least outside of PicoChess; VLC plays music in decent quality, YouTube video's have normal audio without hitches, and the PicoChess voice clips sound fine when played with VLC. I assume they'll sound fine with PicoChess as well; if not, then there's a problem there somewhere.

[Lucas van der Ploeg | DGT]

Hi Marcel,

 

The hciuart.service needs to be replaced to enable the standby mode of the DGT Pi. You can turn the DGT Pi “off” by pushing the button on the bottom and leaving the power connected. When pushing the button again the Pi restarts but the Bluetooth chip does not and is in a different state as the pi expects. This means Bluetooth no longer works after standby. The new hciuart.service fixes this.

 

Best regards,

Lucas van der Ploeg | DGT

--

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 on the web visit https://groups.google.com/d/msgid/picochess/92e07d30-c64e-4e71-b9ca-4ea9b4d557c7n%40googlegroups.com.

[mvanthoor]

Hi Lucas,

Thanks for the explanation. I'll replace the hciuart.service file with the one from the PicoChess repository.

Slowly the kinks are worked out and the image is coming together nicely. If all goes well, it won't be too long now before first tests can begin.

[mvanthoor]

Hi Lucas,

I just installed the hciuart.service from PicoChess.

- stop and disable the existing service
- rename it to hciuart.service.original
- symlink to the picochess version
- enable it to start on boot, and start it / reboot.

It works, but... I noticed that -sometimes-, the service doesn't start, or it terminates. When I check it with "sudo systemctl status hciuart.service", the error is that it timed out. Is this a  known problem?

● hciuart.service - Configure Bluetooth Modems connected by UART
   Loaded: loaded (/opt/picochess/etc/hciuart.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2020-08-04 16:46:54 CEST; 2h 20min ago
  Process: 329 ExecStart=/usr/bin/hciattach /dev/serial1 bcm43xx 115200 noflow - (code=exited, status=1/FAILURE)

Aug 04 16:46:24 picodev systemd[1]: Starting Configure Bluetooth Modems connected by UART...
Aug 04 16:46:54 picodev hciattach[329]: Initialization timed out.
Aug 04 16:46:54 picodev hciattach[329]: bcm43xx_init
Aug 04 16:46:54 picodev systemd[1]: hciuart.service: Control process exited, code=exited, status=1/FAILURE
Aug 04 16:46:54 picodev systemd[1]: hciuart.service: Failed with result 'exit-code'.
Aug 04 16:46:54 picodev systemd[1]: Failed to start Configure Bluetooth Modems connected by UART.


Also, bcm43xx seems to be a very old driver according to the debian wiki:

https://wiki.debian.org/bcm43xx

"Removed from Linux at 2.6.26".

It feels as if I'm missing something. Does the RPi really use very old chips, or is this bcm43xx something else as compared to the driver I'm referring to in the above link?

On Tuesday, 4 August 2020 at 10:50:02 UTC+2 Lucas van der Ploeg wrote:

[mvanthoor]

Just tested this again: I rebooted the RPi, and the hciuart.service is not active.

I'm going to try and copy it instead of symlinking it, but I assume it makes no difference. I symlinked the other services and targets as well.

[Dirk]

I guess that’s why we still have Bluetooth problems and need the fixing scripts!?

But I almost ever take my pi completely from the power supply and then it will work when starting again...

Am 04.08.2020 um 22:21 schrieb mvanthoor <mj.va...@gmail.com>:



To view this discussion on the web visit https://groups.google.com/d/msgid/picochess/4fcf1a9e-7da3-4446-bef1-bc53cdc0581en%40googlegroups.com.

[mvanthoor]

I dislike wireless connections. All of them. More trouble than they're worth, to be honest... particularly BT. WIFI is OK, if you have business-class hardware...

I don't know yet what the BT fixing script does. I'll have to look for it in the group. I hit upon it at random while reading around. The point in this case is that sometimes, after the pi boots up, BT is not there. It's like McAvity from Cats: you know he's in there, but you can't find him.

Or....

Maybe we could leave the original service installed, and then install the picochess one as hciuart_pi.service. Then start the original from .bashrc if running on a standalone raspberry pi, or the other when running on a DGT Pi. I also start the VNC-server from .bashrc, first detecting if it's already running or not.

Is the DGT-clock somehow detectable from the command line?

[mvanthoor]

Update... there does seem to be a difference.

If I make a symlink, /lib/systemd/system/hciuart.service --> /opt/picochess/etc/hciuart.service, and then enable it for autostart on boot, "sudo systemctl enable hciuart.service" does this:

Created symlink /etc/systemd/system/multi-user.target.wants/hciuart.service → /opt/picochess/etc/hciuart.service.
Created symlink /etc/systemd/system/hciuart.service → /opt/picochess/etc/hciuart.service.

If I copy the service from the /opt/picochess/etc folder into /lib/systemd/system/, enabling for autostart does this:

Created symlink /etc/systemd/system/multi-user.target.wants/hciuart.service → /lib/systemd/system/hciuart.service.

It seems the symlink causes a circular reference in this case, or something along those lines. (In the symlinked versions, enabling the service ends up with TWO links; in the copied version, there's only one.) In the symlinked version, I also had problems starting and stopping the service, which I don't seem to have in the copy-version.

To make sure that there aren't any similar problems with picochess and the dgt services, I'm going to unlink them and make a copy as RandyR did in his installation tutorial.

[mvanthoor]

The copy-version also sometimes fails to initialize due to timeouts. I'll have to test to see how often it fails. Maybe it would be best to just disable the service on boot, and start it in .bashrc, using an "hciuart_running" flag to block multiple starts, just as I did with the VNC server. That also had trouble starting as a systemd service, but when started from .bashrc, it has never failed me.

[mvanthoor]

Immediately, one after the other:

pi@picodev:~ $ /usr/bin/hciattach -t 30 /dev/serial1 bcm43xx 115200 noflow -
bcm43xx_init
Initialization timed out.

pi@picodev:~ $ /usr/bin/hciattach -t 30 /dev/serial1 bcm43xx 115200 noflow -
bcm43xx_init
Flash firmware /lib/firmware/brcm/BCM4345C0.hcd
Set Controller UART speed to 115200 bit/s
Device setup complete

I'm confused. I'll see if I can start it using a while loop in .bashrc, keep trying until it succeeds.

[mvanthoor]

Weird. It seems to fail *every time* on the first start; and on the second start, it succeeds.

[RandyR]

Perhaps try installing pi-bluetooth, Marcel.

Randy

[mvanthoor]

Hi,

It is already installed (and the bluez and bluez-utils as well). It comes installed by default.

[mvanthoor]

Hm.... your install script copies hciuart.service from the picochess/etc directory to /lib/systemd/system. Maybe at the time you wrote your script, there wasn't a hciuart.service, or it was called differently, so you weren't overwriting anything.

Could it be that I need to install the picochess hciuart.serice under a different name alongside the standard hciuart.service?

I'll remove / purge bluez and pi-bluetooth, reinstall them to get the default behavior, and then I'll try the hciattach command from picochess's hciuart.service.

And then I'll go to bed.

[RandyR]

Something else I read is that if you reinstall Bluez, you should reinstall pi-bluetooth.

The instructions I listed were mostly copied from http://docs.picochess.org/en/latest/installation.html#manual-installation.

Randy

[mvanthoor]

That's not it either. Now it fails with "Failed to write reset command."

It's so weird that when I replace the service, then try to start it, it almost always fails. But on the second attempt, it immediately initializes and the BT-icon appears in the taskbar.

[mvanthoor]

Known problem on the Raspberry Pi 4:

https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1862831

The RPi4 enables bluetooth using the script in /usr/bin/btuart.

=========================================================================================

pi@picodev:/lib/systemd/system $ cat /usr/bin/btuart
#!/bin/sh

HCIATTACH=/usr/bin/hciattach
if grep -q "Pi 4" /proc/device-tree/model; then
  BDADDR=
else
  SERIAL=`cat /proc/device-tree/serial-number | cut -c9-`
  B1=`echo $SERIAL | cut -c3-4`
  B2=`echo $SERIAL | cut -c5-6`
  B3=`echo $SERIAL | cut -c7-8`
  BDADDR=`printf b8:27:eb:%02x:%02x:%02x $((0x$B1 ^ 0xaa)) $((0x$B2 ^ 0xaa)) $((0x$B3 ^ 0xaa))`
fi

if [ -e /sys/class/bluetooth/hci0 ]; then
  # Bluetooth is already enabled
  exit 0
fi

uart0="`cat /proc/device-tree/aliases/uart0`"
serial1="`cat /proc/device-tree/aliases/serial1`"

if [ "$uart0" = "$serial1" ] ; then
        uart0_pins="`wc -c /proc/device-tree/soc/gpio@7e200000/uart0_pins/brcm\,pins | cut -f 1 -d ' '`"
        if [ "$uart0_pins" = "16" ] ; then
                $HCIATTACH /dev/serial1 bcm43xx 3000000 flow - $BDADDR
        else
                $HCIATTACH /dev/serial1 bcm43xx 921600 noflow - $BDADDR
        fi
else
        $HCIATTACH /dev/serial1 bcm43xx 460800 noflow - $BDADDR
fi
pi@picodev:/lib/systemd/system $

=========================================================================================

It first creates a BDADDR which is later used by hciattach; but the RPi4 does NOT get a BDADDR.

Then it checks if BT is already enabled or not, and exits if it's running.

Then it finds where uart0 and serial1 are.

If they're the same (and they are on the  Pi4), it checks if uart0 has 16 pins. On the RPi 4, it does have 16 pins (I ran the commands to determine which of the final commands it would choose.)

So if I'm not mistaken, btuart comes up with this command in the end, on the raspberry pi 4:

$HCIATTACH /dev/serial1 bcm43xx 3000000 flow - $BDADDR

Filling in the vars (remember $BDADDR is empty on an RPi4, so nothing there)...

Default hciuart.service resulting command, always succeeds:

/usr/bin/hciattach /dev/serial1 bcm43xx 3000000 flow -

Picochess hciuart.service, always fails on first attempt, then succeeds:

/usr/bin/hciattach /dev/serial1 bcm43xx 115200 noflow -

=========================================================================================

Proof of concept.... I removed bluez and related tools, pi-bluetooth, and re-installed. BT came up correctly.

Then I disabled the service, rebooted, and logged in with SSH.

Then I ran the fist command, which is the result of the btuart script, which is called by the default hciuart.service.

This command immediately succeeds:

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Aug  5 03:34:35 2020
pi@picodev:~ $ /usr/bin/hciattach /dev/serial1 bcm43xx 3000000 flow -
bcm43xx_init
Flash firmware /lib/firmware/brcm/BCM4345C0.hcd
Set Controller UART speed to 3000000 bit/s
Device setup complete
pi@picodev:~ $

Reboot, login again...

And then I ran the command that comes from the PicoChess hciuart.service.

This command fails. On second try, it succeeds.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Aug  5 03:37:36 2020
pi@picodev:~ $ /usr/bin/hciattach /dev/serial1 bcm43xx 115200 noflow -
bcm43xx_init
Initialization timed out.
pi@picodev:~ $ /usr/bin/hciattach /dev/serial1 bcm43xx 115200 noflow -

bcm43xx_init
Flash firmware /lib/firmware/brcm/BCM4345C0.hcd
Set Controller UART speed to 115200 bit/s
Device setup complete

pi@picodev:~ $

I cannot explain why the command fails the first time, and then the second time, it succeeds. It may be a bug in hciattach, in bluez, or the Raspberry Pi4 either can't handle the lower speed, or the noflow setting.

Solution...?

- If running on Raspberry 4, test if the DGT Pi works correctly with the default hciuart.service.

- Start the service in .bashrc, using this workaround (where hciuart in this case is the current Picochess version):

HCIUART_STARTED=""
while [ -z "$HCIUART_STARTED" ]
do
        sudo systemctl start hciuart.service
        HCIUART_STARTED=$(systemctl status hciuart.service | grep '(running)')
done

If the DGT Pi / clock MUST have the speed of 115.200, and noflow set to work correctly, this is the only way I can think of to get it initialized like that. If the hciuart.service from picochess works on RPi3, 3B and 3B+, the above script will initialize on the first pass; on an RPi4 it will (probably....) initialize on the second pass. There is a change it'll never initialize, and then .bashrc will hang. (An extra or-statement with a counter can be included, but then Picochess might start without bluetooth.)

I hope this is enough information for Lucas/DGT to say something sane about this, IF they even want to support Picochess on a Raspberry Pi4 in a DGT Pi.

[RandyR]

Impressive troubleshooting, Marcel! The post you linked was the one I read suggesting to install pi-bluetooth. When you said it was in the image by default I assumed Raspberry Pi OS already had the fix. I guess there’s more to it.

Randy

[mvanthoor]

Lucas says this, earlier in the thread:

" The hciuart.service needs to be replaced to enable the standby mode of the DGT Pi. You can turn the DGT Pi “off” by pushing the button on the bottom and leaving the power connected. When pushing the button again the Pi restarts but the Bluetooth chip does not and is in a different state as the pi expects. This means Bluetooth no longer works after standby. The new hciuart.service fixes this."

I do not know how previous versions of RPI OS initialized Bluetooth. Maybe they did it differently. In this version, there are two differences between the final command as constructed by btuart, and the command as used by hciuart.service from Picochess:

- btuart sets speed to 3.000.000, and uses 'flow'

- hciuart.service from picochesss sets speed to 115.200 (the hightest 'default' speed that should work on any version of 'serial1'), and 'noflow'

Replace 3.000.000 from the btuart command with 115.200, but keep 'flow': this works every time, but BT is slower, obviously.

/usr/bin/hciattach /dev/serial1 bcm43xx 115200 flow -

Replace 'flow' from the btuart command with 'noflow' but keep the 3 million speed: (this fails every time on the first try)

/usr/bin/hciattach /dev/serial1 bcm43xx 3000000 noflow -

So it's the 'noflow' parameter that causes problems. Either BT/Uart on the RPi4 can't handle it, or the current version of hciattach is broken. This post:

https://e2e.ti.com/support/legacy_forums/embedded/linux/f/354/t/608587?Linux-CC2564-btattach-command-in-new-bluez-release

says that hciattach has been replaced with btattach since BlueZ version 5.37. BlueZ is now at 5.50.

I'll test btattach this evening using the parameters of hciuart.service from picochess.

[Lucas van der Ploeg | DGT]

If I remember correctly the only change I had to make is the baud rate of the Bluetooth module. At first boot the module has a fixed baud rate. Changing this means the second boot won’t work because the pi assumes the default baud rate. In the service I could change the baud rate to the default value instead of a higher one.

 

For the new version of RPi OS a lot has changed I guess. Maybe the same trick of only changing the baud rate in the new script still works.

 

Best regards,

Lucas van der Ploeg | DGT

From: pico...@googlegroups.com [mailto:pico...@googlegroups.com] On Behalf Of mvanthoor
Sent: 05 August 2020 09:54
To: PicoChess <pico...@googlegroups.com>
Subject: Re: New Picochess v0.9n base image

 

Lucas says this, earlier in the thread:

--

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 on the web visit https://groups.google.com/d/msgid/picochess/c5c41f45-95e6-4bae-ad4b-2cf615795ca0n%40googlegroups.com.

[mvanthoor]

In the new image I could change the baud rate in btuart, in the line the Rpi4 will execute.

Or copy btuart and put it in /opt/picochess/etc, change it there, and then add instructions to either replace hciuart.service (Pi3's) or btuart (Pi4's).

I'll change the speed to 115200 in the line in btuart that the Pi4 will execute. People with DGT-boards and/or DGTPi 3 or modded DGT Pi 4 will then have to test it.

[RandyR]

On Tuesday, August 4, 2020 at 7:35:41 PM UTC-5 mvanthoor wrote:

Hm.... your install script copies hciuart.service from the picochess/etc directory to /lib/systemd/system. Maybe at the time you wrote your script, there wasn't a hciuart.service, or it was called differently, so you weren't overwriting anything.

Marcel, I just checked the Buster image (2020-02-13-raspbian-buster-full.img) I used in that install tutorial and there IS an hciuart.service already in /lib/systemd/system. Here are the contents:

[Unit]
Description=Configure Bluetooth Modems connected by UART
ConditionFileNotEmpty=/proc/device-tree/soc/gpio@7e200000/bt_pins/brcm,pins
Requires=dev-serial1.device
After=dev-serial1.device

[Service]
Type=forking
ExecStart=/usr/bin/btuart

[Install]
WantedBy=multi-user.target

The file is also present in 2020-05-27-raspios-buster-lite-armhf.img. Not sure if that helps much.

Randy

[mvanthoor]

Hi Randy,

This just refers to the btuart file I posted earlier.

It actually seems we need different inits for different raspberry pi's.

Gentoo says this:

https://wiki.gentoo.org/wiki/Raspberry_Pi#Bluetooth

Note
The hciattach command may need to be repeated if it fails. There is patched version in the Arch Linux AUR repository available, which may work more reliably

I have seen references on GitHub, that hciattach (which comes with blueZ) is changed to be able to work with the firmware for the chip that's on the raspberry pi, but that change isn't completely reliable. This patched version has been patched again, by someone else, which is in Arch's AUR repository. hciattach has been deprecated for btattach since bluez 5.37.

Looking into btattach, these commands seem to be equivalent:

/usr/bin/hciattach /dev/serial1 bcm43xx 115200 noflow -
/usr/bin/btattach -B /dev/serial1 -P bcm -S 115200 -N

So I built a service on top of btattach. However, there is an issue with this as well: for some reason, it needs a sleep 1s before the actual invocation of btattach, or it won't work. I found this out through StackOverflow, in a different, unrelated Bluetooth problem. It fixed the BT init there, and here as well.

This service attaches serial1 to UART reliably, on the Raspberry Pi 4B:

[Unit]
Description=Configure Bluetooth Modems connected by UART

ConditionFileNotEmpty=/proc/device-tree/soc/gpio@7e200000/bt_pins/brcm,pins
Requires=dev-serial1.device
After=dev-serial1.device

[Service]

Type=simple
ExecStartPre=/bin/sleep 1s
ExecStart=/usr/bin/btattach -B /dev/serial1 -P bcm -S 115200 -N

[Install]
WantedBy=multi-user.target

This works every time on the RPi4. When I reboot and then log into VNC, the BT-icon is there; so I assume it works.

With regard to flow and noflow, the Gentoo wiki refers to a forum post:

https://forums.gentoo.org/viewtopic-p-8220298.html#8220298

The user there followed the same trail I did, also ending up at the btuart script, which walks through some logic to determine on how to attach BT. (See my post above, or read the one I just linked; the logic is there same.)

As it turns out:

• RPi3B: /usr/bin/hciattach /dev/ttyAMA0 bcm43xx 921600 noflow - <bdaddr>
  
• RPi3B+: /usr/bin/hciattach /dev/ttyAMA0 bcm43xx 3000000 flow - <bdaddr>

The RPi3B (which is in the original DGT Pi if I'm not mistaken; please correct if wrong) needs to be initialized with noflow, which is why the current Picochess hciuart.service works for the default, unmodified DGT Pi.

The RPi3B+ needs to be initialized with "flow".

The RPi4B seems to be able to do both, but "noflow" only works when using btattach AND have a sleep of 1s just before the command. Also, the RPI4 does not need (or want) the BDADDR parameter, while other Pi's may (or could) need it.

So we need different BT init commands for different RPi's. Because btuart already exists and does all the logic for the Pi's, my advice would be to keep this logic intact, and instead of replacing hciuart.service with a one-liner, replace btuart with a Picochess version. This version would then replace each command as necessary:

- Set the baud rate to 115200. (According to Lucas, this might be the only change we need)

- Set "noflow", even on the RPi4, replacing hciattach with btattach if  necessary

If we would want to support all the things, we would need the following:

A RPi3B, Rpi3B+, and RPi4B (I only have the RPi4B). Maybe even a Pi Zero and/or Zero W

A Bluetooth Board

A default DGT Pi with an RPi3B

A modded DGT Pi with an RPi4B

I can extract the commands that steer the logic from btuart, but I can't run them to see the results other than the ones for the RPi4B. So, I only know where the script ends up (and thus, which init command it performs) on the RPI4. I would need the output of the commands to be able to determine with which command other pi's end up.

[RandyR]

Correct. The stock DGTPi has the RPi3B. Unfortunately, I don’t have a Bluetooth board, so can’t test that side.

Randy

[dirk.m...@googlemail.com]

Don't know if this helps but I am using a modded DGTPI with a PI3B+ inside, a standalone PI3 and a standalone PI4 - all in bluetooth mode.

They all use the same Raspian OS image running the current newest OS updates.

I have installed Erics bluetooth fixing script (on all devices - same image) only the DGTPI flag in picochess.ini is of course different in DGTPI - this was especially necessary for the PI4.

I don't use the picochess hciuart.service anymore (this caused problems lately) meaning I have NOT copied the picochess version into /etc/systemd/system.

All three PIs work fine and connect to either the bluetooth eBoard or the Revelation II.

Dirk

[Scally]

Hi all,

Same here, I’ve had a RPi 3, a RPi 3b+ and now a RPi 4 in my DGT Pi, all work with no changes. I have recently applied Lucas’s dgtpicom & dgtpicom.so changes and the DGT Pi with RPi 4 inside still works, as does my stand alone RPi 3b+ and another standalone RPi 4, all connect to my Revelation II via Bluetooth fine.

I also have Eric’s Bluetooth fix script, which works via bash or python, both called via an added line of code in sudo crontab -e (I’m using his later python script).


Cheers,

Al.

[mvanthoor]

Hi Dirk,

Thanks for the information.

Would you be so kind to either point me to the BT fix script you have installed, or send it to me? I can find several different versions (as Al mentioned, Python and Bash, with different installation instructions). There's already a BT-script from 2014, also by Eric Singer, in the picochess repository. That probably did something similar, but is an old version.

If you would prefer to send it, you can do so to mail (at) marcelvanthoor (dot) nl.

It is helpful to know that you have NOT copied the hciuart.service from PicoChess. That should mean that you are using the default version that comes with Buster, which basically executes /bin/btuart, which will then connect serial1 to BT correctly for the different Pi's.

If this works fine in combination with the BT fix script, I'll set it up the same way.

With regard to the BT-board: which USB-connection does it have? Mini, Micro, or even C? IIRC, the current wooden boards have Mini-USB, but I don't know for sure. (My old wooden board has the Hirose connection.) Is the BT-board over BT actually faster (move recognition, displaying moves on the clock) as opposed to when it is connected to USB?

[mvanthoor]

Hi Al,

Very good to know. So you also haven't copied/installed the hciuart.service that comes with Picochess (and thus you are using the default from Buster), and only installed the Python BT-fix script?

Same question; could you send this script to my e-mail, with a short instruction on how to apply it? The address is mail (at) marcelvanthoor (dot) nl.

After I implement either this version or the version by Dirk, I can start finishing up the new base image so it can be tested :)

[dirk.m...@googlemail.com]

Hi Marcel,

this is the „bluetooth fixing thread“ with Eric’s scripts:

https://groups.google.com/g/picochess/c/4dyvi9di6Nc

I have the bash shell script installed and Al the python version - both obviously work, I couldn’t see a big difference…

I will attach both files again in this post.

Just copy the scripts to the picochess/script folder and add the command line to crate like Eric has describe, eg 

@reboot /opt/picochess/scripts/fix_bluetooth_4b.sh 1>/opt/picochess/logs/fix_bluetooth_4b.log 2>&1

for the bash shell scripts.

Yep - it looks like we can use the default hciuart service (at least in combination with the fixing scripts  for a PI4).

Regrading the USB connection of the BT board: It is a mini USB connection (so not the smallest one) and USB-C is only used in the latest DGT Smart Board (USB only).

I am happy with the speed of the BT connectivity but I think USB might be a little fester - at least what I can tell from various YouTube movies.

Before my Personal V 1.0 version it was a real pain for me to play quick games especially via BT because you often got a „set pieces“ message when executing the engines and your own move too fast in sequence.

With my „Pre-Moves“-Option it is now a real joy for me to play rapid and Blitz games with picochess (you can even execute your own move before the engines move ;-) There might be better or more elegant ways to implement this feature but thatÄs all I could do and for me it works.

By the way: with a BT board and its built-in battery and with an external battery for the DGTPI it gets almost kind of a mobile chess computer solution with almost no cables…

Dirk

P.S: I have never "requested" that you shouldn't use my 2.01 version for your work or base image- I just said it makes no sense to commit changes to my repository because I have already enhanced and further developed my version and I would not recommend to implement some features exactly like I have done etc... So it is up to you to use it or not.

[mvanthoor]

Hi Dirk,

Thanks for posting the files and instructions. I will look into them tomorrow.

Because of this statement, "I would not recommend to implement some features exactly like I have done etc...", I gathered that you wouldn't be happy with your code ending up in a new image as the basis for new developments, because you're not satisfied with this code.

Di you wish me to rephrase this in the roadmap or remove it entirely?

It would be a pity if your work wouldn't be used, because you dud implement some interesting features. I fully intend to "forward port" those to a PicoChess version after it has all its libraries updated. I would certainly appreciate a collaboration for achieving this.

With regard to the pre-move function... I played a very fast game yesterday to test the new player for move announcements. Move announcements are much faster than the clock, but the setup didn't go down the drain. After the computer was out of book and started thinking, the clock was still displaying past moves for some seconds :P

Maybe the USB-board is different in this regard to the BT boards.

[Dirk]

Hi Marcel,

no, all fine - I just wanted to clarify…

Regarding your fast play: that has nothing to do with my pre-move function.

So are you saying you play the computer move before you see it on the clock because you can hear it already?

Displaying things on the clock and playing voice announcements are separate event loops/handlers - that’s why they are processed independently and always in sequence of the events - so that can happen all the time.

Using book option will be of course faster than waiting for an engines answer and when you play very fast there won’t be delays in processing both event queues - I think that was one reason for Jürgen to automatically switch off voice announcements in 09N when having less than 10 seconds or so game time (can’t remember these good old days ;-)

I had no problems with that but I think that might be even more an „issue“ when you use stand alone PIs and not a DGTPI or a clock with PI in "DGTPI mode“ even though you use USB instead of BT.

All my PIs are connected in DGTPI mode (I have one DGTPi and the other stand alone PIs connect to a REV2 what fortunately behaves like a DGTPI (at least regarding the display).

Dirk

> --
> You received this message because you are subscribed to a topic in the Google Groups "PicoChess" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/picochess/KtgbdEBgppM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to picochess+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/picochess/1619a7e1-3257-420b-b8cf-eaddd68605abo%40googlegroups.com.

[mvanthoor]

Hi,

I just installed Eric Singer's BT fix-script for the 4B (Python version) from this thread:

https://groups.google.com/g/picochess/c/4dyvi9di6Nc

Later today I'll clean up the image and shrink the partitions. Then I'll create and zip the image, and post it on my Google drive as picochess_10_beta1.7zip, in a new thread. Then it can be tested, and after it is found to work correctly on all relevant raspberries and with all boards, it can become the new base image.

After I recover from my cataract operation, I'll start looking into upgrading dependencies.

At this point, there are just a few small changes:

- Add a roadmap

- Fix the warning when starting / enabling dgtpistandby.service

- Replace "ogg123" by "play" to improve sound

- Install the BT-script

- Replace "Pico 0.9n" with "Pico 10" on the clock

- Move outdated or unused files in /opt/picochess/scripts to an "old" folder

- Move outdated or unused files in /opt/picochess/etc to an "old" folder

(In the final version, those "old" folders can be removed)

There have been no functional changes to the 0.9n code.

After the image is done, I'll open a new thread.

[RandyR]

On Saturday, August 22, 2020 at 9:53:37 AM UTC-5 mvanthoor wrote:

After I recover from my cataract operation, I'll start looking into ...

That's funny.

Looking forward to it, Marcel. Hope the recovery is speedy.

Randy

[mvanthoor]

Thanks Randy :)

It wasn't intended to be funny :X I just assume/hope everything will be without complications.

It seems the BT Fix script interferes with the Argon One shutdown script for my Argon One case.

As people may know, the Raspberry keeps some power on the board, including the USB-ports after it shuts down. I don't want that, because my DGT-board is connected permanently. Therefore I looked for (and found) a case with a powerbutton: the Argon One. It includes a script that monitors shutdown events, and if the RPi shuts down, it writes a signal cutoff command to the GPIO. (The power button is connected to the RPi through GPIO.) The RPi's lights go out (literally), as if you pulled the power.

This works fine with my own Pi that's now connected to the board, but the development Pi behaves strangely since I installed the BT Fix script: the RPi's light goes out, but it immediately comes on again. The RPi *IS OFF*, however, because I can't SSH into it anymore. Most of the time the light goes off permanently after some time, but twice, it didn't go out.

I'll have to uncomment the fix script in crontab to check.

(As I don't have a BT board or a DGT Pi, I'll be uninstalling those scripts in my own personal image.)

[mvanthoor]

The problem isn't the BT fix script. It could also be the DGTPi services that causes my development Pi to sometimes not turn off completely.

The Pi connected to the DGT-Board does the same thing: the light turns off, on, and off again in the space of about two seconds. I have never seen the light to stay on. The only difference between the Pi connected to the DGT Board and the development Pi are the DGTPi services, and the BT Fix script.

[RandyR]

Marcel, I think that will be the issue trying to use one image for both wired and unwired Pi's without any command-line intervention to disable the DGTPi services in the unwired Pi, if I'm understanding what you mean.

Randy

[mvanthoor]

To be honest, I sometimes frustrated seeing stuff fail left and right on Linux all the time, be it desktops, servers, or embedded systems. It seems that it still isn't common practice in Linux to actually CHECK if a service or software can be started or actually needs to be started.

I'm thinking of setting up a cascading system:

1. Create one image that completely works for a Pi + Clock + board, and use that for development. (That is what I'm doing now.)

2. Create an image on the basis of 1., and add the DGTPi services and test it separately. Recommend to not use this for stand-alone Pi's.

3. Create an image on the basis of 1., and add my own stuff such as the Argon One shutdown script. Maybe it isn't really necessary, but I just don't want the Pi to power the board all the time, even if it's only standby power.

Then I can maintain all three images with apt for the Linux software, and I only need to copy the Picochess software from my development Pi to the other images when needed.

Because of the issues the DGT Pi has with standby, dgtpicom and dgtpicom.so (if not using a stock DGT Pi and image) and the fixes needed for BT, I'm not inclined to go out and buy a BT-board and DGTPi for my own use... but it also means it's not possible for me to test these setups.

[mvanthoor]

Oh, and what I meant was:

Both the development Pi and the one I use for playing exhibit the same behavior when turning off:

The light turns off, on, and off again, in about two seconds, and then it stays off. The Pi should be powered down completely. Cutting power to the Pi is done by the Argon One script. (The Argon One case connects to the Pi's GPIO to make this possible. It sends the cut-off signal through the GPIO, just as connecting the pins would do by using a physical button.)

However, the development Pi sometimes does NOT turn off the light after it comes on again. (But most of the time, it does.) So, I can't guarantee that the Pi is turned off completely. I've connected a card reader to the Pi by USB, which has its own LED. It turns off, even when the Pi's light doesn't, but I can't be sure that there is no power in the card reader. It might be receiving power, but not enough to actually turn on the LED. (Standby power.)

The only way to be 100% sure that there is no power in the Pi is when it's on-board LED is off. Normally you can only achieve this by using a physical power button, by software that controls the GPIO, or by pulling the cable. (Or use a USB-cable with an on/off switch.)

[mvanthoor]

And, the only difference between the development Pi and the one I use for playing is that the development Pi has the DGTPi services and the BT Fix script installed, and the one for playing doesn't.

[RandyR]

I wonder if uhubctl would help? You can also get a port tester for pretty cheap if you want to see if there's power there. Or unplug the board. I turn off my RPi4 after shutdown and (usually) unplug the DGTPi, but I'm not too worried about leaving it in standby mode.

Randy

[mvanthoor]

I think it's the DGTPi services that are causing this problem. I've just put the card from my development Pi into the playing Pi, and now it also doesn't power down some of the time. After I disable the DGTPi services, it does power down correctly.

Even so, there is a hardware difference: The playing Pi powers down much quicker than the development Pi.

The playing Pi goes like: light off, on, off, in a total of about 2 seconds.

The development Pi does this: light off, light on (wait for about 6 seconds) light off

They behave like that with both the playing card (without DGTPi services), and the development card (DGT Pi services disabled).

They both have a problem powering down when the DGTPi services are enabled.

I'm going to create two different cards: one configured for the DGTPi with the services enabled and the DGTPi option in picochess.ini set to true, and one with the DGTPi services disabled (but installed in the correct place) and the DGTPi option in the ini-file disabled.

Then people should be able to just download the correct image for their setup and have it working correctly, without failing services on a normal Pi, and without powerdown problems (if one has a case like the Argon One) on a standalone Pi.

( Obviously none of the images will have the Argon One powerdown scripts. I'll install those onto my own image only. )

[mvanthoor]

Some problems had to be investigated and ironed out, but the new image is now available in this thread:

https://groups.google.com/g/picochess/c/hvBMzyGwKOA

Please comment in this new thread. Thanks for anyone who has provided information, guidance, or scripts.