mikrocontroller.net

Forum: Projekte & Code Floppy FDD Diskette an AVR Mikrocontroller ATmega Beispiele Assembler


Autor: Bernhard S. (bernhard)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Mal wieder etwas Nostalgie ^^

Beispiel eines Floppy-Testers mit einem ATmega1284p.

Es ist interessant, wie sich ein Floppylauwerk in manchen Situationen 
verhält :-)



Eine Menueführung erlaubt u.a. folgendes:

- Motor-A Motor-B on/off
- Drehzahlmessung
- Spur Step +/-
- Spur NULL anfahren
- Head-Umschaltung
- alle 17 Pin-Zustände anzeigen (bei Motor off--> alle HIGH)
- Data read (sowieso aktiv, wenn Motor on, Pegelwechsel an RDDATA)
- Data Write (eine konstante Frequenz wird an WRDATA angelegt)


MFM beherrscht der µC nicht, ist aber Voraussetzung, um Die Daten von 
der Disk zu lesen und zu decodieren.

Vermutlich benätigt man zusätzliche Hardware.

Einige hilfreiche Beiträge fand ich u.a. hier:

Beitrag "3,5" Floppy auslesen"
Beitrag "Floppysimulation, möglich?"
Beitrag "Ersatz einer Diskette im Diskettenlaufwerk??"

Anmerkung:

Im Video ist das hin- und herfahren des Kopfes sehr schön zu sehen und 
das typische Laufwerksgeräusch zu hören ^^

Der Floppy-Bus im PC lässt sich durch einen einfachen Adaper mitlesen, 
interessant sind die Impulse für WRE, beim formatieren wird z.B. eine 
komplette Spur beschrieben, bei anderen Schreibvorgängen nur Teile einer 
Spur (nur kurzeitig WRE auf low).

Ein ATmega1284p ist natürlich für diesen Anwendungsfall total 
unterfordert, denn es genügen nur wenige Pins, um ein Floppy grundlegend 
anzusteuern.

Für Hinweise bin ich sehr dankbar.

Bernhard

: Bearbeitet durch User
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard S. schrieb:
> MFM beherrscht der µC nicht, ist aber Voraussetzung, um Die Daten von
> der Disk zu lesen.

Ich hatte das vor Jahren mal mit jemandem anderes gedanklich 
durchgespielt (war eine offline-Fortsetzung eines der verlinkten 
Threads). Mit einem Koprozessor (der dann praktisch 100 % ausgelastet 
ist) sollte sich MFM gerade so decodieren lassen, zumindest DD.  Für HD 
wird ein AVR nicht genügen, da muss man schon zu einem ARM greifen.

Das sollte damals ein Floppy-Emulator für ältere Messgeräte werden, das 
Projekt ist allerdings leider nie fertig geworden (Hardware liegt noch 
in der Kiste ;).

: Bearbeitet durch Moderator
Autor: Bernhard S. (bernhard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> das Projekt ist allerdings leider nie fertig geworden....

Ich bin auch schon am vordenken,
ob es mit einem AVR überhaupt möglich ist HD-Disks auszulesen.

Kann sein, daß die Hardware sehr aufwändig wird (z.B. mehrere PLL).

Das Floppy stellt ein Datenstrom zur Verfügung, z.B. für Spur NULL,
wo dieser Datenstrom beginnt bzw. endet kann keiner sagen,
oder hilft dabei der Index-Impuls?

Wie genau ist der Index-Impuls?

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard S. schrieb:

> Kann sein, daß die Hardware sehr aufwändig wird (z.B. mehrere PLL).

Naja, heutzutage würde man das wohl eher in Software machen, statt da 
noch externe PLLs zur Taktrückgewinnung dranzusetzen.

Wenn du das willst, kannst du auch einen HD44780 nehmen. ;-)

> Das Floppy stellt ein Datenstrom zur Verfügung, z.B. für Spur NULL,
> wo dieser Datenstrom beginnt bzw. endet kann keiner sagen,
> oder hilft dabei der Index-Impuls?

Der Index-Impuls sagt, das jetzt eine Spur anfängt, richtig.  Den 
genauen Spuraufbau habe ich nicht mehr im Kopf, müsste ich auch 
nachlesen.

> Wie genau ist der Index-Impuls?

Weiß ich jetzt auch nicht.  Bei 5,25" ist das ja eine Lichtschranke, die 
ein Loch abtastet.  Bei 3,5" muss das, was abgetastet wird, irgendwie 
mit dem Loch in der Blech-Armierung der Floppy verbunden sein, also da 
hinein einrasten.

: Bearbeitet durch Moderator
Autor: Sinus T. (micha_micha)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Index-Impuls wird nur mein Formatieren genutzt. Der Controller 
erkennt den Beginn eines Tracks/sektors an bestimmten Marken im 
Datenstrom. Die Marken sind Bytes, bei denen bestimmte Taktimpulse 
ausgelassen wurden und die daher im normalem Datenstrom nicht vorkommen

Autor: Sinus T. (micha_micha)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Hier auf Seite 30/31 ist schön erklärt, wie eine Spur aufgebaut ist. Auf 
Seite 26 ist der Aufbau der Marken beschrieben
http://www.swtpc.com/mholley/DC_5/TMS279X_DataSheet.pdf

