Posts by Larry

    So wie ich das gelesen habe, suchst du ein Tool, dass eine oder alle Dateien eines Datenträgers scannt und die Bytegröße der einzelnen Dateien, ohne Adressbytes ausgibt?

    Korrekt.


    Erst die Datei normal öffnen, dann mit dem "B-P"-Befehl den Lesezeiger auf Offset 0 setzen, ein Byte lesen, mit "B-P" den Zeiger auf Offset 1 stellen, wieder ein Byte lesen, Datei schließen. Jetzt hat man den ersten Linkpointer und kann die restlichen Blöcke per U1 lesen.

    Super. Das könnte wesentlich schneller gehen. Probiere ich aus.



    Besteht die Möglichkeit, einen IFFL-Scanner für soetwas zu nutzen. Letzendlich zählt eine Routine dieser Art auch nur Bytes.

    Ja möglich, funktioniert dann aber im BBS wegen Platzmangel nicht mehr. Der IFFL Scannercode müsste ja irgendwo permanent untergebracht werden.

    Der IFFL Scanner müsste dann aber mit allen Laufwerksarten funktionieren. Ggf. sowas wie bei N0SDOS.



    Haben gescratchte Files ein Byte weniger ? Stehe gerade etwas auf'n Schlauch.

    War ja klar... ich mal wieder. Alle Files die nicht mehr auf 18 / 01 stehen werden nicht gefunden. Warum ? Weil die 2 Bytes vom Track / Sektor Link der Directories ja auch mitgelesen bzw. überlesen werden müssen.

    Fettes double

    :platsch::platsch:

    Mit "sauberen" Directories funktioniert mein Code von gestern Nacht.

    Habe ich aber gescratchte Files, werden zum Teil die zu scannenden Files nicht mehr gefunden.

    Ich suche in Zeile 4 ja zeichenweise aufbauend nach dem Inhalt von f$, also mein Suchfile.

    Liegt mein Suchfile hinter einem oder mehrerem gescratchten Files, wird mind. das erste Zeichen vom Filenamen im Dir nicht mehr richtig ausgelesen und daher das Suchfile niemals gefunden. In Zeile 6 ist dann Ende.


    Haben gescratchte Files ein Byte weniger ? Stehe gerade etwas auf'n Schlauch.

    Ja was lange währt.....

    Funktioniert, ist aber ziemlich lahm. Mal sehen ob ich das ins Terminal einbaue.



    Wie ich im Posting davor geschrieben haben müsste es

    b=b+s-1:print"bytes:"b

    Das hatte ich glatt überlesen und ich wundere mich warum ich ein Byte zuviel im Ergebnis habe :platsch:

    Per Direktzugriff auf die entsprechenden Bytes im Directory.

    Ja und wie komme ich da ran ?

    Stell Dir eine CMD-HD vor mit 500+ Files in einer Partition, oder ein SD2IEC mit noch mehr Files (also nicht in einem .Dxx Image).

    Muss ich dann je Laufwerkstyp schauen, wo der Directory Track liegt und dann von dort alle Einträge durchgehen, Sektor für Sektor, bis meine gesuchte Datei gefunden ist ?

    Oder geht das irgendwie eleganter ?

    Den einfachen Teil habe ich scheinbar erledigt....

    Wie komme ich denn nun an die Information, von Start Track / Sektor ?

    Klar die Info liegt im Sektor in Track 18 wo auch der Fileeintrag ist.

    Aufbau ist dann Byte 0: Filetyp, Byte 1:Track, Byte 2: Sektor, Byte 3 - x: Filename


    Versuche ich das wie folgt auszulesen, kommt da irgendwas anderes raus:


    Code
    1. 1 b=0:z$=chr$(0)
    2. 2 open 8,8,0,"$test"
    3. 3 get#8,a$:get#8,t$:get#8,s$
    4. 4 close8
    5. 7 print"start track:";asc(t$+z$)
    6. 8 print"start sektor:";asc(s$+z$):stop
    7. run
    8. start track: 4
    9. start sektor: 1

    Erwartet hätte ich Track 19, Sektor 0 da wo das File auch tatsächlich ist.



    Hat das DOS die Track / Sektor Information an der Stelle schon längst gelesen ? Wenn ja, wie komme ich denn dann da ran ?

    So, bissel gebastelt heute Abend.

    Und ich bin positiv überrascht, daß das gar nicht so lange dauert wie befürchtet.


    Hier mein vorläufiges Ergebnis (Start Track und Sektor vorgegeben anstatt aus dem DIR ausgelesen):

    Code
    1. 5 t=17:s=0:b=0:z$=chr$(0)
    2. 10 open1,8,2,"#"
    3. 20 open2,8,15
    4. 30 print#2,"u1 2 0 "str$(t);str$(s)
    5. 40 get#1,a$,b$
    6. 45 t=asc(a$+z$):s=asc(b$+z$)
    7. 50 print t,s
    8. 60 if t<>0 then b=b+254:goto 30
    9. 65 b=b+s:print"bytes:"b
    10. 70 close 2:close 1

    OK, but why does the same code, with same Action Replay work just perfect in C64Debugger ? Just curious.

    Btw. this Version was from Sourceforge (Tarball) some month ago.

    No I'm just using these 3 lines of Code, nothing else.

    Version:

    3.5 (GTK3 3.22.30, GLib 2.56.4)


    Linux 4.15.0-139-generic

    #143-Ubuntu SMP Tue Mar 16 01:30:17 UTC 2021

    x86_64

    Man könnte auch versuchen, die Datei im freien RAM zu puffern

    Haha der ist gut :) Du kennst C*BASE nicht. Da ist nicht viel mit freiem RAM. Ich kämpfe hier immer wieder um jedes freie Byte.

    Y-Modem einzubauen hat mich deswegen knapp 2 Monate freie Zeit gekostet. (und weil ich vorher 0 Ahnung hatte wie das funktioniert und keinerlei Doku etc.).


    Gut also um mal die TODO Liste zu erweitern:


    - BAM auslesen ist quatsch stattdessen:

    - Directoryeintrag lesen ("$filename" ?) und dann schauen wo Start Track und Sektor liegen.

    - weiter wie gehabt.....


    Naja, hab ich noch was vor mir.


    PS: gerade gesehen. Die Scan Routine, die genau das wohl machen soll im Terminal Programm "X-Term" von I.Horvath (64'er Ausgabe 01/94) crasht die Floppy (in VICE, Floppy CPU Jam).

    Super....

    Also das bedeutet theoretisch:


    - Datei in der BAM suchen

    - Start Track + Sektor auslesen

    - o.g. lesen erste beiden Bytes (=nächter Track/Sektor in der Kette)

    - In der Hoffunung, dass überall die Sektorgrößen gleich sind, je gescannten Sektor 254 Bytes addieren.

    - wenn nächter Track/Sektor = $00 / $00 (oder ähnlich ?!), dann die Bytes des letzten Sektors bis zum Ende der Datei lesen und addieren


    Richtig soweit ?

    Produziert Novaterm denn wirklich beim Upload zu große Dateien

    Ja leider. Deswegen kommen immer mal wieder Fragen auf, warum das Easyflash Game soundso nicht läuft...

    Bei einfachen Dateien (Spielen) wo es egal ist, wenn ein paar Bytes mehr dran hängen, ist das auch kein großes Thema.

    Z-Modem hat das Filepadding Problem schon nicht mehr. Nur X- / Y-Modem

    Problem ist auch, es muss ja nicht zwingend eine 1541 angeschlossen sein. HD, SD2IEC, etc. pp. haben ja alle einen anderen BAM Aufbau.

    Tja, dann wird's bei mir wohl auch bei der Notlösung a la Striketerm bleiben müssen.

    Hallo zusammen,


    ich suche nach einer Methode die Größe einer Datei in Bytes von Diskette zu ermitteln.

    Das Ganze sollte möglichst schnell gehen, weil keiner ohne Floppyspeeder 5 min. warten will....


    Hintergrund zur Frage (dazu muss ich etwas ausholen):

    Ich bin dabei das Terminal Programm bei C*BASE zur bearbeiten. Ich habe Y-Modem batch als neues Transferprotokoll eingebaut.

    Y-Modem batch ist praktisch eine Erweiterung von X-Modem. Findet sich in Terminalprogrammen wie Novaterm, Striketerm, X-Term, Desterm etc. Das Protokoll überträgt, wie X-Modem auch, nur komplette "Transferblocks", d.h. ganze 128 Byte oder 1024 Byte (1K) Datenpakete.

    Das Ende einer Datei hört aber in den seltensten Fällen genau an dieser Grenze auf. Die restlichen Bytes füllt das Protokoll mit "Müll-Bytes" auf. Daher sind die empfangen Dateien auch meistens etwas größer als die ursprünglich gesendeten Dateien (Filepadding....), was beim Download von Easyflash CRTs zum Beispiel zu Problemen führt.

    Y-Modem batch überträgt, im Gegensatz zu X-Modem, neben dem Dateiname auch die Byte-genaue Größe der zu übertragenden Datei. Der Empfänger weis also wie viele Daten er zu erwarten hat und kann die "Müll-Bytes" einfach ignorieren.

    In Nova- / Striketerm kann man das einstellen unter "Chop X-/Y Modem Padding". Striketerm macht es sich beim ermitteln der Dateigröße allerdings einfach. Es rechnet die Anzahl Blocks aus dem Directory *254. Damit werden dann leider doch immer einige "Müll-Bytes" nicht abgeschnitten.


    Und genau da fängt nun meine Frage an, wie man das besser machen, also Byte-genau und schnell. (Zur Not auch in ML?!).


    Ich hoffe ihr habt ein paar gute Ideen :)

    Hallo zusammen,


    mir ist gerade etwas komisches aufgefallen.

    In VICE 3.5 habe ich als Cartridge ein Action Replay drin.

    Um die Tasten C= / Shift / CRTL abzufragen, bzw. die Funktion zu testen habe ich folgende Code Zeilen bei $C000:


    Code
    1. .> c000 ad 8d 02 lda $028d
    2. .> c003 8d 00 04 sta $0400
    3. .> c006 4c 00 c0 jmp $c000

    Wenn ich das mit SYS $C000 starte, und eine der drei Tasten drücke, oder auch in Kombination, dann ändert sich der Wert nicht, d.h. bleibt auf $00.

    Gleiches im C64Debugger auch mit dem AR funktioniert es einwandfrei, d.h. der Wert in $0400 ändert sich wie geplant.


    Ist das einem von euch schon aufgefallen ? Oder mache ich was falsch ?

    Naja, mit den Cracks verdient haben hierzulande hauptsächlich die Spreader,

    Das will ich mal stark bezweifeln. Spreader oder auch Megaswapper, die damals wöchentlich ihre oft mehrere Hundert Contacts weltweit mit aktuellen Releases beglückt haben,

    haben da wohl nicht selten drauf gezahlt, selbst mit Stamp Cheating und manchmal auch finanziellem Support der Kollegen aus der eigenen Gruppe.