Hallo Robert!Da hast Du vollkommen recht! Zumindest die eigentliche Engine dürfte bei jedem Bretti pures Assembler sein. Bei den Routinen wie für die Displays etwa würde ich das nicht beschwören wollen, sehe aber keinen Grund, warum für sowas vergleichbar banales nicht Maschinencode gewählt wurde.Das ist wohl wahr. Die Prozessorarchitekturen haben sich aber auch sehr verkompliziert. Wollte man heute in reinem Assembler schreiben, müsste man sehr genau aufpassen, dass auch wirklich jede CPU mit dem Code klarkommt. Da tut man sich mit einer höheren Programmiersprache und gut darauf angepassten Assemblern einfacher. Der Code ist dann nur wesentlich aufgeblähter und natürlich langsamer. Aber bei der Vielzahl an verschiedenen Prozessoren wäre es ein Unding, von den Programmieren pures Assembler zu verlangen. Sie müssten sich dann zwangsläufig mit dem Code begnügen, den alle CPUs gemeinsam gleich interpretieren und auf diverse CPU-abhängige Beschleunigungsmöglichkeiten verzichten. Wird so langsam Zeit, dass DER ultimative Superprozessor entwickelt wird, damit dieses Problem der Vergangenheit angehört.Ja, hier konnte man ungemein tricksen! Die Ausführung von Assembler ist bei dem Ding locker bis zu 1000 mal schneller als die von Basic und man hat wesentlich mehr Speicher zur Verfügung. Selbst wenn man auf Routinen des Interpreters oder des Kernels direkt zugreifen will (um sich diverse Sachen einfacher zu machen), kopiert man einfach den entsprechenden ROM-Bereich ins RAM und fertig. Einerseits schade, dass mein 64er "gemopst" wurde - andererseits hätte ich heute kaum mehr die Zeit dafür.

Gruß, Willi

Ach ja - wie so ein Programm beim Rechnen ausschaut, will ich mal im Groben schildern:
Der Code selbst -nebst Bibi- bleibt freilich unverändert. Das Programm legt die Ergebnisse seiner aktuellen Berechnung in einer Tabelle im RAM ab. Die wesentlichen Informationen hieraus werden direkt ans Display geschickt. In der Tabelle wird (ich glaube nach vollständiger Berechnung des ersten Ply) festgelegt, in welcher Reihenfolge gesucht werden soll (damit die "besseren" Züge in Hinblick auf die Zeitkontrollen zuerst berechnet werden). Diese ändert sich nur dann, wenn ein besserer Zug gefunden wurde als in der Ausgangsberechnung. Der vormals beste Zug wandert damit auf Platz 2. Weitere Änderungen finden dort erst einmal nicht statt. Das in dieser Tabelle eine vollständige Umstellung in die Reihenfolge der besten Bewertungen aus Sicht des aktuellen Halbzuges stattfindet, ist bei den wenigsten Programmen der Fall - warum auch immer das so ist. Weiterhin wird die beste errechnete Variante im RAM festgehalten - als Ausgangspunkt für die Berechnungen im nächsten Halbzug. Alles andere (bis auf die gespeicherte Reihenfolge) "vergisst" das Programm wieder, will heissen: Es wird nicht im RAM abgelegt. Nur so ist es möglich, dass die Dinger mit nur wenig RAM überhaupt komplexe Zugfolgen ermitteln können. Bei ausreichend Speicher werden halt mehr Positionen für eine weitere Berechnung festgehalten, nebst der bisherigen Bewertungen. Das läuft dann aber bereits in Richtung "Hashtables". Bezogen auf ein Programm wie das des Polgar bedeutet das: Der Code bleibt bis auf die abgelegte kleine Tabelle weitgehend statisch. Natürlich verändern sich permanent sie Inhalte diverser Variablen, etc. Das führt dann dazu, das es aussieht als würde sich der Code fließend bewegen. Dies trifft aber eher aus der Sicht der CPU zu - von unserer Warte aus bewegt sich da praktisch nichts - ausser der Tabelle eben.

"Wissen" tu ich das aufgrund meiner Erfahrungen mit dem C64. Prinzipiell ist das auf alle 6502 Maschinen übertragbar und mit hoher Wahrscheinlichkeit auch auf alle anderen Brettis aus der "guten alten Zeit". Bei Ruud's Monstern mag das ein wenig anders ausschauen, aber darum ging es hier ja nicht.