Von die GK2100-klone haben Travel Champion 2100, President und MM VI nicht der H8-bug.
Über der RadioShack Champion 2250XL weiss ich kein bescheid.
Alle andere sollten der H8-bug haben.
Das konnte man aber schnell ausprobieren mit die teststellungen auf die Bug-seite
Übrigens betrifft das 2. beispiel tatsächlich der Explorer Pro!

Edit: Der H8-bug ist zwar sehr ärgerlich, kommt aber sehr selten vor. Also kein grund um sich sorgen zu machen.

Gruss, Paul

__________________
Wenn ich mich irre, sollte es ein Horizont Wirkung sein

Ich finde das vom Software-Versions-Release-Management noch interessant.

In der "GK 2000"-Software-Version war also dieser "H8 bug" vorhanden.
Offenbar hat man den Fehler erkannt und korrigiert und in der "GK 2100"-Software-Version war der Fehler eliminiert.

Aber offenbar gibt es trotzdem "GK 2100"-basierte Geräte mit dem "H8 bug".

Was hatte Saitek/Mephisto in dieser Zeit wohl für ein Software-Versions-Release-Management?

Nun ich will beileibe nicht pingelig sein aber bei Fritz von chessbase war das über viele viele Jahre genauso. Und welche engine lief dort ? Eine frans morsch engine. Ich behaupte nicht das Frans fehlerhaft programmiert. Aber ich behaupte das in seinem Umfeld die zuständigen Leute für die Finalisierung nicht richtig gearbeitet haben. Sie scheinen bei jedem neuen Produkt immer wieder auf dieselbe fehlerhafte sourcebase zurückgegriffen zu haben.

__________________
Die ganze Welt des Computerschachs

Nein, der Bug tauchte erst in den Klonen des GK2100 auf.

__________________
Viele Grüße
Robert

Meiner Meinung nach ist der H8 Bug ein Portierungsfehler im Rahmen der Nutzung einer aktuelleren (und möglicherweise preiswerteren) MCU-Generation und sollte man nicht direkt Frans Morsch anlasten.

Ich habe einen Verdacht, was da passiert sein könnte, mangels Quellcode ist das jedoch nicht belegbar.

Als der Fehler dann festgestellt wurde, war es zu spät. Die MCU sind maskenprogrammiert und wurden aus Kostengründen sicher in einem Batch zu 1000den vorgefertigt und mit der Zeit in mehreren verschiedenen Geräten auf den Markt geworfen.

In "alten Zeiten" (1-2 Jahrzehnte früher) hätte man einfach neue Eproms gebrannt und das Problem gefixt. Hier ging das leider nicht mehr. Das Management musste abwägen zwischen "alle Chips entsorgen" oder "zu 99 % spielt er ja korrekt" und hat sich für letzteres entschieden.

Später wurde mindestens eine weitere Serie MCU neuer Bauform hergestellt. Da ist mir vollkommen schleierhaft, wieso man ein buggy Produkt nochmal herstellen lässt... Aber solange es der (zumeist unwissende) Kunde kauft...

Allerdings, ganz so schlimm kann das alles nicht sein, denn interessanterweise hat Pewatronic ausgerechnet ein Gerät mit H8 Bug für die Herstellung eines hübschen Holzgeräts ausgewählt.

Hallo Drahti,

Vielen Dank für deine interessante Antwort.
Es geht ja auch nicht darum irgend einem Entwickler eine "Schuld" geben zu wollen.
Aber diese Geräte sind ja vor allem auch Zeitzeugen der Technikgeschichte und da sind solche Fehler und ihre Ursachen einfach mal interessant (mindestens für mich).

Hans

Der MMVI hat ja den H8 Bug nicht, dafür den K,S-K bzw. den K,L-K Bug.

In dieser Constellation sieht er sich immer im Vorteil, erkennt nicht, das es Remis ist, und vermasselt sich dadurch so manche Endspiele, indem er solche Stellungen zulässt.

Hallo Udo, ist es nicht eher mangelndes Wissen in diesem Falle? Irgendwo ist halt die Grenze: was implementiere ich noch und was lasse ich weg, weil es nur seltenst Relevanz hat. Der Limiter kann speichertechnisch oder auch rechenzeittechnisch bedingt sein oder einfach Entwicklungsaufwand/zeit sparen, um das Zeitfenster für die Produktion rechtzeitig vor Weihnachten noch zu schaffen.

Was mich als Entwickler vermutlich absolut kirre gemacht hätte: wenn mehr oder weniger regelmäßig der Kaufmann kommt und einen neuen (günstigeren) Prozessor zuweist und man also wieder gezwungen ist, das gewachsene Programm anzupassen an die neuen Gegebenheiten.

Dass hier Fehler passieren, ist wohl nur allzu menschlich. Deshalb auch eher mein Versuch, Frans Morsch zu "entlasten". Soweit ich das sehe, war er derjenige, der im Vergleich mit anderen Schach-Programmierern die vielfältigsten Hardware-Plattformen bedient hat (gerne mal umschrieben mit "hat einem Waschmaschinen-Prozessor das Schachspielen beigebracht"). Und das auch noch ausgerechnet im Low Cost Bereich, wo es also eher um Stückzahlen als um Marge ging... und der erreichbare monetäre Gegenwert somit ohnehin nicht der höchste gewesen sein wird.

Mein Respekt an die Programmierer der damaligen Zeit und auch an all jene die sich aktuell um Emulation alter Geräte und Pflege der Tradition kümmern! Die aktuelle Entwicklung finde ich durchaus erstaunlich. Wer hätte das damals kommen sehen, als die Heim-PCs mit immer stärker aufspielender Schach-Software die Brettgeräte doch recht rasch verdrängt hatten...

Grüße
Andreas

Hallo Andreas, Mangelndes Wissen vermute ich auch. Aber hätte man dem Programm gesagt, das ein einzelner Springer oder Läufer mit König eine Bewertung von 0.00 hat, anstatt +2,5 oder ähnlich, würde es der MMVI wohl zu mindestens vermeiden, sich in solche Remis-Situationen zu bringen, er aber dabei "denkt", er ist im Vorteil.

Ich vermute, das dies nur eine kleine Änderung in der Programmierung wäre, da wurde es einfach vergessen, nehme ich an.

Ich hatte vor vielen Jahren noch einen anderen Bug bei meinem MMVI festgestellt, den damals auch an Millenium gepostet. Nach Zugrücknahme der Rochade weigerte sich mein MMVI, dieselbe nochmals anzunehmen. Das wurde seinerzeit auch von Millenium bzw. Hegener und Glaser bestätigt. Allerdings ist dies ein wohl sehr selten auftretendes Ereignis.

Ich habe es jetzt auch nicht mehr im Kopf, ob es für diesen Bug spezielle Bedingungen gab. Ev. nach einer Stellungseingabe ? Muss ich noch mal testen.