letzter Beitrag von steril am
-
-
Ich teste auf VICE gerade 1581-Unterverzeichnisse. Leider krieg ich immer nur Fehlermeldungen, obwohl die Test-"Partition" korrekt angelegt wurde. Sie wird nicht formatiert (stattdessen schon mal die ganze Disk, obwohl ich laut Floppy-Fehlerkanal *im* Verzeichnis war), wenn ich das Verzeichnis verlasse, gibt's 27 READ Errors.
Hat da einer Vorschläge?
Arndt
-
Muss der Tauschbutton denn doppelt? Da er ja eine fest definierte Aktion macht, würde doch ein einzelner reichen: Jeder klick wechselt Source und Dest.
Würde eventuell noch ein bissel Platz schaffen. -
BladeRunner:
Der ist nicht doppelt. Der untere Button ist zum ein- und ausblenden der Infos vom Destination-Drive (zwei Pfeile nach oben bzw. zwei nach unten) und der obere Button ist zum Tausch von Source und Destination (ein Peil nach oben und einer nach unten). Ich hoffe, ich habe es richtig verstanden und auch richtig wiedergegeben.Die Frage ist, ob man den Button zum Ein- und Ausblenden braucht? Als noch die Überlegung im Raum stand, dass man eine Zwei-Fenster-Ansicht macht, wäre der Button wichtig gewesen. Jetzt bleibt es ja bei der Ein-Fenster-Ansicht und es geht nur um die paar Infos vom Dest.-Drive und nicht mehr um eine weitere Dateiliste. Das könnte man z.B. auch so lösen, dass man den kpl. Platz für das Source-Drive nimmt und mit der Auswahl eines Dest.-Drives die Zusatzinfos eingeblendet werden. Dann sollte man für das Dest.-Drive in der LW-ID-Auswahl aber auch "keins" oder so zum Abwählen anbieten. Hab ich es verständlich genug erklärt?
Vielleicht wird es so verständlicher:
Beim Start des "Explorers" sieht es in etwa so aus:
https://www.forum64.de/index.p…nt/130554-explorer06-gif/
(Mit dem Tausch- anstelle des Infos-Einblenden-Button und als Dest.-Drive ID "keins" (oder etwas in der Art) anstelle von "9")Jetzt kann man auf die LW-Auswahl für das Dest.-Drive klicken und wenn man eine ID auswählt, dann werden die Infos so eingeblendet:
https://www.forum64.de/index.p…nt/131050-explorer10-gif/
(Ohne den Infos-Ausblenden-Button)Wenn man für das Dest.-Drive in der LW-Auswahl jetzt wieder "keins" auswählt, sollte die Anzeige der Infos wieder verschwinden:
https://www.forum64.de/index.p…nt/130554-explorer06-gif/
(Mit dem Tausch- anstelle des Infos-Einblenden-Button und als Dest.-Drive ID "keins" (oder etwas in der Art) anstelle von "9")Wenn man ohne gewähltes Dest.-Drive auf den Wechsel-Button klickt, sollten die Infos des bisherigen Source-Drives unten als Dest.-Drive eingeblendet werden. Da es bisher kein Dest.-Drive gab, würde ich die Auswahl für das Source-Drive so lassen wie sie ist. In diesem Augenblick wären also Source- und Dest.-Drive (und natürlich auch die aktuelle Partition bzw. das Verzeichnis) das gleiche.
-
Ah, ich sehe! Ich hatte das auf den Bildern bislang übersehen.
-
Schön beschrieben, Cyberdyne!
Hier mal in Aktion:
Kopieraktion von Drive 9 (1571) auf Drive 10 (1581) mit einer Riesendatei (382 Blöcke), kurz vor Schluss der Aktion. Die Größe einer Datei ist goDos egal, ich hab jetzt mal (Anzeige-) Platz gelassen für 9999 Blöcke, hehe...
Also, ich finde die Anzeige des Destination-Drives unten ganz wichtig, ebenso, dass ich das bei Bedarf wegblenden kann. Kann ruhig so bleiben.
Was allerdings noch gar nicht so zur Rede gekommen ist: Die goDos-Kopieraktionen verlaufen auf einem Stock-Equipment schnarch-langsam, wer da nicht irgendwas speeder-mäßiges eingebaut hat, wird viel Geduld mitbringen müssen...
Hat einer eine Idee mit meiner 1581-Frage? Bin ich vielleicht (schon *wieder* mal!) auf einen VICE-Bug gestoßen? Unter VICE jedenfalls funktioniert der Zugriff auf 1581-Partitionen nicht, auch nicht von reinem BASIC aus (im mod..ChangeDir ist ein Bug, das funktioniert daher unter GoDot/goDos auch nicht - Bugfix noch nicht veröffentlicht). Die Partition wird korrekt angelegt, man kann auch korrekt in sie hineinwechseln (laut Floppy-Meldung), aber das Formatieren funktioniert schon nicht mehr, ab da ist der Drive nicht mehr erreichbar, selbst dann nicht, wenn ich wieder zurück ins Root-Verzeichnis wechsele. Ein Verzeichnis-Directory kommt nie zustande. Wenn das aber auf einer Real-81 geht, ist es ein VICE-Bug. Probiert das mal einer aus?
Arndt
-
Kopieraktion von Drive 9 (1571) auf Drive 10 (1581) mit einer Riesendatei (382 Blöcke), kurz vor Schluss der Aktion. Die Größe einer Datei ist goDos egal, ich hab jetzt mal (Anzeige-) Platz gelassen für 9999 Blöcke, hehe...
Wieviel Blocks hat denn so eine d64 Datei ?
Profitiert eigentlich die Kopierroutine durch eine Beschleunigungskarte wie die SuperCPU oder den Turbo vom Chameleon ? Ich frage deshalb, weil ich Anfang 2000 mal d64 Images mit dem 64Net Copy unter Godot
von c64 zum PC und zurück, geschaufelt hatte und fest stellte, dass der Kopiervorgang durch hinzu schalten der 20 Mhz von der SuperCPU 64 den Kopiervorgang extrem beschleunigte. -
Profitiert eigentlich die Kopierroutine durch eine Beschleunigungskarte wie die SuperCPU oder den Turbo vom Chameleon ?
Das sollte sie (wobei ich zu Chameleon keine Angaben machen kann). Alle Speeder, die C=kompatibel bleiben, sollten problemlos funktionieren.
Das gefixte mod..ChangeDir ist jetzt im GoDot-Download-ZIP zu finden. Die nächste Probierversion des Explorers müsste auch bald soweit sein.
Arndt
-
Wieviel Blocks hat denn so eine d64 Datei ?
Roh betrachtet, 683 Blöcke.
-
Schön beschrieben, Cyberdyne!
Hier mal in Aktion:
Kopieraktion von Drive 9 (1571) auf Drive 10 (1581) mit einer Riesendatei (382 Blöcke), kurz vor Schluss der Aktion. Die Größe einer Datei ist goDos egal, ich hab jetzt mal (Anzeige-) Platz gelassen für 9999 Blöcke, hehe...
Das Hauptfile der IDE64 Demo 'Weekend' hat 14383 Blöcke. Bei Rush sinds derer 55952
Wird das abgefangen?
Gruß
Chris -
Am Wochenende werde ich mit testen. Dann hab ich meine CMD HD auch am c64 und kann das testen.
-
Das Hauptfile der IDE64 Demo 'Weekend' hat 14383 Blöcke. Bei Rush sinds derer 55952
Ja, nur die Anzeige ist leider auf 4-stellig begrenzt. Da sie rechtsbündig arbeitet, ist dann die Zehntausenderstelle nicht zu sehen. Hehe, das dauert aber ein paar Tage mit dem Kopieren...
Arndt
-
Ja, hat ein bisschen gedauert
Hab lange nur beobachtet. Das Konzept gefällt mir gut. Wäre Klasse wenn du das bis zu einem finalen Stand bringen würdest. Die Tage werden ja jetzt wieder länger....
Gruß
Chris -
Ja, hat ein bisschen gedauert
Hab lange nur beobachtet. Das Konzept gefällt mir gut. Wäre Klasse wenn du das bis zu einem finalen Stand bringen würdest. Die Tage werden ja jetzt wieder länger....
Gruß
ChrisLass mal den Arndt das in Ruhe machen. Der hat noch nie halbgares abgeliefert.
-
Klar, sollte ja auch kein Drängeln sein.
-
Lass mal den Arndt das in Ruhe machen. Der hat noch nie halbgares abgeliefert.
Hehe... danke!
Arndt
(der gerade nach einem Algorithmus sucht, die Dateilängen korrekt vor die Dateien zu pappen, das Ganze ist asynchron, weil ich für den Directory-*Inhalt* die GoDot-Systemroutinen verwende, die aber keine Längenangaben abrufen, und da GoDot das Directory blockweise liest muss es eben irgendwie mit der Einzelfile-Liste zusammengebracht werden - hab aber eben eine Erleuchtung gehabt...) -
Lebenszeichen:
Ich hab anderthalb Wochen hin und her probiert, aber ich krieg die Synchronisierung einfach nicht geschissen...
Vorwärts im Directory blättern läuft wunderbar, wenn ich aber an den Umkehrpunkt komme (Ende des Directory) und zurückblättern will, geht es zu 90% in die Hose. Irgendwann kriege ich die richtigen Parameter noch hin, aber damit ihr was zum Ausprobieren habt, geb ich aktuelle Version jetzt schon mal online: Klick für Download. Die Filelängen werden übrigens nur beim Quelldrive angezeigt (daran erkennt man dann auch, wenn man den Zieldrive geklickt hat). Klick auf die Drive-Nummern führt zur Drive-Auswahl. Klick in die Drive-Kopfzeilen holt das Directory wieder von vorn (gut, wenn die Synchronisation im Eimer ist...)
Tagging funktioniert noch nicht (immer nur ein File), "Run" und die meisten Sachen auf der rechten Seite ebenfalls noch nicht. 1581-Subdirs werden erkannt, CMD-Dirs ebenso, aber noch nicht unterstützt und auch nicht besonders gekennzeichnet (kopieren zwischen zwei Verzeichnissen auf einem Drive ist auch noch nicht gelöst, denn da müsste ein Verzeichnis auf einen Drive gemappt werden, denke ich mal).
Da kein Platz mehr ist, überlege ich schon, wie ich die fehlenden Funktionen anders eingebunden kriege. Mal sehen, Ideen habe ich schon (Platz ist ja da).
Soviel für heute.
Arndt -
Tolles Projekt.. Danke fürs Update!
-
Jetzt hab ich die Nase voll!
Nach drei Wochen Kodiererei von wegen eine lineare, ununterbrochene Liste (das mit LOAD geladene Directory) mit einer zwar auch linearen, aber unterbrochenen und anders gegliederten Liste (dem Directory als Block-Kette, in der es auch mal Löcher gibt, weil DEL-Files ja nicht gelöscht werden , sondern nur "deaktiviert") zu synchronisieren, gebe ich es erstmal dran.
Es funktioniert beim Vorwärtsblättern, wenn keine DEL-Löcher vorhanden sind. Es funktioniert auch beim Zurückblättern, wenn beide Panels an sind (beim langen Panel ist die Synchronisation nach dem zweiten Rück-Klick hin). Aber mehr auch nicht. Steinigt mich nicht, wenn ich erstmal was anderes mache. Ich verlier sonst die Lust.
Und sag mir nicht, "warum arbeitest du denn überhaupt mit zwei Listen?" Die Antwort ist, ich verwende das System-Directory, es ist eben sehr viel kürzer, grad mal "JSR GD_DIR" zu coden, als den Algorithmus für ein Directory *neu* zu implementieren. Ich hab eh nur noch 15 Bytes frei und muss weiterdenken.
Ich kümmere mich dann als nächstes mal um das Aufbohren der Screenlisten, damit auch andere anfangen können, Ideen für Module zu entwickeln. Das Explorer-Modul ist ja nur ein winziger Baustein. Die jetzige Version ist wieder zum Download (Link in Post 277). Code auf Github (s.u.)
So, jetzt lese ich erstmal ein Buch.
Arndt
-
Wir könnten ja für einen Forum64-Punching Bag zusammenlegen.