Posts by markusC64

Gut, mit den Infos teste ich weiter.

Inzwischen habe ich die deskpack neu erstellt (d. h. die originale d64 neu gepatcht, ich habe mir dankenswerterweise die Offsets aufgeschrieben, so dass das leicht ist).
Nachdem ich identifiziert habe, dass die Umwandlung g64 -> d64 das Problem verursacht, kann ich so sicher sein, dass ich das Problem nicht in die aktuelle Version einschleppe.

Demnach ist es Version 601 - 603, auf die nibconv67 basiert (eher letztere, aber nicht sicher, da ja nicht sofort nach Anfang der Arbeiten veröffentlich sein muss - Im code einzusteigen dauert ja etwas).

Danke für's Feedback.

Ja, mein nibconv ist im Einsatz. Da muss ich gleich testen, ob das auch mit der unveränderten Version auftritt. Nibconv67 basiert ja auf einer älteren Version von nibconv (leider steht nirgendwo, welche, man muss daher per Datum abschätzen).
Aktuelle nibconv ist nämlich auch buggy - siehe Thread nebenan.

An solch einer Stelle habe ich nämlich eigentlich nichts geändert. Trotzdem: Muss ich erst kontrollieren.

Nachtrag: Ja, ich habe mein nibconv genommen. Allerdings eine Version, die auf SVN 633 baseiert (die aktuelle).
Nachtrag 2: Der Fehler passiert beim Konvertieren von g64 nach d64 mittels nibconv.

Quote from wweicht

Auch hier kann ich leider nicht weiterhelfen.

Habe ich auch nicht erwartet - aber das Fehlende hier aufzulisten ist imemrhin chancenerhöhend. Vielleicht liest das ja jemand, der just so ein d64/64/nib oder gar Originaldiskette hat.

Quote from wweicht

