WD177x und MFM - 1570 1571 1581

Quote from PiCiJi

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.

Quote from Unseen

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...

Quote from PiCiJi

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

Quote from PiCiJi

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

Quote from PiCiJi

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...