Hallo Besucher, der Thread wurde 2,8k mal aufgerufen und enthält 32 Antworten

letzter Beitrag von uwe1972 am

16MB großes DNP Spur/ Blockfehler

    Ich bin gerade dabei, meine d64 durchzusehen, und habe Unzählige Fonts gefunden.

    Also habe ich mir ein 16MB DNP erstellt, (Dank an Jojo) und die Fonts in UVs A-Z kopiert.

    Soviele sind es noch nicht, dennoch habe ich plötzlich Fehler auf dem DNP.

    Anfangs war das DNP in Ordnung, Nachdem ich nun Ca. 200 Dateien Insgesammt auf mehrere UVs verteilt aufkopiert habe,

    gibt es Probleme. Möchte ich mir die Eigenschaften ansehen, bekomme ich den Fehler

    das die Spur/Block nicht gefunden wird, Beim Überprüfen bekomme ich einen Totall Crash! (Absturz)

    Die Icons sehen nicht Beschädigt aus. Das DNP wurde mit GeoDesk erstellt


    GeoDos zeigt auch Fehler an (Fehler 2) stürzt aber nicht ab.


    16 MB laden ja gerade dazu ein, alles draufzuknallen was man hat.............

    Natürlich auf UVs verteilt..........


    Konfiguration:

    C64 mit Ultimate 16MB Reu

    A-B,D =SD-LW

    B= Ultimate Reu

    Meinst Du nicht es wäre hilfreich gewesen das DNP als ZIP oder 7z hier anzuhängen damit ich mir das anschaue? So ist das ja rätselraten... oder wenn es Fonts beinhaltet die Du nicht teilen willst, dann gerne auch per Konversation.


    Und nein: 16Mb laden nicht dazu ein alles "draufzuknallen"... ich halte 16Mb DNPs für komplett falsch, zumindest unter GEOS.

    Ist aber meine persönliche Meinung.


    P.S. UND GANZ WICHTIG!

    Welcher MP3/SnapShot und welche GeoDesk-Version ?

    Hier die Details:


    GDesk V.1.052

    MP3 09.10.2021


    Das DNP hänge ich dran, sind nur Fonts, keinerlei Privates drauf.

    Die Fehlermeldung hängt auch dran.

    Datenblock nicht Lesbar

    Spur/Blockadresse Ungültig

    (Sorry, das Foto ist etwas Verwackelt)


    Vorsicht: Die Überprüfung läuft bis Ordner O, dann kommen komische Zeichen und alles bleibt hängen.................


    Ich habe aber noch eine Frage:

    Wenn ich ein DNP erstelle (6336 KB) (Egal ob GDesk/GDos) bekomme ich in den Eigenschaften folgendes Angezeigt:

    Anzahl der Dateien 637

    Anzahl Verzeichnisse 23

    Schreibgeschützt 31 :gruebel

    Anzahl Nicht Geos dateien 9 :gruebel

    Anzahl Geos dateien 628


    Ist das so In Ordnung ???.........Auf einem Frischerstelltem, Leeren DNP???

    Löschen/Formatieren bringt Nix anderes..............

    Definitiv nicht... warum sollte es auch ?

    Hab eben auf 33r9v211016 und 1.52 eine 6336Kb DNP erstellt... 0 Dateien, 25280 Blks frei... Eigenschaften zeigt in der Statistik alles mit "0" an...

    Das alleine ist ja schon seltsam, da würde ich erstmal eine Neu-Installation auf einem *LEEREN* D81-DiskImage testen...


    Ich nehm jetzt mal Dein DNP... das scheint 255 Tracks zu haben, warum also Track $70 als "INVALID" markiert wird erklärt sich mir aktuell nicht...


    Hatte eben mit einem älteren SnapShot hunderte Dateien auf verschiedene Verzeichnisse verteilt. Ohne Probleme.

    Teste das jetzt aber nochmal mit dem aktuellen SnapShot.

    Auf Deinem DNP ist das "FONT P"-Verzeichnis fehlerhaft. Unter BASIC kann man das zwar öffnen, aber der Inhalt ist Müll...


    Wenn ich mir den Header anschaue, dann hat das Verzeichnis selbst den Namen "Font O" (Auch wenn der Dateiname "Font P" ist...)... Hast Du das O-Verzeichnis dupliziert mit einem neuen Namen P? Oder Hast Du alle Verzeichnisse über das Menü neu erstellt ?

    Gut,

    Ich werde den MP3 Morgen nochmal auf einem ganz Sauberen Frischerstellten d81 neu Installieren..............

    Ich habe Übrigens gerade geschaut, Bei D64 & D81 wird in den Eigenschaften alles Korrekt angezeigt................Scheint nur bei DNP zu sein


    :thnks: für deine Mühe, ich bin Gespannt, wer der Schuldige ist..................

    Bei Bedarf kann ich noch weitere DNPs Hochladen........................


    PS.Leider ist das Pic etwas Undeutlich...............

    Ich hab jetzt mal das P-Verzeichnis versucht zu löschen... und kopiere gerade das DNP per DiskBackup auf eine RAMDisk. Da geht Verify schneller. Die restlichen Verzeichnisse scheinen sich kopieren zu lassen...


    GeoDesk kann das Verzeichnis selbst auch nicht löschen. Muss ich wohl in GeoDesk eine neue Option einbauen. Hab es dann über dualTop gelöscht (das kennt keine Verzeichnisse). Danach läuft das Validate durch...


    Also ist es das P-Verzeichnis... mal sehen ob mir dazu was einfällt...


    Verzeichnis duplizieren scheint jedenfalls nicht zu gehen, ist aber ein anderer, neuer Bug...

    Ich habe die UVs alle über das GDesk-Menü erstellt.

    UVs Dupplizieren, / Kopieren hab ich noch nie Versucht.


    Genauso fängt das immer an, Grade geht noch alles, und plötzlich kommen die Fehlermeldungen.

    UVs können nicht mehr Gelöscht oder die Namen Geändert werden.

    Irgendwann kann ich die DNPs garnichtmehr Lesen.............


    -Wenn ichs nicht besser wüßte, würde ich an einen Virus Denken.-


    Aber das Gute an der Sache ist, das du es Nachstellen kannst, Bzw. dem Fehler auf der Spur bist..................

    Anmerkung:

    Auf meiner FD und der Reu habe ich auch UVs, aber noch nie Probleme mit UVs gehabt

    (bis jetzt)

    Zitat von uwe1972

    Aber das Gute an der Sache ist, das du es Nachstellen kannst, Bzw. dem Fehler auf der Spur bist..................

    Also auf der Spur bin ich nicht... ich kann nur den Fehler auf Deinem DNP nachstellen.

    Ich kopiere aktuell noch weitere Dateien auf ein 16Mb-DNP... das ist schon zur hälfte Voll... bisher keine Probleme.


    Versuch doch mal das FONT-DNP auf einem anderen SD2IEC+SD-Karte zu erstellen. Nur um auszuschließen das evtl. eine Deiner SD-Karten oder SD2IEC ein Problem hat... Oder mal auf einem REU-Native und dann als Backup auf die SD-Karte/DNP kopieren.


    Die Treiber nutzen ja alle die gleichen Routinen, egal ob HD-Native oder SD2IEC/Native. Wenn es auf anderen Laufwerken klappt liegt der Verdacht nahe das ein SD2IEC oder die SD-Karte Probleme hat...

    Hmmmmmmm,


    Die SD-Karten habe ich schon Getauscht, also kommt Morgen die SD-LW Firmware dran,

    und dann kopiere ich mal die Fonts auf die Reu.

    Wird aber erst Morgen Nachmittag


    Das Erklärt aber noch nicht, die Belegten Verzeichnisse und Schreibgeschützten Dateien,

    die ich den Eigenschaften sehe. ich hänge mal ein kleines DNP dran.

    und ein leeres 16MB DNP..................

    Würde mich Interesieren ob bei dir das selbe steht wie bei mir in den Eigenschaften............

    Es muß ja einen Grund für alles Geben

    Du kannst auch so ein DNP per DiskBackup auf ein anderes Medium kopieren... REU-Native z.B. und dann die Eigenschaften betrachten. Wenn das auch bei Dir funktioniert dann ist da definitiv was mit SD2IEC/Native faul... Treiber, Laufwerk, SD-Karte...

    Oder mal ein leeres REU-Native auf ein SD2IEC-DNP-Image per DIskBackup kopieren und überprüfen ob da überall "0" steht...

    Grüße,


    So, um es Kurz zu Machen, Es lag an der Firmware der SD-LW!!

    Ich habe auf meine SD.LW die neuste Firmware aufgespielt und dazu den neusten MP3

    und siehe da, bei einem leeren DNPs bzw. in den Eigenschaften wird überall korrekt 0

    angezeigt, wie es sein sollte.................

    Liegt also nicht am MP3, oder Treibern, war wohl wirklich die Veraltete Firmware schuld


    Vielen Dank für die Hilfe

    Zitat von uwe1972

    So, um es Kurz zu Machen, Es lag an der Firmware der SD-LW!!

    Das glaube ich nicht wirklich ;-) .


    Auch bei älterer Firmware sind mir keine Probleme mit DNP bekannt. Durch das Aufspielen der Firmware wurde sehr wahrscheinlich nur eine Blockade auf Deinen SD2IEC gelöst. Bis zur nächsten Blockade .... ;-) .


    Gruß

    Werner

    Hallo Werner,


    Naja, noch funktionierts, und die Eigenschaften werden Korrekt angezeigt.

    Ich werde nun die Dateien auf kleinere DNPs kopieren und die 16MB DNPs löschen.


    Da die meisten Hier mit Realer Hardware arbeiten ist das Problem für euch ganz schwer Nachzuvollziehen. Aber ich hab ja schon immer, von Anfang an Probleme mit DNP.................

    Ich hoffe ja, das der Fehler nun Beseitigt ist..................


    Abwarten, bis ich wieder Nerve..............ROTFL

    Zitat von uwe1972

    Naja, noch funktionierts, und die Eigenschaften werden Korrekt angezeigt.

    Ich werde nun die Dateien auf kleinere DNPs kopieren und die 16MB DNPs löschen.

    Naja, das ist ja das seltsame. Warum immer wieder Probleme bei Dir aber keine bei mir???


    Ich arbeite am C128 mit 4 DNPs als MP3-Bootdisketten, 2 für MP3-128 und 2 für MP3-64. Eines der beiden hat je 191 Tracks (12 MB), das andere je 255 Tracks (16 MB). Probleme damit ich damit bisher nicht. Der Unterschied zwischen Dir und mir ist ja nur, dass Du 3 bzw. 4 SD2IECs nutzt. Bei mir ist es nur eins als Lfw. A: ......


    Gruß

    Werner

    Zitat von wweicht

    Warum immer wieder Probleme bei Dir aber keine bei mir???

    Weil es evtl. noch Fehler in MP3 gibt die nur bei bestimmten Abläufen auftreten, der Bug im TaskManager der mit 1610 gefixed wurde könnte so ein Kandidat gewesen sein (aber nur wenn es bei Nutzung des TaskMan in mehreren Native-Laufwerken Disketten mit dem gleichen Namen gibt, was eh nicht gut ist und ein Grund dafür ist warum GeoDesk beim DiskBackup den Namen nicht mehr per Default mitkopiert). Oder der Bug mit dem NativeMode und der Nutzung von für das ROOT-Verzeichnis reservierter Sektoren für Daten.


    Ich will nicht ausschließen das da noch ein Fehler ist der nur in seltenen Fällen auftritt. Die letzten Fehler hab auch nur ich festgestellt, kein anderer. Da könnte ich ja auch Fragen warum bemerkt kein anderer die nachweislich vorhandenen Fehler? Da kann ich MP3 ja gleich einstampfen wenn es keiner nutzt :Peace


    Gut das es hier wohl durch eine Neuinstallation behoben wurde, was meinem Verdacht eines beschädigten Treibers zumindest nicht widerspricht. Wäre gut gewesen so ein leeres DNP per Backup auf ein ReuNative zu kopieren, dann hätte man Gewissheit gehabt. Da die DNPs aber hier i.O. waren bleib ich bei meiner Vermutung.


    Daher hab ich immer ein Backup vom letzten Boot-D81 mit Schreibschutz, das kann ich dann immer zum testen hernehmen.

    Wobei ich sowieso täglich mehrere Builds durchlaufen lasse und spätestens nach zwei bis drei Tagen die Boot-Disk aktualisiert wird. Da spare ich mir ab&zu das schreibgeschützte Backup ;)