nibconv: Fehlerkorrekturen

Hallo,

ich habe festgestellt, dass nibconv die Konvertierungen von g64 in irgendwas leider ziemlich schlecht macht. Da ich aber öfter mal g64 nach d64 brauche, habe ich den Sourcecode mal durchstöbert und korrigiert.

nibconv67 ist übrigens integriert, die Option "-7" schaltet um auf GEOS-Tailgaps bei der Konvertierung von d64 nach g64.

Bitte mal testen. Die korrigierten Fehler sind

• Fehlendes seek beim Einlesen von g64 Dateien. Macht sich bemerkbar, wenn die Tracks nicht in aufsteigender Reihenfolge lückenlos im g64 gespeichert sind.
• Das Sync-Ende muss nicht an der Bytegrenze sein - aber nibconv nimmt das an.
• Ein Header-/Datenblock kann im g64 auch so am Ende des Tracks gespeichert sein, dass er am Anfang fortgesetzt wird - die Originalhardware hat ja kein Anfang/Ende eines Tracks. Dies beherrschte nibconv auch nicht.

Wenn man diese Fehler anschaut, gewinnt man den Eindruck, dass der Code nicht besonders ausgereift ist. Verbesserungsvorschläge sind daher jederzeit willkommen.

Wohl wahr (die Frage mit dem Vergleich zu anderen Tools).
Nur brauche ich nibconv sowieso (wegen der Option mit den GEOS-Tailgaps, ehemals als separates Programm; und wegen der Option, nib-Dateien in g64 umzuwandeln).

Interessant wäre mal, wie verschiedene Tools sich anstellen, wenn die Diskette (d.h. das g64-Image) mit einen Offset von einer Spur formatiert ist, also das was auf SPur 1 gehört, auf Spur 2 ist, was auf Spur 2 gehört auf Spur 3 ist usw.
Da müsste die aktuelle Version von nibconv nämlich noch eine Schwäche haben.

Genau, ich habe auch 64copy genommen, aber auf einen anderen PC. Und das wurde mir jetzt zu umständlich. Und 2 Versionen zu fehlerkorrigieren ist auch keine Alternative, also musste die Option rein.

Sollten weitere Problemfälle auftreten (jetzt mal abgesehen von der mit Offset formatierten Diskette - wovon ich derzeit kein Testexemplar habe; ich weiß aber, dass eine echte 1541 damit keine Probleme hat), immer her damit.

Lt. Source-Code erkennt nibconv die Endungen .d64 (read_d64), .g64 (read_g64), .nbz (read_nib + entpacken), .nib (read_nib) und .nb2 (read_nb2). Dabei stehen in Klammern immer der Funktionsname, in dem die Lesefunktionalität implementiert ist.

Demnach ist .nb2 ein weiteres, mir ebenfalls unbekanntes, Format.

Erläuterungen zu nb2: http://www.lemon64.com/forum/v…4259121c231c89e550222bce5

Hat irgendwer Details zu Timex? Ich meine so detailreich, dass es für eine GCR-Anpassung reicht.

Details zu Cyan Loader / Janis Patch?

Zitat von GenerationCBM

Cyan loader grundsätzlich beschrieben bei Pete Rittwage: http://c64preservation.com/cyan

Der Patch ist furchtbar einfach: in einem betroffenen D64 bei bytepos 0x592d das $2f in ein $a2 und bei 0x5935 das $18 in ein $0f ändern. Dann sollte jedes Cyan Loader-Spiel original laufen. Das ist in dem von Pete besagten Track 5 Sektor 5, und der scheint bei allen damit geschützten Spielen identisch zu sein.

[...]

Ich habe aber leichte Bauchschmerzen, ob es eine gute Idee ist, sowas in nibconv einzubauen. Das ist ja eigentlich ein Konverter, und kein Crack Tool das aktiv die High Level-Daten in einem D64 verändern sollte. Das hat dann mit "Erhalt originaler Software/Daten" herzlich wenig zu tun, ich bin da gespalten.

Alles anzeigen

Kann ich nachvollziehen. Die Information, dass "nur" 2 Byte gepatcht werden müssen, habe ich auch schon gefunden - nur eben nicht, welche mit welchen Werten. Und die Aussage, dass Du es bereits gemacht hast, gab mir Anlass, trotzdem zu fragen: Es war dann ja so, dass Du den Patch recht schnell angeben kannst.

Aber was man hier nicht gebrauchen kann, braucht man dann beim nächsten Projekt: Entweder ich finde einen guten GCR-Viewer/Editor, oder ich muss mir selber einen schreiben. Selbst so eine Sache wie der Yan Loader patch ist auf einer g64 ja nicht einfach - ganz zu schweigen von einer menschenlesbaren Ansicht, welche Daten auf der Spur drauf sind (GAP-Längen etc.).

Nein, x64 kann das nicht, da die 1541 emuliert wird, und die muss immer einen ganzen Sektor inkl. Sync schreiben. Dabei werden öfter mal die Tailgaps von GEOS zerstört.
Fazit: Ein Inhaltspatcher für g64 fehlt mir derzeit, und d64 ist dabei dann ja nur eine kleine Erweiterung.

Ja, natürlich, ansonsten ist das ja nicht so richtig menschenlesbar. Und am besten so, dass wenn man die lesbare Übersetzung im Texteditor bearbeitet, das Ergebnis wieder rückwandelbar in eine g64 ist.

Als Ergebnis eine Text-Datei zu haben, eröffnet nämlich viele Möglichkeiten - insbesondere zwei Stände einfach textuell vergleichen zu können, um zu sehen, wo ein Tool änderungen gemacht hat.

Zitat von GenerationCBM

Was Timex angeht, den Fake Header Writer habe ich pro forma mal angehängt.

Der scheint im VICE leider nicht zu laufen - nach dem Lauf ist Track 18 derart unlesbar, so dass ein load"$",8 nicht mehr geht. Wäre es kein Image, so wäre das mit Sicherheit der Worst-Case.

Ich weiß, habe schon extra mit zwei Pokefinder-Nightlies von Februar 2016 probiert.

Zitat von GenerationCBM

[aber ein lauffähiges G64 eines MagicDisk-Menüs habe ich damit noch nicht hinbekommen.

Dafür habe ich aus den TOSEC-NIB ein lauffähiges G64 von Game ON 10/89 hinbekommen.
Doppeltes nibconv (g64 -> d64 -> g64) beweist, dass der Time-X Schutz noch drauf ist, weil dann wird es als Kopie erkannt.

Jetzt muss man "nur" noch rausfinden, was den Kopierschutz genau ausmacht.
Ich habe aber schon gesehen, dass auf Track 18 ungültige Bytes siind ( 00 ).

Update: Durch Ersetzen aller Tracks außer Track 18 durch den Output der Umwandlung g64->d64->g64 [*] habe ich erfolgreich eingegrenzt, dass Track 18 alleinig für den Schutz verantwortlich ist.

[*] Dabei muss man etwas tricksen, damit im Sektorheader die richtigen IDs stehen.