Hallo Besucher, der Thread wurde 3,8k mal aufgerufen und enthält 25 Antworten

letzter Beitrag von markusC64 am

WD177x und MFM - 1570 1571 1581

  • Die max track Länge muss angepasst werden, sobald nur ein MFM Track geschrieben wird, bzw. das komplette image einmalig anhand der neuen max länge neu gebaut werden.

    Schon, aber wenn ihr Bit 15 der Pro-Track-Länge als MFM/GCR-Marker baut, dann ist das fast eine Garaantie für einen Bufferoverflow in Nicht-MFM-angepassten Programmen. Die können sich ja darauf beschränken, einen Trackpuffer in der Grosse der MaxLen aus dem globalen Header anzulegen und wenn ein Track mit Bit15=1 als MFM markiert ist wird zwangsweise irgendwann über das Pufferende hinaus gelesen oder geschrieben.

  • Schon, aber wenn ihr Bit 15 der Pro-Track-Länge als MFM/GCR-Marker baut, dann ist das fast eine Garaantie für einen Bufferoverflow in Nicht-MFM-angepassten Programmen

    Richtig, das ist die Gefahr. Deswegen baue ich das derart um, dass Bit 15 nur gesetzt wird + (dekodierten Sektor Daten), wenn Option Ultimate Format ausgewählt ist und natürlich der MFM Track geschrieben wurde.

    Bei der zukünftigen MFM stream Variante schreibe ich Bit 15 nicht, bestenfalls als speedzone 8 ausgewiesen, mal sehen

    Beim Einlesen werte ich dann Bit 15 aus um das Ultimate Format zu erkennen.

  • wird zwangsweise irgendwann über das Pufferende hinaus gelesen oder geschrieben.

    Recht wahrscheinlich: Ja. Zwangsweise: Nein. Denn die Größe kann auch als "signed int16" vom Tool aufgefasst worden sein... da keine Werte größer als 8k bei den betrachteten Floppies vorkommen, gibt es dazu i. d. R. keine Angabe, ob das signed oder unsigned zu sein hat.


    Nun, das ganze G64 Format ist voll von Kompromissen - der wichtigste ist: Einen bestehenden Track zu schreiben ändert nur den lokalen Bereich der Trackdaten. Und zumindest bei der jetzigen G64 Erweiterung (PiCiJi's neue Erweiterung also außen vorgelassen) kann die Größe beim Umformatieren zwischen GCR und MFM beibelassen werden (außer Bit 15, ist klar, oder?), da eigentlich eh die im Header angegebene Größe im Image freigelassen sein muss (macht man das nicht, gibt es Probleme mit derzeitigen Emus). Das sorgt dafür, dass man damit was brauchbares effizient auch auf schwächerer Hardware inpolementieren kann.


    Nun, da die schwächere Hardware abgedeckt ist, braucht eine weitere Erweiterung die nicht mehr abdecken, die schwächere Hardware muss nur einfach erkennen können, dass die das Image nicht mögen will...

  • - Write Precompensation fehlt noch (dient der Langlebigkeit echter Disketten)

    Um Bit Shifting auf den inneren Tracks zu verhindern und somit die Langlebigkeit der Disks zu erhöhen, verwendet der Controller Write Precompensation.

    Hierbei wird der Flusswechsel je nach eingehendem Bitmuster um 128 nano nach recht oder links verschoben.

    Muss man das überhaupt emulieren?


    Ich habe dazu mal etwas recherchiert: Die Write-Compensation dient dazu, den physikalischen Peak-Shift-Effekt auszugleichen. Kurz zusammengefasst sorgt der Effekt dafür, dass die gemessene Position der Flusswechsel nicht der physikalischen Position auf dem Datenträher entspricht. Damit die gemessene Position der entspricht, die man gerne auf den Datenträger haben will, schreibt man leicht anders.


    Nun ist es aber so, dass in einer P64 Datei geschriebene und gelesene Position übereinstimmt. Wenn man dann aus praktischen Gründen annimmt, dass P64 Dateien immer die Position enthalten, die beim Lesen festgestellt würde, so gibt es nichts zu korrigieren beim Schreiben, wenn die Korrektur bei der echten Hardware 100% wäre. Ist die WPcom dagegen nur in etwa passend, so bräuchte es umfangreiche Messungen an original Hardware, um überhaupt die Unterschiede zwischen mit WPcom geschriebenen und anschließend gelesenen Daten festzustellen.


    Kurz: Die kann man so einfach gar nicht emulieren, und braucht es vermutlich auch nicht.


    Literatur: https://books.google.de/books?…20sektor%20aufbau&f=false

  • Muss man das überhaupt emulieren?

    Nein, für die Emulation ist das völlig unwichtig und in keiner Weise sinnvoll nutzbar.

    Eventuell nur interessant, wenn man das P64 auf eine echte Disk zurückschreibt, wobei dann wohl besser das entsprechende Tool diesen Ausgleich beim Schreibvorgang vornehmen sollte.

  • Eventuell nur interessant, wenn man das P64 auf eine echte Disk zurückschreibt, wobei dann wohl besser das entsprechende Tool diesen Ausgleich beim Schreibvorgang vornehmen sollte.

    Davon gehe ich auch aus ("das entsprechende Tool diesen Ausgleich beim Schreibvorgang vornehmen sollte") - denn das selbe Tool wird beim Einlesen ja gespeichert haben, wie die Flux anscheinend liegen und nicht, wie sie wirklich liegen.


    Gut, auch wenn die Emulatoren und Konvertierungstools das nicht brauchen: Es wäre schon mal interessant zu wissen, wie man damals tatsächlich kompensiert hat...