Forum64

Für weitere Versuche nimmt bitte die v0.3m , die ich eben hochgeladen habe...

@Jasmin: Wo steht "Transfering"... konnte es nicht finden

Ah und noch was, das mit der InI ist eventuell jetzt en bissel umständlich, aber ich denke der Aufwand es so hinzubiegen dass man die alte wiederverwenden kann steht nicht in Relation zum Nutzen... Wenn du die alte behalten willst, dann versuche PRGMover mit der alten zu starten, macht diese Probleme beim Start, so füge am Ende einfach einige Zeilen ein (Space+Enter) und schon funzelt sie auch in ner neuen Version... also sagen wir mal zu 90%

ich muss weg

Quoted from "HOL2001"

Mach dir blos keinen Stress.

Ups... schon zu spät ;-) 0.3n ist auf der Welt, neben ein paar Schönheitsfehlern wurde auch ein, bis dahin wohl noch nicht erkannter Fehler beseitigt. Das Kopieren mehrerer Dateien über Mulitiselektion hat vom Image zu Floppy nicht funktioniert... jetzt geht's wieder :-)

Quoted from "Jasmin"

Naja, ich würde es schon als Fehler werten, wenn ein Retry auftritt, evtl. wieder ne Config-Option dafür
.
.
.
Und immer erst nach 2 mal Schreiben als Fehler werten ist auch problematisch, da - ausser auf der ersten Spur - ein Retry meiner Meinung nach schon auf eine problematische(s) Disk/Laufwerk hinweist.

Also ein Retry bei Track 1 scheint wohl eine obligatorische Sache zu sein, auch meine 1571 tut dies kontinuierlich... OpenCBM wertet dies auch nicht als Fehler. Weder auf Kanal 1 noch 2 lässt cbmforng was von sich hören, selbst bei einem Sync Error bleibt es auf dem Kanal 2 stumm?? Wie auch immer. Die Abfrage ist nun in 0.3n wie folgt.
Prinzipiell wird PRGMover ab dem ersten Retry aktiv, ist dieser jedoch bei Track 1, so behält er dies noch für sich, kommt dann aber noch ein Retry hinzu (egal bei welchem Track auch immer) dann wertet PRGMover dies als Fehler.

Quoted from "Jasmin"

nach wie vor (bei 35 tracks) "--end-track=36" obwohl OpenCBM "--end-track=35" übermittelt bekommt. Am einfachsten wäre wohl hier nicht einen separaten Text zu verwenden (der wie man sieht fehleranfällig ist), sondern wirklich die original übermittelte command line in das Fenster einzufügen.

Da war tatsächlich noch ein Eintrag mit 36... der ist jetzt weg und ich hoffe es war der letzte. Von einer Ausgabe des original Strings, welche an D64Copy geht bin ich nicht so angetan, zum einen reicht der Platz nicht aus und zum anderen gäbe es dann Fragen bezüglich des Images... Denn alle Images heißen nach dem Laden temp.d64 und zwar konsequent, quer durch die Bank. Auch D81-Images und D71, X64... usw. Dies ist aus der Historie so entstanden und würde viel Zeit kosten dies wieder rückgängig zu machen. Von daher lass ich das jetzt mal so. Funzt ja jetzt wie's soll hoffentlich

Quoted from "Jasmin"

Erkennung von Fehlern bei Write Image funktioniert NICHT! Log kommt nicht hoch! Schreib-/Lesekopf rödelt hin und her, Test mit CMD-Window zeigt auch entsprechende "Write error"-Meldungen. Ohne CMD-Window mit Show Log kommt KEIN Log hoch!

Das ist leider auch so zu erwarten. OpenCBM bricht den Prozess leider nicht ab, sondern rödelt munter weiter. Solange aber OpenCBM am rödeln ist, kann PRGMover nicht aktiv werden, weil es immer auf das Ende von OpenCBM wartet. Abhilfe würde hier nur die Variante bringen, die zeitgleich die OpenCBM Meldungen erfasst, die wird es aber aus zeitlichen Gründen nicht geben. Ich denke dass es jedem früher oder später auffallen wird dass da was schief gelaufen sein muss. Mit anderen Worten, beendet OpenCBM die Aktion nicht sauber, so wird PRGMover da auch nicht eingreifen. Erst wenn OpenCBM sich beendet hat wird PRGMover fortfahren und dann auch Fehler erkennen. Für dieses spezielle Problem wird es keine Lösung geben.

