D+ und D++
 

wie ihr ja wißt hatte ich meine Leonardo Maestro bzw. Analyst Module verkauft. Irgendwann vor Jahren mal. Und hatte nur einen Sparc.

Gestern hat mein Kumpel Uli mir 2 bei ihm herumfliegende Module geschenkt.

1 x Maestro 6 mhz
1 x Analyst 6 mhz

ich aufgeschraubt. in beiden keine EPROMS.

In dem einen Maestro auch keine CPU.

die CPU im Analyst war abgeschliffen und mit bleistift verziert,nehme
an das hat jemand zum testen der übertaktung gemacht.

Ein quarz von 5.5 mhz ist im Analyst drin.

ich habe hier auch noch den Baustein d++ herumfliegen. allerdings
keine bibi und kein EGR II.

Wo wir gerade beim Thema Unterschiede D+ und D++ sind möchte ich erwähnen was ich kürzlich an Email-Korrespondenz zu diesem Thema hatte:

da schrieb also jemand das zwischen dem D+ und dem D++ nur
1 Byte unterschiedlich sein soll.

und unser Schriftwechsel geht weiter:


da ich gerade sowieso nur ein Eprom habe könnte ich testen ob der D++ OHNE bibi so spielt wie der alte MIT bibi gespielt hat, ob die Idee das Programmteile im Bibibaustein ausgelagert sind, stimmt.
Es könnte auch sein das das 1 Byte quasi den Suchstil ändert im Hauptprogramm, bei Morsch kann man ja auch umschalten.

und das der D++ quasi ein D+ mit mehr selektivität ist.

AW: D+ und D++
 

Hallo Thorsten,

habe mir gerade mal kurz die Mühe gemacht und das ganze mit deinen ROMs verifiziert. Es sind 4 Bytes Unterschied, sonst wirklich absolut identisch. Die folgenden Bytes sind unterschiedlich:

$0000 D+: $B7 D++:$97
$1613 D+: $CD D++:$4D
$1615 D+: $4D D++:$CD
$1616 D+: $B0 D++:$90

Ob das nur Daten oder Instruktionen (eventuelle Sprungziele) sind, müsste man mal überprüfen.

Gruß Mike

AW: D+ und D++
 

Wär doch klasse, wenn die Module ansonsten noch lauffähig sind - EPROMs rein, CPU rein und ... Engage! :D

Das mit dem Abschleifen der CPU macht in Verbindung mit dem Testen von Taktraten absolut keinen Sinn.
Überhaupt macht das Abschleifen von Bausteinen keinen Sinn... :vogel:Klingt zunächst unlogisch, aber...... genau diese interessante These würde der Sache doch wieder einen Sinn geben!

War bzw. ist es nicht so, das die +/++ Versionen experimentelle sein sollen? Ich meine, die sind doch nie offiziell in den Verkauf gelangt, oder? Es ist doch durchaus denkbar, dass gewisse Erweiterungen sofort mit in das Eprom gebrannt wurden und nur durch das Flag wurde bestimmt ob sie angesprochen werden oder nicht. Das würde eine spätere Bearbeitung des Programmes sicher erleichtern, dann nämlich, wenn es eine neue Verkaufsversion geben soll. Zum letzteren kam es ja leider nicht mehr.

Vielleicht kann ja noch jemand die Inhalte seiner +/++ EPROMs auslesen und den 1-Byte-Unterschied bestätigen? Meiner Meinung nach erübrigt sich dann ein Rückkompilieren, weil in diesem Fall eigentlich nur deine These Sinn macht.

Der Vergleich mit dem Corona II musste doch was anderes ergeben, meine ich. Dort ist m.W. ein "normales" D-Programm verbaut, was sich von +/++ gewiss unterscheidet. Das Spielverhalten allein weist schon darauf hin. Das Programm kümmert sich aber auch um die ganze I/O-Geschichte. Die Drucksensoren von Corona II bzw. TK II erfordern alleine schon eine andere Programmierung als die Magnetsensoren der Holzkisten. Dazu die diversen Displaymöglichkeiten letzterer, die ja auch irgendwo berücksichtigt sein müssen und bei Corona bzw. TK ja fest liegen. Ich käme nie auf den Gedanken, bei einem Vergleich der Programme Ähnlichkeiten zu erwarten. :nene:

Gruß, Willi

PS: In der Wiki gibt es zum Corona II bisher keinen Eintrag - hat den keiner? Auch beim TK II sind die Infos eher mager, selbst die Bilder dort sind lediglich die vom ersten TK...

AW: D+ und D++
 

Oh, also doch mehr als nur 1 Byte? Aber gut - selbst 4 Byte sollten es nicht wirklich ausmachen, sofern es keine Debug-Unterschiede sind. Die These dass die +/++ Programme gleich sind und im ++ lediglich andere/weitere Routinen abgearbeitet werden, wird dadurch höchstens noch erhärtet, vor allem dann, wenn es bei den anderen 3 Byte tatsächlich um Sprungziele geht. Also vielleicht doch rekompilieren???

Danke für das schnelle gucken, Mike! :top:

Gruß, Willi

AW: D+ und D++
 

Da wäre ich mir nicht so sicher: Wenn man die BT2450-Zeiten von Stratos II 6 MHz (das ist die Drucksensorversion des Corona (der hat übrigens Magnetsensoren)) mit denen des Analyst D 8 MHz vergleicht, sieht man zwar (in Relation zur unterschiedlichen Taktfrequenz) viele ähnliche Ergebnisse, aber (vor allem in der 2. Hälfte) auch etliche, die sich deutlich unterscheiden.

Inwieweit diese Ergebnisse nun zuverlässig sind, müsste man mal überprüfen. Und mW hat bei diesen Saiteks auch der Zufallsgenerator noch ein Wörtchen mitzureden; auch das könnte noch ein Grund für die unterschiedlichen Zeiten sein.
Da meiner mit dem D+ ausgestattet ist, würde ich den mal als II-er ansehen. Er bringt beim BT2450 nämlich vergleichbare Ergebnisse wie mein TK II (taktfrequenz-bereinigt)

Sieht aber von außen wie ein normaler I-er aus.
Das wird wohl daran liegen, dass die meisten vermutlich nachträglich aufgerüstet worden sind (wie vermutlich mein Corona auch)

Gibt es überhaupt TK mit unterschiedlichen Aufdrucken? Ich glaube zwar, ja, aber sicher bin ich mir momentan nicht. Oder war es nur auf der OVP?


viele Grüße,
Robert

AW: D+ und D++
 

Das mit den Sprungzielen halte ich für nicht denkbar.
Wo ist denn dann der "neue Code" wo hingesprungen wird? Er wird ja nicht vorher schon dagewesen sein und nicht verwendet worden sein, oder?

AW: D+ und D++
 

Ja, Mensch! Wie oft verwechsle ich die Dinger denn noch??? :doh:
Kennt der Zuffi bei diesen Programmen kein "AUS"??? :bigeyes:
Ist dein TK II ggf. auch mit D+ aufgerüstet worden?
Es würde mich überraschen, wenn ein "verbessertes" Gerät nicht durch eine modifizierte Namensgebung kenntlich gemacht würde. Aber in der Schachcomputerbranche ist eben alles möglich... :dead:

Gruß, Willi

AW: D+ und D++
 

Genau um die Beantwortung dieser Frage geht es.
Oder wie erklärst Du dir den bis auf lausige 4 Byte identischen Programmcode zweier so unterschiedlich agierender Versionen?
Wäre es auch so undenkbar, das zusätzlicher Code ins Bibi-EPROM gepackt wurde?

Bei heutigen Engines wird sicher auch oft so verfahren, zumindest bis ins Betastadium. Unnötiger Code wird erst bei der finalen Engine entfernt. Warum sollten die Programmierer während der Testphase immer wieder Code hinzufügen und entfernen, wenn durch einfache Angabe anderer Sprungziele viel schneller gearbeitet werden kann? Und die D+/D++ Versionen waren experimentell, also Betaversionen...

Gruß, Willi

AW: D+ und D++
 

Ich kann es mir nicht wirklich erklären :raffnix:

Aber irgendwie erscheint mir das alles etwas unlogisch. Irgendwo muss da ein Denkfehler sein.

Wenn man durch die Änderungen den Spilstil so komplett ändern (verbessern ???) kann dann wäre es doch nur logisch gewesen das umschaltbar zu machen und kein neues ROM dafür zu machen.

