Hier übrigens noch eine Umsetzung mit dem 2KB Programm: http://bralug.de/wiki/BLIT2008-Board_spielt_Schach

@Fred Super zusammengefasst soweit!

Bei der Software sollten wir uns vielleicht am Umfang der neuesten UCI-Engines orientieren. Ich weiß zB, daß die Rybka Engine sehr sehr groß ist, schon die v2.2 war knapp 2MB groß. Damit schätze ich daß in der Zukunft auch die durchschnittliche UCI-Engine größer als früher sein wird.

Die Größe der Firmware von unserem Teil dürfte kaum 32-64kB übersteigen, wäre bei der Berechnung somit gegenüber der Engine-Größe eher vernachlässigbar.

Aber mindestens 4MB ROM bräuchten wir. Kann man den Atmega eigentlich mit externem RAM & ROM bestücken, oder ist es einfach kein guter Controller, um mit solchen Datenmengen zu operieren?

Das nächstbessere wäre ARM7, der könnte mit solchen Größen auf jeden Fall arbeiten, wenn auch extern.

lustig fand ich eigentlich das im Filmbeitrag der Conchess die üblichen "schwierigkeiten" mit Reedkontakten hatte )

ich denke Rybka auf so ein schwachen Hardware macht gar nicht soviel sinn. es gibt andere Programme die aus der schwachen Hardware viel mehr rausholen könnten. Rybka wurde für größere Rechner konzipiert.

Das Tiger-Programm, Fruit oder Rebel würden auf ner schwachen Hardware viel mehr bringen.

__________________
Die ganze Welt des Computerschachs

Stimmt, wichtiger als die nominelle Stärke wäre Optimierung auf die Spezialhardware, sprich ARM RISC Architektur.

Ich erinnere mich Hiarcs 9.6 und CT14.9 auf Palm 68k/33Mhz verglichen zu haben und da sah Hiarcs 9.6 überhaupt kein Land (6-0), weil Tiger trotz nominell schlechterer Algorithmen die Hardware einfach besser ausnutzt und schneller läuft auf dem 68000.

Trotzdem wäre der Einsatz von Rybka & anderen neuen Engines nicht uninteressant. Unser Gerät soll ja nicht maximale Spielstärke bieten, sondern Abwechslung ?!


Tiger läuft auf diversen PPCs eher schlecht als recht. Fruit kommt bestimmt als erstes drauf.

Statt Rebel würde ich eher Gideon Madrid 3.1 und King 1.0-2.5 vorschlagen

ich denke the king war auch immer eine kleine engine.
richtig.

__________________
Die ganze Welt des Computerschachs

Hallo Handyfreunde, kommen wir mal wieder zum Thema

Hallo Theo,

natürlich kann man externen Speicher ansteuern, aber mit Zeitverlust.

Ich bin im Augenblick am überlegen, welche Prozessorbasis ich wählen würde. Durch das HIVE-Projekt angeregt, habe ich auch mir den Parallax-Propeller-Prozessor beschäftigt. Das sind preiswerte Mehrkernsysteme. Macht sowas Sinn? Außer den Eingabe und Ausgabevorgängen, die wohl zeitlich unkritisch sind, wofür kann man mehrere Kerne gleichzeitig brauchen? Hat jemand eine Idee? Gibt es C-Programme, die sowas hardwarenah ausnutzen? Ich denke die PC-Engine nutzen nur die Betriebssystemfunktionen bei Mehrkernprozessoren, oder?

Hier fehlt mir dioch ein ganzes Stück Wissen.

Gruß Fred

__________________
Schach ist ein See, in dem eine Mücke baden und ein Elefant ertrinken kann. - Indisches Sprichwort

Gibt es CPUs mit internem Speicher im Megabyte-Bereich? Ich glaub dann sind wir gleich beim ARM9, also etwa Resurrection-Klasse.


Mehrprozessorsysteme sind immer dann gut, wenn große Datenmengen parallel abgearbeitet werden können. Also zum Beispiel Anwendung von Filtern auf Grafiken (zig Megapixel) oder Multimediaanwendungen (Video?) allgemein. Bei komplizierteren Robotern ist es auch wichtig, mehrere Echtzeit-Berechnungsflüsse gleichzeitig zu haben, weil da mehrere Sensore & Motoren gleichzeitig arbeiten müssen.

Beim Schach tun sich die Programmierer jedoch sehr schwer, den Rechenvorgang auf mehrere Kerne aufzusplitten. Da ist halt die Frage welcher Kern was untersuchen soll. Klar, theoretisch könnte man so Deep Rybka mit 8 Kernen implementieren Wäre unheimlich schwer schätze ich.