Autor: foobar (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich meine, das Index-Signal wurde bei keinem der gängigen 
soft-sektorierten Formaten genutzt - sonst hätte das beidseitige 
Verwenden von SS-Disketten (durch umdrehen) gar nicht funktioniert.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
foobar schrieb:
> Ich meine, das Index-Signal wurde bei keinem der gängigen
> soft-sektorierten Formaten genutzt - sonst hätte das beidseitige
> Verwenden von SS-Disketten (durch umdrehen) gar nicht funktioniert.

Früher™ konnten wir die Rückseite auch erst nutzen, nachdem man in die 
Hülle noch eine zweite Öffnung für das Indexloch der Rückseite gestanzt 
hat.

Autor: foobar (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> Früher™ konnten wir die Rückseite auch erst nutzen, nachdem man in die
> Hülle noch eine zweite Öffnung für das Indexloch der Rückseite gestanzt
> hat.

Wie gesagt, "bei den üblichen soft-sektorierten Formaten". Da mußte man 
nur das Schreibschutzloch an der Seite "nachrüsten" - Indexloch war 
egal.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
foobar schrieb:
> Wie gesagt, "bei den üblichen soft-sektorierten Formaten".

Soft-sektoriert waren die sowieso, "hard sectors" gab's meines Wissens 
nur bei 8".  Trotzdem wurde das Indexloch dort ausgewertet.  Der HD44780 
benutzt es zumindest noch dafür, um festzustellen, dass er einen Sektor 
nicht finden konnte (wenn das Indexloch zweimal vorbei kam, ohne die 
passende Sektormarke zu finden).  Vermutlich hat er ohne Indexloch dann 
einfach nie einen Timeout.

Autor: Bernhard S. (bernhard)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Messung der Genauigkeit des Indeximpulses in Bezug auf den Datenstrom:

Ohne weiteres tritt eine Schwankung vom mehreren µs auf, hat sicherlich 
auch mechanische Gründe, die wir nicht weiter diskutieren wollen.

Nach meiner momentanen Meinung muss jede Spur jedes Mal komplett 
gelesen werden, mit oder ohne Indeximpuls.

Dann wird der Datenstrom untersucht, so wie bei RDS

Beitrag "RDS DECODER selber bauen / Rohdatendecoder Eigenbau"

Und anschließend möchten wir die Marken finden...


Sinus T. schrieb:
> Hier auf Seite 30/31 ist schön erklärt, wie eine Spur aufgebaut ist. Auf
> Seite 26 ist der Aufbau der Marken beschrieben

Danke, habe die PDF hier mal mit veröffentlicht (für die Nachwelt)

: Bearbeitet durch User
Autor: Bernhard S. (bernhard)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Diese Infos dürften interessant sein.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Bernhard S. schrieb:
> Nach meiner momentanen Meinung muss jede Spur jedes Mal komplett gelesen
> werden, mit oder ohne Indeximpuls.

Ein richtiger Floppycontroller konnte natürlich auch mittendrin die
Sektormarken erkennen und den gewünschten Sektor zurückgeben, wenn er
gerade vorbei huschte – ohne auf die komplette Spur zu warten.

Jeder Sektor hat ja sein eigenes Synchronfeld.

Autor: Erich (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Bernhard S. schrieb:
> Diese Infos dürften interessant sein.

Die Datei "Grundlagen.pdf" ist hier überhaupt nicht relevant,
da sie "hard disc" beschreibt, also Festplatten.
Das andere Dokument ist ein verschnitt von "PC"-Diskinfos, welche die 
5,25 Zoll und 3,5 Zoll Unterformate beschreiben, die wichtigesten Basics 
jedoch auslassen. Wenig nützlich.


Bei Floppy Disc ist das 8" Format IBM 3740 die Mutter aller 
Diskettenformate.
https://en.wikipedia.org/wiki/List_of_floppy_disk_formats

Wie die einzelnen Spuren aufgebaut sind, sieht man am besten bei der 
Beschreibung einen FDC (Floppy Disc Controller), z.B. des FD1771 von 
Western Digital
http://deramp.com/downloads/floppy_drives/FD1771%2...
Dort Seite 13.


Ein übliches 8" Laufwerk war das Shugart SA800
http://deramp.com/downloads/floppy_drives/shugart/...

Am ersten Bild hier http://q7.neurotica.com/Oldtech/Xerox/820-II.html
sieht man auch die mechanische Größe dieser Laufwerke,
was sich ja auch aus 8" Dikettengröße ergibt 
https://en.wikipedia.org/wiki/List_of_floppy_disk_...

Gruss

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Henrik Haftmann hat sich mit der Materie etwas eingehender beschäftigt 
und einen USB-zu-Floppy-Adapter auf Basis eines Atmega32u4 entwickelt:

https://www-user.tu-chemnitz.de/~heha/basteln/PC/usbfloppy/

Komplett fertig ist das Ding zwar wohl nicht, aber da dürften etliche 
wertvolle Erkenntnisse drinstecken.

Autor: Christoph db1uq K. (christoph_kessler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg - HD44780 ist der berühmte LCD-Controller. Floppycontroller hießen 
FD.. oder WD oder ähnlich wie oben der FD1771.
Beim Atari1040 hieß er Ajax wenn ich mich recht erinnere.

Das Original AppleII-Format wurde per Software decodiert, das kann nicht 
so kompliziert gewesen sein.

: Bearbeitet durch User
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Da war doch was … ah ja, i8272 alias µPD765.

Ja, völlig vermasselt.  Asche auf mein Haupt :)

Autor: 2⁵ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph db1uq K. schrieb:
> Das Original AppleII-Format wurde per Software decodiert, das kann nicht
> so kompliziert gewesen sein.

War aber IMHO GCR, wenn ich mich recht erinnere. Die 1541 hatte doch 
auch GCR verwendet...

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph db1uq K. schrieb:
> Das Original AppleII-Format wurde per Software decodiert, das kann nicht
> so kompliziert gewesen sein.

Das hatte nun aber auch eine besonders geringe Datendichte.

Autor: Amiga Floppy (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Arduino Amiga Floppy Disk Reader/Writer
Open Source and Free! - by Robert Smith

http://amiga.robsmithdev.co.uk/history

Autor: Bernhard S. (bernhard)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Thema MFM-Rohdatendecoder, mommentan bin ich erstan dieser Stelle

Folgende Grundüberlegung:

Eine PLL (soft/hard) synchronisiert sich auf den Takt des MFM-Signals 
(ca.500kHz) und bestimmt, wenn das MFM-Signal abgetastet werden soll.

Nur bei der PLL muss auf Frequenz und Phasenlage in Einklang gebracht 
werden.

Ergebnis: alle 2µs kullert ein Datenbyte aus dem Decoder


Frage-A: ist "MFM-theoretisch" korrekt dargestellt?

Frage-B: Kann jemand die "MFM-Floppy" deuten?

[Tippfehler korrigiert - Mod.]

: Bearbeitet durch Moderator
Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Meinst Du MFM?

Lies Dir mal das durch, was ich ein paar Postings weiter oben verlinkt 
habe - Henrik Haftmann hat sich da recht ausführlich drüber ausgelassen.

Autor: Bernhard S. (bernhard)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> Meinst Du MFM?
oh ja, sorry, könntest Du es mal bitte abändern, liest sich ja 
schrecklich



> Lies Dir mal das durch, was ich ein paar Postings weiter oben verlinkt
> habe - Henrik Haftmann hat sich da recht ausführlich drüber ausgelassen.

stimmt, danke, nur MFM ist nach meiner Meinung doch etwas knapp gehalten

Er beschreibt, s.Bild, MFM mit und ohne Synchronimpuls, welches 
Verfahren wird wann verwendet?

Autor: Benni (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Deinen Datenstrom kannst du mit der Lese-Routine von Henrik Haftmann 
dekodieren:

https://www-user.tu-chemnitz.de/~heha/basteln/PC/u...

Autor: Bernhard S. (bernhard)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hab mal ein Referenz-Signal mit dargestellt, ich denke, so ist die 
Bitfolge nun doch erkennbar.


> Deinen Datenstrom kannst du mit der Lese-Routine von Henrik Haftmann
> dekodieren:

ja, die Zeitmessungsmethode, erscheint mir auch am sympathischsten :-)

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard S. schrieb:
> Ergebnis: alle 2µs kullert ein Datenbyte aus dem Decoder

Byte?  Bit. :-)

Autor: Bernhard S. (bernhard)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Die Rohdaten-Decodierung nach dem MFM-Zeitmessverfahren
(Quelle:Henrik Haftmann) verlangt am Anfang ein korrektes Merkbit.


Der Datenstrom synchronisiert sich leider nicht von alleine 
(s.Beispiel).

Vermutlich sollte man am Anfang das 0xA1 (Synchronwort) ganz explizit 
suchen, damit der Datenstrom synchronisiert wird.

Nach meiner Meinung müsste zuerst nach einem Zeitmuster gesucht und
anschließend mit dem Verfahren Schreibe... Merke... weiter gearbeitet 
werden.

Frage:

Bei 0xA1 (0b10100001) kullern die Bits vom Floppy so heraus: 
...10000101..?



Etwas Statistik der gemessenen Impulslängen hänge ich mal mit an, zur 
Info.

: Bearbeitet durch User
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Bernhard S. schrieb:
> Bei 0xA1 (0b10100001) kullern die Bits vom Floppy so heraus:
> ...10000101..?

Ja.

Autor: Benni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard S. schrieb:

> Vermutlich sollte man am Anfang das 0xA1 (Synchronwort) ganz explizit
> suchen, damit der Datenstrom synchronisiert wird.

... beziehungsweise nach der langen "Lücke", die bewusst die 
MFM-Codierung verletzt, damit sie leicht gefunden wird. Danach kannst du 
sauber aufsetzen und weiter lesen.

Autor: eProfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einer der fortgeschrittenen FDD-Controller war der WD2797 (integrierte 
PLL). Mit dem habe ich jahrelang gearbeitet (bin sogar x00km nach 
München in die WesternDigital-Niederlassung gefahren, um ein Datenbuch 
zu bekommen). Die einfacheren hatten noch eine externe PLL.
Beitrag "Ersatz einer Diskette im Diskettenlaufwerk??"
Beitrag "SAB2797B-P Wofür verwenden?"

Zur Soft-Dekodierung, falls es unbedingt ein AVR8 sein soll und die Zeit 
nicht ausreicht: die laufen bei sauberem Aufbau auch bis 24 / 28 MHz.

Zum HD44780 fallen mir noch HD64180 (verbesserter Z80 im shrinkDIP64 
1,778mm) und HD63484 (color graphic controller) ein, mit denen ich auch 
sehr viel gemacht habe.

Hier eine aktuelle Übersicht über FDD-Emulatoren:
http://hxc2001.free.fr/floppy_drive_emulator/index.html

Wie ich gerade sehe, wurde mein Wikipedia-Artikel "Shugart-Bus" 
gelöscht, weil: nicht Oma-tauglich, dann redirect auf SCSI (Schmarrn) 
und dann: falscher Redirect -->  Kick
kein Kommentar...

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
eProfi schrieb:
> Einer der fortgeschrittenen FDD-Controller war der WD2797

Der brauchte aber noch einige Analogbeschaltung für den Datenseparator, 
neuere FDCs wie der WD1771 (u.a. im Atari ST verbaut) enthielten einen 
digitalen Datenseparator, wie auch der spätere WD3765 (zu finden in 
etlichen IBM-AT-kompatiblen Rechnern).


> Zum HD44780 fallen mir noch HD64180 (verbesserter Z80 im shrinkDIP64
> 1,778mm) und HD63484 (color graphic controller) ein

Hitachi hat alle(?) seine Digital-Bausteine mit dem Präfix HD versehen.
Speicherbausteine hatten das Präfix HM.

Die Hitachi-Variante des 6809 hieß dann HD6309, das berühmte 
2-kByte-SRAM HM6116 ...

Autor: Bernhard S. (bernhard)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So werden die MFM Rohdaten vom Floppy gesendet,
nun auch zeitlich korrekt dargestellt

mit 1x Null, 2x Null, 3x NULL und 4x Null.

Beweis:

Ein Mitschnitt von 10.000 Messzeiten (s.Excel-Tabelle),
3 x 0xA1 (Synchronwort), also das Zeit-Bitmuster (2-3-2-3 Zellen), wurde 
schnell gefunden. Ab dann ist der Bitstrom definitiv synchronisiert.



Die Abbildung "Decodierung_nach_Zeitverfahren.png" (etwas weiter oben)
ist leider nicht korrekt, sorry, ich wußte es auch nicht besser.



>> Vermutlich sollte man am Anfang das 0xA1 (Synchronwort) ganz explizit
>> suchen, damit der Datenstrom synchronisiert wird.

>... beziehungsweise nach der langen "Lücke", die bewusst die
>MFM-Codierung verletzt, damit sie leicht gefunden wird. Danach kannst du
>sauber aufsetzen und weiter lesen.

... seltsam, ich finde die lange "Lücke" nicht vor dem 3x 0xA1.

Die Datenaufzeicnung beginnt direkt nach dem Lichtscharankenimpuls.

PS:

Danke für die sehr hilfreichen Beiträge, kann leider nicht auf jeden 
einzelnen Beitrag antworten, die Materie ist zu komplex.

: Bearbeitet durch User
Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da hier anscheinend die geballte Diskettenkompetenz anwesend ist eine 
Frage:
Für die MIPS CPU in TTL steht noch ein Diskettencontroller an.
Welchem empfehlt ihr denn da?
Bisher habe ich nur welche gefunden, die ne externe PLL und 
Datentrennung wollen.
Die hier genannten WD Chips können dann aber wiederrum kein High 
Density, also wär ich in der Auswahl der lesbaren Disketten beschränkt.

Also welchen Floppycontroller IC empfehlt ihr für:
5,25" und 3,5"
Er soll ALLE bis zuletzt verfügbaren Formate unterstützen dies bis zum 
aussterben gab.

Das mit dem AVR hier klingt auch interessant, dann hätte der 
Floppycontroller aber mehr Rechenleistung als die CPU!

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:
> Er soll ALLE bis zuletzt verfügbaren Formate unterstützen dies bis zum
> aussterben gab.

Auch 2,88 MB? ;-)  (Die waren ziemlich rar, sowohl Medien als auch 
Laufwerke.)

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wasses nicht alles gibt, das hatte ich garnicht auf dem Schirm.
Das konnte nichtmal das recht moderne FDD in meinem alten P3 Laptop.

Also alles hoch bis zum 1,44MB 3,5" reicht dicke ;)

Autor: Schlaubischlumpf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> neuere FDCs wie der WD1771 (u.a. im Atari ST verbaut)

Sorry, aber im Atari ST wurde schon immer der WD1772 verbaut (28pin 
statt 40pin WD1771). Der in einem oberen Artikel erwähnte "Ajax" war 
eine Atari eigene Entwicklung nachdem sie den WD1772 lizenziert hatten. 
Dieser Ajax konnte im Gegensatz zum ursprünglichen WD1772 auch HD 
Disketten lesen/schreiben und natürlich formatieren.

Nix für ungut, aber als alter Atarianer musste ich das einfach loswerden 
;-)

Gruß und schönen Tag noch,
Schlaubischlumpf

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schlaubischlumpf schrieb:
> Sorry, aber im Atari ST wurde schon immer der WD1772 verbaut (28pin
> statt 40pin WD1771)

Das werd' ich dann wohl verwechselt haben. Den hab' ich vor 30 Jahren 
mal in meinem Selbstbau-Rechner untergebracht, da kann dann schon mal 
ein (Erinnerungs-) Bit kippen.

Der 40-Pinner hieß allerdings FD1771, nicht WD1771.

Mw E. schrieb:
> Die hier genannten WD Chips können dann aber wiederrum kein High Density

Sieh Dir den WD37C65 an. Der kann alles, was ein IBM AT konnte.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Sieh Dir den WD37C65 an.

Solche Teile sollte man doch von alten PC-Mainboards ausschlachten 
können.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Solche Teile sollte man doch von alten PC-Mainboards ausschlachten
> können.

Wenn man eines findet, das alt genug ist.

Oft aber ist ein "Super-IO-Chip" verbaut, der parallele und serielle 
Schnittstellen mit dem FDC kombiniert, und nicht mehr am parallelen 
ISA-Bus, sondern einem "LPC" genannten seriellen Bus hängt.

Wenn man wirklich alte PC-Hardware hat, kann man den 37c65 auf einem 
ISA-MFM- oder -RLL-Festplattencontroller finden, wie dem WD1006.

Wer aber hat so etwas noch herumliegen?

Autor: soul e. (souleye)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Mw E. schrieb:

> Also welchen Floppycontroller IC empfehlt ihr für:
> 5,25" und 3,5"
> Er soll ALLE bis zuletzt verfügbaren Formate unterstützen dies bis zum
> aussterben gab.

Wie jetzt, IC?? An eine TTL-CPU gehört ein TTL-Controller. Sieh Dir die 
WozMachine vom Apple II an.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
soul e. schrieb:
> Sieh Dir die WozMachine vom Apple II an.

Die kann noch nicht mal MFM.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beim WD37C65 sehe ich im Datenblatt auch nur wieder was von Double 
Density?
Gleichzeitig finde ich auch nicht inwiefern eine HD Floppy anders als 
eine DD bescherieben wird. Zwischen SD und DD sehe ich den Unterschied 
in der Codierung.
Die Anzahl der Tracks von DD zu HD ist jedenfalls gleich (80).

@soul e:
Der CPU Kern sollte unbedingt in reinem TTL gebaut werden.
Bei den IO Karten wird das soweit durchgezogen wie möglich.
Die LAN Karte wird wohl in TTL mit FIFOs kommen, aber die SDRAM Karte 
bekommt nen FPGA verpasst.
Aber es steht dir natürlich frei ein TTL Floppy Controller für das 
Projekt zu bauen und zu spenden ;)

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mw E. schrieb:
> Gleichzeitig finde ich auch nicht inwiefern eine HD Floppy anders als
> eine DD bescherieben wird.

