Hallo Besucher, der Thread wurde 2,6k mal aufgerufen und enthält 16 Antworten

letzter Beitrag von detlef am

G64/G71 Dateien am PC bearbeiten

    Moin moin,


    anbei eine .NET 4.0 DLL, die es erlaubt, einzelne Sektoren einer G64 bzw. G71 zu lesen und zu schreiben. Er kommt auch mit dem sehr harten Testfall aus Neuer Cbm File Browser / Editor klar.


    Benutzung etwa so:


    GcrImage.GCRImage foo = new GCRImage("geos128r_d1.g64");
    byte[] sector = foo.readSector(18, 0);
    // After changing the content:
    foo.writeSector(18,0,sector);
    foo.save("foo.g64");



    Daneben gibt es noch eine zweite Variante von "readSector" und "writeSector", die einen zusätzlichen Parameter haben, der dann als erstes angegeben werden muss. Es handelt sich um die physikalische Tracknummer - verdoppelt, damit ganzzahlig (Stichwort: Halftracks).
    So kann der Track angegeben werden, auf den anch dem Sektor gescuht werden soll. Dies ist für die Rückseite einer G71 notwendig. Aber auch Disketten, die mit einem Offset k bespielt wuden, d. h. der Sollinhalt von Track i ist auf Track i+k geschrieben, können so verarbeitet werden. Um deren Verarbeitung zu unterstützen, gibt es noch eine Funktion


    foo.getTrackFromHeader(trackNumber)


    wobei wegen der Ganzzahligkeit auch hier die Tracknummer verdoppelt werden muss (Halftracks).


    Grüße


    Markus

    Ein Update der Library ist in Arbeit. Ich habe eingeplant, dass ein paar Checks eingebaut werden, ob die echte Tracknummer[*] im Bereich ist, der durch das Image abgedeckt ist. Und eine Signaturprüfung der Datei.


    Weiterhin kann man zukünftig den Konstruktor auch direkt ein Byte-Array mitgeben, statt das Image vom Datenträger einzuladen. Und analog zum Speichern kann man es auch wieder als ReadOnlyCollection<Byte> abfragen.


    Falls noch wer Optimierungswünsche hat, dann bitte hier aufschreiben. :-)



    [*] also nicht die, die im Header steht. Wenn man angibt, auf welcher Spur man suchen will, und diese Spur im erlaubten Bereich liegt, kann man ja durchaus nach einem Block suchen, der eine normalerweise ungültige Tracknummer hat. Kann für Kopierschutzvarianten vielleicht nützlich sein - zumindest gibt es keinen Grund, warum eine Library das verbieten soll.

    Hallo Markus,


    wirst du auch die Quellen zu der DLL veröffentlichen?


    Mich interessiert natürlich, wie du vorgehst und würde meine Leseroutine im CbmFileBrowser gerne optimieren. :whistling:


    Gruß, Detlef

    Es wird von mir noch eine weitere DLL geben, die das Dateisystem von 1541, 1570, 1581, DNP und FD2000, FD4000 lesen und schreiben kann. Jetzt inkl. Geos und so weiter. In der Tat habe ich jene DLL weitestgehend fertig kodierrt, aber noch nicht angetestet. Es werden also ziemlich sicher Bugs drin sein.


    Jedenfalls, wenn die auch fertig ist, gilt folgendes: Ich bräuchte dann ein PC-Progamm, welches solche Sachen wie Dateien und Verzeichnisse (sic! DNP untestützt Verzeichnisse) kopieren ermöglicht (von Image zu Image oder zwischen Image und PC). Unter Benutzung der Libray.
    Wenn ich das Programm bekomme (als Quelltext, damit Probleme problemlos beseitigt werden können) - egal von wem - gibt es den Quelltext der G64 Library.
    Die Dateisystemlibary wird es sowieso als Quelltext geben...


    Ihr wisst schon: Eine Hand wäscht die andere...



    @detlef: Da war doch was, ein alter Thread... na, genau. Du hattest den Filebrowser in C# geschrieben. Vom Grundsatz könntest Du also die Libraries einbinden.

    Du kannst selbstverständlich die Quellen von meinem Browser bekommen.
    Aber das Ding ist ziemlich komplex, unaufgeräumt und buggy. Ich blicke da selber gerade noch so durch. Ich weiss nicht, ob du dir das antun willst. :D
    Mir fehlen mal ein paar Tage Zeit am Stück, um wieder Ordnung zu schaffen.


    In der bestehenden Form kann ich deine DLL leider nicht einbinden. Das passt nicht in meine Klassen-Hierarchie.
    Was evtl. funktionieren könnte ist, wenn ich deiner Library statt einem Dateinamen das komplette Image als ByteArray übergeben könnte.

    Das können wir versuchen. Wobei mich eigentlich die noch nicht veröffentlichte Version von meiner großen Library interessiert - die mit dem Dateisystemzugriff. Im Gegensatz zum alleinigen Sektorzugriff.


    Irgendwie haben derzeit alle Filebrowser Macken. Ich zähle mal einige für mich wichtige auf:


    * G64 Zugriff. Aus deinem Filebrowserthread (s. o.) kennst Du ja den Härtetestfall. Damit bekommt man eigentlich alle Programme an die Grenzen.
    * DNP Support mit Geos-Dateien und Unterverzeichnisse. Ich möchte meine Geos Megapatch Installation damit bestücken können, die ist in einer DNP. Quellen liegen in D64 und D81.
    * Geos Topdesk Ordner (falls die Dir nichts sagen: Das sind Pseudounterverzeichnisse, also keine echten Unterverzeichnisse, sondern pro Verzeichniseintrag wird einfach ein Marker hinzugefügt, zu welchen Pseudo-UV die denn nun gehören. Aber alle Einträge sind im selben Directory untergebracht).
    * Muss unter 64 Bit Windows laufen(!!!)
    * Export und Import zwischen PC-Dateisystem und Image auch für Geos- und REL-Dateien. Letztere so, wie es das SD2IEC erwartet.


    Sind also ein paar Brocken dabei... die es nicht einfacher machen. Und weil eben alle verfügbaren Programme an dem einen oder anderen Punkt scheitern und/oder schwerwiegfende Fehler beinhalten (wie bei DirMaster), soll diesmal der Dateisystemzugriff als Quelltext vorliegen - so dass jeder erkannte Probleme korrigieren kann. Habe da zwischen den Jahren einige Tage dran gesessen.
    Wenn dann was ist, braucht man nur die DLL optimieren und die bevorzugte Software neu übersetzen und alles ist gut.




    Edit: Ich füge der obigen Liste noch eine sehr wünscheswerte Sache hinzu - auch das kann meine nächste Library:
    * Aus Geos-Dateien Info-Block sowie einzelnen VLIR-Record einzeln exportieren
    * Bestehende Dateien updaten unter Verwendung der bereits verwendeten Sektoren in der selben Reihenfolge.

    Mit GEOS kenne ich mich leider überhaupt nicht aus. Ich könnte mir aber vorstellen, dass wir mit deinem Know-How einige Dinge in den CbmFilenBrowser einbauen könnten.
    64 Bit Windows ist gegeben (Visual Studio C# Projekt).
    Export und Import von Dxx-Images ins Windows-Dateisystem ist bereits implementiert.
    Auch den Import und Export von REL-Dateien hatte ich schon implementiert. Ich muss aber mal testen, ob das noch funktioniert. Es gab da ein paar strukturelle Umstellungen. :whistling:


    Die Quellen des CbmFileBrowser werden ich auf jeden Fall veröffentlich. Ich habe das nur noch nicht gemacht, weil er - wie schon gesagt - nicht aufgeräumt ist.


    Die TapecartFlasher habe ich ja auch komplett veröffentlicht.
    Du kannst die Quellen gerne vorab bekommen.


    Ich muss einfach mal die anstehenden Projekt priorisieren. Es wäre vielleicht ganz gut, mal wieder was am CbmFileBrowser zu machen. ;)


    Programmierst du in C#?

    Ja, C# 7 mit Visual Studio 2017.


    Also ich hätte kein Problem damit, Dir schon mal eine Vorabversion der goßen Libray zu geben, damit Du die Integation prüfen kannst. Die braucht die Libray, um die dieser Thread eigentlich geht, so dass wir eine gute Kapselung der Funktionalitäten haben.


    Allerdings ist die in der Benutzung etwas eigen: Statt eines Dateinamens wollen quasi alle Funktionen den Directtoyeintag haben. Hat den Vorteil. dass man den dann ohne Suche manipulieren kann - und so auch keine Probleme bekommt, wenn man es mit manipulieten Directories zu tun hat, die ja dann keine Eindeutigkeitsbedingung unterliegen... Dateien anlegen tut man, indem man sich einen leeren Verzeichniseintrag geben lässt, dort die Eintagungen mit Ausnahme von Tack/Sektor und Länge über .Net Properties macht und das dann der Schreiberoutine übergibt. Etwas eigentümlich, erlaubt jedoch die volle Kontolle über alle erweiterten Geos-Infos.


    Und ein Dateiname ist ein byte[18], ein Diskettenname ein byte[21] (also inkl. ID und $A0 "2A"). Hilfreiche Konveengsfunktionen kann ich der Library noch hinzufügen - eigentlich ist das aber Sache der Applikation.

    Zitat von markusC64

    Allerdings ist die in der Benutzung etwas eigen: Statt eines Dateinamens wollen quasi alle Funktionen den Directtoyeintag haben. Hat den Vorteil. dass man den dann ohne Suche manipulieren kann - und so auch keine Probleme bekommt, wenn man es mit manipulieten Directories zu tun hat, die ja dann keine Eindeutigkeitsbedingung unterliegen... Dateien anlegen tut man, indem man sich einen leeren Verzeichniseintrag geben lässt, dort die Eintagungen mit Ausnahme von Tack/Sektor und Länge über .Net Properties macht und das dann der Schreiberoutine übergibt. Etwas eigentümlich, erlaubt jedoch die volle Kontolle über alle erweiterten Geos-Infos.

    Ich sehe schon, hier treffen wohl unterschiedlich Konzepte aufeinander. ;)
    Aber das heisst nicht, das man das nicht zusammenbekommt.


    Hast du mal einen Beispielaufruf: Anlegen eines Directory-Eintrages?



    Zitat von markusC64

    wenn man es mit manipulieten Directories zu tun hat, die ja dann keine Eindeutigkeitsbedingung unterliegen

    Du meinst Einträge mit identischem Namen?

    Zur ersten Frage: Habe ich - stelle ich Dir mogen zusammen. Konzept: Man lädt das Directory - dazu gibt es im Objekt des Dateisystems einen Aufuf. Jenes hat wiederrum eine Methode, einen freien Eintrag zu suchen - und falls erforderlich, dazu einen Sektor dranzuhängen. Es muss eine Funktion des Directories sein, weil es ja Unterverzeichnisse geben kann.


    Zur zweiten Frage:
    Ja, genau. Gerne zu sehen bei DEL Dateien, die nur zur Formatierung dienen. Auch die will man ggf. löschen.


    Und zur nicht gestellten Frage:
    Alle Formate gehen exakt gleich - mit einer Ausnahme. Abstrakte Klassen stellen das sicher.
    Die Ausnahme sind die beiden CMD FD-Formate. Da muss man zur Erzeugung wohl oder übel eine Patition auswählen, bevor man beim klassischen Dateisystem ankommt.

    Zitat von markusC64

    Alle Formate gehen exakt gleich - mit einer Ausnahme. Abstrakte Klassen stellen das sicher.

    Eine Basis-Klasse, von der sich alle Laufwerke und Images ableiten.
    So sieht das bei mir aus:




    Zitat von markusC64

    Die Ausnahme sind die beiden CMD FD-Formate. Da muss man zur Erzeugung wohl oder übel eine Patition auswählen, bevor man beim klassischen Dateisystem ankommt.

    Da muss ich wieder passen.

    Zitat von detlef

    Hast du mal einen Beispielaufruf: Anlegen eines Directory-Eintrages?

    Zitat von detlef

    Eine Basis-Klasse, von der sich alle Laufwerke und Images ableiten.

    Man sieht ihr die Abwesenheit von Partitionen, Unterverzeichnissen und Geos-Unterstützung an. Würde sagen: Ist halt auf 1541 bis 1581 ausgelegt - ohne Geos-Erweiterung.

    Zitat von markusC64

    Man sieht ihr die Abwesenheit von Partitionen, Unterverzeichnissen und Geos-Unterstützung an. Würde sagen: Ist halt auf 1541 bis 1581 ausgelegt - ohne Geos-Erweiterung.

    Zumindest 1581 Partitionen und Unterverzeichnisse sind implementiert, aber ungetestet, weil ich keine 1581 habe und die Emulation in allen von mir verwendeten Vice-Versionen kaputt war.
    In der aktuellen Vice-Version soll es wieder funktionieren und ich könnte die von mir erzeugten Images überprüfen.


    In der obersten abstrakten Klasse findet sich das nicht wieder, weil Unterverzeichnisse erst mal als Besonderheit von bestimmten Image-Typen behandelt werden.
    Hier sieht man, dass das prinzipiell schon berücksichtigt wurde. Unterverzeichnisse und Partitionen sind einfach spezielle Filetypen. In der 1581 wurde das ja auch so realisiert.
    Die oberste abstarkte Klasse um entsprechende Methoden zu erweitern, wäre keine große Sache.

    Ich habe jetzt nicht viel Zeit, genau genommen fast keine. Wird heute Abend aber besser mit der Zeit. Kann ich Dir die *.cs-Dateien meiner großen Library zukommen lassen?

    Ja, gerne. Ich werde heute Abend mein Projekt so umbauen, dass ich es auch rausgeben kann. Im Moment sind da zuviele externe Referenzen drin (auf andere Commdore-Projekte).
    Dann kann ich dir das auch schicken.

    Weil ich heute noch Urlaub habe (ab nächste Woche wird's dann auch knapper mit meiner Zeit), habe ich das CbmFileBrower-Projekt schon mal ein wenig aufgeräumt und kann dir das jetzt zuschicken, wenn du Interesse daran hast.


    Weiteres dann der PN.