Irgendwie glaube ich das wir da was übersehen ...

AW: D+ und D++
 

ICH würde es auch per Umschalter machen, aber frage mal in der Community, was man hier von einer irreversiblen mechanischen Veränderung gewisser Sammlerstücke hält. Das Gros dürfte inhaltlich irgendwas zwischen :mad:, :motz: und :maul: antworten.

Als die +/++ Versionen geschrieben wurden, waren die Compis bereits hochpreisige Heiligtümer. Das Wechseln von EPROMs war das höchste der Gefühle, was sich der interessierte Schächer im Normalfall zutraute. Die Tester mussten das natürlich...

Es ging damals um das worum es immer ging: Das stärkste Proggi ermitteln! Der Stil war zweitrangig, da bin ich sicher. Es sollte nicht die Wahl zwischen zwei verschieden agierenden Programmen geben, sondern herausgefunden werden welches stärker ist um es dann als E-Version zu vermarkten. natürlich hätte man zu diesen Testzwecken auch einen Umschalter direkt an das EPROM basteln können, aber es hätte dann auch ein anderes, doppelt so großes sein müssen. Da kann auch die Kostenfrage ein gewisses Gewicht gehabt haben...

Aber wir können lange spekulieren - wenn sich jemand mit der nötigen Kenne das Proggi genau ansieht, erfahren wir vielleicht mehr. Am besten geeignet für Auskünfte wäre natürlich der Programmautor!

Gruß, Willi

AW: D+ und D++
 

Mal eine blöde Frage: Wie kommt es eigentlich, dass hier so viele ein D+ oder D++ Modul haben?

AW: D+ und D++
 

Ich würde mal darauf tippen, der Grund liegt darin, weil es hier so viele Sammler gibt! :)

Ich habe übrigens kein D+/++ ... leider! :heulsuse:

Gruß, Willi

AW: D+ und D++
 

Trotz 4 Bytes scheint es nur wenig Unterschied zu geben.

Beim D+ sind die drei zusätzlichen Bytes wohl folgender Code:

JSR $ADC0
LDA $CD
CMP $4D
BCS $961F

Wenn mein 6502 Assembler Verständnis noch funktioniert, sollte das bedeuten:

Wenn Inhalt von $CD >= Inhalt von $4D dann verzweige

Beim D++ steht dort:

JSR $ADC0
LDA $4D
CMP $CD
BCC $961F

Das sollte fast identisch sein mit dem obigen:

Wenn Inhalt von $CD > Inhalt von $4D dann verzweige

Einziger Unterschied scheint ">=" zu ">" .... plus das Byte bei Offset 0

Vielleicht überprüft das mal jemand dessen Kenntnisse frischer sind als meine :D

Gruß Mike

P.S.: Das erste Byte (Offset 0) scheint in der Routine ab $D72E verwendet zu werden, keine Ahnung was damit gemacht wird.

AW: D+ und D++
 

Die Antwort ist recht einfach. Thorsten bietet auf seiner HP diese Programmversionen zum Download an. Somit kann man ein Analyst- bzw. Maestro-Modul recht schnell auf D+/D++ updaten.

Gruß,
Micha

AW: D+ und D++
 

Ich meine, das Carry-Flag wird bei "=" gesetzt und bei "<>" nicht. Ist schon ein paar viele (ca. 20 !) Jahre her das ich mich zuletzt mit dem 6502 befasste, aber ich bin mir ziemlich sicher. Also nix mit >= oder so. Ansonsten stimmt es aber, die Befehle vergleichen den Inhalt zweier Speicherzellen. Es werden bei beiden Programmen die gleichen Zellen verglichen. Das sie das in umgekehrter Reihenfolge tun ist zunächst irrelevant, da es auf das Ergebnis des Vergleichs ankommt der ja nur "wahr" oder "unwahr" sein kann.

Aber:
Der D+ verzweigt wenn der Vergleich "wahr" ist (Carryflag gesetzt) und
der D++ verzweigt wenn der Vergleich "unwahr" ist (Carryflag NICHT gesetzt)

Das steht jedenfalls nicht gegen die These, dass beim D++ andere Routinen angesprochen werden als beim D+. Leider genügt das auch nicht zum Beweis...

