Hello, Guest the thread was called7.8k times and contains 47 replays

last post from Chagizzz at the

UNIXtime64 / Unixzeit / Unixtime

  • Wenn ich bloß wüsste, was Dein Plan ist... ;)
    Also wenn Dir tatsächlich reicht, wenn Dein Programm Dir auch die dazugehörigen Zeiten anzeigt und bei load"$",8 nix erscheint, dann kannst Du Dir natürlich auch eine REL - Datei mit den jeweiligen Daten anlegen. Feste größe - also z.B. 4 oder 6 Byte. Im Falle der 1541 mit maximal 144 Dateien sind das dann etwa 3-4 Blocks die für diese Daten draufgingen - wenn die gesamte Diskette vollgeknallt ist.


    Aber um dazu Überlegungen zu machen, wäre eben interessant, wie Du die Daten benötigst, was für Hardware benutzt wird und mit wievielen Daten Du rechnen würdest.

  • Wenn ich bloß wüsste, was Dein Plan ist...

    Hab' doch keinen 8) .


    Hab' mir das vorhin nochmal angeguckt: Wenn man die neun 'freien' Bytes im Directory benutzt, könnte man damit sogar zwei Zeitpunkte speichern (z. B. erstellt/geändert), da bei [Jahr, Monat, Tag, Stunde, Minute, Sekunde] nur 6 Bytes und davon 33 (von 48) Bits benötigt würden. Für drei Zeitpunkte reicht es (eigentlich) wieder nicht (96 <-> 99). Und da i. d. R. nicht mehrere Dateinamen den gleichen Namen haben dürfen, müsste eh eins von den Daten in den Dateinnamen wandern...

  • Hab' mir das vorhin nochmal angeguckt: Wenn man die neun 'freien' Bytes im Directory benutzt, könnte man damit sogar zwei Zeitpunkte speichern (z. B. erstellt/geändert), da bei [Jahr, Monat, Tag, Stunde, Minute, Sekunde] nur 6 Bytes und davon 33 (von 48) Bits benötigt würden.

    Ob ich jetzt versuchen will nachzrechnen, wie Du mit 33 / 48 Bits rechnest?! Ich denke jetzt gerade nicht. Aber die Frage ist, inwieweit Dir das hilft, wenn Du die Bytes bitweise zerstückelst. Kommt dann nicht am Ende wieder genauso viel Code raus, dass Du doch auch den Unix-Timestamp nehmen kannst?!


    Was aber die 9 Bytes für "ertstellt/geändert" angeht. Zwei der neun Bytes werden doch bei Änderung genutzt, da muss man also vorsichtig sein, dass die erst danach geschrieben werden.


    Dennoch wäre vielleicht die einfachere Lösung die Files einfach zu nummerieren und Zusatzdaten dann in der REL Datei zu speichern. Oder nur eine Datei zu nutzen, an die man die nächsten Messungen anhängt. Ein kleines Trennzeichen kennzeichnet neuen Eintrag, darauf folgend in fester Größe das Datum, vielleicht sogar die Daten an sich... wie csv - Dateien. Somit auch leicht zu durchsuchen, leicht zu vergleichen, leicht weiterzuverarbeiten und übersichtlich in der Directory - die ja ohnehin ihre Grenzen hat.

  • Ob ich jetzt versuchen will nachrechnen, wie Du mit 33 / 48 Bits rechnest?!

    Das war ausgehend von:


    Jahre/Monat/Tag/Stunde/Minute/Sekunde - 84/12/31/24/60/60 und die somit 7/4/5/5/6/6 Bits (=33) verbrauchen, wobei die 84 Jahre noch aus den Directory-CHR$-Codes rührte, also eigentlich Quatsch sind.

    Kommt dann nicht am Ende wieder genauso viel Code raus, dass Du doch auch den Unix-Timestamp nehmen kannst?!

    Ja, lässt sich aber einfacher/schneller auswerten/filtern.

    Was aber die 9 Bytes für "ertstellt/geändert" angeht. Zwei der neun Bytes werden doch bei Änderung genutzt, da muss man also vorsichtig sein, dass die erst danach geschrieben werden.

    Das war doch nur bei @-Replace, oder?

    Dennoch wäre vielleicht die einfachere Lösung die Files einfach zu nummerieren und Zusatzdaten dann in der REL Datei zu speichern.

    Dann hat man aber wieder zwei Dateien, die man händeln muss (beim Speichern auf eine andere Diskette z. B.).


    Wahrscheinlich haben beide Möglichkeiten ihren Sinn. Ich grübel mal weiter...

  • Das war doch nur bei @-Replace, oder?

    Ich dachte bei einem Zeitstempel für geändert würde das @-Replace bedeuten.


    Dann hat man aber wieder zwei Dateien, die man händeln muss (beim Speichern auf eine andere Diskette z. B.).

    Na wenn Du jeweils eine neue Datei anlegst, stört die eine REL-Datei für alle ja nun auch nicht.
    Aber die fortgesetzte Datei ist keine Alternative?

  • Ich dachte bei einem Zeitstempel für geändert würde das @-Replace bedeuten.

    War auch mein erster Gedanke, aber es gibt auch noch den Append-Modus (open2,8,2,"file,a").


    Dieser Thread und der nebenan sind allerdings tolle Beispiele dafür, warum normalerweise erst das Problem und dann die Lösung kommt und nicht umgekehrt. :weg:

  • Ich dachte bei einem Zeitstempel für geändert würde das @-Replace bedeuten.


    War auch mein erster Gedanke, aber es gibt auch noch den Append-Modus (open2,8,2,"file,a").

    Ich versteh' grad nur Bahnhof, ihr beiden - macht aber nix... :D .



    Dieser Thread und der nebenan sind allerdings tolle Beispiele dafür, warum normalerweise erst das Problem und dann die Lösung kommt und nicht umgekehrt.

    So is' das eben manchmal ... :) . Obwohl: Einen kleinen Hintergrund gibt es schon - ist nur etwas ausgeartet :P .


    Musste nun erstmal durch das Directory-Byte-Gedöns durchsteigen, aber läuft:



    Heute Abend dann der nächste Schritt... :kruecke::winke:

  • Über Sinn und Zweck kann man sich streiten.

    Je nach Sinn und Zweck sollte man evtl auch nochmal überdenken, ob Strings überhaupt geeignet sind. Scherze wie MID$/LEFT$/RIGHT$ müllen reichlich den Heap voll, Garbage collection, ick hör dir trapsen, das kann schon mal bis zu 2h die Uhr lahmlegen ;) Ergebnisse der BASIC Garbage Collection Compo

  • Ich versteh' grad nur Bahnhof, ihr beiden - macht aber nix...

    Na wenn Du eine Zeit in der Directory für "geändert" speichern willst und diese Änderung ein Überschreiben der alten Datei bedeutet benutzt Du eben genau dieses @Replace und damit 2 Deiner neun Bytes. Wenn Du an die alte Datei etwas dranhängst nicht.



    Heute Abend dann der nächste Schritt..

    Und, bist Du ihn gegangen?


    Je nach Sinn und Zweck sollte man evtl auch nochmal überdenken, ob Strings überhaupt geeignet sind. Scherze wie MID$/LEFT$/RIGHT$ müllen reichlich den Heap voll, Garbage collection, ick hör dir trapsen, das kann schon mal bis zu 2h die Uhr lahmlegen Ergebnisse der BASIC Garbage Collection Compo

    Habe das zur Compo mal im Schnelldurchlauf gelesen. Bin da unter anderem auf folgendes gestoßen:


    Ich kenne auf jeden Fall (leider aus schmerzlicher Erfahrung) noch aus meiner BASIC-aktiveren Zeit jede Menge Wege und BASIC-Befehle, um die GC sauber ins endlos Langsame zu schroten, aber nur zwei wirklich brauchbare Wege, sie im Griff zu haben, nämlich a) keine Strings oder b) kein BASIC UND keine Strings zu benutzen

    bzw. von Dir zitierter



    Quote from Sauhund

    diese frage [edit: nach dem "sinn"] stellt sich wenn es um basic geht aber grundsätzlich immer.

    Also geht es jetzt hier um Zweifel am Basic allgemein oder hast Du hier eine bessere Methode bzw. einen Denkanstoß?

  • Hab eine Noob-Frage:
    Was heißt "freie Bytes im Directory"? Eine freie Anzahl Bytes hinter einem zu vergebendem Disk-Namen mit x Stellen?


    Ich nehme an, Directory ist das Hauptverzeichnis einer C64 Diskette. Unterverzeichnisse gibt's da ja nicht.


    Der Zweck wäre dann zu hinterlegen, dass meine Diskette am 23. Mai erstellt wurde. Oder ich werkel darin herum und beschreibe die 9 Bytes erneut und "Zuletzt geändert am" ist dann jetzt.


    Die 9 Bytes-Beschreibroutine ist ein Basic Programm das ich immer wieder ausführen kann um den aktuellen Änderungszeitpunkt festzuhalten. So kann ich verschiedene D64 mit "Versionsständen" führen, z.B. mit Basic oder ASM Projekten.


    Eine weitere Routine wäre dann eben cool, die sagt: Lies den Zeitstempel aus und drucke ihn menschenlesbar aus.
    Das wäre schon irgendwie geil. Man könnte das echt benutzen!

  • Was heißt "freie Bytes im Directory"? Eine freie Anzahl Bytes hinter einem zu vergebendem Disk-Namen mit x Stellen?

    Siehe hier: https://www.c64-wiki.de/index.…ory#Aufbau_des_Directorys


    Da sind halt i. d. R. 9 Bytes unbenutzt (Byte 21-29) pro Directory-Eintrag.

    Der Zweck wäre dann zu hinterlegen, dass meine Diskette am 23. Mai erstellt wurde. Oder ich werkel darin herum und beschreibe die 9 Bytes erneut und "Zuletzt geändert am" ist dann jetzt.

    Pro DATEI ! Ob man irgendwo noch ein Datum, wann die Diskette erstmals erstellt wurde, noch irgendwo unterbringen kann, könnte man tatsächlich auch noch gucken.

    Die 9 Bytes-Beschreibroutine ist ein Basic Programm das ich immer wieder ausführen kann um den aktuellen Änderungszeitpunkt festzuhalten. So kann ich verschiedene D64 mit "Versionsständen" führen, z.B. mit Basic oder ASM Projekten.

    Siehe davor.

    Eine weitere Routine wäre dann eben cool, die sagt: Lies den Zeitstempel aus und drucke ihn menschenlesbar aus.

    Das macht mein Programm ja schon.


    Das wäre schon irgendwie geil. Man könnte das echt benutzen!

    Sehe ich auch so!

  • Was heißt "freie Bytes im Directory"? Eine freie Anzahl Bytes hinter einem zu vergebendem Disk-Namen mit x Stellen?

    s. Handbuch bzw. http://www.softwolves.pp.se/id…/vc1541_de/#datenstruktur - Dort Tabelle 7.
    Für jedes File gibt es dort den Eintrag mit fester Anzahl an Bytes. Manche werden eben standardmäßig nicht genutzt.


    Directory wäre das, was Du normal unter load"$",8: list erhältst.
    Hier ging es eher um die einzelnen Dateien und deren Erstellung. Die Diskette kannst Du ja entsprechend des "Erstellungsdatums" benennen, wenn Dir danach ist.
    Die nicht verwendeten Bytes kann man eben per Direktzugriffsbefehlen beschreiben... womit bleibt ja Dir überlassen ;)#


    Die .d64 ist eigentlich eine "Diskette", d.h. darauf befinden sich ja dann die entsprechenden Informationen wie Diskettennamen, enthaltene Dateien usw.


    ... aber was Du genau vor hast, habe ich noch nicht verstanden...

  • Warst schneller Hexworx....

    Pro DATEI ! Ob man irgendwo noch ein Datum, wann die Diskette erstmals erstellt wurde, noch irgendwo unterbringen kann, könnte man tatsächlich auch noch gucken.

    http://www.softwolves.pp.se/id…/vc1541_de/#datenstruktur Tabelle 5... Byte 177 bis 255 nicht genutzt... .also genug Platz für Erstellungsdatum usw.



    Sehe ich auch so!

    Na so hat unser gequatsche am Ende ja doch irgendwie ein Ergebnis. Hatte auch angefangen, allerdings nicht weitergemacht.
    Macht natürlich nur aus einem Programm heraus Sinn.

  • softwolves.pp.se/idoc/alternative/vc1541_de/#datenstruktur Tabelle 5... Byte 177 bis 255 nicht genutzt... .also genug Platz für Erstellungsdatum usw.

    Ich war auch schon gedanklich bei der Disk-ID, also den Bytes 162-166. Das könnte auch schon reichen.


    Zu den Bytes 177 bis 255 steht da aber noch:

    Quote

    177-255 0 Nicht benutzt, aufgefüllt mit Nullen


    Bem: Die Positionen 180 bis 191 können mit ASCII-Zeichen belegt sein.

    WANN können die belegt sein?


    Ansonsten reicht der Platz ja noch zusätzlich für Name, Adresse und Telefonnummer (wenn man mag ;) ). Guter Tipp.

    Na so hat unser gequatsche am Ende ja doch irgendwie ein Ergebnis. [...] Macht natürlich nur aus einem Programm heraus Sinn.

    Klar, z. B. Spielstände, Highscores etc..
    Ich könnte auch meine alte eigene Textverarbeitung noch damit erweitern (falls ich noch durchsteige :schande: - ist ja erst gut 25 Jahre her...).

  • WANN können die belegt sein?

    Puh... na wenn man das vorhat, müsste man sich mal genauer belesen. Oder erst bei Byte 192 anfangen... wenn denn nicht alles genullt sein muss...


    Klar, z. B. Spielstände, Highscores etc..

    Naja, wenn man aber nicht jedes Byte auf der Disk sparen muss, leuchtet mir nicht ein, wieso man nicht direkt in die Spielstandsdatei o.ä. die entsprechenden Daten und Datums (haha) schreiben sollte.


    Ich könnte auch meine alte eigene Textverarbeitung noch damit erweitern (falls ich noch durchsteige - ist ja erst gut 25 Jahre her...).

    Da macht das in meinen Augen tatsächlich sinn. Da die Texte ja in der Regel auch mit anderen Programmen gelesen werden könnten, wäre ein Timestamp in der Datei eher verwirrend. Würde dann aber auch bei Bearbeitung mit anderem Programm verloren gehen...
    Durchzusteigen ist sicher eine echte Herausforderung... ;)

  • wieso man nicht direkt in die Spielstandsdatei o.ä. die entsprechenden Daten und Datums (haha) schreiben sollte.


    ...um die Datei nicht laden zu müssen. Bei einer Datei: O.K., da ist es egal. Wenn ich aber mehrere Dateien von 'irgendwas' habe, ist es ja logisch einfacher, nur die 9 Bytes einzulesen.


    Ich hab' mich grad gefragt, wie 'Claus' das bei "Zeit der Stille" gemacht hat. Naja, ganz einfach...*:


    *EDIT: Soll natürlich nicht negativ gemeint sein. Ist ja im Grunde so ähnlich, wie ich es auch gedacht hatte, mit dem Datum im Filenamen.



    Mir fällt sonst (außer GEOS) auch nix weiter ein, wo mal solche Zeitstempel o. ä. angewandt wurden und man mal (ab-)gucken könnte.


    Ach ja: Es heißt "Datumme" :party2: .

    Da die Texte ja in der Regel auch mit anderen Programmen gelesen werden könnten


    Bei mir wahrscheinlich nicht. Wahr wohl schon irgendwie ASCII, aber mit irgendwelchen eigenen Steuerzeichen (soweit ich mich erinnere). Muss ich mal rauskramen.


    müsste man sich mal genauer belesen.


    Ich guck' mal die Tage.

  • Aktennotiz, weil alte Kladde voll*: "UnivTS64"... :hand:) .


    * wenn die mal jemand in die Finger bekommt, denkt der bei den wirren Aufzeichnungen wohl auch: Nur bekloppt :woot::freak ? Oder schlafender Attentäter 8\|:kill: ...? :weg:


    Neue A5-Kladde aber schon die Tage bei TeDi geholt: So ein weibisches Teil mit vielen pinken Streifen :bussi::sex: , aber das Inlay ist prima :thumbup: .


    Aktennotiz #2: Unbedingt Neues-Thema-Aufmach: "Wie verwalte ich meine blöden Ideen": Kladde oder "Evernote" (<- feine Sache btw.)?


    Nacht.

  • ...um die Datei nicht laden zu müssen.

    Reichen ja die ersten Bytes, wird also auch nicht länger dauern - bei Einzeldateien. Bei mehreren Dateien ist es natürlich von Vorteil im Sektor 18 zu bleiben...


    Ist ja im Grunde so ähnlich, wie ich es auch gedacht hatte, mit dem Datum im Filenamen.

    Naja... 6 Bytes allein für die Zeit - ohne ein Datum. Und zwei Bytes vermutlich für den Spielernamen... also 1 Byte HEX.
    Du wolltest aber sparsamer sein im Dateinamen, wenn mich nicht alles täuscht?
    8 Zeichen wäre ja auch ein komplettes Datum mit Zeit in Unix.


    Bei mir wahrscheinlich nicht. Wahr wohl schon irgendwie ASCII, aber mit irgendwelchen eigenen Steuerzeichen

    Naja, ob sich da dann ein Datum in der Datei nicht besser anbietet... was ist sonst, wenn Du die Datei von A nach B kopierst? Schwupp... ist das Datum weg.


    wenn die mal jemand in die Finger bekommt, denkt der bei den wirren Aufzeichnungen wohl auch: Nur bekloppt

    ...hättest Du doch was gesagt, dann wär ich auf ein paar Bier vorbei gekommen :drink::beer: ... haha, anders kann mich mir den letzte Eintrag von Dir jedenfalls nicht erklären. Grins.

  • Mir fällt sonst (außer GEOS) auch nix weiter ein, wo mal solche Zeitstempel o. ä. angewandt wurden und man mal (ab-)gucken könnte.

    Die CMD-Laufwerke verwenden GEOS-kompatible Zeitstempel, sd2iec kann ebenfalls damit umgehen.