Ist es möglich über das SD2IEC auch eine DNP zu öffnen ?
wen ja wie bekomme ich das hin ?
SD2IEC
- Stefan_h
- Thread is marked as Resolved.
-
Natürlich geht das und zwar genau so, wie Du in ein d64 oder d81 wechselst.
Am einfachsten mit den CBM-Filebrowser oder halt von Hand:
open1,8,15, "cd:testdisk.dnp":close1Diese Seite ist für SD2IEC-Anfänger recht hilfreich:
https://www.c64-wiki.de/wiki/sd2iec_(Firmware) -
mit dem FileBrowser geht es aber nicht ?
Doch, geht!!! Habe es gerade noch ausprobiert, der CBM-Filebrowser kann es. Fibr (nur eine alte Version auf meiner SD-Karte) kann es nicht!
-
Keine Ahnung, ich habe bis jetzt nur welche benutzt, die ich selbst mit Dir-Master erstellt hatte.
-
Vielleicht hilft ja dieser Thread weiter?
Wheels und DNP-Images (SD2IEC)
Aber ein "Zurückspielen" wird dort anscheinend auch nicht erwähnt.
-
Mir ist da noch was eingefallen, DNP-Images müssen eine bestimmte Größe haben, siehe das ReadMe:
Disk images are recognized by their file extension (.D64, .D41, .D71, .D81,
714 .DNP) and their file size (must be one of 174848, 175531, 349696, 351062,
715 819200 or a multiple of 65536 for DNP). If the image has an error info block
716 appended it will be used to simulate read errors. Writing to a sector with
717 an error will always work, but it will not clear the indicated error.
718 D81 images with error info blocks are not supported.
719 -
oder d81
Btw., bei mir funzt kein .d81 auf allen meinen SD2IECs, obwohl z.T. extra für SD2IEC.. . Eines davon immerhin mit recht aktueller FW, die anderen mit etwas älterer 0.10.3.
Was läuft da falsch ? Ist mir nicht so wichtig, aber neulich wollte ich das 'mal testen u. läuft halt nicht.. . -
Du meinst bestimmt 0.10.3
Der D81 Support ist aber schon seit ewigen Zeiten in der Firmware (05.09.2008) implementiert, keine Ahnung, was da falsch läuft. -
Vielleicht hilft ja dieser Thread weiter?
Wheels und DNP-Images (SD2IEC)
Aber ein "Zurückspielen" wird dort anscheinend auch nicht erwähnt.
Würde ich mit Vorsicht handhaben, hab in der Zwischenzeit festgestellt, dass die meisten "BackUp" fehlerhaft sind.
Wheels scheint sich irgendwie zu verheddern, davon abgesehen sind HD-DNP und SD2IEC-DNP nicht exakt gleich.Im GEOS MegaPatch - Thread ging es auch um die "BackUp"-Möglichkeit.
Daraus entstand u.a. DT64 Native-Copy Test und mit dem neuen GeoDos sollte es auch funktionieren, in beide Richtungen.
Hab es aber zu wenig getestet und es war noch was mit 8 MB-Grenze.
Gruss C=Mac.
-
ok ich habe ein paar DNP, s von einer HD Sicherung auf meinem PC
Wie hast du die HD-Sicherung erstellt? Falls deine "DNP"-Dateien ein Image der kompletten HD sind können sie nicht mit sd2iec funktionieren, weil DNP nur den Inhalt einer einzelnen Partition enthalten.
Btw., bei mir funzt kein .d81 auf allen meinen SD2IECs, obwohl z.T. extra für SD2IEC..
Wie äussert sich denn das "funzt nicht" und welche Dateigrösse (in Byte) haben diese D81-Dateien?
Wheels scheint sich irgendwie zu verheddern, davon abgesehen sind HD-DNP und SD2IEC-DNP nicht exakt gleich.
Na ja, die Implementierung in sd2iec ist halt anhand von Doku und einem Image einer echten HD reverse engineered, ohne Zugriff auf die echte CMD-Hardware zu haben. Kann schon sein, dass da was nicht 100% korrekt implementiert ist - das einzige mir bekannte Problem ist eine leicht unterschiedliche Berechnung des freien Speicherplatzes in sd2iec vs. Wheels, was aber nur ein kosmetisches Problem ist.
-
Habe vlt. nur nicht genug .d81 ausprobiert. Öffnen des .d81 geht, lädt dann aber ewig ohne Erfolg (die epyxgames collection). Da ist vlt. irgendein Loader drin, auch wenn das ja eigentl. extra für das SD2IEC erstellt wurde.
-
Habe vlt. nur nicht genug .d81 ausprobiert.
Games für's SD2IEC
- Games in D81 formate for SD2IEC
- Games for other Drive Ist eigentlich für CMD-Geräte gedacht, aber diverse Games laufen auch auf dem SD2IEC (siehe Liste Beitrag 7)
Sollte genug, funktionierendes, Futter für's SD2IEC sein.
Gruss C=Mac.
-
das einzige mir bekannte Problem ist eine leicht unterschiedliche Berechnung des freien Speicherplatzes in sd2iec vs. Wheels,
Es gibt da noch ein weiteres Problemchen
.
Das MD-Kommando (Unterverzeichnis erstellen) innerhalb eines DNP benutzt (wenn frei) die Sektoren vor Sektor 64 auf Track 1 zur Ablaga des UVs. Dieser Bereich (die "ominösen" 29 Sektoren) ist auf CMD-Geräten aber ausschließlich für Directory-Blöcke reserviert....Gruß
Werner -
Es gibt da noch ein weiteres Problemchen
.Das MD-Kommando (Unterverzeichnis erstellen) innerhalb eines DNP benutzt (wenn frei) die Sektoren vor Sektor 64 auf Track 1 zur Ablaga des UVs. Dieser Bereich (die "ominösen" 29 Sektoren) ist auf CMD-Geräten aber ausschließlich für Directory-Blöcke reserviert....Aber Unterverzeichnisse sind doch auch Directory-Blöcke?
-
Das MD-Kommando (Unterverzeichnis erstellen) innerhalb eines DNP benutzt (wenn frei) die Sektoren vor Sektor 64 auf Track 1 zur Ablaga des UVs. Dieser Bereich (die "ominösen" 29 Sektoren) ist auf CMD-Geräten aber ausschließlich für Directory-Blöcke reserviert....
Werden denn die 29 Sonderblöcke wenigstens dann benutzt, wenn keine anderen mehr frei sind? Falls ja: Dann erzeugt SD2IEC doch ein völlig konformes Dateisystem, denn durch eifriges Anlegen und Löschen von Files könnte der gleiche Zustand auch auf CMD-Hardware auftreten.
-
Aber Unterverzeichnisse sind doch auch Directory-Blöcke?
Nein.
Die 29 Blöcke sind für das Directory reserviert. 1 Block wird ja dafür schon automatisch reserviert, der bis zu 8 Dateinamen (des Directory) aufnehmen kann. Werden mehr Dateien auf die Partition kopiert, wird der nächste Block dort für das Directory benutzt, bis alle der noch freien 29 Blöcke belegt sind.
Ich habe das auf meiner FD-4000 ausprobiert:
- frisch formatierte Disk im Native-Format
- mit dem MD-Befehl der FD-4000 ein UV angelegt
- die Diskette zeigt mir 2 Blocks weniger frei an
- nachgeschaut, was wo auf der Diskette landet: Das UV (Header und 1. Directory-Block des UVs landen ab Track 1 Sektor 64 (hinter dem reservierten Bereich)auf dem SD2IEC ein frisch formatiertes DNP:
- mit dem MD-Befehl des SD2IEC ein UV angelegt
- an der Diskettenbelegung ändert sich nichts (gleiche Anzahl Blöcke frei wie vorher)
- nachgeschaut: Der UV-Header und der erste Directory-Block des UV landen im reservierten BereichIch mache also das Gleiche auf echter CMD-Hardware und auf dem SD2IEC (DNP) und erhalte unterschiedliche Diskbelegungen....
Hier noch ein Zitat aus einem CMD-FD-Handbuch:
"The directory and BAM of a Native Mode partition take up 64 blocks regardless of the partition's size. For example, a Native Mode partition that takes 256 blocks to create will show 192 blocks free, a 512 block partition will show 448 blocks free, and a 12,800 block partition will show 12,736 blocks free."
Werden denn die 29 Sonderblöcke wenigstens dann benutzt, wenn keine anderen mehr frei sind?
Diese 29 (eigentlich sind es 30, denn ein Block wird automatisch beim Formatieren angelegt) sind für das Directory des Hauptverzeichnisses reserviert aber in der BAM noch nicht belegt. Das ist im Prinzip wie bei einer 1541, wo ab Track 18 Sektor 1 das Directory steht.Gruß
Werner