Gruß, Willi

AW: D+ und D++
 

Ich habe nochmal Google bemüht ...

http://www.6502.org/tutorials/compare_beyond.html

A surprisingly common sequence in 6502 code is:

LDA NUM1
CMP NUM2
BCC LABEL
BEQ LABEL

(or something similar) which branches to LABEL when NUM1 <= NUM2. (In this case NUM1 and NUM2 are unsigned numbers.) However, consider the following sequence:
LDA NUM2
CMP NUM1
BCS LABEL

which branches to LABEL when NUM2 >= NUM1, which is the same as NUM1 <= NUM2. Not only that, it's shorter and (in many cases) faster.

Scheint meine Erinnerung mich doch nicht getäuscht zu haben :D und vielleicht ist genau der Vergleich der Grund dafür, dass der D++ ein Tick selektiver ist, obwohl ansonsten (fast) vollkommen identsich.

Gruß Mike

P.S.: Der ein oder andere hier hat in seiner Jugend sicherlich mal eines meiner Programme mit Unmengen von Data Zeilen aus 'ner 64er oder Happy Computer abgetippt (war 6510 Assembler deshalb ist es mir noch ein wenig vertraut) ;)

AW: D+ und D++
 

:o Ich werde eben alt, Alzheimer lässt grüßen!
:doh: Die Existenz von BEQ hatte ich schon ganz vergessen...

Ja, die Befehle bewirken prinzipiell das gleiche ... mit eben den von Dir bereits festgestellten Unterschied von >= zu >. Das heisst, der D+ verzweigt auch dann, wenn beide Speicherinhalte gleich sind. Der D++ tut das nicht. Damit bleibt es aber dabei: Thorsten's These wird dadurch nicht entkräftet (eher erhärtet), aber beweisen kann das leider auch nix...In meiner Jugend warst Du noch etwas jünger (komisch, ist bis heute so geblieben... :gruebel:) - aber abgetippt habe ich gelegentlich auch, wie wohl die meisten in unserem Alter. Hast Du mal eine Programm-Liste parat? Vielleicht finde ich was wieder. Keine Angst, wenn damals was nicht funzte erwachte zwar stets der Killer in mir, aber das ist heute längst verraucht! :D

Gruß, Willi

AW: D+ und D++
 

An den falschen Prüfsummen in den Listings war ich nicht schuld, das war stets das Werk des Verlages :D

Gruß Mike

AW: D+ und D++
 

:raffnix: Was haben falsche Prüfsummen mit nicht funzenden Proggis zu tun?
Du willst Dich nur rausreden noch bevor Du dich als Verfasser diverser Reinfälle outest! :D

Gruß, Willi <--- der sich eben noch was weinhaltiges besorgen muss, weil er sonst das Spiel gleich nicht erträgt...

AW: D+ und D++
 

Vielen Dank :)

Kann man alle Maestro/Analyst Module updaten, oder nur die D Version?

AW: D+ und D++
 

Nein, es sollten sich alle Module updaten lassen. Zumindest habe ich noch keine anders lautenden Infos bekommen.

AW: D+ und D++
 

Mahlzeit,

ich habe die beiden Roms gerade nochmal mit der vergleichen Funktion von HEX-Editor MX verglichen. Das Programm zeigt mir nach wie vor eine Abweichung bei $0000 an und zwar wie geschrieben $B7 bzw. $97.

Die Abweichung auf $1613/$1615 findet der nicht, gleichwohl ist diese aber vorhanden!!!!

Ist hier also ein Softwarefehler des Hex-Editors. Ich hatte natürlich nicht alle 32000 Bytes zu Fuß verglichen.

Anyway ist eine dermaßen massive Auswirkung auf die Spielweise aus der Änderung dieser einen Instruktion für mich nicht nachvollziehbar.

Klärung könnte m.E. nur das vergleichen weiterer D+ bzw. D++ Roms bringen insofern nicht ohnehin alle von Thorsten stammen (dann haben wir quasi ein Inzuchtproblem).

Der Corona II Rom sieht dagen völlig anders aus (Hex MX findet 3672 Unterschiede!).

Und noch zum eigentlichen Anliegen meinerseites.

Der Corona läuft stabil mit 8 Mhz, allerdings laufen die Uhren zu schnell.