Gab es GEOS 1.5 auf deutsch?
Ich meine mich zu erinnern, dass das 1990 meinen ersten C64s als Disk beilag und das das ein englischsprachiges Geos war (nur Bootdiskette sonst nichts weiter). Leider konnte ich diese Disketten bisher hier nicht wiederfinden ... :-(.

Ich habe hier ein Original "GEOS deskTop 1.5 User's Manual" Developed by Berkeley Softworks. Erste Hälfte Deutsch - zweite Englisch. Im deutschen Teil sind die Screenshots in Deutsch. Demnach müsste es eigentlich jene Version in Deutsch geben.
Und ja: Der Sammlung täte das zur Vervollständigung ganz gut...

Quote from r.cade

Anyway, give it a test if you want. It is better now, probably far from perfect. Parsing KF G64's results in less errors now than the code you submitted into extract_*. Please send me examples of bad parses so it can be further improved.

YMMV, but I find the opposite being true: Take the attached geocalc64.g64 as an example. My nibconv-version (based on revision 620, not the one attached to this posting) converts iit to d64 without errors, your revision 633 fails at 2 sectors.

Quote from wweicht

Außerdem suche ich in diesem Zusammenhang noch GeoProgrammer.

Dito. Außerdem geoWrite Workshop, Deskpack Plus und GEOS 1.5 deutsch. Zur Not auch d64 (weil besser als nichts).

Mario28: Leider ist das nib dann natürlich installiert...

Habe jetzt auch noch den "Graphics Grabber" deinstalliert. Das "Deskpack" scheint mir eine der am besten geschützten Programme zu sein... Jede der 3 deinstallierten Apps üebrschreibt einen kompletten Sektor bei der Installation - irreversibel.
Das jungfräuliche GeoMerge von Geos 2.0 hat den Sektor jedoch liefern können.

Trotzdem: Wir könnten von dem jungfräulichen Original 3 Sektoren entfernt sein (nur belegte Sektoren gezählt)...

Danke. Den habe ich wohl übersehen. Kümmere ich mich gleich drum.

PS: Die Version ist auch nur gebraucht erworben. Aber der intakte Kopierschutz und die Seriennummernabfrage sind sehr klare Anzeichen dafür, dass die Diskette weitestgehend original ist.

In dem Zusammenhang fällt mir ein: Das war schon immer in der php ini konfigurierbar. Vielleicht wurde "nur" der Default geändert.

Prüf mal 'short_open_tag' in der php.ini nach.

anbei eine deinstallierte Version von Deskpack.

Leider ist für jene Version kein Deinstaller verfügbar, und das Programm zur Seriennummernanpssung aus dem 64'er funktioniert auch nicht (wahrscheinlich geht es nur mit Deskpack Plus).

Daher musste ich das deinstallieren manuell durchführen. Nun haben wir derzeit aber nichts anderes , also ist dies derzeit die Version, die dem uninstallierten Original am nächsten kommt.

Nachtrag: Sobald meine 1571 geliefert worden ist, erstelle ich von dem installierten Original ein nib - das kommt dem Original dann sehr nahe, aber eben nicht dem uninstallierten Original.

Could you please tae a look at the foo.g64 of posting 53?

I'll translate you our results shortly:

Test case was: Convert foo.g64 to a d64 image.

nibconv cannot read direcory sector. nibscan says "unformated".
DirMaster outputs garbage.
micro64disktool creates an empty 40 track d64.
Emulators (Vice, CCS64, Micro64, Hoxs64) cannot display directory content in GUI Dialog for attaching image. When the image is attached, all of these can read the drectory and everything else.

These results are surprising, aren't they?

Before you question: That image has been made just for testing. The content which should be on track 1 is actually on track 2, the content that should be on track 2 is actually on track 3 and so on.

A real 1541 can handle this situation without any problems: The DOS 2.6 finds that the head is initially one track below the desired track and corects it. Then all goes on just as if the disk has been formatted normally.

Addition: One more thing. I have reports that the GEOS 128 version 2.0r Kryoflux Image (the one from above) cannot be written back to a 1571 using a ZoomFloppy and nibwrite (unknown version). Can you check that?

Moment mal, ich glaube, wir haben ein Missverständnis.

Ich habe lediglich den Wunsch / Vorschlag / Möglichkeit geäußert, dass das mit nibread / nibconv erzeugte g64 doch uninstalliert werden kann.

Beim Installieren wird nämlich 1 Sektor überschrieben, und mit ihm mit eienr gewissen Wahrscheinlichkeit auch die Head- und Tailgap. Ich habe nur vorschlagen wollen, jenen Sektor im g64 zu reparieren - mit dem dazu passenden Tool.

Track 18 Sektor 0 hat in beiden besagten Bytes die Seriennummer drin, damit bei Erstinstallation vpn Geos 2.0 und Anwahl von "Ich habe bereits eine installierte App" (sinngemäß!) der Geos 2.0-Installer an einer zentralen Stelle nachschauen kann.

Die eigentliche Stelle der Seriennummer ist die andere.

So ähnlich, wie es oben per Edit nachgefügt habe für Dein GeoCalc128.g64 - so wenig wie möglich ändern, nur das, was die 1541 bei der Installation kaputt gemacht hat. Sollten eher weniger als 15 Bytes im x64 sein (kann ich nicht prüfen, habe kein GeoCalc 64).

Egal, im Falle der Fälle kann ich den minimalen Hexpatch auch nachreichen, der es deinalliert - direkt auf dem g64. Also muss ich mir darum keinen Kopf machen.

Nachrag: Trotzdem wäre es schön, wenn die minimal geänderte g64 oder wenigstens der Patch mit in der Zip-Datei wäre. Weißt schon, wiederfinden, zuordnen etc.

Genau wie vermutet. Nach Reparartur der Header- und Tailgaps auf den Sektor, der die Seriennummer beinhaltet, geht die Installation wieder, wenn man das ganze auf einen g64 macht.
Habs mit geoCalc 128 probiert - da haben wir ja das gleiche Problem.

Zur g64 Repearatur empfehle ich meinen g64conv in der aktuellsten Version.

Für alle, die es interessiert: Das Gcalc128.g64 von wweicht kann man durch einen Patch von 9 Bytes im Hexeditor deinstallieren (Offset, Alt, Neu):

00018904: 73 75
00018905: DB DD
00018906: B5 75
00018A26: 97 AA
00021254: 6D 4A
00021255: 9D 52
00021256: D4 94
000212A6: AC 9D
000212A7: F5 E5

Näher am Original geht es nicht.

Quote from wweicht

Hallo marcusC64,

leider komme ich erst jetzt dazu, zu antworten.

Ja, das funktioniert (zunächst nur getestet mit GeoFile 64 (daran arbeite ich gerade)), wenn man Deinen Weg benutzt (Diskette als D64 und die TailGabs (Kopierschutz) im Nachhinein auf die Disk bringen). Unter "GEOS 64 und 128 V2.0 GE jungfräulich" wurde diese Methode mal als "Holzhammer-Methode" bezeichnet .

Mir geht es vor allem darum, die Geos-Disketten möglichst nahe im originalen Zustand zu belassen. Aus diesem Grund nutze ich G64s für alle Geos-Disketten die irgendwie eine Installation benötigen. Und da funktioniert es nicht! Nach der Deinstallation lassen sich die Disketten nicht mehr installieren (Fehlermeldung: "Auf dieser Diskette kann das Programm nicht installiert werden.").

Display More

Ich denke, er fragt den Kopierschutz genau auf jenen Track ab, wo er die Seriennummer speichert. Dadurch brickt er den Kopierschutz beim Schreiben des Datensektors.
Nicht ganz trivial, sollte man aber mit g64conv minimalinvasiv reparieren können, so dass das Ergebnis so original wie möglich ist.
ZU geoMerge: Wenn Du Hilfe haben möchtest, bitete ich gerne welche an. Dazu bräuchte ich dann natürlich das installierte Image.

Danke. Den muss ich doch auch mal testen...

Derweil habe ich in nibconv eine Heuristik eingebaut: Beim Lesen von Track 18 Sektor 0, was ganz am Anfang gemacht wird) wird im Fehlerfall der Track des gefundenen Sektors 0 genommen und daraus die Trackdistanz berechnet. Der Rest des Programms (inkl. des erneuten Versuches, Track 18 Sektor 0 zu lesen) wird mit jener Trackdistanz verschoben durchgeführt.