Höhere Datenrate, wimre. wird bei 3,5" auch noch die Drehzahl geändert.

Erst ED hat dann nochmal das Aufzeichnungsverfahren geändert (so 
genanntes perpendicular recording).

: Bearbeitet durch Moderator
Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Höhere Datenrate, wimre. wird bei 3,5" auch noch die Drehzahl geändert.

Andersrum, bei 5.25" gibt es zwei Drehzahlen, 300/min und 360/min.

3.5" hat immer* 300/min und bringt damit mehr Daten auf einer Spur unter 
als 5.25" mit 360/min.



*) seltene japanische 3.5"-Laufwerke konnten den Quatsch auch und damit 
auch "HD"-Disketten mit nur 1.2 MB beschreiben

Autor: nachtmix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard S. schrieb:
> Wie genau ist der Index-Impuls?
 Ungenau. Er wird lediglich beim Formatieren gebraucht, um dem 
Controller den Anfang der Track zu signalisieren.
Später dann, beim Lesen oder Schreiben, erkennt der Controller einen 
Fehler, wenn beim zweiten Auftauchen des Index noch nicht die 
gewünschten Daten (Track/Sector) erkannt wurden.

Jörg W. schrieb:
> Soft-sektoriert waren die sowieso, "hard sectors" gab's meines Wissens
> nur bei 8".