Quoted from "Jasmin"

Ansonsten fehlt noch eine Abbruch-Option nach fehlerhaftem Format.

Wird Formatieren im Zuge eines Imagetransfers vorgeschaltet (Option), so wird bei einem Formatfehler eine Fehlermeldung ausgegeben und der Transfervorgang nicht gestartet. Welche Option fehlt da?

Quoted from "Jasmin"

temp.d64 schreibgeschützt erstellt wird...wenn ich während prgmover läuft, nachdem er die temp.d64 erstellt hat, den Schreibschutz der Datei aufhebe, ist jeweils alles normal!!!

Ok, das ist jetzt was neues... Also diese Problem hatte ich noch nie und kann es auch anhand der Beschreibung so nicht nachvollziehen? Hat das sonst noch jemand? PRGMover setzt zu keinem Zeitpunkt Datei-Attribute (bewußt), merkwürdig ???

zunächst mal zu Ryk:

Quoted from "TheRyk"

Klitzekleines Minus: Die Hervorhebung der BASIC-Schlüsselwörter funktioniert noch nicht ganz vollständig. Scheint besonders dann zu passieren, wenn man zwischen Befehl und Variable kein Space setzt (z.B. aus "pokex" wird nicht "pokex", Hervorhebung findet nicht statt, gilt auch für "forx"/"ifx"/"printc".

Du hast es schon erkannt. Wenn die Befehle zueinander oder zu Variablen nicht getrennt werden, dann kann der Syntaxhighlighter diesen Befehl auch nicht finden, ich sage es auch nur ungern, aber so funktionieren Syntaxhighlighter. printe ist eben nicht print und wenn ich dies dem Syntaxhighlighter beibringen möchte, so müsste er auch BASIC mit allen Ausnahmen und Regeln wie der CBM sie nutzt verstehen.Denn er müsste entscheiden ob "formel" nun eine Variable ist oder eben der Befehl FOR mit der Variable MEL... Das führt dann irgendwann dazu, dass du nach dem Drücken einer Taste 2 Sekunden warten musst bis das Zeichen dann im Editor erscheint... Ich kenne auch keinen Editor der dies Beherrscht... Dem CBM BASIC Interpreter ist es allerdings wurscht ob alles zusammengeklatscht ist oder nicht... drum funzt zum Schluss ja auch :-)
Mann kann den Syntaxhighlighter ja für eigene Programme nutzen und darauf achten, es einfach ignorieren oder man müsste ne Option in Einstellungen bringen "ich nix Syntaxhighlighting will" ;-)

So, nun Jasmin:

Quoted from "Jasmin"

Ich habe den gesamten fehlerhaften Write Image Vorgang bis zu Ende abgewartet...OpenCBM hat seine Aktion "sauber beendet", halt nur mit vielen Fehlermeldungen, diese wurden von PRGMover NICHT erkannt.

So en Fehler hätte ich auch mal gerne... also nur um zu Testen was PRGMover dann macht. Hast du die Diskette irgendwie mechanisch bearbeitet oder war das eine die ohnehin schon defekt war? Mit anderen Worten, kann ich das nachstellen? Wenn nicht, dann würdest du mir einen großen Gefallen tun, wenn du das ganze nochmal mit der Option "Show Log" durcheiern könntest und mir dann dem Log zukommen lässt, das wäre genial :-)
Das könnte alles einfach sein, wenn D64Copy auch einen Fehler über die zweite Ausgabe tätigen würde, so wie es die meisten Konsolentools tun... könntest du das eventuell auch mal für mich testen speziell bei diesem Fehler? Eventuell muss es ja hart auf hart kommen bis sich da was tut... Würdest du das tun?

Quoted from "Jasmin"

Format vor Write Image: Fehler wurde erkannt (log wurde automatisch gezeigt), Image wird trotzdem geschrieben! (bricht nicht ab).

Das hätte ich dir jetzt beinahe nicht geklaubt, da ich es gestern extra noch min. abend 5x durchgespielt hatte... Aber wie der Zufall es so will hatte ich kurz vor Schluss noch eine Kleinigkeit geändert, die das alles wieder futsch gemacht hat... egal, jetzt geht es wieder. Lade einfach die 0.3n nochmal runter, mach jetzt deswegen nicht ne neue Version, da eh bald wieder eine folgen muss wegen der Fehlererkennung beim Imagetransfer...

