Hallo Besucher, der Thread wurde 9,4k mal aufgerufen und enthält 43 Antworten

letzter Beitrag von C=Mac am

Wheels und DNP-Images (SD2IEC)

  • Hallo,


    zunächst mal Danke an C=Mac, Unseen und Pusti64 :D


    Richtig, ist gibt glaub auch nichts anderes.

    Ja und nein :-) .


    Das HD-DOS hat eigentlich jeder Besitzer einer CMD-HD. Ist auf der Diskette dazu drauf. Bei mir (Disk stammt aus dem Internet) HD DOS 1.92. Habe mir daraus und aus dem "fakehd.bin" ein hd.bin für mein uIEC gebastelt, dass 32kB groß ist und eben das HD-DOS (von Adresse $9400-$FFFF enthält. Das ändert aber nichts an den Problemen.....


    Ich hab irgendwie im Hinterkopf, das es einen Bericht in der 64'er gab, dass nicht die max. Grösse benutzt werden sollte.

    Naja, die 64er hat ab und an auch Blödsinn verbreitet ....... ;-)


    Diese zwei Byte sind das einzige, was Wheels per M-R aus dem Laufwerksspeicher liest.

    Nun ja, das DNP wird als CMD-HD erkannt und sowerit also OK.


    Aber woher liest Wheels die Größe der jeweiligen Partition????
    Das kann eigentlich nur von der System-Partition kommen oder eben aus den Speicherbereichen, die ich erwähnt hatte....
    Warum die Informationen anscheinend 2x gespeichert werden, keine Ahnung.


    Beides ist in einem DNP leider nicht verfügbar....


    $8200-$82ff
    04 = 1581
    01 = Native

    Und da gehen die Probleme schon weiter....


    Nach den Informationen hast Du 2 Native-Partitionen auf Deiner HD (Part 17 und 44). Aber: die Größen-Angbae speziell bei Part 44 macht mich stutzig. Die dazugehörende Größe ist $4400, was 17408000 Bytes entspricht. Ein so großes DNP kann es nach meiner Informationen (Beschreibung DNP-Format) gar nicht geben ....


    Ich bin verwirrt.....


    Gruß
    Werner

  • Nun ja, das DNP wird als CMD-HD erkannt und sowerit also OK.
    Aber woher liest Wheels die Größe der jeweiligen Partition????
    Das kann eigentlich nur von der System-Partition kommen oder eben aus den Speicherbereichen, die ich erwähnt hatte....

    Oder aus der Antwort des G-P-Befehls, mit dem man Typ, Label, Startsektor und Grösse einer Partition auslesen kann, ohne im Speicher der HD oder in der Systempartition wühlen zu müssen.

  • Hallo,

    Oder aus der Antwort des G-P-Befehls, mit dem man Typ, Label, Startsektor und Grösse einer Partition auslesen kann

    und wo nimmt G-P die Angaben her ;-) ?


    Probier mal den Nightly Build von heute.

    irgendwie verwirrend das Ganze ;-)


    Also, neue Firmware auf mein uIEC aufgespielt. Mit "64Copy" das größte mögliche DNP erstellt.


    am PC: Größe: 15,94 MB (16.711.680 Bytes)


    auf dem C128 in Basic: das DNP ist im Directory auf dem uIEC 63999 Blöcke groß. Wenn ich das DNP öffne, zeigt mir das Directory 65244 freie Blöcke.



    Unter Wheels: die gleichen Probleme wie bisher. Also den "uIEC_Manager" (14 Blöcke groß) kopiert, keine Änderung. Dann habe ich nach und nach CMD-Sub-Dirs (je 2 Blöcke) erstellt. Nachdem ich 7 Sub-Dirs erstellt hatte (gesamt Inhalt im DNP: 28 Blöcke) normalisiert sich die Anzeige der Füllstandsanzeige. Wheels zeigt jetzt unter "disk" - "Info" bei "Total Space": 65216 blocks und auch bei "Space Free" 65216 blocks.


    Also irgendwas stimmt da nicht....


    Gruß
    Werner

  • und wo nimmt G-P die Angaben her ;-) ?

    Bei CMD wohl aus irgendwelchen Systemtabellen, bei mir aus der Dateigrösse des Diskimages.


    Die letzte gültige Tracknummer einer Native-Partition steht übrigens in Byte 8 von Track 1, Sektor 2 im Image, damit braucht man keine externe Daten um die Grösse zu bestimmen.


    Zitat

    auf dem C128 in Basic: das DNP ist im Directory auf dem uIEC 63999 Blöcke groß. Wenn ich das DNP öffne, zeigt mir das Directory 65244 freie Blöcke.

    Ja, sd2iec beschränkt die angezeigte Dateigrösse im Directory auf maximal 63999 Blöcke, auch wenn die Datei grösser ist. Der tatsächliche Wert wäre eh nicht als Zeilennummer darstellbar.


    Zitat

    Unter Wheels: die gleichen Probleme wie bisher. Also den "uIEC_Manager" (14 Blöcke groß) kopiert, keine Änderung. Dann habe ich nach und nach CMD-Sub-Dirs (je 2 Blöcke) erstellt. Nachdem ich 7 Sub-Dirs erstellt hatte (gesamt Inhalt im DNP: 28 Blöcke) normalisiert sich die Anzeige der Füllstandsanzeige. Wheels zeigt jetzt unter "disk" - "Info" bei "Total Space": 65216 blocks und auch bei "Space Free" 65216 blocks.


    Also irgendwas stimmt da nicht....

    Wahrscheinlich eine kleine Diskrepanz zwischen der Berechnung der Zahl der freien Blöcke in sd2iec und der Berechnung von Wheels auf der C64-Seite. Normalerweise fragt Wheels die freien Blöcke durch ein Loader-Kommando ab und das Laufwerk berechnet die auf etwas schräge Art(*), sd2iec liefert einfach den gleichen Wert wie er auch im Directorylisting stehen würde. Eventuelle Unterschiede sollten lediglich kosmetischer Natur sein.


    (*) Wheels fängt die Berechnung mit Track 2, Sektor 64 an und ignoriert den frei/belegt-Zustand aller Sektoren vor diesem Punkt - meines Wissens ist das aber kein "besonderer Punkt" in der Block-Allokationsstrategie bei Native-Partitionen?

  • Das HD-DOS hat eigentlich jeder Besitzer einer CMD-HD. Ist auf der Diskette dazu drauf. Bei mir (Disk stammt aus dem Internet) HD DOS 1.92.

    Stimmt auch wieder ;)


    Bei mir ist HD-DOS 1.90 installiert, ist gibt auch noch eine Datei: GEOS/HD V2.00 auf der Systemdisk.
    Leider keine Beschreibung zum Programm.



    Die dazugehörende Größe ist $4400, was 17408000 Bytes entspricht. Ein so großes DNP kann es nach meiner Informationen (Beschreibung DNP-Format) gar nicht geben ....

    Laut HD-Tools ist die kleinste mögliche Partition 256 Blocks und die Grösste 65'280 Blocks gross, es kann in Schritten von 256 Blocks einstellen werden.


    Probier mal den Nightly Build von heute.

    Hoffe ich kommen morgen dazu.



    Bei CMD wohl aus irgendwelchen Systemtabellen,

    Vermute mal, aus der Partition 0 (Systempartition).



    Eventuelle Unterschiede sollten lediglich kosmetischer Natur sein.

    Wenns nur kosmetischer Natur ist, spielt es eigentlich keine Rolle :whistling:




    Mehr Sorgen macht mir im Moment, das die Block-Angaben auf der CMD-HD nicht übereinstimmen ?(


    Partitionsliste: 58'112 Blocks (64 Blocks gehen für's Dateisystem weg), Wheels meldet Total Space: 60'096 Blocks ?(
    Auch bei einer anderen Partition stimmen die Angaben nicht überein, beide Partitionen sind ziemlich gut gefüllt.


    Gruss C=Mac.

  • Bei CMD wohl aus irgendwelchen Systemtabellen, bei mir aus der Dateigrösse des Diskimages.

    Vermute mal, aus der Partition 0 (Systempartition).

    Was wohl sehr wahrscheinlich die von mir erwähnten Adressen im Speicher der HD sein werden ....
    Kann mir nicht wirklich vorstellen, dass da jedesmal auf die Systempartition gewechselt wird um da nachzuschauen.


    Ich ergänze hier mal das Zitat aus der Wheels-Anleitung von C=Mac aus Posting #1:


    Zitat von Wheels-Anleitung

    In diesem Fall solltest Du zur Sicherheit alle Dateien eine andere Diskette kopieren und dann versuchen die Diskette zu validieren um sie zu reparieren. Der Dashboard zeigt keine flasch geschlossenen Dateien an, also kannst du diese auch nicht zur anderen Diskette kopieren wo dasselbe Problem auftauchen könnte.

    Wheels stellt also ein Problem auf der Partition fest! Nach meinen Versuchen gibt es eine Diskrepanz von 28 Blöcken zwischen "Speicher gesamt" und "Speicher frei". Wenn ich von so einer Diskette eine Disk-Kopie erstelle, wundert es zumindest mich nicht, dass die Kopie dann irgendwie fehlerhaft ist (wie C=Mac es mit DraCopy erlebt hat).



    @C=Mac, probiere mal diese Programm:


    http://csdb.dk/release/?id=148151&show=summary


    Nutze zunächst nur das Programm im D64 um eine Kopie einer HD-Partition auf das SD2IEC zu erstellen. Gibt es irgendwelche Unterschiede zwischen dieser Kopie und der Kopie mit DraCopy?
    Dann bitte mal in dem neuen DNP in Wheels alle Dateien löschen. Tritt das gleiche Problem auf mit der Diskrepanz "Speicher gesamt" und "Speicher frei" ?


    @Pusti64, wie werden Deine Partition 17 und 44 (dezimal) unter MP3 oder Wheels angezeigt (Größe)? Irgendwie ist Partiiotn 44 eigentlich zu groß ....


    Gruß
    Werner

  • Nach meinen Versuchen gibt es eine Diskrepanz von 28 Blöcken zwischen "Speicher gesamt" und "Speicher frei".

    Bei mir sind es immer 29 Blöcke bzw. 7 KB :D



    @C=Mac, probiere mal diese Programm:


    csdb.dk/release/?id=148151&show=summary

    Danke für den Tipp.
    Ist am Kopieren, das dauert ;)



    Gibt es irgendwelche Unterschiede zwischen dieser Kopie und der Kopie mit DraCopy?

    Bei DraCopy hab ich eher die Vermutung, das es nicht für Native-Partitionen und/oder SD2IEC geeignet ist.
    CMDREADER erkennt wenigstens schonmal das SD2IEC :D



    Probier mal den Nightly Build von heute.

    Hab ich installiert.
    Auf dem neuen SD2IEC ist ja wirklich ein Bootloader drauf :D
    Mir fällt (noch) kein Unterschied zur letzten Firmware auf.


    Gruss C=Mac.

  • Bei mir sind es immer 29 Blöcke

    - Die Angaben der Speichergrösse/Blöche weicht von einander ab.
    Total Space: 15'088k (60'352 blocks)
    Space free: 15'095k (60'380 blocks)

    Wie kommst Du jetzt auf 29 Blöcke???? 8o
    Wenn ich rechne sind es 28 Blöcke ..... ;-)


    Aber erstmal egal ;-) , wir meinen wohl das selbe. Aber: So lange diese Diskrepanz beteht, würde ich DNP nicht als Backup oder für wichtiges nutzen wollen......


    Gruß
    Werner

  • Wie kommst Du jetzt auf 29 Blöcke????
    Wenn ich rechne sind es 28 Blöcke .....

    Stimmt bei dem DNP-Image sind's 28 Blöcke.
    Ich weiss schon gar nicht mehr welches dies war ^^


    Bei den anderen sind's 29 Blöcke :)


    Spielt wie gesagt keine Rolle.



    Das wird von "REWRITE DOS" und "CREATE SYS" intern verwendet und ist kein eigenständiges Programm.
    Gruß
    Werner

    Ist mir bekannt.


    Die Fragen sind:
    - Ist GEOS/HD V2.00 irgendwie relevant für das Problem?
    - Gibt es eine neuere Version?



    @C=Mac, probiere mal diese Programm:


    csdb.dk/release/?id=148151&show=summary

    Das Programm scheint nicht wirklich entwickelt zu sein :/


    - Stürzt immer mal wieder ab. Dabei ist der Bluescreen doch ein Windows-Phänomen :rolleyes:
    - Ist sehr langsam 16 MB brauchen gut 4 Std. ?(
    - Entstandene DNP-Images sind nicht benutzbar. Weder in Basic noch unter Wheels.
    - Jetzt wird nicht mal mehr die CMD-HD erkannt; "Unknow Device". Wheels erkennt die Partitionen zum Glück noch.


    Ich glaub es ist besser die HD-Partitionen manuell, per File-Copy zu kopieren.
    Auf diese Weise sind die Daten auch auf die HD gekommen.
    Dauert halt länger und ist mit Arbeit verbunden.


    Gruss C=Mac.

  • Hab ein wenig rumexperimentiert :rolleyes:


    Erstelle ich auf der CMD-HD mit HD-Tools eine Native-Partition von 2'048 Blocks Grösse,sind davon nur 1'984 Blocks benutzbar.
    Die fehlenden 64 Blocks werden wahrscheinlich für "Verwaltungszwecke" gebraucht.
    Das selbe bei 4'096 Blocks, siehe Tabelle.



    CMD-HD Blocks Blocks
    HD-Tools 2'048 4'096
    Basic 1'984 4'032
    Wheels Total Space 1'984 4'032
    Wheels Space Free 1'984 4'032


    Es ist immer der gleiche Wert: 64 Blocks; egal ob Basic oder Wheels.



    Bei den DNP-Images sieht die Sache ein wenig anders aus.



    SD-Karte DNP Image Blocks Blocks
    Erstellung 2'048 4'096
    Basic 2'013 4'061
    Wheels Total Space 1'984 4'032
    Wheels Space Free 2'013 4'061


    Der Unterschied zwischen "Erstellung" und Basic/Space Free beträgt nur 35 Blocks, im Gegensatz zu 64 Blocks bei der CMD-HD.


    Bei Total Space wird wieder der gleiche Wert, wie bei der CMD-HD angegeben.


    Der Unterschied zwischen Total Space und Space Free beträgt 29 Blocks.


    Rechne ich die 35 und 29 Blocks zusammen, komme ich auf 64 Blocks und somit auf den gleichen Wert wie bei der CMD-HD.



    In meiner Unwissenheit bin ich jetzt auf folgende Idee gekommen.


    Wheels sieht die "reale" Blockzahl einer Partition (z.B. 2'048 Blocks) und dies egal ob bei einer Native-Partition oder DNP-Image.
    Und zieht einfach immer 64 Blocks davon ab, dieser Wert wird unter Total Space angegeben.


    Bei den freien Blöcke wird entweder "durchgezählt" oder der Wert aus der Partition übernommen.
    Dadurch wird bei einem DNP-Image einen anderer Wert angegeben, welcher sogar höher ist als der Total Space.


    Wieso ein DNP-Image 29 Blöcke mehr als eine Native-Partition hat weis ich nicht.



    Aber wahrscheinlich, spinne ich nur wieder was zusammen ;)


    Gruss C=Mac.

  • Wieso ein DNP-Image 29 Blöcke mehr als eine Native-Partition hat weis ich nicht.


    Weil sd2iec da alle freien Blöcke in der Partition reinrechnet und eine CMD HD wohl die Sektoren 0 bis 63 auf Track 1 auslässt. Das ist auch konsistent mit dem Verhalten der Freie-Block-Berechnung im Drivecode von Wheels und das Verhalten von sd2iec sollte ich im Laufe der Nacht an die Vorlage anpassen.

  • @Unseen
    Besten Dank für die neue Firmware :thnks:


    Konnte leider nur kurz antesten.


    Total Space und Space Free haben jetzt den gleichen Wert, gleich wie auf der CMD-HD. :thumbup:
    Auch ist bei einem leeren DNP-Image kein karierter Füllbalken mehr vorhanden.


    Das einzige was mir aufgefallen ist, bei DNP-Image unter 1 MB (4032 Blocks) Grösse, wird der freie Speicher nicht runtergezählt.
    Speicher ich Daten in so einem Image, bleibt der freie Speicher immer auf dem gleichen Wert.


    Dies ist aus meiner Sicht irrelevant, es werden ja meistens grössere Image verwendet :rolleyes:


    Gruss C=Mac.

  • Das einzige was mir aufgefallen ist, bei DNP-Image unter 1 MB (4032 Blocks) Grösse, wird der freie Speicher nicht runtergezählt.

    Hier auch. Aber Native-Mode fängt bei mir erst ab 1 MB an ;-) . Da kann ich ja andere Formate nehmen .... ;-) .


    Aber:


    Unseen: vielleicht doch noch irgend ein "Käfer" in der Berechnung?


    Gruß
    Werner