aber vielleicht organisiert Ihr da auch einfach eine lokale Einkaufsgemeinschaft?
Reichelt-Einkaufsliste (ohne Gewähr) :
FLUXCOPY: Projekt zum fluxbasierten Kopieren von hard- und softsektorierten Disketten via USB
-
-
Hier ein neuer Zwischenstand zu meinen hartsektorierten 5,25" Wang-Disketten.
Ich habe das Format inzwischen verifiziert: Die Daten werden mit FM kodiert, pro Sektor werden folgende Informationen geschrieben:
20 x 0x00h
0x03h
Tracknummer
Sektornummer
20 x 0x00h
0x03h
256 Byte Nutzdaten
2 Byte CRC
Physikalisch liegen die 10 Sektoren sequentiell auf der Diskette, d.h. in den Headern finden wir der Reihe nach die Sektornummern 0, 1, 2,.. 9.
Der Inhalt wird dagegen offenbar versetzt geschrieben:
Code
Alles anzeigenPysikalisch Logisch 0 0 1 7 2 4 3 1 4 8 5 5 6 2 7 9 8 6 9 3Nach dem abschließenden CRC und vor dem nächsten Sektorheader (d.h. im Bereich der Sektorindexlöcher) liest FLUXTEEN irgendwelchen Mist, den man getrost ignorieren kann. Teilweise habe ich auch Fehler in den Synchronbytes (die zwei mal 20 Nullbytes im Header) gefunden. Ob die beim Lesen Probleme machen oder ob der Floppycontroller einfach nur auf das nachfolgende 0x03h wartet muss ich noch testen.
Ein Knackpunkt auf dem Weg, Disketten zu erstellen dürfte noch der CRC werden. Der wird im Controller per Hardware mit einer Kombination von Schieberegister und Flip-Flops mit diversen Rückkopplungen erzeugt, und da fehlt mir die Durchblick, um daraus den Algorithmus zu bestimmen.
Davon abgesehen bin ich mit den Ergebnissen bereits sehr zufrieden. Schönes Projekt!
-
Zitat von Georg
Ein Knackpunkt auf dem Weg, Disketten zu erstellen dürfte noch der CRC werden. Der wird im Controller per Hardware mit einer Kombination von Schieberegister und Flip-Flops mit diversen Rückkopplungen erzeugt, und da fehlt mir die Durchblick, um daraus den Algorithmus zu bestimmen.
Da hast du ja schon umfangreiche Erkenntnisse bei der Datenanalyse vorgelegt! Super!
Mit dem CRC hast du natürlich recht.
Frage: woher weißt du dass es ein CRC sein soll und keine einfachen Checksummen. War das irgendwo zu lesen, oder ist das nur eine Annahme von dir?
Frage: hast du einen Schaltplan vom Floppycontroller mit den Schieberegistern. Wäre vielleicht hilfreich für mich bei der Suche nach dem CRC.
Grüße, PAW
-
Frage: woher weißt du dass es ein CRC sein soll und keine einfachen Checksummen. War das irgendwo zu lesen, oder ist das nur eine Annahme von dir?
Frage: hast du einen Schaltplan vom Floppycontroller mit den Schieberegistern. Wäre vielleicht hilfreich für mich bei der Suche nach dem CRC.
Das steht in der mir vorliegenden Doku, und ist auch im Schaltplan erkennbar:
Allerdings gibt es da noch ein paar Ungereimtheiten - so sollte der abgebildete CRC-Generator bei einem Sektor voller 0-Bits auch einen CRC von 0 erzeugen. Tatsächlich findet sich auf der Diskette aber etwas wie 0x0A88 afair.
Ansonsten habe ich mir ein Programm geschrieben, das aus den von Dir dekodierten Bitfolgen die Sektorinhalte komplett automatisch rausliest. Die Fehler im Header stören dabei nicht, weil ich von den je 20 Nullbytes nur 6 prüfe (d.h. ich synchronisiere auf die Sequenzen 0 0 0 0 0 0 3) . In den echten Nutzdaten gibt es dann tatsächlich keine Lesefehler.
Umgekehrt könnte ich nun beliebige Disketten erstellen - da fehlt mir nur der CRC.
Ich muss mal nach weiteren Schaltbildern suchen oder ggfs. die Originalschaltung prüfen um zu sehen, wie es zu den Diskrepanzen kommt.
Nachtrag: Damit Ihr Euch nicht durch alle 79 Seiten arbeiten müsst: das Thema CRC findet sich im zitierten Dokument auf Seite 66.
-
Hallo Georg
Danke für die Infos. Die sind sicher hilfreich!
Zitat von GeorgAllerdings gibt es da noch ein paar Ungereimtheiten - so sollte der abgebildete CRC-Generator bei einem Sektor voller 0-Bits auch einen CRC von 0 erzeugen. Tatsächlich findet sich auf der Diskette aber etwas wie 0x0A88 afair.
Könnte sein, dass (entgegen der Doku) auch das Byte davor (hex 03) mit einbezogen wird.
Aber das werden wir schon noch rausbekommen.
Frage zum Schaltbild des CRC: die 16 Ausgänge, sind die der Reihe nach Low-Bit bis High-Bit? Und wo ist Low?
PAW
-
Ich habe mal versucht, den CRC-Generator aus dem Schaltbild in Software zu simulieren. Keine Ahnung, ob ich das richtig gemacht habe, aber der liefert mir auch bei Hinzunahme des Synchronbytes (0x03) nicht den gewünschten CRC-Code. Dabei habe ich schon alle denkbaren Varianten berücksichtigt: Vorwärts, rückwärts, positive Logik, negative Logik.
Wegen der Ausgangsleitungen des Schieberegistes bin ich leicht überfordert. Die Ausgänge gehen zu vier Datenselektoren, deren Ausgänge dann wieder über weitere Stufen weiter verarbeitet werden. Etwas unübersichtlich. Und da ich von WANG weiß, dass dort gerne mindestens die Nibbles vertauscht wurden, und man auch an dem Schieberegister gut sehen kann, dass die mitnichten die Flipflops der Reihe nach benutzt haben (wenn man die FF in den Chips von 1 - 15 durchnummeriert, hat man etwa folgende Reihenfolge: 3,2,4,5,6,...15,16,1) habe ich noch keine Vorstellung, in welcher Reihenfolge die Bits dann tatsächlich abgelegt werden.
Dadurch ist natürlich auch der o.g. Test mit dem Synchronbyte eigentlich wertlos - allerdings stimmt schon die Bit-Verteilung nicht: Der tatsächlich auf der Diskette befindliche CRC-Code hat 12 0-Bits und 4 1-Bits (12:4). Alle meine Versuche liefern Verteilungen von 5:11, 6:10 oder 8:8.
Aber nochmal: Dieser CRC-Simulation traue ich noch nicht wirklich.
Falls es jemand interessiert, der darin besser ist als ich, habe ich zum Studium den mir vorliegenden Schaltplan des Controllers angehängt. Das Schieberegister findet sich auf der zweiten Seite, Mitte links, L27-L30.
-
Ich habe mal versucht, den CRC-Generator aus dem Schaltbild in Software zu simulieren. Keine Ahnung, ob ich das richtig gemacht habe, aber der liefert mir auch bei Hinzunahme des Synchronbytes (0x03) nicht den gewünschten CRC-Code. Dabei habe ich schon alle denkbaren Varianten berücksichtigt: Vorwärts, rückwärts, positive Logik, negative Logik.
Erledigt.
(Dein Emailprovider mag die EXE im ZIP nicht. Hab's 2mal versucht.)
ZitatP:\Eigene\Georg_210731>crc_sim.exe
crc=0x0A88
Die Datenbytes werden mit MSB zuerst gesendet, Der Rest ist ganz normal, ohne Tricks.
Man muss aber die Ausgaenge der ICs in die richtige 16bit Reihenfolge bringen. Krum verdrahtet und ebenso gezeichnet.
Viel Spass
-
Cool!
Irgendwie habe ich schon gewusst, dass ich mit Flipflops und Schieberegistern bei Dir gut aufgehoben bin.
Ich werde mir jetzt mal Deinen Code ansehen und prüfen, was bei mir falsch gelaufen ist. Herzlichen Dank jedenfalls schon mal in Richtung 51°03'30.0"N 6°26'32.9"E
Georg
-
Gut gefunden!
Weisst du was in der Spalte "Check" gemeint ist? Der Rest ist ja nachvollziehbar.
-
Auch Klasse!
Die Seite hatte ich auch schon mal in den Fingern, aber das war noch zu der Zeit, wo ich nur von den 256 Nullbytes ausgegangen bin. Nachdem ich mir dann die Theorie zu den CRC-Generatoren angesehen hab hatte ich den Eindruck, dass das nie und Nimmer irgend ein Standard sein könnte.
Ich habe jetzt mal nach diesem CRC/BUYPASS gesucht und bin beim CRC-16/UMTS gelandet. Angeblich mit dem Erzeugerpolynom 8005 - das passt ganz gut zu der Anordnung der XOR-Gatter in der Schaltung, aber da gibt es eben auch eine Abweichung, die ich bisher noch nicht verstanden habe. Muss ich mir noch mal durch den Kopf gehen lassen.
Auf jeden Fall auch Dir ein herzliches Dankeschön!
-
Zitat von funkenzupfer
Gut gefunden!
Weisst du was in der Spalte "Check" gemeint ist? Der Rest ist ja nachvollziehbar.
Da die Spalten "Result" und "Check" immer identisch sind, gehe ich davon aus, dass mit "Check" die Prüfsumme gemeint ist, mit der verglichen werden soll. Die Spalte ist für mich aus jetztiger Sicht unnötig.
-
Gibt's gerade noch übrige Bausätze bzw. eine Platine? Klasse Projekt!
Gruß
Robert
-
-
-
Bei Ralph_Ffm habe ich mir schon 2 Platinen aus seinem Vorrat erbeten
Die Platinen sind mittlerweile eingetroffen (vielen Dank nochmals an Günther ( gpospi ) !), 2 Stück liegen für Dich bereit, Gerd5 , die können wir wie besprochen gerne bei einem persönlichen Treffen übergeben.
Da ich mir selbst 2 Stück behalten und aufbauen werde, bleibt damit noch eine überzählige Platine aus der Lieferung. Für die 5 Platinen habe ich insgesamt 20 Euro bezahlt (10 für die PCBs, 10 für den Versand Ö -> D), damit ergeben sich sehr "erträgliche" 4 Euro Pro Stück. Plus natürlich "nacktes" Porto bei einem eventuellen Weiterversand, das sollte als leicht ausgepolsterter Brief sehr günstig gehen.
-
-
Damit wären dann auch schon alle Platinen vergeben bzw. reserviert...
-
Alles anzeigen
habe inzwischen einen passenden CRC-Online Rechner gefunden, der die richtigen CRCs berechnet. Wie weiß ich auch noch nicht, aber der Algorithmus nennt sich CRC-16 BUYPASS
siehe CRC-Rechner
Habe ihn mit ein paar Testsätzen gefüttert (alles 00, alles 07, alles 04, etc. sowie 00-FF)
Wichtig ist, wie ich vermutet hatte, vor den 256 Bytes das Byte hex 03 davorzustellen!
Habe mich inzwischen näher mit dem oben verlinkten CRC-Onlinerechner https://crccalc.com/ auseinander gesetzt.
Dabei ist mir aufgefallen, dass bei Eingabe von Texten, die Leerzeichen enthalten, wie "HALLO WIE GEHTS?",
der CRC, nicht wie erwartet, berechnet wird!
Modus: 16 Bit CRC-CCITT-FALSE (für PC-Disketten, z.B. mit µPD765)
Erwartet: 0xAC59
Ergebnis: 0xAFED
Das liegt offenbar daran, dass die Leerzeichen nicht mit 0x20, sondern mit 0x2B berechnet werden. Das Fragezeichen und der Rest stimmen auch nicht.
Processed data: 0x48 0x41 0x4c 0x4c 0x4f 0x2b 0x57 0x49 0x45 0x2b 0x47 0x45 0x48 0x54 0x53 0x25 0x33 0x46
Andere Onlinerechner scheinen diesen Fehler nicht aufweisen.
Gruß
PAW
-
FLUXDUMP Neue Version 0.50FLUXDUMP bietet neue Möglichkeiten!
Bei Version 0.42 war nur ein Dump von AES-Lanier- oder BULL-Disketten möglich (Hardsektor).
Die Version 0.50 bietet nun auch die Möglichkeit viele andere Formate zu Dumpen:
- FM und MFM-DD-Disketten (Softsektor, µPD765-kompatibel)
- MFM-HD-Disketten (Softsektor, µPD765-kompatibel)
- WANG-FM-Disketten (Hardsektor)
- C64-Disketten (GCR Softsektor)
Außerdem gibt es ein neues Feature für MFM: "Qualityinfo"
Wird diese Funktion angehakt, dann wird bei MFM-Disketten eine eigene CSV-Datei je Spur erstellt. Diese enthält die Verteilung der Fluxwechselintervalle. Daraus kann man erkennen, ob die Write-Precompensation gut funktioniert hat. Hier ein Beispiel. CSV-Dateien können z.B. mit EXCEL oder einem Texteditor geöffnet werden:
Track 01 einer 3.5“ HD-Diskette
Code
Alles anzeigenRPMexact 300,601202 LimLow 63 LimHigh 88 Sum of all Sectors Intervall Anzahl 45 0 46 3 47 79 48 1123 49 6792 50 12363 51 10814 52 9666 53 7875 54 5679 55 6993 56 2423 57 202 58 5 59 0 60 0 61 0 62 0 63 0 64 0 65 0 66 4 67 43 68 415 69 1744 70 3697 71 5841 72 8049 73 8668 74 6240 75 3448 76 1812 77 858 78 299 79 75 80 7 81 0 82 0 83 0 84 0 85 0 86 0 87 0 88 0 89 0 90 0 91 4 92 34 93 192 94 606 95 1234 96 1853 97 2216 98 2602 99 2644 100 2288 101 1741 102 963 103 356 104 78 105 18 106 4 107 0 255 0LimLow und LimHigh wird bei der Dekodierung verwendet. Sie bilden die Grenze zwischen kurzen/mittleren/langen Intervallen.
Darunter gibt es eine Auflistung, der im FLX-File vorhandenen Intervalle, nach Länge sortiert. 50 bedeutet z.B.: 50 x 40nsec = 2 µSekunden
Die erste Auflistung ist die Summe des gesamten Tracks (hier als Beispiel aufgezeigt), danach kommen die Werte nach Sektoren getrennt. Man sieht dabei eine Anhäufung der Werte bei ca. 50, 75 und 100, was 2, 3 und 4 µsec entspricht (ist hier von 3.5" HD mit 300rpm). Die Werte verschieben sich natürlich auch noch leicht rauf oder runter, je nach effektiver Drehzahl. Idealerweise wären nur Werte bei 50, 75 und 100 zu finden, gibt es aber in der Praxis nicht.
Die Qualität erkennt man an den Abständen zwischen den drei Hügeln, also den Tälern. Je mehr 0-Werte vorhanden sind, desto besser lassen sich kurz/mittel/lang Intervalle erkennen.
Wie immer gilt: Die Verwendung des Programms erfolgt auf eigenes Risiko!
HINWEIS: FLUXCOPY Vers. 0.90 kann die neuen Formate nur lesen, aber nicht alle schreiben. Eine neue Version ist in Arbeit bzw. in Test (Vers. 0.93e derzeit nur für einige Test-User).
Ich wünsche viel Erfolg!
PAW
-
Hallo,
feine Sache!
Ich habe es eben mal ausprobiert (mit Wine bekomme ich das auch unter Linux ans Laufen) und direkt mal meine zwei Wang-Disketten, die ich per Fluxteen/Fluxcopy ausgelesen habe, damit bearbeitet.
Die Testdisk wurde fehlerfrei verarbeitet; bei meiner Programmdisk tauchen gelegentlich CRC-Fehler auf. Das muss ich noch etwas genauer prüfen - momentan kann ich nicht sagen, ob die Diskette falsch/schlecht gelesen wurden oder ob vielleicht doch noch ein Fehler im CRC-Algorithmus ist.
Ich habe am Wochenende meine eigene Version von FluxDump programmiert; es sind zur Zeit drei kleine Konsolenprogramme in C, die in drei Schritten
- die Flux-Dateien interpretieren,
- die Impulslängen per FM in Bitfolgen dekodieren und schließlich
- die Wang-Struktur analysieren.
Also im Grunde das Gleiche, was Fluxdump in einem Rutsch macht.
Mir ging es weniger darum, systemunabhängige Software zu haben, sondern auch um das Verständnis des Formats und der Zusammenhänge. Mein eigentliches Ziel ist ja der umgekehrte Weg: Aus einem bestehenden Binär-image einer Diskette eine Flux-Datei zu generieren, die dann mit Hilfe von Fluxteen/Fluxcopy auf physikalische Disketten geschrieben werden können.
Leider habe ich aus Zeitgründen in das letzte Programm die CRC-Prüfung noch nicht eingebaut - deshalb kann ich auf die Schnelle die Frage von oben nicht beantworten. Ich hoffe, aber, dass ich das im Laufe des Abends noch fertig bekomme.
Noch eine Anmerkung zur aktuellen Version von FluxDump: Bei der Auswahl des Ordners für die Fluxdateien mag das Programm offensichtlich nur einen direkten Unterordner. Wenn ich mit Linux-Pfaden und damit mit "/" arbeite, beschwert er sich über ungültige Pfadangaben und schmiert ab; wenn ich einen mehrstufigen Pfad mit "\" verwende, meldet er, dass ":" oder "\" im Zielpfad nicht erlaubt sind.
Davon abgesehen: Tolle Sache! Ich habe jetzt nur die WANG-Variante getestet, aber die Möglichkeiten des Projekts sind ja wirklich grandios.
-
Zitat von Georg
Noch eine Anmerkung zur aktuellen Version von FluxDump: Bei der Auswahl des Ordners für die Fluxdateien mag das Programm offensichtlich nur einen direkten Unterordner.
Das ist richtig. Ich habe absichtlich keinen Mehraufwand reingesteckt.
Außerdem kannst du ja FLUXDUMP in verschiedene Verzeichnisse kopieren.
Zitat von GeorgDie Testdisk wurde fehlerfrei verarbeitet; bei meiner Programmdisk tauchen gelegentlich CRC-Fehler auf.
Wenn du möchtest, kannst du mir ja ein Image schicken. Kann ich mir dann näher ansehen.
Gruß
PAW
-
Ich habe inzwischen die CRC-Prüfung selber drin. Dabei bekomme ich in den gleichen Sektoren CRC-Fehler wie Dein Programm - ich sehe auch das Problem:
in den 20 Null-Bytes vor dem zweiten Synchronisationsbyte (3) habe ich immer wieder einen Glitch drin; d.h. ich lese gelegentlich statt der erwarteten langen Impulse auch mal zwei kurze. Das würde die Synchronisation kaputtmachen; deshalb habe ich die Zahl der benötigten Null-Bytes etwas reduziert, um das Sync-Byte sicher erkennen zu können. Mit anderen Worten: Ich suche nicht nach 20 Null Bytes, gefolgt von der 3, sondern z.B. nach 6 Null-Bytes, denen eine 3 folgt.
Ich gehe mal davon aus, dass Du das ähnlich machst, weil die Testdisk sonst nicht gelesen werden könnte.
Bei der zweiten Disk, die mir Probleme macht, taucht zwischen den rund 160 langen Impulsen folgende Sequenz auf:
... 208,206,208,205,209,157,102,135,108,202,210,205,210 ...
Impulslängen von ca. 200 stellen ein 0-Bit dar; zwei Impulslängen von ca. 100 ein 1-Bit. DIe Werte 157, 102, 135, 108 passen nicht in dieses Raster rein, und man hat nun Interpretationsspielraum. Wenn man festlegt, dass alles, was deutlich kleiner als 200 ist, ein kurzer Impuls ist, sind das zwei 1-Bits, und das Programm erkennt fälschlicherweise ein Synchronisationsbyte und setzt falsch auf.
Anscheinend stolpern beide Programm darüber, aber in unterschiedlicher Weise, denn die erwarteten und berechneten CRC-Werte unterscheiden sich - und stimmen in beiden Fällen nicht mit dem tatsächlichen CRC überein.
Natürlich kann man die Synchronisation auch anders gestalten, z.b. in der Art "18 Bytes oder 144 Bits überlesen, dann die erste 3 suchen". Das würde im aktuellen Fall helfen - aber natürlich ist nicht auszuschließen, dass so ein Fehler auch ganz knapp vor dem "echten" Synchronisationsbyte auftritt.
Ich schätze, ich muss die Diskette noch mal einlesen und sehen, warum er in dem Bereich so gerne Fehler liest - und warum der physikalische Controller damit dennoch zurecht kommt. Das wird aber etwas dauern...
-
in den 20 Null-Bytes vor dem zweiten Synchronisationsbyte (3) habe ich immer wieder einen Glitch drin
Ich würde davon ausgehen, das die Nullbytes (egal wieviele) nur zum einschwingen der PLL im Floppy-Controller gut sind. Der FDC wartet nur auf die 2 Bits in der 0x03.
So oder ähnlich geht das in meinem NorthStar FDC auch.
-
Das denke ich mir eigentlich auch, denn der Controller wird sicherlich nicht 160 Null-Bits abzählen.
Aber dann müssen das auch zuverlässig Nullen sein - und dummerweise habe ich dort ziemlich regelmäßig Fehler, d.h. Eins-Bits.
-
Der Controller bekommt einen seriellen Datenstrom, 2 Bits muessen '1' sein, erst danach schiebt der Contoller 8 bits zu einem Byte zusammen.
Du darfst also niemals 2 Eins-Bits bekommen. Sonst ist der Sektor nicht lesbar und sollte von der Checksum aussortiert werden.
-
Du darfst also niemals 2 Eins-Bits bekommen. Sonst ist der Sektor nicht lesbar und sollte von der Checksum aussortiert werden.
Exakt. Nur im konkreten Fall habe ich so unsaubere Werte, dass je nach Interpretation 2 Eins-Bits gelesen werden können.
Statt der erwarteten Impulse von 8ns kommen hintereinander vier Impulse mit Längen von ca. 6, 4, 5 und wieder 4ns. Zwei Impulse von 4ns machen eine Eins - ergo kann man das als zwei Einsen interpretieren. Oder man interpretiert den 6er und den 5er Impuls als lang, d.h. Null, hat dann aber zwei einzelne kurze Impulse, die bei FM nicht vorkommen dürfen, und wo dann wieder die Frage auftaucht, wie man damit umgeht.
Man könnte angesichts dieser Unsauberkeit den Sektor als fehlerhaft zurückweisen - deshalb interessiert mich brennend, was der Original Controller in dem Fall macht. Ich müsste aus der Flux Datei also wieder eine Diskette erzeugen und die in den Rechner stecken.
-
Nanosekunden, GEIL !!!
Das wären Übertragungsraten gewesen.
Ich geh auch davon aus, die Zeiten meinen die Zeiten zwischen den Impulsen und nicht die Impulslänge.
Ich muss mich nochmal in die Kodierung einlesen.
Bei FM und 125kbit/s sind nach Datenblatt doch nur 8µs oder 4µs möglich.
Auf welcher Flanke messt ihr denn die Zeiten?
Ich würde auf dem Impulsanfang messen, weil die Impulslänge größere Toleranzen hat.
Weiterhin viel Erfolg
-
Nanosekunden, GEIL !!!
Das wären Übertragungsraten gewesen.
Tja, war schon was spät am Abend/früh am Morgen.
Über den Rest kann ich nicht viel sagen - ich bekomme vom uController nur die nackten Zahlen (afaik die Anzahl von 25MHz-Takten zwischen zwei Flusswechseln). Nach meinem Verständnis von FM wird dabei jede Flanke berücksichtigt, und die gemessenen Zeiten entsprechen der Dauer der dabei entstehenden positiven und negativen Impulse.
Code__ _ __ | |__| |_| |_ 0 0 1 0 -
Zitat von funkenzupfer
Auf welcher Flanke messt ihr denn die Zeiten?
Ich würde auf dem Impulsanfang messen, weil die Impulslänge größere Toleranzen hat.
Die Zeiten werden am "falling edge" (vom Flachkabelanschluss) gemessen, also am Beginn des Impulses.
Zitat von GeorgNach meinem Verständnis von FM wird dabei jede Flanke berücksichtigt, und die gemessenen Zeiten entsprechen der Dauer der dabei entstehenden positiven und negativen Impulse.
Das stimmt grundsätzlich, bezieht sich jedoch auf die Magnetisierung am Datenträger. Die Elektronik am Floppylaufwerk macht daraus bei jedem Fluxwechsel einen kurzen Impuls. Die Leitung am Shugartbus ist im Ruhezustand auf +5 volt. Der Impuls zieht gegen Masse (für ca. 1µsec).
Code
Alles anzeigenBits: 0 0 1 0 Magnetisierung: ________ ____ ________ _| |________| |____| |______ Impulse von Laufwerk am Bus: _ ______ ______ __ __ ______ ____ |_| |_| |_| |_| |_| |_| <---8µ--><---8µ--><-4-><-4-><---8µ-->