Da dies im Maestro offenbar nicht der Fall ist, hatte ich gehofft durch Vergleich der Corona mit den D+/D++ Roms dahinterzukommen wo der Code für die Uhren steht.

Der Plan war nun, das Rom so zu patchen, daß die Uhren bei 8 Mhz richtig gehen. Würde sich das einer von Euch Assembler-cracks mal ansehen, ich habe ziemlich wenig Plan von ldx etc.

Grüße, Dirk

AW: D+ und D++
 

Hallo Leute.

Wir haben damals direkt vom Programmierer Eproms bekommen die wir
(Dirk Frickenschmidt und ich) in unsere Kisten, das waren damals noch
Maestro in Leonardo-Gehäusen einsetzten.

Das waren Experimentalversionen die noch nicht im Handel waren.

Wie gesagt: direkt vom Programmierer.

Dabei fiel uns der große Unterschied im Spielstil auf zwischen D+ und D++.

Uns gefiel aber der D+ schon sehr. Spielte solides schönes Schach.
Der D++ sozusagen davon nochmal eine übersteigerte Version.
Fast schon wie ein betrunkener D+.

Als wir das damals testeten und Artikel schrieben hieß es erst, die Versionen kommen nie in den Handel.
Weil schon Brute Force da wäre. bzw. Sparc.

Später sind dann aber doch D+ Versionen in den Handel gekommen.
Soweit ich weiß in allen dem Maestro/Analystmodul üblichen/ähnlichen Geräten, also auch Corona und Drucksensor-Pendants.

Aber die sind nie als D+ bezeichnet worden. Wurden wohl als D bezeichnet.
Oder weiß der Henker wie. Als II version.

der Begriff D+ bzw. D++ war ja auch eher eine Wortschöpfung von uns.
Es hieß das kein E mehr käme. Und weil es experimentell war erschien uns ein D+ bzw. D++ als angemessen.

Damals fand ich diese Versionen extrem attraktiv.
Die Partien waren verglichen mit den Produkten anderer Hersteller
sowas von ansehnlich und schön, ich hätte am liebsten ständig
"!" verpaßt.

Gar nicht zu vergleichen mit dem Spielstil von Lang... eher schon mit Superconny.

Es muß jetzt nicht sein das was im Bibi-Baustein ist. es kann ja auch sein das nur ein Schalter den Spielstil oder die Suchstrategie ändert.
Ich meine aber wir hätten damals auch das austauschen der Bibi ausprobiert
und das hätte beim D++ weniger gute Ergebnisse erbracht und dann habe ich damals einfach rückgeschlossen das im Bibi Baustein NICHT NUR Bibi drin ist sondern eventuell vom Hauptprogramm benutzte Algos.
Mir erschien die 32 KByte als etwas zu wenig für die spielweise. und in 64 KByte paßt ja mehr.

Laß die bibi 20 oder 24 sein. Dann hat man immer noch ausreichend Platz um ein mehr an Algos über die 32 KByte hinaus im Bibi Baustein unterzubringen. man muß ja sehen das die Geräte ZUgumstellungen in der Bibi können.
ATM hieß der algo glaube ich:automatic transposition manager oder so.

wir haben damals nie die eprominhalte studiert. unser eprommer lief auf einem atari ST: ich bezweifle das wir damals schon PC's hatten.

aber einen ATARI schon.

Alles was wir an erkenntnissen gewonnen hatten, haben wir durch ausprobieren.
das partien spielen machte mit dem Kaplan programm sehr viel spaß und ich finde der hat sehr viel
Ästhetik aus den kisten herausgeholt.

AW: D+ und D++
 

erscheint mir logisch!

denn das würde auch erklären, wieso mein Corona D+ die gleichen BT-Ergebnisse bringt wie mein TK II.


Robert

AW: D+ und D++
 

Ich habe mir den Kaplan nochmal angesehen, es ist wirklich nur der Unterschied >= zu >, das vierte unterschiedliche Byte (gleich zu Beginn des ROMs) ist Teil der Prüfsumme (2 Bytes). Die Kaplan-Eproms bilden eine Prüfsumme über den Rom-Inhalt und morsen :D und verweigern den Dienst wenn die Prüfsumme nicht stimmt.

Gruß Mike