Genaue Dateigröße ermitteln. Wie am besten / schnellsten ?

Es gibt 79 Antworten in diesem Thema, welches 10.643 mal aufgerufen wurde. Der letzte Beitrag (27. März 2021 um 23:08) ist von darkvision.

  • Ich bin gerade dabei den IFFL-Scanner vom NOSDOS zu testen. Mal schauen, was der kann und wie schnell der mit unterschiedlichen Speichermedien klar kommt.

    Und natürlich, was für Daten die Routine sammelt und wo diese angelegt werden.

  • Warum denn das?

    Ok, hab den Hinweis von MacBacon überlesen.

    1 b=0:z$=chr$(0):f$="test"
    3 open 15,8,15:open8,8,8,f$:printBitte melde dich an, um diesen Link zu sehen.,"b-p 8 0":getBitte melde dich an, um diesen Link zu sehen.,t$:close8:close15
    4 open 15,8,15:open8,8,8,f$:printBitte melde dich an, um diesen Link zu sehen.,"b-p 8 1":getBitte melde dich an, um diesen Link zu sehen.,s$:close8:close15
    5 t=asc(t$+z$):s=asc(s$+z$):b=254
    10 if t=0 then b=s-1:goto 70

    Es funktioniert tatsächlich auch dem von ihm gemachten Vorschlag

    3 open 15,8,15:open8,8,8,f$:print#15,"b-p 8 1":get#8,s$

    4 print#15,"b-p 8 0":get#8,t$:close8:close15

    Was dann die Dauer der Verzeichnissuche auf die hälfte reduziert.

    Bei allen Medien, die eine 1541 oder sonstiges Laufwerk emulieren ohne die Buffer-Befehle vollständig abzubilden, neigen hier natürlich zu scheitern.
    Da scheint es keine schöne Lösung zu geben.

    Eventuell kann man überlegen, sich einen Index mit Dateilängen anzulegen, der entweder "on-demand" gefüllt wird oder alle Dateien einer Disk durchgeht, um einen vollständigen Index zu erstellen (auch wenn es länger dauert).

    Eventuell kann man das auch offline machen, indem auf einem Cross-System das Image durchforstet und eine Index-Datei anlegt/aktualisiert (oder etwa die Länge in einem Directory-Entry in ungenutzen Bytes unterbringt.

  • Eine Frage zwischendurch:

    Was gibt denn ein 1541 Ultimate aus nach @ui wenn SoftIEC aktiv ist ?

    Beim Ultimate64 ist das z.B. 73, u64iec ulitmate dos....

    Vorstellung Raveolution BBS -> Bitte melde dich an, um diesen Link zu sehen.
    Raveolution BBS -> raveolution.hopto.org:64128
    Raveolution Gopher Hole -> gopher://raveolution.hopto.org:70

  • Eine schnelle unkomplizierte Lösung hat man nur, wenn man sie programmiert.

    Ich hab man eine Lösung gepostet, die die End-Adresse der Datei gleich mit der Datei abspeichert.

    Der Normale Aufbau einer Basic-Datei ist ja:

    Startadresse(2B),Link-Adresse(2B),Zeilennummer(2B), Basic-Programm...

    Der Trick ist, daß man die Link-Adresse vor dem Abspeichen mit der Datei-End-Adresse ersetzt.

    Dann kann man mit :GETBitte melde dich an, um diesen Link zu sehen.,a$,b$,c$,d$: die Start-Adresse und End-Adresse aus der geöfneten Datei lesen.

    Der Trick ist schnell und einfach und vor allem für selbstprogrammierte Basic-Programme und Dateien geeignet..


    Schönen Gruß.

  • Ich habe gestern und heute soein Tool komplett neu gecodet, um zu sehen wie schwierig es wird. Einfach war es wirklich nicht. Aber nun funktioniert die Grundversion schon hervorragend.

    Als ultimativen Test, habe ich die D81-Version von "Pool of Radiance" mit 554 Dateien genutzt. Von alle Dateien auf der Disk, wurde eine fehlerfreie Tabelle der Bytegröße in Hexadezimal angelegt.

    Das Bild unten zeigt die Bildschirmausgabe der Daten während des erfassens der Größe und die Intern abgelegten Daten ab $c800 im C64 RAM.:)

  • Oh cool. Und mit welchen Laufwerkstypen funktioniert das ?

    Ich hatte gestern Abend wenig Glück, die Byteabfrage beim SD2IEC über das Directory zu ermitteln. In der SD2IEC Doku (von Unseen verlinkt) genannten Floppycommandos DI / DR / DW hatte ich gestern nicht ohne Floppy Errormeldung oder Absturz vom SD2IEC hinbekommen. Ggf. gehe ich da gleich nochmal ran, denn die Files Byte für Byte lesen mit SD2IEC ist arg langsam.

    Vorstellung Raveolution BBS -> Bitte melde dich an, um diesen Link zu sehen.
    Raveolution BBS -> raveolution.hopto.org:64128
    Raveolution Gopher Hole -> gopher://raveolution.hopto.org:70

  • Im Moment nur mit der 1581. Ich muss eine Offsettabelle erstelle, dann funktioniert es auch mit der 1541,1571,1581,FD-2000, CMD-HD, und RamLink.

    die Tabelle unten muss ich noch einfügen und den Code für die manuelle oder automatische Auswahl des Laufwerks erstellen.:)

    1541 - 12,01

    1571 - 12,01

    1581 - 28,03

    FD-2000 - 01,22

    CMD-HD - 01,22

    RAMLink - 01,22

  • In der SD2IEC Doku (von Unseen verlinkt) genannten Floppycommandos DI / DR / DW hatte ich gestern nicht ohne Floppy Errormeldung oder Absturz vom SD2IEC hinbekommen

    Was willst du damit?! Die Kommandos lesen/schreiben die (512 Byte grossen) Sektoren der SD-Karte direkt und machen im Kontext von Dateigrössenermittlung überhaupt keinen Sinn.

    die Tabelle unten muss ich noch einfügen und den Code für die manuelle oder automatische Auswahl des Laufwerks erstellen

    Ah, dein Code funktioniert also nicht mit 1581-Subpartitionen oder CMD-Unterverzeichnissen.

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Natürlich, wird der Filetyp #$86 analysiert und die Dateien dann erfasst. Nur die original 1581-Partitionen unterstützt das Tool nicht. Wozu auch? Die werden so selten genutzt, das lohnt sich nicht.

  • Unseen :

    Dann hab ich Dich und die Doku irgendwie missverstanden. Kannst Du mich erleuchten und ggf. 2 kleine Beispiel BASIC Code Zeilen schreiben, um zu zeigen wie es richtig geht ?

    Vorstellung Raveolution BBS -> Bitte melde dich an, um diesen Link zu sehen.
    Raveolution BBS -> raveolution.hopto.org:64128
    Raveolution Gopher Hole -> gopher://raveolution.hopto.org:70

  • die Tabelle unten muss ich noch einfügen und den Code für die manuelle oder automatische Auswahl des Laufwerks erstellen.

    Wenn man "$" mit Sekundäradresse >1 öffnet und dann die oben erwähnte "B-P"-Methode zum Lesen des ersten Linkpointers benutzt, funktioniert das auf all den aufgeführten Geräten sogar ohne die besagte Tabelle.

    Zusätzlich

    - bekommt man bei CMD-Geräten nicht das Rootverzeichnis, sondern das derzeit aktive.

    - würde die Methode automatisch auch in 1581-Subpartitionen, auf einer 1561 oder anderen (hypothetischen) CBM-DOS-Laufwerken funktionieren.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Danke, das werde ich gleich mal testen. Übrigens, mein Tool ist nicht in Basic gecodet.

    Als Anhang meine noch unfertige Version. Das Scannen eines d81-Images funktioniert. Wenn das Scannen beendet ist, färbt sich der Rahme grau. Die Tabelle der Bytelängen befindet sich ab $c800 im RAM.

    Sollte ein anderes Laufwerk genutzt werden, müssen z.Z noch ab Adresse "$c22b 28 03" die zwei Bytes angepasst werden. Ich werde am Tool noch einiges hinzufügen und auch einiges ändern bzw entfernen.

    Achja, laden mit ,8,1 und mit sys49152 starten. Das scannen erfolgt sofort.:)

  • Klar werde ich die Buffer-Pointer Methode testen. Schneller ist immer besser.:)

    Ich bin immer noch dabei, diverse IFFL-Scanner zu untersuchen, um eine dieser Routinen anzpassen und als Byte Zähler nutzen zu können.

    Achja, mein Scanner erstellt, wenn er mal fertig wird, die Bytegröße immer in 24Bit Breite.

  • Das hindert ja nicht, es mittels der sehr pfiffigen Methode mittels Buffer-Pointer von Mac Bacon zu nutzen

    Danke für die Blumen, aber die Methode stammt nicht von mir. Ich glaub ich hab sie vor Jahren mal von skern gelernt. :D

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Natürlich, wird der Filetyp #$86 analysiert und die Dateien dann erfasst. Nur die original 1581-Partitionen unterstützt das Tool nicht. Wozu auch? Die werden so selten genutzt, das lohnt sich nicht.

    :winke:

    Hier sind zwei Beispiel-*.d81-Images, wo mir die CBM-Partitionen der 1581 geholfen haben, das Hauptverzeichnis einigermaßen aufgeräumt zu halten. Für den VC-20 mit +24K Speichererweiterung.

    VG,

    Michael

  • Danke für die Blumen, aber die Methode stammt nicht von mir. Ich glaub ich hab sie vor Jahren mal von skern gelernt. :D

    Ist ja nicht so, dass das so eine unerforschte Technik wäre. Das beim Öffnen einer Datei das DOS schon den ersten Block holt und im Puffer liegen hat, ist ja als ein nicht allzu unerwartetes Verhalten zu werten. Das würde ich ähnlich der Erfindung des Rades einordnen. So grandios sie auch ist, irgendwer wäre auf jeden Fall darüber gestolpert. Insofern hätte ich "Methode von" als "erwähnt von" verstanden und nicht "Erfinder von" gesehen. Wer weiß schon, woher "skern" das womöglich hat ... ;)

  • Irgendwie finde ich beim Directory vom SD2IEC nicht das Byte, wo die MOD 254 Info stehen soll.

    Als Beispiel habe ich ein File, 10 Blocks groß, mit insgesamt $0914 (2324) Bytes (lädt von $0801 bis $1115).

    Das File ist nicht in einem .Dxx Image sonders direkt auf der SD Karte.

    Hier die Hardcopy wo das File noch in einem D64 Image ist:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Das Directory der SD Karte habe ich mal mit LOAD"$",8 geladen und dann als Datei mit SAVE"DIRECTOY",8 auf Disk gespeichert.

    Diese Dir Liste sieht dann im DirMaster so aus:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Bei $08a1 beginnt der DIR Eintrag von o.g. File. Als Rest von MOD 254 müsste ich 38 Bytes haben also hex. 26.

    Die sehe ich aber irgendwie leider nicht.

    Hilfe ?!

    Vorstellung Raveolution BBS -> Bitte melde dich an, um diesen Link zu sehen.
    Raveolution BBS -> raveolution.hopto.org:64128
    Raveolution Gopher Hole -> gopher://raveolution.hopto.org:70

  • Am schnellsten dürfte es mit einem kleinen Programm in der Floppy gehen: Directory-Eintag auslesen, dann den gesamten Track, auf der sich der erste Block befindet, in einer Umdrehung einlesen (nur jeweils die ersten beiden Byte der Daten, der Rest ist uninteressant).

    Wenn es einen Track-Wechsel gibt den neuen Track komplett ebenso einlesen.

    Normalerweise schreibt die Floppy keine Daten mehr auf einen Track, der schon beschrieben wurde (weil er erst gewechselt wird wenn er voll ist). Daher müsste es gehen, immer nur die Link-Daten des aktuellen Tracks einzulesen. "Bösartig konstruierte" Diskettten könnten allerdings wild zwischen den Tracks hin- und herspringen. Dann könnte man noch einen Puffer "schon eingelesener" Tracks anlegen.

    Sollte mit knapp 5 Tracks pro Minute machbar sein.

  • Irgendwie finde ich beim Directory vom SD2IEC nicht das Byte, wo die MOD 254 Info stehen soll.

    Ich glaub ich hab das jetzt verstanden... ich versuche es mal zu erklären.

    Du mußt das Verzeichnis mit open2,dev,0,"$" öffnen und dann die Daten einlesen.

    Als erstes folgen zwei Bytes für die Ladeadresse.

    Danach folgt die erste Zeile mit dem Disknamen... LinkBytes, Zeilennummer und Rest der Zeile bis $00-Byte überlesen.

    Danach folgen die ersten beiden Link-Bytes... das erste ist das gesuchte Byte für den nachfolgenden Dateieintrag.

    Ich hab das mit einem D81-File getestet. Das hat 819200 Bytes. Das sind 3226 Blocks.

    819200 / 254 gibt 3225 ganze Blocks. 819200 - 3225*254 ergibt 50. Dazu muss man 2 addieren. Ergibt 52.

    In meinem Verzeichnis war das Linkbyte $34 = 52... scheint zu passen.

    Nach den Link-Bytes folgt die Zeilennummer = Dateigröße in Blocks. Bei mir stehen hier die 3226 Blocks.

    Jetzt muss man nur noch die Blockzahl korrigieren (-1), x254 + den Rest im letzten Sektor von oben -2 und man hat die Dateigröße.

    Das Directory der SD Karte habe ich mal mit LOAD"$",8 geladen und dann als Datei mit SAVE"DIRECTOY",8 auf Disk gespeichert.

    Das ist das Problem... denn beim laden einer BASIC-Datei (oder wie hier das Verzeichnis) passt der BASIC-Interpreter die Linkbytes für das gesamte Programm neu an, d.h. die MOD-Info wird durch die für BASIC-Programme notwendigen Linkbytes auf die nächste BASIC-Zeile im Speicher ersetzt. Damit ist dann die MOD-Info weg.