Hello, Guest the thread was called530 times and contains 14 replays

last post from hexfile at the

SD2IEC Kopierprogramm DC64 stürzt nach jeder Diskette ab!

  • Hallo Zusammen,


    hab grad an nem (fremden) SX64 mit EXOS III Rom und SD2IEC (letzte SW & FW Stände lt. offizieller Website) folgendes Problem:


    Der SX läuft an sich stabil, er hat keinen SID derzeit verbaut, aber das sollte ja wohl keine Rolle spielen. (Kein TESA Gerät, nur SID nach Defekt entfernt)


    Es ging nun darum, Disketten damit vom internen LW 8 auf die SD2IEC auf 9 zu überspielen.


    Es wurden 20 vorbereitete leere D64-Images in ein Verzeichnis kopiert.


    Verwendet wird DC64, das "mitgelieferte" Kopierprogramm.


    Wenn die Funktion DiskCopy verwendet wird, d.h. sektorbasiertes Kopieren, dann geht es, aber dauert bei nur teilweise gefüllten Disketten natürlich (trotz Exos) ewig, so 5 Min. je Diskettenseite.


    Wenn aber über die Mehrfachauswahl und entsprechend Mehrfachkopie kopiert wird, dann geht es gefühlt sehr zackig (für C64 Verhältnisse), aber das Programm stürzt regelmäßig bei der 2. Diskette kurz nach Start des Kopiervorgangs ab, mit einem Syntaxerror in einer nicht Basic-konformen Notation (also scheinbar von nem Compiler stammend, was aber auch wieder verwundert, denn "Syntax" sollte wohl schon beim parsen resp. compilieren erkannt und abgefangen werden...)


    Ein erneutes "Run" führt zu keinem Neustart des Programms, der Rechner verhält sich auch im Basic dann merkwürdig, nur reset hilft noch.


    Meine Frage: ist das geschilderte Verhalten des DC64 bekannt? Liegt es eventuell am EXOS? (leider kein Rom-Umschalter installiert und beim SX kommt man ja eher schlecht ran, um mal spontan das ROM zu tauschen....)


    Gibt es da "SD2IEC" kompatible Kopierprogramme, die das besser hinbekommen, was mich insbesondere auch stört ist, dass nach der Multifile-Kopie die freien Blocks zw. Vorlage und Kopie abweichen, manchmal sogar die Blocks, die die einzelnen Einträge angeblich belegen...


    Mir fehlt da jetzt echt das Vertrauen in diese Toolkette, ein "Verify" gibt es ja nun auch nicht...


    Als ich zuletzt vor ca. 20 Jahren Disketten eingelesen habe, mit Parallelportkabel und DOS-PC, da lief das irgendwie solider, allerdings kann ich mich erinnern, dass auch damals irgendeine Version des "StarCommanders" oder so (NC Clon) da teils Ärger machen konnte, aber was genau, das hab ich nicht mehr in Erinnerung und müsste mir auch erst wieder einen Rechner passend einrichten und ein Kabel dafür löten, hab das alles zwischenzeitlich mal weitergereicht...


    Es geht darum, jetzt auf die Schnelle mal Sicherheitskopien von Disketten anzulegen, die ich dann -auf sein Angebot hin- an Parser senden würde für eine Archivierung mittels Kryoflux.

    Da es sich aber um Disketten zu sehr seltener HW handelt (AMS64 Audiomesssystem und Ascom Akustikkoppler etc), die ich sonst noch nirgends im Web entdecken konnte, möchte ich die Inhalte schon auch gerne sichern, bevor ich das in die Hände von DHL gebe... Man weiß ja nie...


    n.b. die Floppy des SX zeigt auch komisches Verhalten: mehr oder minder regelmäßig werden Disketten erst nach dem 2. Einlegen korrekt erkannt und das Directory dann gelesen, im ersten Durchgang führt sich das LW auf, als sei ne unformatierte oder ziemlich defekte Disk eingelegt und macht neben dem bekannten Alps-Rekalibriergeräusch auch sonst noch sehr hektische Geräusche und hängt teils minutenlang fest, bis Fehlermeldung und schnelles Blinken der LED folgen. Hab ich in der Form früher noch nie gesehen... Auch eine Folge von EXOS???



    DANKE!

  • Der SX stand halt samt SD2IEC grad griffbereit rum, aber wenn es so nicht geht, muss ich wohl doch mit meiner 4040 auf herkömmliche Weise die Kopien ziehn, aber dann ist halt auch nix mit .d64 Files vorerst... Zudem würde ich das natürlich auch gerne mal testen, wenn ich mein eigenes System wieder aufgebaut habe, aktuell immer noch Umzugschaos und jetzt rückt mir auch die Gemeinde auf den Leib, da ich angeblich ja ungenutzte Flächen habe, die ich für die Flüchtlinge freimachen soll... So viel zum Thema Privateigentum...

  • Der SX stand halt samt SD2IEC grad griffbereit rum, aber wenn es so nicht geht, muss ich wohl doch mit meiner 4040 auf herkömmliche Weise die Kopien ziehn, aber dann ist halt auch nix mit .d64 Files vorerst...

    ... du machst dir Sorgen & Probleme, wo keine sind ... und Arbeit umsonst. Bitte diese Originaldisketten nicht über Gebühr beanspruchen & strapazieren ... nach dem Kryoflux-Stream kannst du damit machen, was du gerne möchtest. Vorher das zu machen ist nicht förderlich und gut. ;)

  • nach dem Kryoflux-Stream kannst du damit machen, was du gerne möchtest

    Bitte nicht falsch verstehen, aber das KÖNNTE ich auch jetzt schon ;-)


    Wie schon in div. PNs geschrieben, hab ich zu schlechte Erfahrungen mit Post & Co. als dass ich sowas ungesichert (letztlich würde ein Verlust der -vermutlich NICHT kopiergeschützten! Originale ja auch meine HW entwerten...) versenden werde. Zudem hab ich den SX nicht ohne Grund gewählt, da die Floppy dort NOS ist, hab ich gerade aus meinen Beständen dort für den Besitzer neu eingebaut und davor natürlich mit Werks-Kalibrierdiskette überprüft. D.h. in Sachen HW weiß ich, was ich mache, nur mit dem "neumodischen" Erweiterungen wie SD2IEC, U1541 & Co. hab ich fast keine Erfahrungen, schlicht weil es das damals(tm) nicht gab und ich mich auch irgendwie innerlich wehre, alt und neu zu vermischen. Beim SD2IEC überwiegt natürlich der Vorteil, in einem Rutsch zu nem D64 File zu kommen, daher der Ansatz jetzt.


    Ohne Kopie und Durchsicht hinsichtlich möglicher "privater" Dateien auf den Disketten gebe ich nix raus, das war und ist Grundbedingung.


    Es ging jetzt konkret darum, ob das den üblichen SD2IEC Packages beiliegende DC64 von 2020 wirklich so gravierende Fehler hat, sprich nach jeder Multi-Datei-Kopie neu geladen und gestartet werden muss, da scheinbar Speicherleck o.ä. und ob das Programm an sich "vertrauenswürdig" ist, was die erstellten Kopien anbelangt.


    Alternativ werde ich es demnächst nochmal mit Original-Kernal und MEINER (Mitsumi)-1541 probieren, von der ich auch weiß, dass sie noch nicht viel zu tun hatte seit Neukauf damals sowie mit den üblichen Kopierprogrammen, die man eben auch damals schon kannte. Aber wenn ich nicht überzeugt bin, dass auf der SD wirklich eine 1:1 Kopie der Programme und Daten landet, dann lieber ne Kopie 1:1 mit der 4040 wie seinerzeit, das hat zumindest geklappt und dauert auch nicht sooo ewig, nur schade um die ganzen bislang noch OVP-Disketten, die ich dafür nun opfern müsste...

  • Bitte nicht falsch verstehen, aber das KÖNNTE ich auch jetzt schon ;-)

    Ab Anfang 05/2022 bitte zuschicken ... vorher habe ich da keine Zeit bzw. bin zeitlich nicht verfügbar. Bitte mache da jetzt erstmal nichts mehr mit diesen deinen Originaldisketten. Überlasse das bitte mal den Profis ... bitte da jetzt keine unnötigen Fehler machen. Wäre zu schade darum für die C64-Community! THX! ;)

  • Hmm, ich weiß ja nicht, was Du für ein Bild von mir vor Augen hast Parser, aber mit Disketten kann ich durchaus umgehen ;-)


    Und meine Disketten liefen jetzt die letzten 30 Jahre bei jeder sporadische Inbetriebnahme, um etwas aus alten Zeiten vorzuführen stets fehlerfrei. Bei neu zugekauften kann ich das natürlich nur auf den jetzigen Ist-Zustand beziehen, aber meine Laufwerke werden regelmäßig gereinigt und entmagnetisiert und ausser mit ein paar damals schon sehr unzuverlässigen "No-Names" hatte ich noch keine Ausfälle zu verzeichnen.


    Deshalb hat mich das Rumgezicke der Floppy unter EXOS ja so verwundert.


    Schreibschutz war natürlich auch auf jeder Diskette drauf und beim Aus- und Einschalten das LW immer entriegelt rsp. die Diskette ganz draussen.


    Auf meinen Geräten habe ich keine solchen Speeder drauf, war jetzt mal ein (heilsamer) Versuch, der mich in meiner Einstellung, C= Produkte so original wie möglich zu belassen noch bestärkt hat. Nur hab ich meinen "historischen" SX grad wieder gut eingelagert und der andere stand grad eh noch zum testen rum...


    Demnächst bekomme ich nen SX, den ich dann so umbauen werde, wie ich es für die Aufarbeitung meiner ganzen Lagerbestände an C= Zeugs benötige, der bekommt dann wohl auch ne neumodische U1541 oder Ähnliches. Von der SD2IEC bin ich ziemlich enttäuscht, das Teil ist ja mega umständlich in der Bedienung (kein Vergleich zu z.b. den originalen USBStick2Floppy-Emulatoren für den PC (nicht die China-Klone!), wo man am Display unkompliziert das image der "eingelegten" Diskette wählen kann) und auch von der HW her nicht ausgereift, da schwankt z.b. trotz externem 5V Netzteil die Spannung bei jedem Zugriff derart, dass sogar die LCD-Hintergrundbeleuchtung zu flackern anfängt...

  • Hmm, ich weiß ja nicht, was Du für ein Bild von mir vor Augen hast Parser, aber mit Disketten kann ich durchaus umgehen ;-)

    Mache wie du meinst ... aber bitte verstehen & einsehen, dass es hier im Forum64 sehr, sehr viele Forenmitglieder/-innen gibt, die in bestimmten Themenfeldern mehr wissen und diesbezüglich mehr Erfahrungen haben als du. Du kannst nicht alles können ... :D.

  • mehr wissen und diesbezüglich mehr Erfahrungen haben

    Ja, deshalb ging der Thread ja drum, ob eben JEMAND Erfahrungen mit dem DC64 Programm sowie generell mit SD2IEC in Zusammenhang mit EXOS III hat, da mir das

    "spanisch" vorkam, wie sich die Floppy benimmt, dachte zunächst (eine Disk nach der anderen eingelegt und das DIR auszulesen versucht) schon, ich hätte da lauter "Nieten" gegriffen, bis dann eine von mir zuvor noch verwendete Test-Diskette plötzlich auch Zicken machte... nochmal probiert: alles super, auch inhaltlich alles da.


    Andere Disk nochmals probiert: wieder nix. LW auf- und wieder zugemacht, nochmal probiert: plötzlich DIR lesbar ohne Mucken, Hauptprogramm lässt sich auch starten...


    Weiter probiert und rausgefunden: es geht im ersten Anlauf nur extrem selten, im zweiten aber IMMER, auch wenn die Diskette NICHT zwischendurch rausgenommen wurde (hatte auch schon den Verriegelungsmechanismus von Alps im Verdacht...)


    Also Quintessenz: EXOS III hat wohl Probleme in dieser Konstellation, da LW ok (NOS und getestet/Kalibriert), SX selbst ok und im zweiten Anlauf ja auch fehlerfreies Lesen möglich. Weiß NICHT woran das krankt (mein Verdacht anderswo wäre Diskwechsel nicht erkannt, aber haben das die 1541 überhaupt???) oder auch nicht, ob das dann zum Aussteigen des DC64 führt, ich hab dort ja nach Diskwechsel auch das DIR zweimal eingelesen, um die Quelldateien markieren zu können, d.h. an dem obigen Fehler allein kanns kaum liegen...


    Ich könnte auch andersrum fragen:


    Mit welchen Kopierprogramm erzeugt ihr Euch .d64 Dateien auf SD2IEC, wenn sicher ist, dass die Quelldiskette keinen "ernsthaften" Kopierschutz hat, bestenfalls die Reihenfolge der Einträge "optimiert" wurde und es Einträge gibt, deren Länge im Directory scheinbar falsch angegeben ist, da diese auf der Kopie dann größer wurden?


    Sektorbasiert oder Dateibasiert?


    Verify müsste es auf JEDEN Fall aber können, da ich nicht jede Datei einzeln auf Funktion testen kann, dazu müsste ich mühsam die ganze HW. die angesteuert wird, aufbauen und teils wohl auch erst reparieren, recappen etc...

  • Mit welchen Kopierprogramm erzeugt ihr Euch .d64 Dateien auf SD2IEC, wenn sicher ist, dass die Quelldiskette keinen "ernsthaften" Kopierschutz hat, bestenfalls die Reihenfolge der Einträge "optimiert" wurde und es Einträge gibt, deren Länge im Directory scheinbar falsch angegeben ist, da diese auf der Kopie dann größer wurden?

    nibtools & Kryoflux.

  • Danke fepo !


    Scheinbar hat das Exos auch an sich nen Schuss, dass es immer zwei Anläufe braucht, um auch nur das Directory korrekt einzulesen...

    Wie gesagt: mech. Laufwerk kann ich ausschliessen, das ist neu und geprüft und war auch davor ne Alps, also nix umgebaut oder umgejumpert...


    Möglicherweise ist das alte LW dann auch gar nicht so unzuverlässig und könnte auch drinbleiben, muss ich mal gegentesten, Problem ist halt immer

    der Zeitaufwand für sowas, wenn ich da nen Tag mit rumspiele, dann kann ich das Zeugs auch gleich unbesehen wegwerfen...


    Und kommt mir nicht mit dem "Hobby"-Argument: alte Floppies reparieren macht vielleicht einmal in 10 Jahren Spass, aber weder "im Auftrag" noch öfters...


    Aber andere Baustelle...


    edit: gerade eben mit normalem C64 und x-beliebiger aus dem Regal geholter 1541-II probiert: funzt auf Anhieb und liest die DIRs auch immer sofort ein. Ist halt nur nochmals langweiliger beim sektorbasierten Kopieren...


    Möchte aber doch gerne ein Kopierprogramm MIT Verify, das kann das DC64 ja gar nicht, oder hab ich was überlesen???

  • Ruudi


    Verify, siehst Du daran, dass keine rote LED blinkt.
    Dann bricht DRACopy ab.


    Exos und Beast funktionieren beide nicht sauber mit dem SD2IEC.

    Liegt eher am SD2IEC, da die Speeder sich nicht mit der SD2IEC

    Laderoutine vertragen.

  • Möchte aber doch gerne ein Kopierprogramm MIT Verify, ...


    In dem Kopierprogramm FCOPY (aus den CMD FD Ultilities) können mit der Funktion X (=Compare) gezielt ausgewählte Dateien (Auswahl mit F) auf zwei Disketten miteinander verglichen werden. Vielleicht hilft das weiter. Man kann auch alle Einträge im Directory auswählen und dadurch alle Dateien vergleichen lassen. Besonders schonend ist ein solches erneutes Lesen für physische Disketten natürlich nicht.


    [Evtl. geht auch das Programm MCOMPARE um ganze Disketten zu vergleichen; mit zwei 1541-II (im Emulator) will das bei meinem Test aber nicht funktionieren - erst wenn eines der Laufwerke ein (emuliertes) FD-2000 ist, lässt sich ein Target-Laufwerk wählen.]


    In den angehängten Bildern sind zur Veranschaulichung bspw. zwei Disks mit identischen Inhalten in Laufwerk 8 bzw. 9 eingelegt. Fürs Vergleichen werden die zwei Dateien FCOPY+ und MCOPY ausgewählt. Die Meldung Comparison Complete am Ende bedeutet, dass die hier geprüften zwei Dateien auf den Disketten in LW 8 und LW 9 gleich sind.