Es gab auch 5,25" Hard sektorierte Floppies mit 16+1 Indexlöchern.
Ein Lesegerät für derartige MFM-Daten war ca. 1979 eine meiner ersten 
kommerziellen Enwicklungsarbeiten.
I.W. bestand der Datenseparator aus einer analogen PLL, die sich während 
der Präambel synchronisiert und dann kontinuierlich Nullen oder Einsen 
liefert.
Beim Erkennen der Addressmark (bereits von Benni erwähnte 
Protokollverletzung) wird ein Flipflop gesetzt, das den Bitstrom 
invertiert oder nicht. Danach kam praktisch nur noch ein 8-Bit 
SIPO-Schieberegister.

Eine mit 2,26MHz getaktete Z80 war gerade schnell genug, um die Daten 
vom SR in den Speicher zu transportieren. Sie war aber nicht schnell 
genug um den CRC-16 in Echtzeit zu berechnen. Das passierte erst, wenn 
die Daten im Speicher waren.


Rufus Τ. F. schrieb:
> Wer aber hat so etwas noch herumliegen?

Kann sein, dass ich noch ein paar SuperIO von UMC habe. Da diese Chips 
in PCs verwendet wurden, sind sie alle 765 kompatibel.
M.W. sind 765 und der im TRS-80 und Video Scharnier verwendete FD1771 
aber zueinander nicht Hardware kompatibel. Iirc liegt das an 
unterschiedlichen CRC-Polynomen, evtl. auch an unterschiedlichen 
Sync-Marken.
Diese Dinge sind als Hardware implementiert und nicht konfigurierbar.
Allenfalls kann man die Controller in einen Raw-Modus bringen, und muss 
dann das gelieferte Gemenge von Daten und Verwaltungsinformationen 
mittels Software interpretieren.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nachtmix schrieb:
> M.W. sind 765 und der im TRS-80 und Video Scharnier verwendete FD1771
> aber zueinander nicht Hardware kompatibel. Iirc liegt das an
> unterschiedlichen CRC-Polynomen

Zumindest mit dem Nachfolger des FD1771, dem WD1772, lassen sich 
Disketten problemlos lesen und beschreiben, die auch von einem 765 
gelesen und geschrieben werden können. Sonst wäre ein Datenaustausch 
zwischen Atari ST und IBM-PCs nicht möglich gewesen.

Würde mich wundern, wenn das beim FD1771 tatsächlich anders gewesen sein 
sollte.

Was ist "Video Scharnier"?

Autor: Otto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Was ist "Video Scharnier"?

Video-Genie?

Autor: nachtmix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Otto schrieb:
> Rufus Τ. F. schrieb:
>> Was ist "Video Scharnier"?
>
> Video-Genie?

Ja, der asiatische TRS-80 Nachbau.

Autor: nachtmix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe übrigens vor einigen Wochen ein externes 3,5" Floppy Laufwerk 
mit USB-Schnittstelle von LaCie "706018 MYFLOPPY3" geschenkt bekommen.
Das Ding hat unter Win10 aus dem Stand eine alte DOS-Diskette von 
National Instruments eingelesen. Was es noch kann, weiss ich noch nicht, 
da ich keine BDA habe.
Diese Laufwerke werden gelegentlich gebraucht bei ebay angeboten.

Allerdings gibt es auch neue USB Floppydrives für wenig Geld, z.B. 
Ebay-Artikel Nr. 332532732221

Autor: soul e. (souleye)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nachtmix schrieb:

> Das Ding hat unter Win10 aus dem Stand eine alte DOS-Diskette von
> National Instruments eingelesen. Was es noch kann, weiss ich noch nicht,
> da ich keine BDA habe.

Üblicherweise können die nur das HD-Format (1,44 MB) lesen und 
schreiben. DD (720k) sowie die diversen CP/M-, Keyboard- oder 
CNC-Formate werden nicht unterstützt.

Autor: Bernhard S. (bernhard)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>... beziehungsweise nach der langen "Lücke", die bewusst die
>MFM-Codierung verletzt, damit sie leicht gefunden wird. Danach kannst du
>sauber aufsetzen und weiter lesen.



Wie sollte man eine Schutzverletzung behandeln?

A: ignorieren ?
B: eine 0 schreiben ?
C: eine 1 schreiben ?
D. etwas anderes tun ? ^^

Autor: nachtmix (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Bernhard S. schrieb:
> nach der langen "Lücke",

Was du da zeigst, ist nicht die Marke, über die diskutieren.
Diese Pause ist viel zu lang.
Bei der zur Diskussion stehenden Codeverletzung handelt es sich um eine 
einzige Flanke der MFM-Codierung, die ausgelassen wird.
Auf dem Oszilloguck ist das kaum zu sehen.

Bei deinem Bild handelt es sich wahrscheinlich um die Lücke, die 
zwischen  jeder Sektornummer und den eigentlichen Daten vorhanden ist.

Evtl. ist das auch die relativ grosse asynchrone Lücke, die zwischen dem 
physikalisch ersten und dem letztem Sektor der Track vorhanden ist, denn 
der Controller muss beim Formatieren ja etwas schneller schreiben als 
sich die Scheibe im schnellsten tolerierbaren Fall dreht, damit nicht 
die Sektornummer des physikalisch ersten Sektors (am Index) 
überschrieben wird.

Wenn der Controller Daten für einen bestimmten Sektor schreiben will 
bzw. soll, dann sucht er zuerst den beim Formatieren angelegten und 
ebenfalls MFM codierten Block mit der richtigen Sektornummer und 
schaltet erst nach einer kurzen Pause auf Schreiben um, um dann einen 
neuen Block (Präambel, Sync, Daten, CRC) zu schreiben.
Der beim Formatieren angelegte Block mit Präambel, Sync, Sektornummer 
wird dabei nicht angetastet, sonst würde er beim mehrfachen Schreiben 
allmählich die Track entlang wandern und alle anderen Sektoren 
ruinieren.
Aus diesem Grund besteht zwischen dem Block mit der Sektornummer und dem 
Block mit den Daten (und natürlich auch zwischen diesem Datenblock und 
der nächsten Sektornummer) ein Sicherheitsabstand.

Autor: nachtmix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja:

Mw E. schrieb:
> welchen Floppycontroller IC empfehlt ihr für:
> 5,25" und 3,5"
> Er soll ALLE bis zuletzt verfügbaren Formate unterstützen dies bis zum
> aussterben gab.

Vergiss es!
Ich habe im Laufe der Zeit Floppies in der Hand gehabt, zu denen du 
weder Informationen noch Laufwerke finden wirst.
Ausser den bereits erwähnten, mit Textautomaten benutzten, 
hardsektorierten 5,25" Scheiben, auf denen du aber nichts wirst lesen 
können, weil da kein ASCII sondern der RT-Code ("Redactronski") von 
Kugelkopfschreibmaschinen verwendet wurde, denke ich z.B. an kleine 
Floppies mit vielleicht 4cm Kantenlänge, die nur ein paar kB fassten und 
von (TA- ?) Speicherschreibmaschinen "erzeugt" wurden, sowie an die eine 
Zeit lang in Mode gewesenen Bernoulli-Laufwerke, die technisch eher 
Harddisks waren.

Erschwerend kommt dann noch die grosse Zahl von Filesystemen hinzu, mit 
denen die gespeicherten Daten organisiert werden.
M.W. ist sogar das aktuell (nicht für Floppies) viel genutzte 
NTFS-Filesystem von Microsoft bis heute nicht offiziell dokumentiert.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Ich vermute stark, daß mit "alle Formate" nur alle am PC verwendeten 
Formate gemeint sind.

Dateisysteme hingegen sind bei der Betrachtung irrelevant, das spielt 
sich eine Ebene weiter oben ab; der FDC muss nur Sektoren lesen (und 
gegebenenfalls schreiben) können, der Rest ist Software.

Autor: Bernhard S. (bernhard)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> ...MFM codierten Block mit der richtigen Sektornummer und
> schaltet erst nach einer kurzen Pause auf Schreiben um...

ok, sehr gut erklärt, klingt logisch :-)

