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
Angehängte Dateien:
-
Schaltung.png
65 KB -
Versuchsaufbau_A.jpg
340 KB -
Versuchsaufbau_B.jpg
470 KB -
Platine.jpg
220 KB -
Floppy.jpg
230 KB -
RDDATA_PIN.jpg
55 KB -
PC_Pruefstecker_am_Flopy_BUS.jpg
390 KB
:
Bearbeitet durch User
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
> 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?
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
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
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
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.
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.
> 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.
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.
Angehängte Dateien:
-
Index0.bmp
220 KB -
Index1.bmp
220 KB
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
Diese Infos dürften interessant sein.
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.
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%20Floppy%20Controller.pdf Dort Seite 13. Ein übliches 8" Laufwerk war das Shugart SA800 http://deramp.com/downloads/floppy_drives/shugart/SA800%20Maintenance%20Manual.pdf 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_formats#/media/File:Floppy_disk_2009_G1.jpg Gruss
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.
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
Da war doch was … ah ja, i8272 alias µPD765. Ja, völlig vermasselt. Asche auf mein Haupt :)
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...
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.
Arduino Amiga Floppy Disk Reader/Writer Open Source and Free! - by Robert Smith http://amiga.robsmithdev.co.uk/history
Angehängte Dateien:
-
MFN_theoretisch.JPG
110 KB -
MFN_Floppy.jpg
52 KB
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
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.
Angehängte Dateien:
-
MFM_Henrik.jpg
170 KB
> 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?
Deinen Datenstrom kannst du mit der Lese-Routine von Henrik Haftmann dekodieren: https://www-user.tu-chemnitz.de/~heha/basteln/PC/usbfloppy/mfmread.htm
Angehängte Dateien:
-
MFM_mit_Referenz.jpg
57 KB
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 :-)
Angehängte Dateien:
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
Bernhard S. schrieb: > Bei 0xA1 (0b10100001) kullern die Bits vom Floppy so heraus: > ...10000101..? Ja.
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.
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...
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 ...
Angehängte Dateien:
-
MFM_DECODIERUNG.png
47 KB -
Bitmuster.jpg
170 KB
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
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!
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.)
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 ;)
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
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.
Rufus Τ. F. schrieb: > Sieh Dir den WD37C65 an. Solche Teile sollte man doch von alten PC-Mainboards ausschlachten können.
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?
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.
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 ;)
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
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
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.
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"?
Otto schrieb: > Rufus Τ. F. schrieb: >> Was ist "Video Scharnier"? > > Video-Genie? Ja, der asiatische TRS-80 Nachbau.
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. https://www.ebay.de/itm/USB-Externes-Diskettenlaufwerk-3-5-FDD-Disk-Drive-Diskette-Laufwerk-tragbares/332532732221
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.
Angehängte Dateien:
-
MFM_Schutzverletzung.png
2,5 KB
>... 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 ? ^^
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.
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.
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.
Angehängte Dateien:
> ...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
"Anfängerfrage: Wieviel Sektoren befinden sich auf bzw. in einer Tabelle unten: https://www.elektronik-kompendium.de/sites/com/0310211.htm
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.
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.
Angehängte Dateien:
Es handelt sich um eine 1,44 MByte (HD) mit 300/min. Sorry, hatte ich vergessen mit anzugeben.
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:
1 | 010000010100000101000001010000010100000101000001 AAAA, 41h MSB first |
2 | 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)
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.
Angehängte Dateien:
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
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
> 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.
Danke :-)
:
Bearbeitet durch User
Mögliche MFM Decoder in Assembler: Beitrag "Floppy MFM Decoder selber bauen AVR ATmega Assembler Beispiele FDD Diskette"
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 ;-)
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.
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
>> 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
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.
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).
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/teac/TEAC_FD-55FV-13_Specification_Rev_E.pdf 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.
>> 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
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.
> Sollte doch ausreichen, du brauchst etwa 13 k für den Datenpuffer.
warum nur 13k SRAM ?
>>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
>> 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
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.
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.
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
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
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.
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.
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. ;-)
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.
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.
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.
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.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.