Hello, Guest the thread was called2.3k times and contains 56 replays

last post from Zirias/Excess at the

V1541Commander -- Tool für 1541 disk images (D64)

  • Habe gestern abend V1541Commander V1.1 released.



    Es handelt sich um ein neues Tool für D64 disk images (andere Image-Formate von anderen Laufwerken wie 1571 etc werden aktuell nicht unterstützt).


    Download: https://csdb.dk/release/?id=187433

    Projektseite/Quelltext: https://github.com/excess-c64/v1541commander


    Features:

    • Lesen und schreiben von D64 Images
    • Unterstützt 40- und 42-Track Images
    • Unterstützt die BAM Formate von SpeedDOS, DolphinDOS und PrologicDOS
    • Import und Export von Dateien im PC64 Container-Format (.P00/.U00/...)
    • Komprimieren und Entpacken von 4-pack und 5-pack ZipCode (1!xxx.prg, 2!xxx.prg etc)
    • ZipCode Dateien auf D64 Images
    • Erstellen und Importieren von LyNX Archiven


    Die komplette Logik ist in C geschrieben und liegt in einer separaten Bibliothek, lib1541img. Das Frontend verwendet Qt und ist daher in C++ geschrieben. Das Tool sollte prinzipiell auf allen Betriebssystemen laufen, für die es Qt gibt.


    Das ganze ist nicht als Ersatz für DirMaster gedacht, und wird es wahrscheinlich auch nie werden -- allerdings wird es aktiv weiterentwickelt und neue Releases mit neuen Features werden kommen. Ein paar Kleinigkeiten kann es schon jetzt besser, zum Beispiel kann PETSCII zu einem großen Teil komfortabel per Tastatur eingegeben werden (die Alt-Taste entspricht der C=-Taste), und die Unterstützung für ZipCode und LyNX ist wohl etwas stabiler :) -- außerdem ist es eben Opensource und plattformunabhängig. Die offiziellen Builds sind "portable", es ist keine Installation nötig und das Executable ist lauffähig ohne irgendwelche weiteren Files zu brauchen.


    Nicht unterstützt werden aktuell unter anderem Trackloader, C128 Bootsektoren, GEOS Files, usw. (allerdings ist es kein Problem, Disks zu packen/entpacken, die solche Dinge enthalten).


    Enthalten ist eine (möglichst) vollständige Tastatur-Unterstützung, mehr dazu im README. Seit der Version 1.1 ist auch Drag&Drop vollständig unterstützt.


    Im Paket befindet sich ein ausführliches README, das sich auch auf der Github Seite bequem lesen lässt, und eine kleine Sammlung von FAQs. Die Dokumentation ist allerdings bisher nur auf englisch.


    ---


    Falls jemand Lust hat, etwas beizutragen:

    • Vernünftige Pakete für verschiedene Linux-Distributionen wären nett. Um einen Port für FreeBSD kümmere ich mich selbst :)
    • Ein offizieller Build für MacOS X wäre auch cool, da fehlen mir aber Erfahrung und Werkzeuge
    • Übersetzungen: Die einzige Übersetzung bisher ist auf Deutsch. Wer eine andere Sprache beitragen kann, bitte gerne :)
    • Ganz allgemein sind Pull Requests gerne gesehen, wenn sie zu Codestil und Architektur passen (erfahrene Coder sollten das am bestehenden Code erkennen).
    • Bugs? Ganz tolle Feature-Ideen? Auf Github gibt es dafür "Issues", gerne welche erstellen!
  • Fulgore

    Approved the thread.
  • Danke schon mal für das positive Feedback, das motiviert natürlich direkt, an der V1.2 zu arbeiten :)


    Im Fokus für die nächste Release steht ein eigenes Dateiformat für "DirArt", und dazu ein einigermaßen komfortabler Editor im GUI. Ziel ist es, dass man vorgefertigtes DirArt (oder Teile davon) recht einfach in neu erstellte Disk-Images einbauen kann. Das soll irgendwann auch von einem Kommandozeilen-Tool aus verwendbar sein.


    Außerdem werden kleinere Fehlerchen behoben und es wird einen Modus geben, der Sektoren wirklich exakt wie das originale CBM DOS belegt (die jetzige Implementierung ist nahe dran, aber nicht exakt -- habe direkt vom 1541-Meister "Krill" einen Hinweis auf CSDb bekommen).

  • Ich hab heute noch einen kleinen, recht seltsamen Bug entdeckt und im git auch direkt gefixt...


    Kurzversion für alle: Wenn eine Instanz von V1541Commander bereits läuft und man ein weiteres Image z.b. per Doppelklick aus dem Windows Explorer öffnet, kann es passieren, dass es gar nicht aufgeht sondern nur das bestehende Fenster in den Vordergrund kommt.


    Workaround: Wenn V1541Commander bereits läuft, weitere Images entweder per "File > Open" Menü oder per drag&drop öffnen.


    Hintergrund für technisch interessierte: V1541Commander ist als "single instance application" entworfen. Das heißt die erste Instanz, die gestartet wird, öffnet einen lokalen Socket und nimmt darauf connections an. Weitere Instanzen finden diesen Socket und öffnen einen lokalen Client-Socket um mit der ersten Instanz zu kommunizieren. Alle an der Kommandozeile angegebenen Dateien zum öffnen werden einfach über den Socket an die schon laufende Instanz übergeben (die sie dann öffnen soll) und der neue Prozess endet direkt wieder. Im bestehenden Code werden Dateinamen über den Socket geschrieben, danach wird die Ausgabe "geflusht". Zumindest auf Windows (ich habe nicht geprüft, ob auch andere Systeme betroffen sind) reicht dieser "flush" aber nicht, um sicherzustellen, dass die Nachricht wirklich ankam -- man muss außerdem nach dem schließen des Socket warten, bis das System ihn wirklich als "geschlossen" meldet, erst dann darf die zweite Instanz sich beenden. Mit V1.1 habe ich entschieden, die offiziellen builds von V1541Commander zu crunchen (mit UPX), weil das doch einiges an Plattenplatz spart. Die gecrunchte Version scheint es viel wahrscheinlicher zu machen, dass der Bug wirklich auftritt, weil das Programm endet bevor der Socket sicher geschlossen ist -- nur dadurch habe ich den Bug überhaupt bemerkt...


    Im nächsten Release wird dieser Bug selbstverständlich behoben sein. Falls es jemanden zu sehr nervt kann ich aber auch hier einen V1.1 Build nur mit dem Bugfix posten :)

  • Good news everyone :)


    Die Entwicklung schreitet voran wann immer ich Zeit habe, die Roadmap für v1.2 ist gesetzt (siehe oben), aber natürlich wird es etwas Zeit brauchen, diesen Stand zu erreichen. Ich habe mich deshalb entschlossen, hin und wieder "Pre-Release" Builds zu veröffentlichen, für alle, die die neuesten Änderungen ausprobieren wollen, ohne gleich selbst zu compilieren. Allerdings gehört da auch eine Warnung dazu: Nutzt diese Builds auf eigene Gefahr!. Sie sind nicht so ausgiebig von den netten Kollegen in Excess getestet wie die offiziellen Releases auf der CSDb.


    Pre-Release Builds wird es hier geben: http://sekrit.de/v1541commander/


    Soeben habe ich den ersten Pre-Release Build, "1.1+pre1", hochgeladen, mit folgenden Änderungen:

    • Der oben erwähnte Bug sollte behoben sein, Dateien aus dem Filemanager öffnen müsste jetzt immer funktionieren
    • Per default werden nun Blocks nach exakt der gleichen Strategie belegt, die das originale 1541 DOS verwendet
    • Neue Dateisystem-Optionen sind dazugekommen, um die Blockbelegungs-Strategie im Detail kontrollieren zu können
    • Alle Dateisystem-Optionen haben jetzt einen Tooltip, damit ist der Dialog hoffentlich selbsterklärend
  • Bisher hatten zwei Leute etwas älteres als Windows 7, was aktuell die Minimalanforderung ist...


    Kurzer Einschub: Wer aktuell etwas älteres als Windows 8 einsetzt und dabei einen Internetzugang hat, oder auch nur Wechselmedien (USB-Sticks etc) verwendet, ist genaugenommen des Wahnsinns und bettelt darum, dass der Rechner übernommen wird ;)


    Trotzdem habe ich jetzt mal eine Version gebaut, die auch auf XP und Vista laufen sollte (da ich sowas aber selbst gar nicht habe bräuchte ich da etwas Feedback, ob es tatsächlich tut!). Der Haken ist: Auch die Qt-Version, die diese alten Systeme unterstützt, ist nicht mehr supported. Ich werde das also sicher nicht zum Standard für Release-Builds machen, auch wenn es geht :)


    Die 1.1+pre1 gibt's jetzt auch in einem XP/Vista Build, hier der Direktlink: v1541commander-win32-xp-vista-1.1+pre1.zip.

  • Als Feature Request hätte ich z.B. :

    - 6-pack Support

    - ggf. zusätzlich "exotische" Archiver wie Arc, Ark, Wraptor das kann DirMaster nicht, und PC-Tools gibt es meines Wissens nach auch nicht dafür

    - Wenn ich ein ZIP File in eine Disk reinziehe, dann erscheint es als USR File. Ich würde hier eher einr PRG erwarten, oder den ggf. den entpackten Inhalt als PRG, SEQ whatever...

    - evtl. DirEditor Funktionen wie Protect Disk / File etc., File Type edit etc. pp. quasi wie die C64 Dir-master Programme das auch können.


    Aber wie auf der Party schon gesagt: TOP Tool ! Danke und weiter so :)

  • Hey :) Schauen wir mal drüber ...

    6-pack Support

    Das ist meiner Meinung nach wenig sinnvoll ohne support für rohe GCR-Daten (G64 images), denn 6-pack packt eben diese rohen Daten. Habe ich schon auf dem Schirm, ist leider keine Kleinigkeit :)

    ggf. zusätzlich "exotische" Archiver wie Arc, Ark, Wraptor das kann DirMaster nicht, und PC-Tools gibt es meines Wissens nach auch nicht dafür

    Kannst du das etwas ausführen? Am besten Doku, zumindest ein Hinweis auf ein "original Tool", dann wäre das ein super Kandidat für ein "feature wish" issue auf Github :)

    Wenn ich ein ZIP File in eine Disk reinziehe, dann erscheint es als USR File. Ich würde hier eher einr PRG erwarten, oder den ggf. den entpackten Inhalt als PRG, SEQ whatever...

    Also PC Archiver werde ich nicht unterstützen, denn das können andere Tools besser -- z.B. auf Windows 7zip. Drag & drop zwischen den Tools sollte tun, habe ich aber nicht geprüft.


    Beim droppen einer Datei versucht V1541Commander, anhand vom Namen den passenden Typ zu bestimmen (prg, p00, p01, ... -> PRG. seq, s00, s01, ... -> SEQ. usw). Wenn dabei nichts rauskommt wird USR verwendet, weil das im 1541 DOS am ehesten einem "unbekannten" Typ entspricht. Das kann man aber jetzt schon konfigurieren, in den Einstellungen :)

    evtl. DirEditor Funktionen wie Protect Disk / File etc., File Type edit etc. pp. quasi wie die C64 Dir-master Programme das auch können.

    Ich glaube hier brauche ich mehr Details um zu verstehen, was dir konkret fehlt?

    • "potect disk" <- Die Diskette "quasi" schreibschützen geht, indem man eine DOS Version einstellt, die weder 0 noch original (0x41, bei prologic DOS 0x50) ist. Ist das gemeint?
    • "protect file" <- nunja, es gibt das "locked" Flag, das kann man auch setzen -- oder meinst du was anderes?
    • "file type edit" <- du kannst den Typ doch für jedes File frei wählen? Was nicht geht sind "invalide" Typen, ist das damit gemeint?
  • Hier ist mal eine kleine Sammlung von mir.


    ch glaube hier brauche ich mehr Details um zu verstehen, was dir konkret fehlt?

    "potect disk" <- Die Diskette "quasi" schreibschützen geht, indem man eine DOS Version einstellt, die weder 0 noch original (0x41, bei prologic DOS 0x50) ist. Ist das gemeint?
    "protect file" <- nunja, es gibt das "locked" Flag, das kann man auch setzen -- oder meinst du was anderes?
    "file type edit" <- du kannst den Typ doch für jedes File frei wählen? Was nicht geht sind "invalide" Typen, ist das damit gemeint?

    Protect Disk = Software Disk Write Protection. Da wird irgendwo auf Track 18 ein Byte geändert. Wo genau müsste ich raussuchen

    Protect File = Files mit "<" hinter dem Filetyp.

    File Type Edit = damit meine ich sowohl invalide Typen, als auch valide. Z.B. ändern von PRG nach SEQ z.B. wofür auch immer man das verwenden möchte.

    Schau dir doch mal den DirMaster an. Dann erklärt sich einiges von alleine.

  • Protect Disk = Software Disk Write Protection. Da wird irgendwo auf Track 18 ein Byte geändert. Wo genau müsste ich raussuchen

    Ist drin, allerdings ohne weitere Erklärung: DOS-Version auf irgendeinen anderen Wert stellen hat genau diesen Effekt.

    Protect File = Files mit "<" hinter dem Filetyp.

    Ist drin, genau das ist das "locked" flag (checkbox in den File properties)

    File Type Edit = damit meine ich sowohl invalide Typen, als auch valide. Z.B. ändern von PRG nach SEQ z.B. wofür auch immer man das verwenden möchte.

    Ist drin, mit der Einschränkung, dass man nur die validen CBM DOS Typen (DEL, SEQ, PRG, USR, REL) setzen kann. Bei Wechsel auf DEL wird auch gewarnt, falls man Dateiinhalt verlieren würde. "Invalide" Typen kommen vielleicht später mal :)


    ---


    Ok ich sehe auf der Disk ist dieses "Wraptor" drauf. Mal sehen ob sich daran was erkennen lässt. Ne Doku des Fileformats wäre einfacher gewesen :/ aber ok ;)

  • Ja, danke, inzwischen hatte ich diese Seite auch gefunden ;) Leider ist gerade die Beschreibung zu Wraptor sehr rudimentär, bzw lückenhaft. (wie genau wird komprimiert, dürfen dictionary lookups rekursiv sein, wenn ja bis zu welcher Tiefe, wie wird CRC berechnet, also wirklich standard Algorithmus, und wenn ja, auf den originalen oder komprimierten Daten, usw .... wird leider alles nicht beantwortet)


    Immerhin konnte ich aber so viel erkennen, dass es wohl sinnvoller ist, erst mal GEOS files zu unterstützen, bevor ich mir diesen Archiver vornehme :)

  • Die 1.1+pre1 gibt's jetzt auch in einem XP/Vista Build, hier der Direktlink: v1541commander-win32-xp-vista-1.1+pre1.zip.

    Kleines Update dazu: Altes Windows habe ich ja nicht, aber auf Windows 10 habe ich mit diesem Build einen Bug gefunden: Öffnen von Files per Doppelklick funktioniert nicht richtig, wenn das Tool schon läuft; das Image wird dann "doppelt" geöffnet, der zweite Versuch geht schief und den Dialog bekommt man nicht weggeklickt, man muss den Prozess abschießen. Ich schaue noch, ob ich dazu einen Workaround finde, allerdings ist funktionierender Support für alte Windows-Versionen auch nicht ganz oben auf meiner Prioritätenliste ;)

    edit: Ich denke ich sehe den Bug, vielleicht ist das doch einfach zu beheben -- nachher mal schauen.

  • Ich hätte eine Anregung für ein Feature, welches bisher so viel ich weiß bei keinem existierenden C64 Diskimage Browser/Manager vorhanden ist:


    Eine Vergleichs-Funktion für 2 Images (z.b. D64), wo binär (Byte-weise) vergleichen wird, und die Unterschiede anschließend für jedes File im Image dargestellt werden (z.b. unterschiedliche Files werden farblich anders dargestellt in einer links-rechts Ansicht ähnlich Norton Commander)

    Klickt man dann auf eines der unterschiedlichen Files, dann sollte der Hexcode incl. ASCII Darstellung für beide Images nebeneinander in einem neuen Fenster gezeigt werden, und die unterschiedlichen Bytes wiederum farblich markiert sein. Cool wäre dann auch noch so eine 'zum nächsten unterschiedlichen Byte weiterhüpfen' Funktion. :)


    Es gibt am PC 2 mir bekannte Tools welche das perfekt erfüllen: Beyond Compare, und Total Commander.

    Es gibt sogar ein .D64 Plugin für den Total Commander, allerdings kann man damit nicht vergleichen.


    Wäre wirklich sehr hilfreich um unterschiedliche Versionen von allerlei C64 Software zu vergleichen, 'kaputte' Bytes zu erkennen, etc.


    Ich weiß natürlich, daß das eine riesen Haufen Arbeit wäre und daher vermutlich Jahre an Programmier-Aufwand bedeuten würde, aber evtl. gibt es ja den prinzipiellen Code für solche Vergleiche schon irgendwie frei erhältlich, sodass man es dann 'nur' mehr auf den Inhalt von .D64 Images anpassen müsste?

  • Overdoc Das ist in der Tat ein Riesen-Feature, das man erstmal in handliche Einzelteile zerlegen müsste und die vernünftig ausspezifizieren. Das Vergleichen ist dabei das geringste Problem, da brauche ich keinen fertigen Code -- spannend wird es dabei, den Vergleich auf das logische Dateisystem zu "mappen" und das irgendwie sinnvoll anzuzeigen :o


    Grundsätzlich ist das eine echt interessante Idee, aber in einer "Roadmap" käme das wohl eher später. Bevor das überhaupt sinnvoll umsetzbar wäre bräuchte ich z.B. mal einen "rohen" edit-mode für Sektoren, und sicher noch eine ganze Reihe anderer Voraussetzungen.


    Wenn du willst, dass die Idee "auf dem Schirm" bleibt, lege bitte gerne ein Issue auf Github an -- aber bitte nicht enttäuscht sein, wenn das nicht zeitnah angegangen wird ;)


    Noch entwickle ich ganz allein, und es ist wohl leider nicht unwahrscheinlich, dass das so bleibt :)