Könnte sein. Track 18 sieht jedenfalls ganz anders aus. Ein großer Anteil der Sektoren ist mit 0 Bytes (echte 0, keine 00 gcr encodiert) gefüllt - inkl. Prüfsumme (auch "echte" 0).

Emulator hin, Emulator her - hier kann nur ein echter C64 und eine echte 1541 verraten, welches Verhalten richtig ist.

Ich habe noch ein anderes Problem: Beigefügte (extra zum Testen hergestellte) g64 lässt sich weder mit nibconv noch mit 64copy in ein d64 umwandeln. Im Emulator funktioniert jene aber einwandfrei.

Ist das Problem, dass der Soll-Inhalt von Track 1 auf Track 2 gelandet ist, der von Track 2 auf Track 3 usw.
Eine echte 1541 stellt fest: Kopfposition eine Spur zu niedrig, korrigiert das und alles funktioniert, wie es soll. Im Emulator das gleiche.
Gibt es einen g64 nach d64 Konverter, der das hinbekommt?

Riecht jedenfalls wieder mal nach einem TODO für den nibconv...

Quote from GenerationCBM

Scheint am Template zu liegen. Wenn ich den Track 18-Textpatch anstelle des dortigen Track 18 Sector 18 ins Template setze, dann funktioniert's.

Habe ich unabhängig auch bemerkt. Ist korrigiert.

Quote from GenerationCBM

Alle anderen Ausgaben scheinen (wie auch immer) ungeschützt zu sein. GoldenDisk-Ausgaben, noch nicht geprüft.

In diesem Lichte erscheint die Tatsache, dass vice jene Ausgaben im Turbomode starten kann im ganz anderen Licht - doch keine Ungenauigkeit im Vice?!

Quote from GenerationCBM

Übrigens kriege ich 04/90 nicht per Template-Methode zum Laufen.
[...]

Nachtrag:
Mit deinem Text-Patch aus Post 36 geht's dagegen erfolgreich.

Display More

Danke. Ich werde beide Images vergleichen, dann wird sich der Fehler finden.

Wie im Post 34 geschrieben habe ich auch mit jener Ausgabe getestet. Selbe Ergebnis. Nur mit aufgebrachten Kopierschutz gehts.
Übrigens auch auf echter Hardware.

Bitte sehr, eine exe von g64conv: http://rghost.net/898TYZ72t (leider zu groß für das Forum),.