Finde es übrigens toll das ihr euch soviel Mühe macht und immer schön fleißig nach Fehlern guckt !!! DANKE !

öfter mal was neues... PRGMover V0.3o kann gesaugt werden

So, ich denke dass nun die Geschichte mit der Fehlerabfragen endlich durch ist.
In der neuen Version wird nicht mehr die Ausgabe von D64Copy analysiert, also nicht nach der Länge der einzelnen Zeilen oder nach "?" gesucht, sondern PRGMover zapft direkt den Fehlerkanal von D64Copy an, so wie es übrigens auch das GUI4CBM4Win tut. @Jasmin: Das war übrigens das was du testen solltest, ob über den Fehlerkanal (2) im Falle eines Falles eine Ausgabe erfolgt. Da ich mir nun eine eigene kaputte Diskette gebastelt habe, konnte ich das jedoch selbst testen und es funzt einwandfrei, im Gegensatz zu cbmforng (Formatieren), dort kommt nix raus...
Ne prima kaputte Diskette mit tonnenweise erstklassiger Fehlern bekommt man übrigens wenn man während des Formatierens diese einfach entriegelt bzw. den Abbrechen-Button betätigt :-)
Nun ist es so, dass PRGMover die aufgetretenen Fehler direkt beim Namen nennt und von daher kann man sich im Anschluss nun aussuchen ob man das Log noch sehen möchte oder nicht, im Gegensatz zu vorher, wo man es quasi aufgezwungen bekommen hat.

@Jasmin: Nun zu deinem "speziellen" Problem mit dem Schreibschutz. Also wie gesagt, ich fummele nicht an den Atributen herum, von daher kann dieses Verhalten nicht von einem Fehler im Frontend kommen. Nichts desto trotz setzt PRGMover ab sofort für jedes erzeugte temp.d64 die Attribute explizit auf "normal" also kein Schreibschutz oder sonst was. Ich hoffe, dass dies dein Problem beseitigt...

So, die Nacht is zwar schon um... aber ich muss weg

Quoted from "Jasmin"

Rein kosmetisch: Gibt's ne Möglichkeit den CeVi-Font so zu setzen, dass er nicht vom systemeigenen Antialiasing erfasst wird, mit ClearType sieht der so unauthentisch aus

