Hallo Besucher, der Thread wurde 3k mal aufgerufen und enthält 20 Antworten

letzter Beitrag von Zirias am

File-Copy in Basic

    Hallo,


    Ich möchte ein File-Copy in Basic programmieren.
    Nur um es mal gemacht zu habe.


    Ich möchte Dateien von einer Diskette auf eine zweite copieren, aber mit nur einem Laufwerk.
    Meine Idee ist Quelle und Ziel öffnen und über einen Puffer im c64 übertragen.


    Meine Fragen sind nun giebt es Probleme wenn die Disketten gewechselt werden., wegen der auf verschiedenen Datenträgern geöffneten Dateien. Und ist es möglich den Speicher der Floppy zu nutzen, weil ich mir das schneller vorstelle.


    Im Netz finde ich leider nichts zu dem Thema.
    Und ja, ich weis das es in Basic nicht wirklich schnell sein kann
    aber ich möchte es halt versuchen sowas mal in Basic zu lösen.


    Danke euch im Voraus
    Zyrian

    Zitat von Zyrian

    giebt es Probleme wenn die Disketten gewechselt werden., wegen der auf verschiedenen Datenträgern geöffneten Dateien.

    Ja. Wenn Du die Disk aus dem Laufwerk nimmst, während eine Datei zum Schreiben geöffnet ist, erzeugst Du damit eine "nicht-geschlossene Datei" (engl. "splat file", weil das Sternchen neben dem Dateityp wie ein zermatschtes Insekt aussieht), die man nur mit einem Validate wegbekommt.

    Zitat von Zyrian

    Und ist es möglich den Speicher der Floppy zu nutzen, weil ich mir das schneller vorstelle.


    Das ginge wohl schon, aber die Floppy hat IIRC nur genug freies Ram um ca. 5 Blöcke zwischenzuspeichern. Bei größeren Files wär dann der Zeitvorteil ggü. dem seriellen Transfer zum/vom C64 durch die vielen Diskwechsel wohl wieder weg.

    Zitat von Zyrian

    Und ist es möglich den Speicher der Floppy zu nutzen, weil ich mir das schneller vorstelle.


    1. Nicht in BASIC -- Das Programm muss dazu auf der Floppy laufen
    2. Bei 2K RAM (in denen auch noch das Programm selbst unterkommen muss) wird der Geschwindigkeitsvorteil ab einer nennenswerten Filegröße von der Diskettenwechselei aufgefressen :)


    [edit]: Da war wohl einer mit prinzipiell dem gleichen schneller...

    wie mac schon saagt. so gehts leider nicht mit einem laufwerk.
    in basic wirds sowieso arg langsam - aber egal.
    prinzipiell musst du:
    die quelldatei mit get# auslesen und die ascii-werte in den speicher poken
    die quelldatei schliessen , die zieldatei oeffnen
    und die daten im speicher per peek auslesen und per print# ,chr$ in die zieldatei schreiben
    zieldatei schliessen


    wie gesagt dauert das sehr lang


    das basicprogramm sollte auch nicht zu lange sein, damit du genug platz fuer die quelldatei hast (basicspeicherende heruntersetzen!
    bevor der speicher fuer die quelldatei von strings aus dem basicprogramm ueberschrieben wird).
    ansonsten kann man auch die peek funktion modifizieren (hab ich hier in der basicecke irgendwo mal eine routine abgelegt) dann kann man auch noch
    "bequem" das ram unter dem rom nutzen. stressfrei fuer dieses unternehmen aber auch nur bis 53247 ($d000)
    hoffe konnte etwas helfen


    Danke euch für die Tipps. Leider bestätigen sie meine Befürchtungen.
    Paradroid: So hatte ich mir das Programm auch vorgestellt, aber ich hatte gehofft, dass jemand weis wie das mit dem mehrmaligen Disketten wechsel geht, weil eine Datei ja auch möglicher weise zu groß für einen einfachen Diskettenwechsel sein kann.
    Aber einen Weg muss es geben, die meisten Copy-Tools machen das ja so.

    Zitat von Zyrian

    Aber einen Weg muss es geben, die meisten Copy-Tools machen das ja so.


    Die sind wohl kaum in BASIC geschrieben.


    Luxusvariante: Eigener Drivecode, der auf Sektorebene liest/schreibt und sich eben Positionen für die beiden Files merkt.


    In BASIC könnte man zwar bis zur zuletzt erreichten Position alles einfach nochmal lesen und direkt ignorieren, aber beim Schreiben wird es wirklich schwierig (bzw, unmöglich, gibt AFAIK keine "append" Möglichkeit).

    Zitat von Zirias

    unmöglich, gibt AFAIK keine "append" Möglichkeit


    doch das geht.


    Code
    1. open 1,8,2,"filename,a,w"


    edit:Nachtrag zu meinem post vorher: mit der von mir beschriebenen moeglichkeit kannst du "bequem" 162 blocks lange dateien kopieren - vorausgesetzt
    dein programm inkl. variablen wird nicht laenger als 10 kbyte (ca.39 blocks)


    edit2:war nicht auf der test/demo diskette so ein basickopierprogramm drauf?

    Auf der Demodiskette zur 1541 gibt es ein Programm welches sich "Copy/All" nennt. Das ist in Basic geschrieben und verwendet "B-R" und "B-W".
    Wenn ich mich nicht ganz arg irre sollte ein blockweiser Kopiervorgang funktionieren, da hier nicht mit Dateien an sich gearbeitet wird.



    Wurde schon erwähnt: Ist halt sehr laaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaangsam.

    Warum soll das nicht gehen. Einfach KERNEL-ROM studieren und die nötigen Calls/Combos in BASIC per POKE/SYS aufrufen :)
    http://codebase64.org/doku.php?id=base:dos_examples
    http://unusedino.de/ec64/technical/aay/c64/krnromma.htm


    z.B. so:
    http://www.c64-wiki.de/index.p…NAL#Nutzung_von_BASIC_aus

    Zitat von Zirias

    In BASIC könnte man zwar bis zur zuletzt erreichten Position alles einfach nochmal lesen und direkt ignorieren, aber beim Schreiben wird es wirklich schwierig (bzw, unmöglich, gibt AFAIK keine "append" Möglichkeit).


    Zitat von Paradroid

    doch das geht.

    Code
    1. open 1,8,2,"filename,a,w"

    APPEND bringt allerdings, wie so ziemlich jede CBM-DOS-Funktion, einen Haufen Bugs/Seltsamheiten mit:

    • Man spart sich zwar das Überlesen der bisherigen Daten, aber das Laufwerk tut das intern trotzdem - aufgrund des Dateisystems mit den Linkpointern geht das nicht anders (schnellen Zugriff auf beliebige Dateioffsets gibt es nur bei REL-Dateien). Jedes OPEN mit ",a" braucht also Zeit, die von der aktuellen Dateilänge abhängt.
    • APPEND kann wirklich nur bereits vorhandene Dateien erweitern, aber keine neuen anlegen. Man darf beim OPEN der Schreibdatei also nicht grundsätzlich ",a" anhängen, sondern darf das erst ab dem zweiten Durchgang machen.
    • APPEND hat den Bug, dass die Blockzahl der Datei immer hochgezählt wird, selbst wenn die neuen Daten noch in den bisher letzten Block passen. Unnötig belegte Blocks kann man zwar per VALIDATE freigeben lassen. aber die Blockzahl des Dateieintrages wird dabei nicht repariert...


    Kurz gesagt: Dateien in mehr als einem Durchgang zu kopieren ist von Basic aus kaum sinnvoll machbar. Aber lass Dich davon nicht abhalten. ;)

    Wenn Dir aufgrund der erreichbaren Lese- und Schreibgeschwindigkeit der Gedanke kommt, es doch besser sein zu lassen, schau mal hier (Post 25). Diese beiden Unterroutinen benötigen jeweils nur 32 Byte im Speicher und geben Dir die Möglichkeit, eine beliebige Anzahl Bytes von einem offenen Kanal in den Speicher oder vom Speicher in einen offenen Kanal zu kopieren.

    Zitat von Ace von Heisenberg

    Alternativ eine Speichererweiterung hernehmen (zB. REU oder Neoram) und den ganzen Käse in einem Rutsch dort reinschreiben und
    dann zurück.


    Wäre das nicht schon fast mogeln?
    Gerade die einschrenkungen machen es doch reizvoll.
    Ich müsste das ja gar nicht selbst coden, sondern Turbo-Copy nehmen,
    aber ich möchte es halt auf nem standardmäßigen Cevi mit meinen begrenzten Können schaffen.
    Das ist vielleicht meine masochistische Ader. ;)?(

    Zitat von Zyrian

    Wäre das nicht schon fast mogeln?
    Gerade die einschrenkungen machen es doch reizvoll.
    Ich müsste das ja gar nicht selbst coden, sondern Turbo-Copy nehmen,
    aber ich möchte es halt auf nem standardmäßigen Cevi mit meinen begrenzten Können schaffen.
    Das ist vielleicht meine masochistische Ader. ;) ?(

    Nö. Ich würde es Vereinfachung nennen. Wenn es Dir aber lediglich darum geht, daraus zu lernen wie es ohne zusätzlichen
    Speicher geht, ignorier einfach mein Posting mit der Ramerweiterung :)

    Zitat von Zyrian

    Wäre das nicht schon fast mogeln?
    Gerade die einschrenkungen machen es doch reizvoll.
    Ich müsste das ja gar nicht selbst coden, sondern Turbo-Copy nehmen,
    aber ich möchte es halt auf nem standardmäßigen Cevi mit meinen begrenzten Können schaffen.
    Das ist vielleicht meine masochistische Ader. ;)?(


    Wegen einem Projekt ist das vielleicht noch übertrieben, aber wenn du noch ein paar Ideen hast, die mit Basic nur äußerst schlecht umsetzbar sind, wäre es vielleicht sogar eine Zeitersparnis, Assembler zu lernen ;) Wobei ich natürlich das Thema "Floppy-Code" bei den fortgeschrittenen Themen einordnen würde...

    Ich habe in den 80ern auch in ASM programmiert, aber erstens ist das extrem eingerostet und zweitens wollte ich es unbedingt in Basic realisieren.


    Zur Erklärung: Ich habe in 1983 mit einem Freund ein Disktool angefangen und nie fertig gestellt.
    Jetzt habe ich das auf einer alten Disk wieder gefunden.
    Damals konnte ich nur Basic und deshalb wollte ich das unter realen Umständen fertig stellen.
    So zu sagen eine Hommage an mein junges ich und somit an die Wurzeln meiner Computerei.