Das würde jedoch nur Sinn machen, wenn Schachprogramme auf Mehrprozessorbasis irgendwie interessanter spielen würden als "normale". Tun sie aber eher nicht oder? Dann könnte man besser gleich 1x160 MIPS CPU nehmen statt 8x20 MIPS. Würde auch etwa doppelt so schnell laufen.

Ein anderes Problem wäre der Stromverbrauch und evtl Wärmeentwicklung. Ein echter Schachcomputer müsste doch hunderte von Stunden mit nem Satz Mignons laufen und noch das Brett mit Strom versorgen können. Das wäre das Ende vom Kabelsalat und echter Pluspunkt.

Im Unterschied zu Handies und Pocket-PCs. Und ausserdem soll das Ding nicht so anfällig sein. Und bei nem 8-CPU-System kann schon einiges passieren schätze ich.

Übrigens, es gibt einen französischen Hersteller, der verschiedene PC/Mephisto/Phoenix-kompatible Schachbretter herstellt.

http://www.digital-chess-system.com/fr/

Ein kompatibles Holzbrett an Bord zu haben wäre von Schlüsselbedeutung denke ich.

Was diese Bretter aus Frankreich betrifft: Ich kenne noch niemanden, der ein funktionierendes Exemplar in freier Wildbahn gesehen hat ... nur mal so zur Info ...

__________________
This post may not be reproduced without prior written permission.
Copyright (c) 1967-2025. All rights reserved to make me feel special. :-)

Ich finde die Idee eines Eigenbau-Schachcomputers von jeher reizvoll. Auch die Idee eines eventuellen Community-Projekts spricht mich positiv an. Es wurden jetzt schon einige verschiedene Hardwarelösungen vorgestellt. Doch wie sieht es softwaremäßig aus? Was gibt es bereits an fertigen Programmen, wie sind sie geschrieben und sind diese Programme noch ausbaufähig? Was bisher dazu geschrieben wurde ist inhaltlich ein wenig "dünn", finde ich. Ebenso verhält es sich mit den verfügbaren Angaben bezüglich der zu erwartenden Rechenleistung der vorgestellten Hardware. Teilweise konnte ich nix zu den Taktfrequenzen finden (jedenfalls nicht ohne tiefere Recherchen, zu denen ich mangels Zeit noch nicht gekommen bin) und auch nichts bzw. wenig über die Leistung gemessen in MIPS.

Von den 8-bit Geschichten kann man je nach Hardwareleistung (der Takt alleine sagt ja noch nichts) und Spielstärke der Software eine Eloleistung von bis zu 2100-2200 erwarten ... das ist schon eine recht heftige Hausnummer, sofern man in der Lage ist ein entsprechendes Programm zu schreiben. Bei der zuletzt vorgestellten Möglichkeit ála HIVE habe ich was von 80 MHz gelesen. Ähem ... 32-bit, 24 Kerne und diese Taktrate? Selbst bei nur einem Kern (wer kann schon SMP?) kann da ein schachlicher "Killer" entstehen - man denke an den R30. Puh, und dann lese ich was von UCI, Arena, Datenverwaltung und dergleichen - warum also nicht gleich zu einem Mini-PC ála Atom greifen?

Möglichkeiten scheint es viele zu geben. Doch was eignet sich am besten als "Community-Projekt"?
Die zu findende Lösung sollte m.E. folgendes aufweisen:

• Geringer Kostenaufwand
• Leichter Nachbau (Komplette Bausätze, für "Angsthasen" evtl. fertige Baugruppen)
• Keine hochkomlexe Programmiersprache (also auch für Anfänger nachvollziehbare Befehlsstrukturen)
• 100%ige Emulierbarkeit am PC

Wenn man mehr will, wie z.B. Anschlussmöglichkeiten von USB-Brettern oder Elozahlen größer 2400 usw., kann man ja immer noch ein größeres Projekt "nachschieben". Ich fände es jedenfalls gut, würde ein eher minimalistisches Projekt den Anfang machen und aufbauend darauf das eine oder andere weiterführende Projekt folgen.

Gruß, Willi

Ähm, AVR-MAX ist doch bereits das minimalistische Projekt ?!

Ich denke, er meinte, mit genau so einem Teil anfangen und nicht mit einem neuen R30 ...

__________________
This post may not be reproduced without prior written permission.
Copyright (c) 1967-2025. All rights reserved to make me feel special. :-)