Ja, prinzipiell geht das schon, dann muss die Schriftgröße allerdings so eingestellt sein, dass sie zum Pixel-Raster der PC-Auflösung passt. Diese ist bei der von mir verwendeten Schriftart (Eigenbau basierend auf commodore pixeled) aber erst dann erreicht, wenn die Zeichen ca. die doppelte der jetzigen Größe erreicht haben, was bedeutet das auch das Fenster von PRGMover sich in der Breite dann auch fast verdoppeln würde. Wenn jemand ne andere Schriftart kennt, die eine authentische Darstellung auch ab einer kleineren Größe bietet, dann binde ich diese gerne ein. Eventuell macht sich sogar jemand die Mühe und bastelt eine eigene... Mir fehlt da leider die Zeit zu... :-(

Quoted from "Jasmin"

Unabhängig davon bin ich immernoch ein Fan von der Idee, einfach die OpenCBM Ausgabe während sie entsteht live in einem Fenster zu haben, so wie bei GUI4CBM4WIN...ist aber halt nur meine Meinung...ergänzende Idee hierzu: Ein Kill-Button, der den OpenCBM-Task abschiesst (anders geht beenden ja wohl nicht), sodass man, wenn man einen Fehler sieht (bei der live-Ausgabe), den Vorgang sofort abbrechen kann.

Also einen Kill-Button habe ich ja
Mir gefällt die Textausgabe prinzipiell auch gut. Hat insbesondere dann einen Vorteil, wenn es zu Fehler kommt sieht man das und kann direkt Killen... so auch 1 zu 1 umgesetzt in dieser Experimentell-Version (Geht hier nur beim auslesen einer Diskette und durch drücken des Buttons, welcher sich mitten auf dem Fenster befindet!!!)
Aber dies so komplett zu integrieren fehlt mir in erster Linie Zeit... eventuell später mal. Aber selbst wenn man nicht sieht was gerade im Hintergrund läuft, wenn man der Floppy zuhört und schon einige Übertragungen gehört hat, so weis man gleich ob da was faul ist oder nicht...
Meine Motivation war auch nie die perfekte Komplett-Image-Transfer-GUI zu basteln, die auf alle Eventualitäten eingehen kann, sondern dort anzusetzen was es bislang noch nicht gab. Einzelne PRG's aus einem Image heraus direkt an die Floppy zu senden, ohne den Umweg über ein drittes Tool gehen zu müssen. Images nach lust und Laune aus verschiedenen Quellen (andere Images, BIN's, ROM's...) zusammenzustellen und direkt an die Floppy zu senden. oder umgekehrt. Das ermöglicht auch, aus einem D64/71-Image alle PRG's auf einmal zu einer angeschlossenen 1581 zu senden, oder eben nur ein Teil davon. Wie auch immer, momentan benötigt man für diese Aktionen immer ein zweites Tool... das ist der eigentliche Platz an dem ich das Programm sehe... was natürlich nicht heißt, dass das Transferieren kompletter Images fehlerhaft und deswegen nur unzureichend machbar sein muss - deswegen bedanke ich mich ja auch für eure Tipps und Infos.

Quoted from "Jasmin"

Und zum Fehlerkanal: Wie genau "zapft man den an"? Würde das gerne verstehen. Kann das auch mal googlen, aber evtl. erklärst Du mal kurz, wie genau PRGMover damit umgeht? Wäre nett.

Jede Konsolenanwendung verfügt über drei Kanäle 0, 1 und 2. Kanal 0 dient zur Eingabe, Kanal 1 ist die Standardausgabe und Kanal 2 ist Standardausgabe für Fehler. Fürth man die Anwendung aus, so können bei bedarf beide Ausgaben angezeigt werden. Pipe't man die Informationen jedoch weiter zu einer weiteren Anwendung oder leitet die Ausgabe in eine Datei um, so wird entweder die eine oder die Andere Ausgabe gepipe't bzw. umgeleitet. Da das Umleiten in eine Datei einfach nachzuvollziehen ist, hier mal ein Beispiel:

Die Ausgabe von Kanal 1 wird hierbei in die Datei TEST.TXT umgeleitet. Kommt es nun zu einem Fehler, so wird man in der Datei TEST.TXT darin jedoch keinen sehen können, da dieser über den Kanal 2 ausgegeben wird. Um diesen Abzufragen muss man folgendes eingeben:

Soviel zum Standard. Letztlich liegt es jedoch am Programmierer ob er sich an diese 2 Kanal-Geschichte hält oder nicht. Es gibt Anwendungen die blasen ihre Ausgaben alle auf Kanal 1 raus, manche sogar nur über Kanal 2... Möchte man also die Informationen weiterverwerten, so muss man wissen was wie wo ausgegeben wird. Hat man sich an den Standard gehalten, so kommen über den Kanal 2 nur die Fehlermeldungen, kommt da nix raus bzw. kommt da eine i.O. Meldung raus, so gab es keine Fehler.
Da ich zuerst mit cbmforng rumgespielt und da festgestellt hatte, dass auch bei einem Fehler nichts über Kanal 2 kommt, bin ich davon ausgegangen dass auch bei D64Copy dies der Fall sei, war mir aber nicht sicher, da ich ja keinen Fehler provozieren konnte, der D64Copy nicht zum aufhängen gebracht hätte. Da du allerdings bei einer Diskette einen Fehler hattest, der auch D64Copy durchlaufen ließ... bla bla

Quoted from "Jasmin"

d64copy Fehler erkennen funktioniert (Fenster kommt hoch). Problem ist nur, wenn man viele Warnungen hat, ist das Fenster zu hoch und man kann es nicht wegklicken, weil man unten nicht rankommt und oben der schliessen Button greyed out ist Das muss noch irgendwie geändert werden. Ansonsten schonmal gute Sache.

Hm, das Problem hat das GUI4CBM4Win auch... wie auch immer, ich habe das jetzt so geändert, dass die einzelnen Fehlermeldungen kaskadiert dargestellt werden, dann wird es so schnell nicht eng auf em Bildschirm (siehe Anhang)