Im Bild "MFM_Schutzverletzung.png" ist die erste, nach dem Indeximpuls 
aufgetretene Schutzverletzung dargestellt, bei welchem Byte sich diese 
befindet, kann ich jetzt nicht sagen.

Anmerkung zum Bild "MFM_Schutzverletzung_ANALYSE.png":

Eine Diskette habe ich mit Win98 formatiert und 1,4MB Textdaten, also 
alle Datensektoren mit "AAAAA...." beschrieben. Der Kopf befindet sich 
auf der Spur 20 (ca.)

Ein 22 MHz getakteter ATmega1284p, mit 16K SRAM, versucht sich an der 
MVM-Decodierung ^^

Am Anfang tauchen gleich die 3x 0xA1 auf, es folgt 0x1F und viele 0x39.

Kennt jemand ein Abhandlung, wo dies Bytefolge auftaucht und näher 
beschrieben ist?

In einem Sektor finden wir alle 512 "A" wieder.

In den anderen Sektoren tauchen auch 512 gleiche Bytes auf, das ist 
schon mal gut, müssten eigentlich auch alles "A" sein.
Nur hier scheint meine Synchronisation stark verbesserungswürdig zu 
sein.


Anfängerfrage: Wieviel Sektoren befinden sich auf bzw. in einer Spur?

>der FDC muss nur Sektoren lesen (und
>gegebenenfalls schreiben) können, der Rest ist Software.

So sehe ich es auch.

Wenn ein Sektor ausgelesen werden soll, dann:

-Kopf auf richtige Spur
-Kopf auf A oder B umschalten
-ggf. Index-Impuls abwarten
-Sektor Nr. suchen und finden
-ggf. Schutzverletzung erkennen und behandeln
-Sektor auslesen

