last post from 64erGrufti at the
Hallo,
3. mit nibconv g64 nach d64 wandeln
Schritt 3 drürfte daneben gelaufen sein:
OK, ich gebe mich geschlagen 
.
Punkt 3 weggelassen und stattdessen das installierte G64 unter VICE in MP3-64 mit geoDESK auf eine 2. 1541 (D64) kopiert (Disketten-Kopieren). Dieses D64 läuft anschließend vom SD2IEC.
Gruß
Werner
Ich hatte die Disketten einfach mit der 1541 per StarCommander ausgelesen. Läuft mit SD2IEC.
einfach mit der 1541 per StarCommander ausgelesen
und damit gekonnt allen Konvertierungsproblemen aus dem Weg gegangen - da muss ich einfach dem Reflex folgen und einem "Daumen hoch" geben.
und damit gekonnt allen Konvertierungsproblemen aus dem Weg gegangen - da muss ich einfach dem Reflex folgen und einem "Daumen hoch" geben.
Das war dann eher Zufall. Das war einfach die Möglichkeit, die ich hatte.
Hier erstmal das angekündigte D64 mit der Bootdisk (deine Seriennummer).
Kann man die auch irgendwie auf englisches Tastaturlayout umstellen? Gibt es überhaupt einen C64 mit deutscher Tastatur?
Kann man die auch irgendwie auf englisches Tastaturlayout umstellen?
Nein.
Entweder deutsches Geos mit deutscher Tastatur oder englisches (US) Geos mit englischer (US) Tastatur. Die Tastatur-Tabelle und die System-Zeichensätze (BSW bei Geos 64 und zusätzlich BSW128 bei Geos128) mit entsprechenden Zeichen sind fest im Kernel verankert.
Gruß
Werner
Entweder deutsches Geos mit deutscher Tastatur oder englisches (US) Geos mit englischer (US) Tastatur.
Tatschlich, Du hast Recht. Daran konnte ich mich gar nicht mehr erinnern. Mein altes Geos ist genauso.
Die komische Seriennummernveränderung in Track 18 Sektor 0 hat scheinbar irgendein System.
Ja, wie dort (Test der "install-killer" an jungfräulichen GEOS Images) beschrieben .
Der Wert in Track 18 Sektor 0 (Byte $BE und $BF) ergibt in Lo-High-Format die kodierte Seriennummer:
Die Codierung ist ein einfache Bit- Rotation nach links (RoL).
... über den gesamten Wert.
Track 14 Sektor 8 (Byte $5f und $60) enthält ebenfalls die Seriennummer. Die ist aber anders kodiert. Jedes Byte ist im Falle von Geowrite mit XOR $DE kodiert. Das ergibt dann wieder die Seriennummer. Übrigens, fast der gesamte VLIR-Datensatz (zu dem Track 14 Sektor 8 gehört) ist mit XOR $DE kodiert. Diese Kodierung wird beim Laden des VLIR-Datensatzes rückgängig gemacht.
Zudem gibt es meist ein paar Bytes vor dem XOR-Befehl einen Befehl, der den XOR-Wert der da steht überschreibt. Und $DE gilt nur für Geowrite. File, Calc, Publish nutzen je andere Werte....
Kopierschutz halt .
Die Seriennummer in Track 18 wird benutzt, wenn das Geos-System diese Seriennmummer von einer Applikation (hier geoWrite von der Disk APLLIKATIONEN) übernehmen soll.
Die Seriennummer in Track 14 wird bei jedem Start von geoWrite mit der Seriennummer des gerade laufenden Systems verglichen. Stimmt da was nicht, wird der Start von geoWrite verweigert.
Wenn die beiden Seriennummer nach der jeweiligen Dekodierung auf einer originalen Diskette unterschiedlich sind, hat irgendwer oder irgendwas (ein Programm?) da manipuliert.......
Ich habe mir mal die Mühe gemacht, alle originale von Geos 64 und Applikationen geprüft. Bei mir ist das so.
Gruß
Werner
Der Wert in Track 18 Sektor 0 (Byte $BE und $BF) ergibt in Lo-High-Format die kodierte Seriennummer:
Das ist schon klar. Das Thema hatten wir ja letzte Woche erst. Aber hast Du mal den Wert verglichen? Exakt der gleiche Wert, der da bei mir drin stand. Und da war kein Installkiller am Werk. Es scheint also irgendeinen Vorgang zu geben, wo immer exakt diese Seriennummer geschrieben wird. Und das muss irgendwas in Geos selbst sein. An meinen Disketten waren keine Knacktools dran. Ich glaube, die gab es damals noch gar nicht. Jedenfalls war an meinen Disketten nur Geos und Kopierprogramme dran.
Aber wieso besitzen die, als nie installierte Originale angesehen, Images ("geos20_d1b.g64" aus "c64geos20_d64_nie_installiert.7z" und "1B-GEOS25_Applikationen.g64" aus "GEOS64_25.zip" genau hier Werte. Die Werte auf diesen Images also $11B3 und $7C6A würden den S/N $88D9 und $3E35 entsprechen.
Ein Zitat aus der von Dir verlinkten Nachricht ( GEOS 2.0 gekauft - es fehlen GEOWRITE 2.1 und GEOPAINT )
Was steht da? Auf einer (angeblich) noch nie installiertem Image taucht die gleiche Seriennummer wie bei Deinem. In Deinem Geowrite (Disk "Applikationen") steht eine andere Seriennummer als auf Track 18 Sektor 0. Mir sagt das:
Deine Disks wurden nie richtig installiert (siehe auch die geoMerge-Disk 2b weiter vorne von Dir, die auch nicht oder nicht richtig installiert ist!). Aber Du bist Sicher, daß sie richtig installiert ist (sind). Genau so sicher wie hier :
Daran konnte ich mich gar nicht mehr erinnern.
Ich bin hier raus...
Werner
Deine Disks wurden nie richtig installiert
Wie hätte ich sie dann benutzen können? Ich kann nicht mehr machen, als sie zu starten. GeoMerge habe ich nie genutzt, aber mit GeoWrite habe ich viel gearbeitet. Wenn Geos die Einrichtung nicht richtig macht, kann ich nichts dafür.
Ich tippe eher darauf, dass es eine unbekannte Aktionsfolge gibt, die das wieder auf den falschen Wert setzt. Leider ist das "unbekannte" das wesentliche Wort, also kann ich das nicht ausführen.
Muss jedenfalls etwas sein, was von Geos selbst stammt. Denn warum sollte etwas von dritter Seite ausgerechnet auf der GeoWrite Originaldiskette ausgeführt werden?
Oder so etwas wie: Die Track 18 Sektor 0 Seriennummer ist onch nicht auf Diskette geschrieben, sondern erst mit der nächsten BAM Änderung. Und da man lt. Anleitung eigentlich ein VALIDATE machen sollte, käme die ja bald.
Leider ist das "unbekannte" das wesentliche Wort, also kann ich das nicht ausführen.
Du hast es erfasst. Solche Fehler sind die, die wir als Programmierer am liebsten haben
Wenn man nicht weiß, wie man einen Fehler reproduzieren kann, sucht man sich nen Wolf. Aber deswegen gibt es den Fehler leider doch.
Ich hatte im Studium mal einen ähnlichen Fehler. Wenn man im Debugger eines Mikroprozessors im richtigen Moment einen Prozedurschritt machte (Tastendruck, Einzelschritt), dann sprang er an Adresse $0000 und stürzte ab. Aber den Moment des Tastendrucks exakt zu erwischen, ist ja kaum möglich. Der Dozent hat es mir auch nicht geglaubt. Ich konnte ihm nur zeigen, dass es irgendwann passiert. Aber wie man es exakt reproduzieren kann, das konnte ich natürlich nicht sagen.
Wenn man im Debugger eines Mikroprozessors im richtigen Moment einen Prozedurschritt machte (Tastendruck, Einzelschritt), dann sprang er an Adresse $0000 und stürzte ab. Aber den Moment des Tastendrucks exakt zu erwischen, ist ja kaum möglich. Der Dozent hat es mir auch nicht geglaubt
Vielleicht war das ja auch ein Heisenbug ( https://de.wikipedia.org/wiki/Heisenbug ). So was gibt es, ohne jeden Zweifel. Wobei ein Mandelbug in gewisser Weise noch schlimmer ist... den findet man zwar, bekommt ihn aber dennoch kaum gefixt. Dagegen ist ein higgs-bugson ja echt harmlos...
Du siehst, es gibt sogar Namen für ähnliche Phänomäne...
Du siehst, es gibt sogar Namen für ähnliche Phänomäne...
Ich bin mir recht sicher, dass es einfach ne Timing-Sache war. Wenn man in einem Moment den Befehl abgesendet hat, in dem der Prozessor gerade an einem ungünstigen Punkt stand, lief er ins leere. Je nachdem, wann man den mit dem Debugging im Zyklus erwischt hat.
Ich tippe eher darauf, dass es eine unbekannte Aktionsfolge gibt,
... oder eine nicht originale Diskette!
Die Disk 1b von 64erGrufti habe ich mir jetzt mal genauer angesehen. Sie funktioniert zwar soweit, ABER: anders als bei den Originalen die ich kenne, ist die Geowrite-Seriennummer nicht auf Track 14 Sektor 8 (siehe die Ausführungen von ZAK256 hier ( Test der "install-killer" an jungfräulichen GEOS Images ) steht. Sie steht auf Track 14 Sektor 7. Irgendwie scheint das richtig installierte GeoWrite per Hand auf die Disk kopiert worden sein.
Ich habe seit den 1990ern (da sind die Uninstaller erschienen) nie gehört, daß der Write-Uninstaller nicht richtig funktioniert ...
Wenn diese Disk so wie sie ist eine Kopie des Originals ist, würde der Uninstaller für Geowrite nicht funktionieren. Der ändert auf Track 14 Sektor 8, macht also unter Umsänden diese ominöse Diskette sogar kaputt.
Werner
Das kann natürlich sein - erklärt aber in keinster Weise, warum da ausgerechnet die selbe Seriennummer in der BAM steht wie in dem alten Posting dokumentiert:
Schauen wir mal: $6A7C rotate right 1 = $353E
Edit: Aber eigentlich ist das Mumpitz, ob die verändert ist, lässt sich ja leicht prüfen. GeoWrite beachtet bei der Installation keine VLIR-Verkettung, sondern schreibt die Seriennummer in einen hart einkodierten Sektor. Wenn der nicht mit der Position der Seriennummer übereinstimmt, wurde die Diskette doch verändert - ohne wenn und aber.
erklärt aber in keinster Weise, warum da ausgerechnet die selbe Seriennummer in der BAM steht wie in dem alten Posting dokumentiert:
Lt Ausführungen der das zur Verfügung stellenden Leute (Disketten sind niemals installiert gewesen) steht genau diese Nummer dort in der BAM.
Das wäre natürlich eine Variante - so ausgeliefert und so gelassen...
Aber hatte die Seriennummer aus der BAM bei Dir nicht auch nicht gepasst? Ein Teil der Erklärung scheint mir also noch immer zu fehlen.
Wobei bei Dir die Sache anders gelagert ist. Da muss man sowohl TopDesk als auch Megapatch in die Ursachensuche einbeziehen - anzunehmenderweise hast Du mit beiden mal auf die Originaldiskette zugegriffen. Wenngleich zumindest nicht bewusst so, dass sich die Seriennummer in der BAM verändert.
