Und das ist schon ein erhebliches Problem. Derzeit wird Cortex-M verwendet. Mit dem onchip-RAM ist kein Linux machbar, auch nicht µc-Linux. Selbst das braucht um die 4MB und läuft wegen des dynamischen Programmloaders außerdem sowieso nicht ohne weiteres aus dem ROM. Wenn man das will, muß man es von SD-Karte (oder SPI-Flash) in ein externes RAM (auf dem Board zu bestücken) laden und von da laufen lassen. Blöderweise ist die Programmausführung dann um einen Faktor 6-9 langsamer, das wäre also unsinnig.

Dann kann man auch gleich einen Cortex-A nehmen - allerdings landet man dann bei sowas wie Raspi+DGT, und Batteriebetrieb kann man auch vergessen.

Das hieße also, wenn man beim M7 bleiben will, kein Linux. Auch kein Windows (deswegen auch kein CB-Emu). Man müßte dann schon irgendein RTOS nehmen, da gibt es durchaus OSS-mäßige in sehr genügsam. Dann aber geht die UCI-Ein/Ausgabe nicht mehr unverändert z.B. mit Linux-Sourcen, das müßte man dann alles anpassen.

Außerdem hat ein klassischer Schachcomputer gar nicht erst ein Betriebssystem.

Aber zum eigentlichen Rechner - wenn die Bedieneinheit zur Serie noch etwas edler gemacht wird, könnte das sehr in Richtung TASC gehen, und das meine ich positiv. Der Preis klingt angemessen, und ich finde es mutig von Millennium, daß sie sich das trauen.

Braucht man das denn?

Für eine UCI-Engine braucht es zwei Voraussetzungen: Das Steuerprogramm muss die richtigen Kommandos geben (für den Status einer Partie braucht es etwas Speicher) und der Speicherabdruck des Programms darf nicht zu groß sein.

Ich kann mir daher nicht vorstellen, dass einfach eine bestehende Engine einfach neu für ARM kompiliert wird. Hashtables mit malloc() dürften fest als Array angelegt werden, Programme mit großem sonstigen Datenbedarf sind ungünstig usw.

Aber Millenium könnte hier mit der einmaligen Erstellung eines Steuerprogramms und nur geringen Änderungen am Source Code Engines anbieten. Damit könnte das immer größer werdende ROM besser genutzt werden als mit dem zwölfzigsten Eröffnungsbuch.

Leider schließt dies die einfache Erstellung eigener Engines aus. Ob in dem von mir beschriebenen Szenario die Schnittstelle offen gelegt würde?

Das ist schon das Problem - das wird bei UCI-Engines mit piping gemacht. Dazu braucht man vor allem erstmal einen Unterbau mit pipes.

Und ja, eine bestehende PC-Engine auf einen Cortex-M zu kriegen, wenn man kein OS hat und auch noch die Speicherbegrenzung an allen Ecken, das ist ein erheblicher Aufwand, und bei vielen Engines (speziell denen mit magic bitboards) sogar IMO unmöglich.

Danke an Rasmus und Solwac; wenn man eure Beiträge liest, merkt man als Programmierlaie erst, wie schwierig manche unserer Wünsche umzusetzen sind...

viele Grüße
Robert

Aber das benötigt doch kein Linux.
Pipe heißt nur, dass die Ausgabe eines Programms die Eingabe eines anderen ist. Dafür braucht es nicht viel Speicher.