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

letzter Beitrag von Rob64 am

FluffyFloppy64 - Ein einfacher d64 Datei-Betrachter mit Datenbankfunktion

    Hi Zusammen,


    ich hatte vor vielen Jahren mal mit "case64" einen Anlauf genommen, einen "d64" Datei-Betrachter zu programmieren. Hierzu gibts noch einen alten Forumeintrag hier...

    Auch wenn es schon einige gibt, habe ich es als persönliche Programmierherausforderung für mich zum Spass mal angefangen.


    Es handelt sich um eine sehr frühe (Windows-)Version, welche unvollständig und fehlerhaft ist.


    Beigelegt sind die benötigte und ggf. noch zu installierende Schriftart "C64_Pro_Mono-STYLE" und die sqlite3 Bibliotheken.


    Wer will, kann es sich ja mal anschauen und mir schreiben, ob man so die Richtung was gestalten kann.


    Wenn das hier was Sinnvolles und Verwendbares ist, werde ich dann früher oder später den Quellcode natürlich bereitstellen. Soll/Muss OpenSource werden.


    Grüße

    Frankie The Fluff

    Nun, welches Ziel hat das Projekt denn? Importiert man da quasi in die sqlite-DB dann die Directories der einzelnen Images und kann dann nach Programmen suchen? Wenn ja, klingt das nach einem schönen, kleinen Projekt, das sich nicht zu kompliziert zum Coden anhört.

    Zitat von muffi

    Nun, welches Ziel hat das Projekt denn? Importiert man da quasi in die sqlite-DB dann die Directories der einzelnen Images und kann dann nach Programmen suchen? Wenn ja, klingt das nach einem schönen, kleinen Projekt, das sich nicht zu kompliziert zum Coden anhört.

    Ja, denn man hat ja ggf. in verschiedenen Verzeichnissen "d64" Dateien.


    Meine Anwendung soll dann mal (wenn die sql-Abfrage integriert ist) einfaches Suchen ermöglichen.


    Dzt. kann man entweder durch Verzeichnisse so browsen, also ohne eine Datenbank generieren zu müssen, oder sich eine Datenbank anlegen und Verzeichnissinhalte importieren.


    Angezeigt werden dzt. Inhalte in PETSCII, inkl. gelöschter Dateine, wenn man möchte. Ebenso in Text-Form (die ist technisch relevant für das Durchsuchen), und es zeigt die BAM inkl. den "hidden BAM-Infos", welch maanch ein Schlauberger hinterlassen hat. Es erkennt auch, ob es ein gültiges Standard-image ist oder nicht...


    Naja, mal sehen was das Projekt noch wird...

    :)

    Ich habe mir das Programm ja mal angesehen, deshalb habe ich mein Posting ja abgeschickt. Vielleicht ein paar Ideen... das klingt ganz nett, aber da das Ding ja noch in der Design-Phase ist, ist es schwer zu erahnen, wo es hin gehen soll.


    Wenn Du so eine Suche einfügst, wäre es evtl. ganz interessant, den Original-Pfad der D64 zu speichern.

    Denkbar wäre auch, ein Kommentarfeld für die D64 und den einzelnen Dateien (natürlich hinterher auch durchsuchbar). Oder eine Art Link auf andere D64 oder Dateien, die davon abhängen (könnten) - ich denke da an einen Sourcecode, der z. B. den Input-Ass als Assembler benötigt.


    Das kann man alles (dank sqlite) ja alles ziemlich aufblähen und komfortabel machen. In Sachen Datenbanken ist es halt (leider) unter anderem mein Job auf der Arbeit, mich um Abfragen zu kümmern. Und sqlite ist eine wunderbar schnelle Datenbank, die alles kann, was man so im Normalfall braucht (na gut, außer left joins, die muss man halt umformulieren, aber das ist beim Inner Join bei MySQL/MariaDB ja auch so wie bei sqlite).

    In der Datenbank können von mir aus gerne noch viel mehr Dinge landen:

    Tape- und SID-Dateien, Quelltexte, Koala-Bilder, die Verzeichnisse mit C64-Dateien an sich...

    AUch die Programme aus den D64 könnten ausgelesen und möglichst klassifiziert in die Datenbank.

    Zitat von muffi

    Wenn Du so eine Suche einfügst, wäre es evtl. ganz interessant, den Original-Pfad der D64 zu speichern.

    Denkbar wäre auch, ein Kommentarfeld für die D64 und den einzelnen Dateien (natürlich hinterher auch durchsuchbar).

    Beides schon enthalten. Kommentarfeld ist in der Datenbank drin, änderbar unten links im Rahmen "Image" . Da kann man bereits sich ein Image auch als Favorit markieren.

    Danke für's feedback :)

    Hallo,


    das geht bereits! Über die Einstellungen kann man das definieren.


    - Als "default"-Anwendung im Windows hinterlegte Anwendung öffnet sich bei Doppelklick auf den Dateinamen auf der linken Seite.

    - Wenn man rechts im directory auf den Diskname klickt, startet die floppy mit "Load"*",8,1". Beim Klick auf einzelne Files starten dann entsprechend diese.

    Zitat von Hoogo

    In der Datenbank können von mir aus gerne noch viel mehr Dinge landen:

    Tape- und SID-Dateien, Quelltexte, Koala-Bilder, die Verzeichnisse mit C64-Dateien an sich...

    AUch die Programme aus den D64 könnten ausgelesen und möglichst klassifiziert in die Datenbank.

    Ist man dann nicht schon nahe des Gamebase-Frontends?

    Gerade als zukünftiger SD2IEC-Nutzer würde ich mir wünschen, schnell einzelne Files von einem zum anderen d64 kopieren zu können.


    Eine Art Norton-Commander wäre da schon cool.

    Auf dem C64 nutze ich heute dafür CBMCommand, aber PC-seitig wäre natürlich zeitgemäßer. Auf der alten Hardware will ich ja "cruisen", geniessen, aber nicht bei der Verwaltung meine Zeit verschwenden.


    Und dann natürlich gleich die Funktion drin, das D64 per X1541 auf echte Datenträger zurückzuschreiben :-)

    A500+A570/1MB+2MB, A1200 recapped 3.1.4 2MB+8MB 8GBCF Ethernet, CTDV"-mit-alles"+Joyports, DX64+internHDD, CD32 recapped, C128D+ProspeedGTI2.0, C128DCR, diverse 3rd party, "MerkurHappytouch" als MameCab CRT Touchscreen

    ´92 VW T3 Multivan mit diesen und jenen kranken Features...

    Zitat von T3V6

    Gerade als zukünftiger SD2IEC-Nutzer würde ich mir wünschen, schnell einzelne Files von einem zum anderen d64 kopieren zu können.


    Eine Art Norton-Commander wäre da schon cool.

    Auf dem C64 nutze ich heute dafür CBMCommand, aber PC-seitig wäre natürlich zeitgemäßer. Auf der alten Hardware will ich ja "cruisen", geniessen, aber nicht bei der Verwaltung meine Zeit verschwenden.

    Schau dir hierzu mal https://style64.org/dirmaster an. Da werde ich das Rad vermtl. nicht neu erfinden...

    Hui!

    Hiermit ziehe ich den grössten Teil meiner Aussage zurück.


    "Nicht mehr als" eine zweite Gamebase fände ich aber trotzdem den falschen Ansatz.

    A500+A570/1MB+2MB, A1200 recapped 3.1.4 2MB+8MB 8GBCF Ethernet, CTDV"-mit-alles"+Joyports, DX64+internHDD, CD32 recapped, C128D+ProspeedGTI2.0, C128DCR, diverse 3rd party, "MerkurHappytouch" als MameCab CRT Touchscreen

    ´92 VW T3 Multivan mit diesen und jenen kranken Features...

    Zitat von T3V6

    Ist man dann nicht schon nahe des Gamebase-Frontends?

    Ich hab mir das GB Frontend nie genauer angesehen, weil Spielesammlung nicht so mein Topic ist. Habe mir erst jetzt screenshots angesehen: Ich finde da ein paar Elemente, die mir gefallen: Zu einem Spiel-Titel werden alle möglichen Infos gesammelt.

    Ich nehme an, man kann nach *Hubbard* suchen, bekommt dann alle Spiele mit Musik von Rob Hubbard und kann dann direkt das .sid-File von Spellbound finden und sidplay damit starten?

    Und wenn ich nach "*dunkl*rad*" suche, dann würde die kleine Story zu Elite gefunden und Elite angezeigt, falls die Datenbank entsprechend gepflegt wäre?


    Was mir eher vorschwebt:

    Seit 20 Jahren werfe ich alles mögliche mit C64-Bezug in einen Ordner "C64": D64-Images, TAP-Dateien, Quelltexte, Grafik in verschiedenen Formaten, .Exe-Tools, .Sids... Und gezippt ist auch noch alles mögliche. Dann passieren auch mal Systemwechsel und Backups, die dann irgendwann wieder zusammengeführt werden: Alles in einen Ordner "C64". Versionskontrolle war früher auch noch nicht, es gab kein GIT, sondern Kopien von Dateien mit phantasievollen Namen. Vom Chaos und den Dubletten mal abgesehen sind D64-Dateien mit Bordmitteln eher schlecht zu durchsuchen. Mal eben eine Diskette mit dem "Professional-Ass" finden ist da nicht! Und GIT in D64-Dateien schon gar nicht.


    Daher meine Vorstellung:

    - Erstmal die Verzeichnisse scannen und alles mit Hash in die Datenbank schieben.

    - Auch die Dateien aus den D64 in die Datenbank schieben und so zumindest Dateinamen durchsuchbar machen.

    - Dann mehr Dateiformate mit C64-Bezug erkennen und verstehen. Bei .sid naheliegend, auch Amicapaint-Bilder oder Koala-Bilder könnten erkannt und gerendert in die Datenbank, schwieriger bei alten Quelltext-Formaten und Basic-Programmen, aber auch die könnten nach Ascii gewandelt und Kommentare und Texte indiziert werden.


    Suche und Dublettensuche wären erste Anwendungen der Datenbank.

    Verschobene Dateien zu erkennen, ohne Tags zu verlieren, wäre sicher gut.

    Abgleich mit fremden Datenbanken wäre imho die Krönung. HVSC/CSDB-Datenbank runterladen und die Zusatzinfos für erkannte Dateien importieren, und das meiste Chaos wäre beseitigt.

    Zitat von Hoogo

    Ich nehme an, man kann nach *Hubbard* suchen, bekommt dann alle Spiele mit Musik von Rob Hubbard und kann dann direkt das .sid-File von Spellbound finden und sidplay damit starten?

    Ja, im GameBase Frontend ist sowas möglich: Es kann gefiltert werden und die entsprechend gelisteten Spiele bzw. Musiksstücke können direkt gestartet bzw. abgespielt werden (vorausgesetzt natürlich, dass die GambeBase64 Collection richtig/vollständig installiert und konfiguriert ist):


    Hi Zusammen,

    mein Thema hier ist ja doch schon ne Weile her (2021). Mein Projekt hat lange geruht.

    Vor ein paar Monaten habe ich mal wieder angefangen, die Anwendung etwas weiter zu entwickeln und an meine Bedürfnisse anzupassen.


    Wer möchte kann den aktuellen Stand sich gerne mal anschauen und feedback geben.


    https://github.com/FrankieTheFluff/FluffyFloppy64


    Grüße

    Frankie

    Das ist ja witzig... vor einiger Zeit hatte ich mit SQLite ein ähnliches Programm gemacht.

    Da kann ich alle D64 einlesen, die Directories liest es auch ein und hat zusätzlich eine Dubletten-Suche, die allerdings nur auf D64-Ebene funktioniert.

    Eine Dublettensuche für einzelne Files dürfte nicht so sinnvoll sein. Liest man z. B. GEOS-Disks ein, findet man sonst die DESKTOP oder ähnliche viel zu oft.