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.

Zitat von Hexworx

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.

Zitat von Hexworx

Das war doch nur bei @-Replace, oder?

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

Zitat von Hexworx

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?

Zitat von Chagizzz

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.

Zitat von Mac Bacon

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

Auch wieder war...

Zitat von Chagizzz

Ü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

Zitat von Hexworx

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.

Zitat von Hexworx

Heute Abend dann der nächste Schritt..

Und, bist Du ihn gegangen?

Zitat von TheRyk

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:

Zitat von TheRyk

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

Zitat von 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!

Zitat von Bytebreaker

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....

Zitat von 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.

Zitat von Hexworx

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.

Zitat von Hexworx

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...

Zitat von Hexworx

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.

Zitat von Hexworx

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...

Zitat von Hexworx

...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...

Zitat von Hexworx

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.

Zitat von Hexworx

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.

Zitat von Hexworx

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 ... haha, anders kann mich mir den letzte Eintrag von Dir jedenfalls nicht erklären. Grins.

Zitat von Hexworx

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.