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...
Oder am Treiber der auf der BootDisk evtl. beschädigt ist, daher Neuinstallation testen... 16.10.21 war der letzte MP3 SnapShot...
Würde mich Interesieren ob bei dir das selbe steht wie bei mir in den Eigenschaften............
Eigenschaften/Statistik alles 0.... also die DNPs sehen hier gut aus.
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...
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...
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 ?
Display MoreIch 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
Anzahl Nicht Geos dateien 9
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.
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 ?
könnte man nicht eine kleine Routine schreiben, die einfach alle Blöcke 1x beschreibt und wieder ausliest und vergleicht?
Warum so kompliziert? Nimm das Format mit ID... das beschreibt ja jeden Sektor. Und wenn die 1581 das I/O-Byte in Sektor 40/1 und 40/2 an Pos.6 nicht nur als "Dummy" auf die Diskette schreibt sondern auch auswertet, dann müsste im Standardfall "Verify ON" und "Check Header CRC ON" aktiv sein... also müsste die Lesefehler auch beim Formatieren erkennen.
Hab aber keine 1581, könnte man aber unter VICE mal testen... das ROM ist ja das gleiche.
P.S. Bei der RAMLink sind es sogar noch weniger 1581-Partitionen ~19, es werden ja jeweils 800Kb benötigt.
Und wenn ich das noch richtig weiß gehen eh nur 31 Nutzer-Partitionen.
Das größte Problem ist, dass es nur noch grosse Karten neu gibt. Und alte Karten aus der Digital Kamera sind auch schon ausgenudelt.
Nö... ich kaufe nur neue 1,2,4Gb-Karten, meist MicroSD-Karten mit Adapter. Geht Problemlos... Man zahlt da aber ggf. etwas mehr je Gb als bei großen Karten...
ok, dann lege ich für jede 1581 GEOS Diskette eine eigene Partition an und kopiere mit MCOPY, die RAMLink kann ja ein paar hundert ...
Ähm... 16Mb / 720Kb = ~22 Partitionen vom Typ 1581. Du verwechselst das evtl. mit der CMD-HD, die kann aber max. 254 Partitionen wenn der Speicher reicht bzw. x mal 254 mit einem SCSI2SD wenn man IDs wechselt.
Selbst mit 1541-Disketten schafft die RAMLink gerade mal ~90 Partitionen. Auch die CMD-HD würde da nicht mehr als 254 Partitionen je ID verwalten können, egal ob 1Gb oder 4Gb...
Von "ein paar hundert..." bist Du also weit entfernt 
MCOPY geht aber nur mit CMD-Laufwerken, evtl. noch CBM-Laufwerken... meine letzten Tests mit einem SD2IEC scheiterten kläglich... habs aber schon länger auch nicht mehr getestet.
Unterverzeichnisse geht theoretisch, dann Dateien aber nur unter GEOS kopieren. Trotzdem ist dann jedes Verzeichnis wie eine Art "Diskette", denn GEOS sieht immer nur das aktuelle Verzeichnis. Anwendungen in einem Verzeichnis und Dokumente in einem anderen auf dem gleichen Laufwerk geht also nicht (je nach GEOS-System gibt es da Ausnahmen).
Einfach bei Interesse weiter googlen. 🙂
In Kürze zur Tastatur, die Zeichen auf den Tasten sind nicht nur einmal draufgelasert, sondern zweimal. Darum Doubleshot.
Bitte selbst auch mal googeln... DoubleShot ist meines Wissens nach was völlig anderes...
Die alten braunen C64-Tastaturen sind DoubleShot, die neueren C64C sind SingeShot obwohl oben+vorne was aufgedruckt ist...
was aber nicht unbedingt hilfreich ist. Wenn 2 der Dateien die gleiche Klasse haben, wird normalerweise nur die erste auf Disk vorhandene benutzt ....
Der Original 128Desktop, DualTop128 und TD128 nutzen nicht die gleiche Klasse
Außerdem zeigt er mir dieses große Board dann am Ende nicht sofort an. Stattdessen kommt nach ein paar Minuten die Meldung "Success,this file has been saved to your File Manager". Wobei "File Manager" ein Link ist. Wenn man darauf klickt kommt man in den File Manager, wo man dann das hochgeladene Board auswählen kann. Und dann wird die Größe gleich richtig angezeigt:
Ahhh.... dann wird es daran liegen. Die 96% hatte ich auch, und gewartet... aber ich hab noch keinen Account. Dann warte ich Deine finale Version ab und dann wird das mit dem bestellen schon klappen, Danke. 
Oder wie meinst Du das mit "Alu-PCB"?
So wie ich das geschrieben hab... es geht nur um die Optik, ich werde das nicht aufbauen. Ob es funktioniert oder nicht ist egal. Mir geht es nur um das Design von 0xdeadbeef und seinem 250466 auf einer Platine.
Also die Gerberdateien im Archiv sind die, die ich für meine Bestellung benutzt habe.
Wo hattest Du bestellt ? Ich hatte die Gerber mal bei JLCPCB hochgeladen. Hat soweit geklappt, aber ich wurde noch nach der Board-Größe gefragt (länge x breite in mm). Was wäre denn die genaue Größe? Ich glaub ich hab ein SixtyClone vom 250466 in rot, aber ob das die gleiche Größe hat?
Da es bei mir ja nur um die "Optik" geht... bei JLCPCB gibt es auch Alu-Platinen ? Zwar nur in wenigen Farben... aber ich glaub das muss ich mal testen... ich warte aber Deine finale Version ab (auch wenn das hier nicht aufgebaut wird... das schaffe ich nicht)
Ein großes Danke für Deine Arbeit... tolles Projekt und lass Dich von solchen Rückschlägen nicht entmutigen.
Und die Doku ist 1+
Der o.g. Fehler sollte hiermit behoben sein
Gruß Pusti64
Eben getestet... Lange Dateinamen überschreiben nicht mehr den Anzeigebereich
Außerdem finde ich das D81-Format und die geänderten Dateinamen (mit Sprache) gut, da kann man die Dateien parallel zu anderen "128 DESKTOP" Dateien nutzen... ohne umbenennen...
Aber... siehe ScreenShot... Der lange Dateiname macht wohl auch bei der Dateiinfo Probleme...Sorry, 
OK, vielleicht macht die HD unter VICE als Source das Ganze so langsam ....... Werde ich irgendwann nochmal probieren...
Mit Sicherheit... da es unter VICE/x128 keine RAMLink gibt hast Du auch kein "virtuelles" PP-Kabel, d.h. beim Zugriff auf die CMDHD wird die CPU auf 1MHz heruntergetaktet...
Der neue Snapshot (16.10.2021) ist inzwischen auch ein paar Mal installiert. Bisher keine Probleme.
Danke fürs testen...
Das sind die Maximalangaben, die muss der Prozessor auch erstmal schaffen. Laptop schreit eigentlich immer "thermisches Problem", was zum Heruntertakten führen kann.
Ich hab mich da wohl auch in den Werten geirrt... meine CPU hat max. 3.7GHz... cpufreq-info zeigt während dem assemblieren auch durchgehend Werte über 4GHz an, d.h. die CPU läuft immer auf Hochtouren... merkt man auch am Lüfter.
Jedenfalls wären 78min je Build für mich ein Grund keine Updates mehr rauszugeben... das dauert einfach zu lange. Es sind ja 8 Builds (Kombinationen von 64/128 + TurboDOS/Kernal und DE/EN) zu erstellen. Das wären ca. 10h... Man hat ja auch noch andere Dinge zu tun...
Von daher bin ich froh das es mit meiner CPU schneller geht.