: Bearbeitet durch User
Autor: Benni (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
"Anfängerfrage: Wieviel Sektoren befinden sich auf bzw. in einer

Tabelle unten:

https://www.elektronik-kompendium.de/sites/com/0310211.htm

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benni schrieb:
> Wieviel Sektoren befinden sich auf bzw. in einer
> Tabelle unten:

Diese Fragestellung ist ohne die Angabe der Größe der Sektoren reichlich 
sinnlos. Zwar arbeiten PCs mit 512-Byte-Sektoren, aber in anderen 
Systemen gab es auch 256- und sogar 128-Byte-Sektoren.

Autor: Benni (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Die Frage kam von  Bernhard:

Beitrag "Re: Floppy FDD Diskette an AVR Mikrocontroller ATmega Beispiele Assembler"

-------

Aus Bernhards vorangegangenen Beiträgen und der verlinkten Tabelle 
entnehme ich, dass es sich um eine 3,5 Zoll HD-Diskette handelt.

1,44 MByte (HD): 2 Seiten, 18 Sektoren, 80 Spuren

Auch die 2 µs / Bit sprechen für eine 3,5 Zoll HD mit 500 KBit / s 
Übertragungsgeschwindigkeit.

Autor: Bernhard S. (bernhard)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Es handelt sich um eine 1,44 MByte (HD) mit 300/min.

Sorry, hatte ich vergessen mit anzugeben.

Autor: nachtmix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard S. schrieb:
> In einem Sektor finden wir alle 512 "A" wieder.
>
> In den anderen Sektoren tauchen auch 512 gleiche Bytes auf, das ist
> schon mal gut, müssten eigentlich auch alles "A" sein.
> Nur hier scheint meine Synchronisation stark verbesserungswürdig zu
> sein.

Das erinnert mich stark an meine Experimente mit dem TRS-80, als ich 
mich seinerzeit entscheiden musste, ob ich den Auftrag mit den 
hardsektorierten MFM-Floppies überhaupt annehmen wollte.

Du wirst die AAAA (41h) schon wiederfinden, wenn du die ((( (28h) 
Sequenz einmal bitweise verschiebst. Die Synchronisation der Bits 
besteht ja offensichtlich, und sie wird durch die PLL auch während des 
Lesens der Daten aufrecht erhalten:
010000010100000101000001010000010100000101000001  AAAA, 41h MSB first
     001010000010100000101000001010000010100000101000  ((((, 28h MSB first
Den Sektor mit der  <<< (3Ch) Sequenz hingegen, wirst evtl. nicht du 
beschrieben haben, sondern das sind vielleicht noch Daten, die beim 
Formatieren geschrieben wurden. Andererseits ist die Zuordnung der 
Flußwechsel zu den Bitwerten bei MFM nicht immer trivial.
Man sollte solche Experimente daher stets mit frisch formatierten 
Floppies machen, damit man nicht über irgendwelche Dateireste stolpert, 
die das Diskmanagement hat stehen gelassen.





Rufus Τ. F. schrieb:
> Ich vermute stark, daß mit "alle Formate" nur alle am PC verwendeten
> Formate gemeint sind.

Ja, und da frage ich mich, was die Quälerei mit dem Datenseparator soll, 
anstatt einfach das Floppylaufwerk an einen alten PC anzuschliessen.
Für fremde Filesysteme gibt es da Tools, ich verwende z.B. den HxD - 
Hexeditor, mit denen man Datenträger unter Umgehung des Filesystems 
auslesen und manipulieren kann.
Auch die diversen Linuxe haben entsprechende Utilities. Einfach mal die 
Dokumentation zu dd anschauen: https://de.wikipedia.org/wiki/Dd_(Unix)

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nachtmix schrieb:
> Ja, und da frage ich mich, was die Quälerei mit dem Datenseparator soll,
> anstatt einfach das Floppylaufwerk an einen alten PC anzuschliessen.

Nicht jeder hat noch einen so alten PC herumstehen.

Und die letzten PCs mit Onboard-FDC konnten einen auch überraschen, mir 
ist ein Asrock-Board untergekommen, das nur ein Diskettenlaufwerk 
ansteuern konnte, und das auch nur 3.5"-Laufwerke im BIOS-Setup kennen 
wollte.

Mein "kostbares" 3.5"+5.25"-Kombilaufwerk war mit diesem Board nicht zu 
gebrauchen, ich wollte ein paar alte 5.25"-Disketten auslesen.

Für 3.5"-Disketten habe ich ein USB-Laufwerk, ich habe auch schon 
versucht, herauszufinden, ob der darin befindliche USB-FDC dazu zu 
überreden ist, mit einem 5.25"-Laufwerk zu funktionieren, habe aber im 
Datenblatt keine Hinweise darauf finden können.

Autor: Bernhard S. (bernhard)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ein 22Mhz getakteter ATmega1284p liest die Spur-20, ermittelt 16.000 
Zeitabstände zwischen den einzelnen Impulsen (ca. 40ms lang, entspricht 
knapp 4 Sektoren) und sendet diesen "Zeitenstrom" per RS232 an den PC.

Das kleine selbstgefummelte Visual-Basic-Programm erleichtert die 
Auswertung.

Eine 3.5" Diskette wurde vorher mit 1.457.664 Bytes (=2847 x 512) "A" 
(41h)  beschrieben, ich hänge die Datei mal mit an.

Im Zeitenstrom wurde das Muster "...111111123232132321323211111112..."
(00h A1h A1h FEh) schnell gefunden, ab hier beginnt der ID-Record.

Die 14h (Spur-Nr 20) ist auch sichtbar,
die Freude darüber ist immer noch riesig ^^

Das Muster "...11111112323213232132321111131..." kennzeichnet den 
DATA-Record, ab hier finden wir 512 x "A" wieder... die Freude darüber 
steigert sich weiter :-)

Nach einer momentanen Meinung ist die Schutzverletzung im MFM-Signal 
bedeutungslos.

Man könnte nach den Mustern suchen und anschließend die Daten bequem 
decodieren.

Den Aufbau der Spuren fand ich hier:
http://info-coach.fr/atari/software/FD-Soft.php


Problem: Ich komme mit der CRC-Berechnung nicht klar, könnte jemand 
bitte helfen?



Jörg W. schrieb:
>> Bei 0xA1 (0b10100001) kullern die Bits vom Floppy so heraus:
>> ...10000101..?
>
> Ja.

...hmmm... ich habe folgendes festgestellt:

Ein 0xA1 (0b10100001) kullert so heraus:  ...10100001...


nachtmix schrieb:
> Du wirst die AAAA (41h) schon wiederfinden, wenn du die ((( (28h)
> Sequenz einmal bitweise verschiebst.

stimmt, man muss nur vorher das korrekte "Merkbit" in der Decodierung 
setzen, denn der Datenstrom synchronisiert sich nicht von alleine

: Bearbeitet durch User
Autor: Einer (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Und die letzten PCs mit Onboard-FDC konnten einen auch überraschen, mir
> ist ein Asrock-Board untergekommen, das nur ein Diskettenlaufwerk
> ansteuern konnte, und das auch nur 3.5"-Laufwerke im BIOS-Setup kennen
> wollte.
>
> Mein "kostbares" 3.5"+5.25"-Kombilaufwerk war mit diesem Board nicht zu
> gebrauchen, ich wollte ein paar alte 5.25"-Disketten auslesen.

Bei derartigen BIOSen half mir immer FDRead welches du im Anhang 
zusammen mit FDFormat findest.

Unter DR-DOS habe ich viele Disketten mit 3,5 und 1.72 MB benutzt.
Die waren teuer damals.
Auch wenn diese mal alle waren wurden 5.25er mit 1.44 MB Formatiert.
es gab auch noch möglichkeiten noch mehr darauf zu Quetschen 2M Format.
Aber das war unzuverlässig.

Also auch mal jenseits Track 80 mal schauen.
(wurde auch als Kopierschutz benutzt/hat aber nichts genützt)

PS. die FDFORMAT.DOC ist eine reine Textdatei nix WORD

Autor: Benni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Problem: Ich komme mit der CRC-Berechnung nicht klar, könnte jemand
> bitte helfen?

https://info-coach.fr/atari/hardware/FD-Hard.php

Am Ende der Seite sind die Abschnitte, "Computing CRC in hardware" und 
"Computing CRC in software", die die Berechnung gut erklären.

Autor: Bernhard S. (bernhard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke :-)

: Bearbeitet durch User
Autor: Bernhard S. (bernhard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: nachtmix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
foobar schrieb:
>> Früher™ konnten wir die Rückseite auch erst nutzen, nachdem man in die
>> Hülle noch eine zweite Öffnung für das Indexloch der Rückseite gestanzt
>> hat.
>
> Wie gesagt, "bei den üblichen soft-sektorierten Formaten". Da mußte man
> nur das Schreibschutzloch an der Seite "nachrüsten" - Indexloch war
> egal.

Das Verfahren hat nur den Schönheitsfehler, dass dabei keine richtige 
doppelseitige Diskette entsteht, weil sich die so beschriebene Rückseite 
in einem echten DS-Laufwerk falschrum dreht ;-)

Autor: nachtmix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard S. schrieb:
> Nach einer momentanen Meinung ist die Schutzverletzung im MFM-Signal
> bedeutungslos.

Nicht ganz.
Die Protokollverletzung (wie kommst du auf Schutzverletzung?) 
identifiziert die Marken eindeutig.


> Man könnte nach den Mustern suchen und anschließend die Daten bequem
> decodieren.
Das geht zwar oft gut, aber dabei läufst du Gefahr ein zufällig 
passendes Muster im Datenstrom oder im Rauschen der Gaps als Marke 
anzusehen, mit dem Lesen zu beginnen und dadurch den wirklichen Anfang 
des gesuchten Adress- oder Datenfeldes zu verpassen.
Die unter solchen Umständen gelesenen Bits sind natürlich auch völlig 
wertlos.

Wenn der Prozessor bzw die Hardware schnell genug ist und genug RAM zur 
Verfügung steht, könnte man alternativ versuchen, einfach die Bits der 
ganzen Track, also von Indexpuls zu Indexpuls. in den Speicher zu 
schaufeln und dann per Software das Gemenge zu analysieren.
 Die PLL synchronisiert sich dabei zwar bei jedem Feld immer wieder neu, 
aber man kann ja anhand der Präambel ja leicht herausfinden, ob man nach 
positiven oder komplementären Marken und Daten sucht.

Wenn Geschwindigkeit der Hardware und die Grösse des Speichers 
ausreichen um die vom Laufwerk gelieferten Impulse innerhalb einer 
Bit-Zeit mehrfach abzutasten, könnte man sogar auf die externe PLL 
verzichten und auch diese Funktion im Nachhinein per Software erledigen.

Die Sequenz der Sektornummern muss übrigens nicht kontinuierlich 
steigend 0-1-2-3...sein, sondern kann auch verschachtelt und sogar 
zufällig sein. Das legt man bei der Formatierung fest.
Verschachtelte Sektoren (Interlaced oder Interleaved) verwendet man, 
wenn das Lesen oder Schreiben einer ganzen Track auf mehrere Umdrehungen 
verteilen möchte, weil z.B. die Hardware die Daten nicht schnell genug 
liefern oder verarbeiten kann, während man scheinbar zufällige -auch 
fehlende- Sektornummern z.B. bei manchen Kopierschutzverfahren findet.

Autor: Andreas B. (bitverdreher)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
nachtmix schrieb:
> Das Verfahren hat nur den Schönheitsfehler, dass dabei keine richtige
> doppelseitige Diskette entsteht, weil sich die so beschriebene Rückseite
> in einem echten DS-Laufwerk falschrum dreht ;-)

Inwiefern stört das?

Edit: Gerade gesehen, daß Du von einem doppelseitigen LW schreibst. Gab 
es so etwas? Ich kann mir vorstellen, wenn es das wirklich gegeben hat, 
war das vermutlich mit einem sehr hohen Verschleiß verbunden (harte 
Köpfe auf beiden Seiten).

: Bearbeitet durch User
Autor: Bernhard S. (bernhard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Nach einer momentanen Meinung ist die Schutzverletzung im MFM-Signal
>> bedeutungslos.
>
> Nicht ganz.
> Die Protokollverletzung (wie kommst du auf Schutzverletzung?)
> identifiziert die Marken eindeutig.


Das mag sein, aber nach einer eventuellen "Schutzverletzung",
also eine Lücke bzw. undefiniertes zw. Sektor-ID und Daten-ID, kommen 
sowieso 12 Synchronbytes + 3 x A1h, womit der Datenstrom wieder 
synchronisiert wird.


>> Man könnte nach den Mustern suchen und anschließend die Daten bequem
>> decodieren.
> Das geht zwar oft gut, aber dabei läufst du Gefahr ein zufällig
> passendes Muster im Datenstrom oder im Rauschen...

Nach dem Index-Impuls taucht nach einigen Bytes die eindeutige Sektor-ID 
auf, gefolgt vom der Daten-ID und den Daten.
In der Sektor-ID ist die physikalische Sektor-Nummer und Head immer mit 
angegeben.
Eine CRC-Prüfung macht das ganze schon ziemlich sicher.
Solange man nicht im Datenbereich nach einer ID sucht ist alles schön ^^


Bin gerade dabei mit einer Umdrehung alle 18 Sektoren mit einem
ATmega1284p /22Mhz einzulesen.

Beitrag "Floppy MFM Decoder selber bauen AVR ATmega Assembler Beispiele FDD Diskette"

Eine neue Verion ist in Arbeit.


>
> Wenn der Prozessor bzw die Hardware schnell genug ist und genug RAM zur
> Verfügung steht, könnte man alternativ versuchen, einfach die Bits der
> ganzen Track, also von Indexpuls zu Indexpuls...

sind pro Umderehung ca. bis ca. 95.000 MFM-Bits



> Die Sequenz der Sektornummern muss übrigens nicht kontinuierlich
> steigend 0-1-2-3...sein, sondern kann auch verschachtelt und sogar
> zufällig sein. Das legt man bei der Formatierung fest.

Das stimmt, vermutlich wird eine unter WinXP formatierte Diskette mit 
0-1-2-3-4... formatiert, so meine Messungen.

: Bearbeitet durch User
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard S. schrieb:
> Das stimmt, vermutlich wird eine unter WinXP formatierte Diskette mit
> 0-1-2-3-4... formatiert

1-2-3-4-5 … Sektornummern fangen immer mit 1 an, nicht mit 0.

Sector skew war eigentlich nur bei ganz alten Laufwerken und Systemen 
üblich, also bei den 26 Sektoren zu 128 Byte.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Andreas B. schrieb:
> Gerade gesehen, daß Du von einem doppelseitigen LW schreibst. Gab es so
> etwas?

Praktisch jedes Diskettenlaufwerk, das ab etwa Mitte der 80er Jahre 
produziert wurde, war ein doppelseitiges mit zwei Köpfen. Einseitige 
Laufwerke wurden nur für "Spar"-Anwendungen konstruiert, wenn es 
besonders billig sein musste (wie Laufwerke für manche Homecomputer).

Autor: nachtmix (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Jörg W. schrieb:
> 1-2-3-4-5 … Sektornummern fangen immer mit 1 an, nicht mit 0.

Stimmt. Ich hoffe du verzeihst mir den Patzer. Ist ja schon lange her.

Andreas B. schrieb:
> Gerade gesehen, daß Du von einem doppelseitigen LW schreibst. Gab
> es so etwas?

Selbstverfreilich.
Pin32 ist der Head-Select.
http://bitsavers.informatik.uni-stuttgart.de/pdf/t...

Andreas B. schrieb:
> wenn es das wirklich gegeben hat,
> war das vermutlich mit einem sehr hohen Verschleiß verbunden (harte
> Köpfe auf beiden Seiten).

Nicht mehr als bei den späteren 3,5" Laufwerken.
Ein Kollege hat damals versucht durch etliche Tage langen Dauerbetrieb 
eine 5,25"-Diskette zu beschädigen: Erfolglos.
Die Magnetköpfe sind ja auch nicht scharfkantig, sondern leicht konvex 
und in einer ebenfalls konvexen und auf Hochglanz polierten Glasmasse 
eingebettet.
Probleme gab es, wenn sich eingeschleppte harte Staubkörnchen unter dem 
Kopf festgesetzt hatten. Dadurch wurde (genau wie bei der späteren 3,5" 
Scheibe) im Handumdrehen die Magnetschicht der Diskette zerstört; 
"Spanabhebende Datenverarbeitung".

Bernhard S. schrieb:
> In der Sektor-ID ist die physikalische Sektor-Nummer und Head immer mit
> angegeben.

Nein, das ist eine logische Sektornummer, die mit der physikalischen 
Lage des Sektors nichts zu tun hat.
Wenn man die logischen Sektornummern der nächsten Track oder Seite z.B. 
eine Viertel Umdrehung später beginnen lässt, kann man die Daten 
schneller lesen, weil man nach einem Spur/Seitenwechsel nicht erst auf 
den Index zu warten braucht. Die Konsequenz ist natürlich, dass dann der 
physikalisch erste Sektor eine höhere Hausnummer hat.

Bernhard S. schrieb:
> Nach dem Index-Impuls taucht nach einigen Bytes die eindeutige Sektor-ID
> auf, gefolgt vom der Daten-ID und den Daten.

Aber du findest sie vielleicht nicht mehr, weil schon vorher im 
Datenmüll etwas so aussah. :-)
Dann hilft es auch nicht mehr, dass der CRC dir bescheinigt, dass du 
nicht die gewünschten Daten erwischt hast.

Bernhard S. schrieb:
> sind pro Umderehung ca. bis ca. 95.000 MFM-Bits

Na und?
Bei den Geschwindigkeiten heutiger Prozessoren und der Kapazität der 
Speicher sollte das kein Hinderungsgrund sein.

Autor: Bernhard S. (bernhard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> In der Sektor-ID ist die physikalische Sektor-Nummer und Head immer mit
>> angegeben.
>
> Nein, das ist eine logische Sektornummer, die mit der physikalischen
> Lage des Sektors nichts zu tun hat.

Du hast Recht. Wir müssen die Bezeichnungen korrekt wählen.

Eine Diskette besitzt 2.880 physikalische Sektoren

(80 Sektoren x 2 Heads x 18 Sektoren pro Spur)

Reihenfolge, wenn nicht gerade Verschachtelte Sektoren (Interlaced oder 
Interleaved), 0,1,2,3,4...


Jede Spur besitzt 18 logische Sektoren

Reihenfolge bei Win98 WinXP formatiert: 1-2-3-4...18



>> sind pro Umderehung ca. bis ca. 95.000 MFM-Bits

>Na und?
>Bei den Geschwindigkeiten heutiger Prozessoren und der Kapazität der
>Speicher sollte das kein Hinderungsgrund sein.

Der ATmega1284p besitzt leider nur 16k SRAM

: Bearbeitet durch User
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard S. schrieb:
>>> sind pro Umderehung ca. bis ca. 95.000 MFM-Bits
>
>> Na und?
>> Bei den Geschwindigkeiten heutiger Prozessoren und der Kapazität der
>>>Speicher sollte das kein Hinderungsgrund sein.
>
> Der ATmega1284p besitzt leider nur 16k SRAM

Sollte doch ausreichen, du brauchst etwa 13 k für den Datenpuffer.

Autor: Bernhard S. (bernhard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Sollte doch ausreichen, du brauchst etwa 13 k für den Datenpuffer.

warum nur 13k SRAM ?

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard S. schrieb:
> warum nur 13k SRAM ?

Weil du Bits mit Bytes verwechselt hast?

Autor: Bernhard S. (bernhard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Weil du Bits mit Bytes verwechselt hast?

meintest Du hier:

> sind pro Umderehung ca. bis ca. 95.000 MFM-Bits

Bei einer Umdrehung habe ich 95.000 Impulse am DATA-Pin gemessen.

Hätte besser das Wort "Impulse" verwenden sollen.... sorry

Autor: Bernhard S. (bernhard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Nach dem Index-Impuls taucht nach einigen Bytes die eindeutige
>>Sektor-ID auf, gefolgt vom der Daten-ID und den Daten.

>Aber du findest sie vielleicht nicht mehr, weil schon vorher im
>Datenmüll etwas so aussah. :-)
>Dann hilft es auch nicht mehr, dass der CRC dir bescheinigt, dass du
>nicht die gewünschten Daten erwischt hast.

Diese Version liest eine komplette Spur nach dem "Suchmuster-Prinzip"
ein, bis jetzt konnte ich noch keinen Decodierfehler bei den getesteten 
Disketten feststellen.

Beitrag "Re: Floppy MFM Decoder selber bauen AVR ATmega Assembler Beispiele FDD Diskette"

: Bearbeitet durch User
Autor: Andreas B. (bitverdreher)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:
> Praktisch jedes Diskettenlaufwerk, das ab etwa Mitte der 80er Jahre
> produziert wurde, war ein doppelseitiges mit zwei Köpfen. Einseitige
> Laufwerke wurden nur für "Spar"-Anwendungen konstruiert, wenn es
> besonders billig sein musste (wie Laufwerke für manche Homecomputer).

Da ist wohl damals was an mir vorbeigegangen. Vermutlich waren diese LW 
auch recht teuer. Diese Anwender konnten sich dann auch gleich 
doppelseitige Disketten leisten und brauchten sie nicht zu lochen. ;-)
Ich weiß nur noch wie damals (Anfang der 80er) für ein eine 5MB oder 
10MB(!) HD etwa 3000DM aufgerufen wurde.

nachtmix schrieb:
> Nicht mehr als bei den späteren 3,5" Laufwerken.

Da waren die Scheiben ja schon nicht mehr "Floppy". Ich bin davon 
ausgegangen, daß diese weichen nachgiebigen 5 1/4" Scheiben bei den 
damaligen Materialien schon sehr geholfen haben den Kopf nicht zu 
beschädigen.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas B. schrieb:

> Diese Anwender konnten sich dann auch gleich
> doppelseitige Disketten leisten und brauchten sie nicht zu lochen. ;-)

Die Disketten waren doch sowieso doppelseitig beschichtet, sonst hätte 
das mit dem Lochen und Umdrehen ja auch nicht funktioniert.

> Da waren die Scheiben ja schon nicht mehr "Floppy".

Doch, die eigentliche Disk war auch bei 3.5" "Floppy". Nur der Antrieb 
in der Mitte und die Schachtel rundrum waren steif.

Autor: Andreas B. (bitverdreher)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Die Disketten waren doch sowieso doppelseitig beschichtet, sonst hätte
> das mit dem Lochen und Umdrehen ja auch nicht funktioniert.

Trotzdem waren die doppelseitigen Disketten teuerer, sonst hätte sich 
die locherei ja gar nicht gelohnt.

Hier noch was interesantes gefunden:
http://www.moria.de/~michael/floppy/floppy.pdf

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas B. schrieb:
> Trotzdem waren die doppelseitigen Disketten teuerer, sonst hätte sich
> die locherei ja gar nicht gelohnt.

Du verkennst den Sinn der Locherei komplett. Es wurde in der Tasche der 
Diskette eine neue Öffnung angebracht, damit ein einseitig arbeitendes 
Laufwerk nach dem Umdrehen der Scheibe sein Indexloch finden konnte 
(und außerdem noch eine Kerbe für die Schreibschutz-Lichtschranke).

Ein doppelseitiges Laufwerk (zwei Köpfe) konnte die Rückseite ohnehin 
einfach so beschreiben, und doppelseitige Disketten besaßen trotzdem nur 
erstmal eine Öffnung für das Indexloch.

Bei einer wirklich nur einseitig beschichteten Diskette (sind mir nie 
untergekommen) hätte der Trick mit dem Lochen gar nicht funktioniert.

: Bearbeitet durch Moderator
Autor: Andreas B. (bitverdreher)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Du verkennst den Sinn der Locherei komplett. Es wurde in der Tasche der
> Diskette eine neue Öffnung angebracht, damit ein einseitig arbeitendes
> Laufwerk nach dem Umdrehen der Scheibe sein Indexloch finden konnte
> (und außerdem noch eine Kerbe für die Schreibschutz-Lichtschranke).

Das habe ich schon verstanden. Irgendwie reden wir aneinander vorbei.

Autor: soul e. (souleye)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Andreas B. schrieb:
>
>> Diese Anwender konnten sich dann auch gleich
>> doppelseitige Disketten leisten und brauchten sie nicht zu lochen. ;-)
>
> Die Disketten waren doch sowieso doppelseitig beschichtet, sonst hätte
> das mit dem Lochen und Umdrehen ja auch nicht funktioniert.

Das war nötig, weil manche Single Side-Laufwerke den Kopf oben und den 
Filz unten hatten und andere umgekehrt.


Umdrehen hat zwei Nachteile :

* bei jedem Umdrehen dreht sich auch die Drehrichtung der Magnetscheibe 
in der Hülle. Damit muss die Filz-Polsterung "umgekippt" werden, was 
erhöhten Abrieb verursacht.

* die Spuren auf Seite 0 und 1 liegen sich exakt gegenüber. Bei 
doppelseitigen Laufwerken sind sie um eine halbe Spurbreite versetzt. 
Wenn das Laufwerk ausreichend tief magnetisiert wird so die Gegenseite 
angegriffen.

Beides hat aber in der Praxis nie gestört -- meine ~400 Apple 
II-Disketten von 1980 - 1990 sind immer noch problemlos lesbar.

Autor: Andreas B. (bitverdreher)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas B. schrieb:
> Das habe ich schon verstanden.

Jörg W. schrieb:
> und doppelseitige Disketten besaßen trotzdem nur
> erstmal eine Öffnung für das Indexloch.

Doch nicht. Das ist mir entgangen. ;-)

Autor: nachtmix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas B. schrieb:
> Ich weiß nur noch wie damals (Anfang der 80er) für ein eine 5MB oder
> 10MB(!) HD etwa 3000DM aufgerufen wurde.

Kommt hin.
Ich habe hier noch eine ST-506, die ich Anfang 1981 aus USA mitgebracht 
hatte, weil Seagate noch keine Exportlizenz hatte.
Das war ein mit dem Controller (Platine mit 8X300, etwa so groß wie 
DIN-A4)  gebündeltes Sonderangebot von Arrow und kostete knapp 2000 US$, 
beim damaligen Kurs gut 4000 DM.
Hinzu kamen bei der Landung in Düsseldorf noch die Einfuhrabgaben/Zoll, 
von -iirc- fast 800 DM.

Autor: nachtmix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Du verkennst den Sinn der Locherei komplett.

Wetten, dass du die folgende Lochung auch noch nicht kanntest:
Einige Sekretärinnen bei unseren Kunden betrieben "Datensicherung", 
indem sie die Disketten kopierten und die Duplikate dann mit einem 
gewöhnlichen Bürolocher behandelten um sie in Aktenordnern zu 
archivieren.

Autor: Benni (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
nachtmix schrieb:
> Jörg W. schrieb:
>> Du verkennst den Sinn der Locherei komplett.
>
> Wetten, dass du die folgende Lochung auch noch nicht kanntest:
> Einige Sekretärinnen bei unseren Kunden betrieben "Datensicherung",
> indem sie die Disketten kopierten und die Duplikate dann mit einem
> gewöhnlichen Bürolocher behandelten um sie in Aktenordnern zu
> archivieren.

Euer unwichtiges Geschwätz stört diesen Thread. Das ist hier ein 
technisches Forum, kein Facebook-Gedöns.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Das Lochen und Abheften funktionierte, wenn man darauf achtete, daß die 
Magnetscheibe in der Diskettenhülle vor dem Lochen auf der den Löchern 
gegenüberliegenden Seite saß. Ein paar Millimeter Spiel hatte die 
Scheibe in ihrer Hülle, und dann wurde sie beim Lochen nicht beschädigt.

Damit konnte man ahnungslose Wichtigtuer ins Entsetzen treiben, weil die 
das natürlich für komplett fatal hielten.

Bei 8"-Disketten allerdings war das Lochen allerdings eine wirklich 
dämliche Idee.


Im übrigen konnte man auch 3.5"-HD-Disketten abheften, der Abstand der 
Schreibschutz- und HD-Löcher entsprach exakt dem Abstand der Ringe von 
Ringordnern. Aktenordner hatten hingegen zu dicke Bügel.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.