FLUXCOPY: Projekt zum fluxbasierten Kopieren von hard- und softsektorierten Disketten via USB

    Eben! Man muss berücksichtigen, dass zwar beim Schreiben dauernd Strom durch den Kopf fliesst und damit auf dem Band längs entweder einen Nordpol oder einen Südpol hinterlässt; aber beim Lesen nur die Änderung der Magnetisierung einen kurzen Impuls im Kopf induziert. Dieser wird dann vom Laufwerk "verlängert". Deshalb ist bei der Schnittstelle am Laufwerk die negative Flanke der Zeitpunkt, bei dem sich die Magnetisierung geändert hat.


    Die Impulslänge ist rein vom Laufwerk bestimmt und eigentlich irrelevant.

    Servus zusammen,

    Hab heute mal mit hardsektorierten 8" AES-Disketten (32 Sektoren) experimentiert , welche ich von Martin Hepperle erhalten habe (Der genaue Systemtyp ist wohl unbekannt).


    Musste dabei erstmal feststellen, dass mein NEC Laufwerk (welches ich normalerweise für Diskimages hernehme) keine hartsektorierten Disketten verarbeiten kann. Der /Index Impuls wird verlängert, daher wird der Impuls des unregelmäßigen Lochs "übersprungen", FLUXCOPY meldet dass kein Index Signal vorliegt.


    Nach Verkabelung und Versuchsaufbau mit einem meiner "fetten" Laufwerke hat das Lesen der Diskette ohne Fehlermeldung funktioniert. Die Indeximpulse werden nun plausibel durchgereicht.

    Ob sich die Diskette allerdings reproduzieren lässt oder das Image brauchbar ist, bleibt erstmal unklar, da ja das passende System nicht vorhanden ist.


    Lt. 2 unterschiedlichen Quellen liegt bei 8" AES Disketten eine M2FM (MMFM)

    Codierung vor.


    PAW, vielleicht magst Du Dir bei Gelegenheit das Image mal ansehen.

    Da FLUXCOPY ja primär für hardsektorierte Formate geschaffen wurde, wäre die Unterstützung von hardsektorierten 8" Formaten ja evtl. eine Bereicherung.


    Grüße, Chris

    Hier noch mal ein Status zu dem Synchronisationsproblem mit meinen Wang-Disketten:


    Zunächst: Wie oben schon geschrieben wurde, sollten bei FM nur Flusswechsel im Abstand von 4us und 8us auftreten. Weiterhin sollten die kurzen Abstände immer nur im Päärchen auftreten. Jede Abweichung davon ist ein Fehler.


    Auf den Disketten finden sich solche Fehler zunächst im Umfeld der Indexlöcher, dort also, wo beim Formatieren mit dem Schreiben angefangen wird und dabei irgendwelche Reste von früheren Aufzeichnungen überschrieben werden. Die nächste Fehlerhäufung findet sich nach den abschließenden CRC-Bytes - dort also, wo mit dem Schreiben aufgehört wird und Reste von früheren Aufzeichnungen beginnen.


    Bei den Nutzdaten zwischendurch gibt es keinerlei Fehlstellen - mit Ausnahme der Fehler im zweiten Synchronisationsteil. Die ersten 160 Synchronbits sind fehlerfrei, bei der zweiten Gruppe kommt ziemlich regelmäßig eine kurze Sequenz mit Fehlern etwa ab dem 120. Bit.


    Der Witz dabei ist: Je intensiver die Diskette nach dem Formatieren genutzt (beschrieben) wurde, desto wahrscheinlicher sind diese Fehler und auch die Länge des Fehlerbereichs nimmt zu. Ein Sektor, der nach dem Formatieren nie mehr beschrieben wurde, ist dagegen völlig fehlerfrei.


    Meine Schlussfolgerung: Beim Schreiben eines Sektors muss der Diskettencontroller zunächst die Daten lesen, die gerade den Lesekopf passieren, um mitzubekommen, wann der richtige Sektor erreicht ist. Der erste Synchronblock (166 x Null, dann 2 Einsen) hilft ihm dabei, den Anfang der für ihn relevanten Information (Tracknummer und Sektornummer) zu finden.

    Um die Nutzdaten zu schreiben muss dann auf Schreiben umgeschaltet werden, und das geht offenbar nicht schnell genug, um im bestehenden Rhythmus weiter zu schreiben. Es besteht also immer die Gefahr, am Beginn der Nutzdaten einen Fehler von ein paar Mikrosekunden zu erzeugen, der dann beim Lesen Schwierigkeiten macht.

    Also erfolgt die Umschaltung früher - d.h. während des zweiten Synchronblocks, nach ca. 120 Bits oder einer knappen Millisekunde. Er schreibt dann noch 7 Null-Bytes (=56 Bits) und das Synchronbyte (3) neu und kann dann ohne Unterbrechung die Nutzdaten schreiben.


    Ein weiteres Indiz für dieses Szenario ist die Datenlänge des zweiten Synchronblocks: : Ein frisch formatierter Sektor enthält dort 165 Nullbits vor dem Synchronbyte (woher die 5 zusätzlichen Bits kommen kann ich bisher nicht erklären - es sollten eigentlich 20x8=160 sein).

    Bei einem beschriebenen Sektor kommen zunächst 120 Nullbits, dann ein paar Mikrosekunden "Störsignale", dann weitere 56 Nullbits und das Synchronbyte. Macht 176+X Bits - ein Beweis, dass beim Schreiben dieser zweite Synchronblock zumindest in Teilen neu geschrieben wird.


    Was mich jetzt interessiert: Macht ein normaler FDC das genauso, oder kann der "übergangslos" von Lesen auf Schreiben umschalten, d.h. dabei den bisher gelesenen Takt halten? Bei der Wang wird das ja alles in Software (plus ein paar Monoflops) erledigt - da gibt es eben die Störungen beim Umschalten.


    Für das Lesen der Disketten gilt nun einfach: Beim zweiten Synchronblock mindestens (120 * 8 + X) Mikrosekunden = ca. 1ms warten, bevor auf die beiden Eins-Bits zum Synchronisieren gewartet wird.

    • Offizieller Beitrag
    Zitat von Georg

    Meine Schlussfolgerung: Beim Schreiben eines Sektors muss der Diskettencontroller zunächst die Daten lesen, die gerade den Lesekopf passieren, um mitzubekommen, wann der richtige Sektor erreicht ist.

    Wir reden hier von hardsektor Disketten, also kann man den Sektor abzaehlen ohne zu lesen.

    Beim NorthStar ist es so beschrieben:

    Sektorregister lesen bis richtiger Sektor erreicht ist

    ~50us warten

    Schreiben der Preambel (eine Anzahl 0x00) und Sync-Byte(s)

    Schreiben der DatenBytes

    Schreiben der Checksum

    Schreiben einer Postambel weiss ich nicht mehr genau


    Der NorthStar schreibt keine Spur- und/oder Sektornummer, wofuer auch.



    Zitat von Georg

    Was mich jetzt interessiert: Macht ein normaler FDC das genauso, oder kann der "übergangslos" von Lesen auf Schreiben umschalten

    Ja, macht er. Aber zwischen dem Bereich mit Spur-/Sektornummer und dessen CRC und dem Datenbereich gibt's einen Gap. Daher haben softsektor FDCs genug Zeit. Abgesehen davon machen die das ueber eine Statemachine und nicht in Software, sind also deutlich schneller.


    Nachtrag:

    Musste ich gerade nachschauen.


    (aus 179x Datasheet)


    Du hast pro Sektor ein ID Field und ein Data Field, jeweils mit Gaps getrennt.

    Zusaetzlich sind beide mit einem spezifischen Adressmarker (AM) gekennzeichnet. Diese Marker sind eindeutige Bitfolgen, die eigentlich Fehler im FM / MFM Datenstrom enthalten und deshalb nur hier vorkommen.

    So lassen sich die Bereiche immer eindeutig finden.


    Viel Spass

    Zitat von Georg

    Meine Schlussfolgerung: Beim Schreiben eines Sektors muss der Diskettencontroller zunächst die Daten lesen, die gerade den Lesekopf passieren, um mitzubekommen, wann der richtige Sektor erreicht ist. Der erste Synchronblock (166 x Null, dann 2 Einsen) hilft ihm dabei, den Anfang der für ihn relevanten Information (Tracknummer und Sektornummer) zu finden.

    Um die Nutzdaten zu schreiben muss dann auf Schreiben umgeschaltet werden, und das geht offenbar nicht schnell genug, um im bestehenden Rhythmus weiter zu schreiben. Es besteht also immer die Gefahr, am Beginn der Nutzdaten einen Fehler von ein paar Mikrosekunden zu erzeugen, der dann beim Lesen Schwierigkeiten macht.

    Also erfolgt die Umschaltung früher - d.h. während des zweiten Synchronblocks, nach ca. 120 Bits oder einer knappen Millisekunde. Er schreibt dann noch 7 Null-Bytes (=56 Bits) und das Synchronbyte (3) neu und kann dann ohne Unterbrechung die Nutzdaten schreiben.

    Hallo Georg,

    das deckt sich auch mit meinen Erfahrungen. Es ist ja auch ein sehr großer Gap zwischen Sektorheader und Sektordaten. Daher stört es nicht, wenn dort fehlerhafte Fluxwechsel auftreten. Bei den Softsektor-Formaten sind die Gaps kürzer, das Problem ist aber das gleiche. es muss irgendwo mit dem Schreiben begonnen und auch wieder aufgehört werden. Dort entsteht immer Schrott, der aber nicht weiter stört.


    Ein direktes "Anstückeln" an die schon vorhandenen Daten ist meines Erachtens nicht möglich und auch nicht nötig.


    Zitat von mister-freeze

    Lt. 2 unterschiedlichen Quellen liegt bei 8" AES Disketten eine M2FM (MMFM)

    Codierung vor.


    PAW, vielleicht magst Du Dir bei Gelegenheit das Image mal ansehen.

    Da FLUXCOPY ja primär für hardsektorierte Formate geschaffen wurde, wäre die Unterstützung von hardsektorierten 8" Formaten ja evtl. eine Bereicherung.

    Hallo Chris,

    ist sicher interessant! Kannst mir ja schon mal das Image senden.

    Weiß nur noch nicht, wann ich Zeit dazu habe, mich näher damit zu befassen.

    M2FM habe ich noch nie dekodiert. Braucht angeblich auch eine Write Precompensation.

    Aber vielleicht stimmt die Information nicht und es ist nur FM, wie bei den 5.25".


    Was du aber schon versuchen kannst, ist eine Kopie mit FLUXCOPY erstellen und diese Kopie wieder einlesen. Dann könnte man die beiden Images vergleichen.


    Schönen Abend!


    PAW

    Bei Softsektorierten Disketten ist - wie schon beschrieben - ein zweites Gap zwischen Sektorkennung und den eigentlichen Nutzdaten.


    Die Sektorkennung wird nur beim Formatieren geschrieben.


    Beim normalen Schreiben eines Sektors findet die Umschaltung auf Schreiben in eben diesem Gap statt.


    Ein bitgenaues Umschalten auf Schreiben ist nicht nötig. Ich wüsste auch nicht, wie das rein physikalisch gehen sollte.

    Ich habe auch gedacht, dass man ja die Indexlöcher zählen kann - das tut die Wang aber wohl nicht. Das sagt einerseits die Doku, andererseits gibt es nicht so etwas wie ein Sektorregister (das die Sektoren zählt).

    Der Controller muss per Software Track und Sektor prüfen; deshalb dauert es hier auch deutlich länger bis er mit dem Schreiben anfängt. Möglicherweise gibt er in der Zeit sogar noch eine Rückmeldung an die CPU - da müsste ich das Protokoll noch mal prüfen.


    Was die Gaps bei den integrierten FDC angeht: leider fehlt auf @funkenzupfer's Ausschnitt deren Aufbau, und die Datenblätter, die ich jetzt auf die Schnelle gefunden habe sind da von schlechter Qualität. Aber diese Gaps scheinen ähnlich aufgebaut zu sein wie das, was ich bei mir als Synchronisationsblock bezeichne: Eine Reihe gleichartiger Bits, gefolgt von eindeutigen Synchronbytes. Und die Umschaltung von lesen auf Schreiben sowie das Abschalten des Schreibens erfolgt jeweils innerhalb dieser Gaps. Ein Teil des Gaps und insbesondere die Synchronisationsbytes vor dem Datenblock werden also bei jedem Schreibvorgang neu geschrieben.

    • Offizieller Beitrag

    Den Ausschnitt findest du in fast allen WD 179x Dokus. Und ich wollte den Post nicht mit unzähligen Bildern sprengen.

    Die Gaps sind einfach x Bytes mit "bekanntem" Wert.

    Die AdressMarks sind nicht einfache Sync-Bytes. Die AdressMarks sind Flux-Wechsel, die im normalen Datenstrom nicht vorkommen.


    Ich weiss nicht, ob ich was übersehen habe, aber erklärst du mal den Track-/Sector-Aufbau bei der Wang.


    Wenn die Wang nicht die Sektorlöcher zählt sondern sich auf die Sektorheader verläßt, wie wird dann der Track formatiert? Mit Software, die die Daten für den ganzen Track schreibt? Wie wird hier der Hardsector Anfang erkannt?


    Echt spannend!



    Nachtrag:

    Hier ein lesbares Datasheet:

    http://www.proteus-internation…rn%20Digital%20FD1791.pdf

    Zitat von funkenzupfer

    Wenn die Wang nicht die Sektorlöcher zählt sondern sich auf die Sektorheader verläßt, wie wird dann der Track formatiert? Mit Software, die die Daten für den ganzen Track schreibt? Wie wird hier der Hardsector Anfang erkannt?

    Ich nehme an, dass die Wang beim Formatieren sehr wohl die Sektoren mitzählt. Den ganzen Track auf einmal Schreiben ist nur bedingt möglich. Es muss bei jedem Sektorloch nachsynchronisiert werden, da ja die Drehzahl nicht 100% mit dem Datenstrom des FDC übereinstimmt. Die Wang zählt die Sektoren offensichtlich nicht mit Hardware sondern mit Software. Sobald die Diskette formatiert ist, stehen beide Wege offen: Mitzählen der Sektoren per Software oder Lesen des Sektorheaders.

    Hier die Info zum Gap beim FD179x:

    Explizit steht dort, dass die Umschaltung auf Schreiben in diesem Gap nach 11 Bytes (ich bleibe bei FM) erfolgt.

    Auf der nächsten Seite ist beschrieben, dass dieses Gap2 aus 11 mal 0xFF und 6 mal 0x00 besteht. Dieses A1 mit "missing clock transition between bits 4 and 5" (ich nehme an, dass sind die "exotischen" AddressMarks von funkenzupfer) gibt es bei FM nicht.


    Von daher würde ich erwarten, dass auch hier in dem Gap2 beim Umschalten von lesen auf Schreiben ungültige oder falsche Bits entstehen. Damit die beim späteren Lesen keine Probleme machen und man den Byte-Anfang sauber identifizieren kann hätte ich allerdings erwartet, dass die Umschaltung innerhalb der ersten 11 Bytes erfolgt, so dass man den Wechsel von FF zu 00 zur Synchronisierung verwenden kann. Ich werde mir mal ein FM formatierte Softsektor Diskette mit Fluxcopy ansehen müssen...


    Zurück zur Wang: beim Formatieren wird jeweils ein Sektor geschrieben. Track- und Sektor-Index werden afaik per Hardware separiert und liefern eigene Signale. Der Track Index startet die Formatierung des Tracks. Das Schreiben der einzelnen Sektoren wird jeweils mit dem Sektorindexpuls gestartet. Die Sektornummer wird dabei per Software hochgezählt.

    Der Aufbau des Sektors wurde bereits oben beschrieben:


    20 x 00, 03, track, sector, 20 x 00, 03, 256 x Daten, crc1, crc2


    Zwischen den Sektoren gibt es nichts, jedenfalls nichts Sinnvolles. Ist anders als bei Soft Sektor hier nicht nötig, weil der Sektorindex sowohl beim Formatieren als auch beim Lesen den Startschuss gibt.


    Und beim Schreiben werden definitiv die Track /Sektor gelesen und geprüft. Jedenfalls steht es so in der Doku (Punkt 16 und 17, ich hoffe, dass man es lesen kann)

    Der Wechsel FF zu 00 dient nicht der Synchronisation.

    Die Synchronisation auf Bitebene geschieht über die vielen 00 bis dann eben dieses "A1" auftaucht, was dann erst zur Bytesynchronisation führt.

    Dieses "A1" gibt es bei FM aber nicht, wenn ich die Grafik oben und auch die Tabellen im Datenblatt richtig verstehe.


    Allerdings habe ich eben gesehen, dass nach dem Gap2 noch ein 0xFB (Data Address Mark) kommt - das wird allerdings als Bestandteil des Datenblocks aufgeführt, und taucht deshalb beim Gap nicht auf. Damit könnte m.E. dann die Synchronisation erfolgen.


    Btw: Dieses ominöse A1 bei MFM ist mir auch nicht ganz klar: Ist das eine Bezeichnung, oder ein Wert? In der Grafik sieht es eher wie Bezeichnung aus (wie "GAP 2") zusammen mit dem Hinweis, dass zwischen Bit 4 und 5 ein Takt ausgelassen wird (wie auch immer das aussieht; mit MFM habe ich mich jetzt noch nicht beschäftigt). In den Tabellen tauchen beim IBM-Format an der Stelle drei 0xF5 auf, bei den Non-IBM-Formaten liest sich das so, als wenn da drei mal 0xA1 geschrieben werden.

    Es ist lange her, dass ich mit diesen WDx7xx Kontroller "per Du" war. Beim Formatieren (FM und MFM) hat man auf jeden Fall den gesamten Trackaufbau anliefern müssen,


    eine gute Beschreibung habe ich soeben unter

    https://hansotten.file-hunter.com/technical-info/wd1793/

    gefunden!


    Ich glaube diese klärt das nun auf.


    Für die WANG ist das aber doch nicht wirklich relevant.

    Zitat von Reinhard

    Für die WANG ist das aber doch nicht wirklich relevant.

    Das ist wohl wahr, zumal auf der von Dir zitierten Seite auch nur das MFM-Format beschrieben wird. Zumindest habe ich jetzt eine Ahnung, woher diese Differenz F5/A1 kommt: Beim Formatieren werden spezielle Zeichen (0xF5, 0xF6 und 0xF7) vom Controller uminterpretiert - auf der Diskette erscheinen dann die spezielen Markierungen mit fehlenden Takten oder es werden die CRC-Werte geschrieben.


    Tatsächlich ging es mir aber auch nur um die Frage, ob diese "Störungen", die beim Aktivieren des Write Gates entstehen, auch bei den integrierten FDCs entstehen, und ob auch dort beim Schreiben eines Sektors die notwendigen Synchronisationsbytes jeweils neu geschrieben werden.


    Bevor ich diese Problematik bei der Wang-Diskette erstmals im Detail gesehen habe, bin ich recht blauäugig davon ausgegangen, dass beim Schreiben eines Sektors nur die 256 (bzw. 128/512/1024) Datenbytes (plus die neuen CRC-Werte) geschrieben werden. Aus Sicht des Programmierers werden auch tatsächlich nur die Datenbytes angeliefert; tatsächlich schreibt der Controller aber neben den CRC-Bytes auch einiges im Vorfeld der Nutzdaten auf die Diskette, um die Synchronisation beim späteren Lesen zu ermöglichen.

    So, heute habe ich es endlich geschafft, meinen FLUXTEEN fertig zustellen. Anschließend habe ich mich durch den kompletten Thread gelesen; hat ein wenig gedauert, bis ich die Begriffe FLUXCOPY, FLUXTEEN, FLUXDUMP, USB-Serial Monitor und somit die einzelnen Programme richtig zuordnen konnte.


    Anschließend den FLUXTEEN an meine Kryoflux/Greaseweazle Teststation angeschlossen; in diesem Fall mein TEAC FD-55BV-06. Eine normale 360KB DSDD Diskette eingelegt und ... ruckzuck waren die 40 Tracks eingelesen und abgespeichert. Zu mehr bin ich aber heute nicht mehr gekommen.


    Chapeau PAW



    Abschließend mit FLUXDUMP alle Tracks in ASCII konvertiert und den Track 0, Sektor 1 (Bootsektor) mit dem Texteditor angesehen; sieht TOP aus.

    Einmal editiert, zuletzt von haglebu ()

    Gefällt mir 3
    • Offizieller Beitrag
    Zitat von Georg

    20 x 00, 03, track, sector, 20 x 00, 03, 256 x Daten, crc1, crc2

    Das sieht der Softsector Aufzeichnung doch sehr ähnlich.

    Und mit den 20 x Null-Bytes nach dem Sector bleibt eigentlich genug Zeit zum umschalten von lesen nach schreiben.

    TEST 1:


    Leider habe ich keine "hardsectored" Hardware, daher nur "softsectored" 360KB und MFM. Erstellt habe ich meine (bulk erased) Testdiskette mit Imagedisk/IMD (9 sec/trk, 512 byte/trk, 250 kbps, MFM, 40 tracks, FORMAT FILL „D1". Die so erstellte Diskette habe ich gespeichert und anschließend auf eine neue Diskette zurückgeschrieben; FLUXCOPY V0.9.


    Beide Disketten habe ich anschließend mit dem Programm TE und dem Deluxe Option Board (https://retrocmp.de/hardware/optionboard/dob.htm) eingelesen (nur den ersten halben Sektor, 256 Byte) und jeweils eine Harddcopy gemacht, siehe Bild und Anlage FLUX1.pdf. Der einzige Unterschied besteht in dem allerersten Byte.



    forum.classic-computing.de/index.php?attachment/106916/

    TEST 2:


    Wie zuvor berichtet habe ich mit 360KB Disketten und MFM keine Probleme. Aber mit QD Floppies (MFM, DS, 80 Spuren) habe ich meine Schwierigkeiten.


    Die Testdiskette habe ich mit der Compaticard IV im Modus /800 erstellt. Dies ist ein eigenes CC4 Format: 800KB, 5,25", 80 Spuren, beidseitig, MFM, 10 Sektoren/Spur und 512 Bytes/Sektor. Hierzu habe ich mein YE-DATA YD480 verwendet; dies ist ein reines QD Laufwerk mit 300 RPM und 250 kbps. Lesen und schreiben unter DOS (mit CC4) geht ohne Probleme.


    Und so sieht die Fehlermeldung aus:



    Meine Frage PAW : Mache ich hier etwas grundsätzlich falsch? Ich verwende mit FLUXTEEN ein modifiziertes Mitsubishi M4855. Dies kann nur 300 RPM, 250 kbps mit 2x80 Spuren. Mit meinem TEAC FD55F-30, also ein reinrassiges QD Laufwerk, funktioniert es aber ebenfalls nicht. Die Fehlermeldung ist die gleiche.

    Zitat von haglebu

    Meine Frage PAW : Mache ich hier etwas grundsätzlich falsch? Ich verwende mit FLUXTEEN ein modifiziertes Mitsubishi M4855. Dies kann nur 300 RPM, 250 kbps mit 2x80 Spuren. Mit meinem TEAC FD55F-30, also ein reinrassiges QD Laufwerk, funktioniert es aber ebenfalls nicht. Die Fehlermeldung ist die gleiche.


    Die Meldung "Time out on waiting for index hole!" kommt, wenn FLUXTEEN nicht innerhalb einer bestimmten Zeit ein Indexloch erkennt (Signal von Diskettenlaufwerk). Passiert mir meistens, wenn ich das falsche Laufwerk selektiert habe (also z.B. Laufwerk 1 statt 2), oder wenn keine Diskette im Laufwerk liegt.


    Ob 300 oder 360RPM ist egal. FLUXCOPY erkennt selbst die Drehzahl (anhand des Zeitraumes zwischen 2 Indexlöchern) und passt sich entsprechend an.


    Schönen Abend!


    PAW

    Zu TEST 2:


    1) Ich habe nochmals eine neue Testdiskette mit Imagedisk (IMD) erstellt. Da ich nur über ein TEAC FD-55GFR (360 RPM) in meinem Testrechner verfüge, habe ich die Formatierung "anpassen" müssen. Da die Diskette ja eine QD mit 2x80 Tracks, MFM, 250 kbps, 300 RPM werden soll, habe ich die Formatierung mit 300 kbps durchgeführt, da das FD-55GFR ja 360 RPM hat; 360 RPM / 300 kbps == 300 RPM / 250 kbps. Als FORMAT FILL habe ich "F2" verwendet.


    Diese so erstellte Diskette habe ich mit dem TE und dem DOB in meinem FD-55BR eingelesen; und zwar nur Spur 0! Das funktioniert obwohl der Lesekopf eigentlich zu breit ist; daher nur Spur 0 lesen und anschauen, mehr nicht. Das Ergebnis war gut. Das INDEX FIELD, ID FIELD UND DATA FIELD konnten eindeutig identifiziert werden; der FORMAT FILLER "F2" war ebenfalls exakt zu erkennen.


    Dann habe ich die Diskette unter Windows 10 / Greaseweazle mit meiner Floppy Teststation eingelesen. Diese Teststation besteht immer aus zwei Diskettenlaufwerken mit einen gekreuzten Kabel; Laufwerk A nach dem Dreher und Laufwerk B vor dem Dreher; beide Laufwerke auf das 2. Laufwerk gejumpert; wie man das halt unter DOS gewohnt ist. Die Testdiskette konnte mit dem Greaseweazle an Laufwerk A: (Mitsubishi "MOD" M4855) einwandfrei gelesen werden, siehe die nachfolgenden Screenshots.




    Soweit so gut!


    2) Statt des Greaseweazle habe ich jetzt das FLUXTEEN an die Floppy-Teststation angeschlossen; ich habe keine Änderungen vorgenommen; Kabel und Jumper alles exakt wie zuvor.


    Ergebnis: wie zuvor, sie Screenshot #199. Durch den HEADLOAD „höre“ ich aber, das FLUXTEEN zugreifen will und auch kann, die Diskette dreht sich auch kurz, aber dann die o.g. Fehlermeldung.


    3) Jetzt habe ich das Laufwerk A: komplett entkoppelt, d.h. ein Kabel ohne Dreher verwendet und auf das 1. Laufwerk gejumpert. Und sie da ... es funktioniert. Die 5.25" QD Diskette, 2x80 Tracks wird ohne Fehler gelesen. Anschließend habe ich wieder FLUXDUMP verwendet, es gab keine Fehlermeldungen und der FORMAT FILLER "F2" taucht wie erwartet in jeden Datensektor auf, siehe den nachfolgenden Quellcode.



    4) Fazit und Frage an PAW :


    Mein Floppy Testaufbau - zwei Laufwerke mit gekreuztem Kabel - funktionieren unter Kryoflux und Greaseweazle einwandfrei, s. oben unter 1). Kann es sein, das beim FLUXTEEN hier ein interner Fehler vorliegt?


    Sonst kann nur wieder sagen: Tolle Leistung an das Team!

    Achtung: das "verzwirbelte" Kabel beim PC macht aus dem "MOTOR ON" welches gemeinsam für alle Laufwerke wäre, einzelne "MOTOR ON"s pro Laufwerk.

    Der PC Kontroller kann dadurch die Laufwerke einzeln anlaufen lassen. Historisch bedingt wegen der Stromaufnahme...

    Zitat von Reinhard

    Achtung: das "verzwirbelte" Kabel beim PC macht aus dem "MOTOR ON" welches gemeinsam für alle Laufwerke wäre, einzelne "MOTOR ON"s pro Laufwerk.

    Der PC Kontroller kann dadurch die Laufwerke einzeln anlaufen lassen. Historisch bedingt wegen der Stromaufnahme...

    Der "Fehler" liegt im Kabel. Ich habe gerade mal ein uraltes DAISY-CHAIN Kabel (ca. 3 m lang) verwendet und Laufwerk A: auf (1) und Laufwerk B: auf (2) gejumpert und ... siehe da es funktioniert!


    :)

    • Offizieller Beitrag

    Da hat man sich dann halt dazu entschieden, diesen vermurksten Bus zu verwenden, mit dem man nur zwei Laufwerke adressieren kann.

    Deswegen habe ich zu meinem Kryoflux extra eine kleine Schaltung mit einem Zähler gebaut, mit dem ich per Taster zwischen den vier angeschlossenen Laufwerken umschalten kann.

    Zitat von haglebu

    Frage an PAW : Was bedeuten die "17" und die Parameter: S, 300, 298,7625, 0,0054 und 0, siehe Screenshot. Danke!


    Im Feld "17" werden die Anzahl der übertragenen Datenblöcke vom FLUXTEEN zum FLUXCOPY hochgezählt. Ist nur reine Information, z.B. falls die Übertragung stockt, sieht man das. FLUXTEEN liest ja den kompletten Track mehrmals (abhängig von den "Num of Retries") ein. Danach werden die Daten zum PC blockweise übertragen.



    Zu Beginn wird die Drehzahl geprüft. Dabei werden ein paar Umdrehungen abgewartet. Danach werden die Parameter berechnet und angezeigt.


    "Parameters:" ist ebenfalls zur Information und zeigt folgendes an:


    Bei Soft Sektor Disk:


    _____"S", Drehzahl (nominal), genaue Drehzahl, max. Drehzahlabweichung, 0


    Bei Hard Sektor Disk:


    _____"H", Drehzahl (nominal), genaue Drehzahl, max. Drehzahlabweichung, Anzahl Hard Sektoren



    Drehzahlen werden in RPM angegeben. Max. Drehzahlabweichung ... maximale Abweichung (Absolutwert) zu einem davor liegenden Umlauf: (RPM - RPMexact) / RPM


    Anmerkung: Für FLUXCOPY ist nicht die absolute Drehzahl interessant, sondern die Abweichungen von Umlauf zu Umlauf. FLUXCOPY passt sich immer an die zuletzt gelesene Drehzahl an.

    Gruß


    PAW

    Besten Dank für die Info.


    Ich habe gerade auch noch mal die Konvertierung FLUXKRYOCONV: RAW Kryoflux zu FLX FLUXTEEN getestet. Wobei ich die RAW Dateien nicht mit Kryoflux sondern mit Greaseweazle erzeugt habe. Anschließend wieder mit FLUXDUMP konvertiert. Das Ergebnis sieht "augenscheinlich" wieder gut aus.


    --Thomas

    Bei mir gibt es auch etwas Neues.


    Ich habe vor Ewigkeiten von Toast_r einen Haufen hartsektorierte 5,25" Disketten für meine Wang übernommen, aber die meisten bisher nicht genutzt.

    Gestern habe ich mir vier rausgepickt, die mit verschiedenen Labeln beschriftet waren:

    * Nascom

    * Eigenbau

    * Horizon

    * MC/CPM


    Auslesen mit Fluxcopy hat zunächst bei allen gut funktioniert. Ich habe mich dann erst mal auf die "Horizon" gestürzt, weil die offensichtlich von einem Northstar Horizon stammt, der relativ gut dokumentiert ist (hat ja auch funkenzupfer weiter oben schon erwähnt).

    Im Gegensatz zu den Wang-Disketten sind die Daten hier MFM kodiert, was eine ganze Ecke aufwendiger in der Dekodierung und Synchronisierung ist. Inzwischen habe ich es aber hinbekommen und kann bereits halbwegs sinnvolle Inhalte lesen:



    Ich muss allerdings deutlich später mit dem Synchronisieren anfangen, als es in der Beschreibung steht; dort ist die Rede von 96us, nachdem das Indexloch erkannt wurde - ich muss mindestens 400us warten, bevor die erwarteten Bitmuster (20 * 0x00, 2 x 0xFB) zum Synchronisieren auftauchen.


    Beflügelt von dem Erfolg habe ich mein Programm dann auch auf die anderen Images losgelassen. Das klappt aber nur halbwegs. Die mit "MC CP/M" beschriftete Diskette geht überraschend gut - aber nach einem Textfragment zu urteilen sind da auch nur Horizon-Daten drauf.

    Beim Nascom musste ich die Sync-Verzögerung fast auf 1ms setzen, um den Sektoranfang eindeutig finden zu können. Bisher habe ich da aber nur ein paar Textfragmente und Andeutungen eines Monitors gefunden. Allerdings habe ich noch nicht sehr viel angeschaut; meine Programme sind noch recht unkomfortabel ;) Vielleicht hat der auch ein ganz anderes Sektorformat, und was ich gesehen habe war nur Zufall.

    Erstaunlicherweise stimmt aber auffällig häufig die Checksumme - nur leider nicht immer. Muss ich alles mal genauer prüfen.


    Mit dem "Eigenbau" stehe ich noch ganz am Anfang. Bei einem schnellen Dump erkennt man ein paar Textfetzen, aber das kann Zufall sein. Ich bin noch nicht sicher, ob die Sektorstruktur überhaupt ähnlich zum Horizon ist.


    Es gibt also noch eine Menge zu tun ...

    Trotzdem immer wieder großes Lob an PAW für ein gelungenes Werkzeug!

    Inzwischen bin ich sicher, dass es sich doch alles um Disketten für den Northstar Horizon handelt.

    Nachdem ich mein Programm noch etwas "gehärtet" und ein paar Stellschrauben optimiert habe kann ich fast alles lesen. Gut erkennbar ist das immer an der ersten Spur - bei meinen vorigen Tests hatte ich mehr oder weniger wahllos auch schon mal Spur 1 oder 2 angesehen. Zusammen mit einigen Lesefehlern (die offensichtlich auch dabei sind) hatte ich das zunächst nicht erkannt (und mich auch von den Beschriftungen etwas verführen lassen).


    Wegen der Lesefehler muss ich mal prüfen, ob das ein Problem der Disketten ist oder ob mein MFM-Dekoder noch etwas getuned werden muss. Auf einer Diskette sind eine Reihe Spiele mit vielen Texten; ich habe den Eindruck, dass man dort den einen oder anderen Fehler bitgenau identifizieren kann.


    Noch ein paar Informationen zum Diskettenformat:


    10 Sektoren á 512 Byte

    Einseitig, 35 Spuren

    MFM-Kodierung

    Ein Prüfbyte im Anschluss an jeden Sektor (nur XOR und Rotation)


    PAW: Wenn Du das Format implementieren möchtest, kann ich Dir gerne ein Image und weitere Informationen zum Aufbau und Prüfalgorithmus zukommen lassen. Ich weiß allerdings nicht, ob das wirklich Sinn hat - ich kenne keinen Besitzer eines solchen Rechners, und da das DOS offenbar auch etwas Spezielles ist, wird es wohl auch wenig Sinn haben, wenn man versucht, die einzelnen Programme zu isolieren.