Dieser Floppy MFM Decoder decodiert die einzelnen Sektoren
einer 3,5" HD Diskette (300 U/min).
Das Prinzip des Decoders ist ganz einfach:
- MFM Impulsabstände mit einem 8-Bit Timer ermitten,
vorher natürlich den Motor einschalten und den Index-Impuls abwarten
- die somit gemessenen Zeiten in Zellwerte (1,2 oder 3) umgerechnen
- und die 16.200 Zellwerte im SRAM ablegen
Bsp: "...1123232132321323211..."
- wenn SRAM komplett gefüllt, dann...
- nach einem betimmten Muster suchen
Bsp: "111111123232132321323211111112"
entspricht: 00h A1h A1h A1h FEh (ID-Sektor)
- Position des gefundenen Musters merken und dann...
- eine definierte Anzahl von Bytes decodieren (z.B. 20 Bytes), nach dem
Verfahren "...wenn Merkbit, dann schreibe.." und
das Ergebnis im SRAM ablegen
- diese Prozedur auch für die ID-DATA wiederholen und
die 512 Bytes des Sektors incl. CRC herausfiltern
- ein einzelnes falsches Bit in diesem Bitstrom bringt die
Decodierung komplett durcheinander, daher die Suche nach einem Muster
und anschl. Decodierung.
Eine PLL müsste sich auch immer wieder synchronisieren.
- im SRAM liegen dann die IDs der Sektoren, die IDs der DATAs und die
Sektorinhalte zur Abholung bereit, leider noch ohne CRC-Prüfung
Diese Version liest nur knapp 4 Sektoren aus, beim 4 Sektor reicht
leider der SRAM nicht aus, also stehen uns 3 Sektoren komplett zur
Verfügung.
Man könnte theoretisch in einem Byte bis 5 Zellwerte
(1,2 oder 3) hinterlegen (komprimieren).
SRAM 16.200 Bytes mal 5 = 81.000 Zellwerte,
mit etwas Glück werden alle 18 Sektoren einer Spur mit einer Umdrehung
ausgelesen.
Nur die Komprimierung bei diesen Zeitverhältnissen und die
Dekoprimierung bei den SRAM-Bedingungen scheint eine Herausvorderung zu
sein.
Theoretisch lässt sich eine HD-Diskete in 32 Sekunden auslesen,
schneller geht nicht :(
0,2 s/Umddr. x 80 Spuren x 2 Heads = 32 s
Eine MFM-Schutzverletzung ist bei diesem Verfahren uninteressant.
Eine Menueführung erlaubt u.a. folgendes:
- Sektoren read
- Messung Anzahl der Impulse pro Umdrehung
- Drehzahlmessung
- Spur Step +/-
- Spur NULL anfahren
- Head-Umschaltung
- Laufwerks-Umschaltung
- Motor on/off
- alle 17 Pin-Zustände anzeigen (bei Motor off--> alle HIGH)
- Data Write (eine konstante Frequenz wird an WRDATA angelegt)
Hier wurden sehr interessante Erkenntnisse und Meinungen
zusammengetragen, ich danke Euch für die Unterstützung:
Beitrag "Floppy FDD Diskette an AVR Mikrocontroller ATmega Beispiele Assembler"
Für konstruktive Hinweise bin ich sehr dankbar.
Bernhard
Ist die Sektorgröße fest codiert, lässt sie sich anpassen?
Wie groß schätzt Du den Aufwand ein, das auf niedrigere Datenraten (DD
und SD) anzupassen?
Ich habe einen ganzen Batzen alter DD-Disketten in einem etwas
ungewöhnlichen Format herumliegen, 80 Spuren, die erste mit SD und die
restlichen mit DD formatiert, alles mit 256-Byte-Sektoren,
die ich gerne auslesen möchte, um an die Daten darauf heranzukommen.
Dein Projekt ließe sich vermutlich erweitern, um z.B. die gelesenen
Sektoren auf eine SD-Karte zu schaufeln o.ä.
> Wie groß schätzt Du den Aufwand ein, das auf niedrigere Datenraten (DD> und SD) anzupassen?
ev. genügt es, den 8 Bit Timer0 entsprechend anzupassen,
momentaner Vorteiler:1
> Ich habe einen ganzen Batzen alter DD-Disketten in einem etwas> ungewöhnlichen Format herumliegen, 80 Spuren, die erste mit SD und die> restlichen mit DD formatiert, alles mit 256-Byte-Sektoren...
Das lässt sich anpassen, es muss nur der genaue Sektorenaufbau bekannt
sein, momentan wird der im Bild dargestellte Aufbau decodiert
In der Praxis sieht das Suchmuster so aus:
> Dein Projekt ließe sich vermutlich erweitern, um z.B. die gelesenen> Sektoren auf eine SD-Karte zu schaufeln o.ä.
Genau, das ist das Ziel.
Der Sektorinhalt einer beliebig formatierten CD soll auf eine SD-Card
geschrieben werden.
Hoffentlich lassen sich die SD-Sektoren auf 256 Bytes
umschalten...grübel?
Wenn nicht, was dann?
Bernhard S. schrieb:> Hoffentlich lassen sich die SD-Sektoren auf 256 Bytes> umschalten...grübel?
Nein. Gar keine Chance.
> Wenn nicht, was dann?
Kein 1:1-Sektor-Abbild erzeugen, sondern Image-Dateien. Dann nämlich
kann man die SD-Karte auch mit einem PC ohne Spezialprogramm lesen.
Zum Schreiben von Dateien braucht's halt einen FAT-Treiber, aber den
gibt es ja.
Danke für Deine Hinweise auf Anpassbarkeit, ich werd' mir das vermutlich
im November oder so mal zu Gemüte führen. Klingt auf jeden Fall
interessant.
ich kenne so ein Format nur von alten CP/M Rechnern und da waren in der
ersten Spur keine Daten sondern bloß das System. Da würde es doch
genügen das einmal auszulesen.
Diese Verion liest 18 Sektoren,
also eine komplette Spur bei einer Umdrehung ein und
speichert die Nutzdaten, Sektor-ID und 512 Data-Bytes,
im SRAM des ATmega1284p.
Einfaches Prinzip:
- Index-Impuls abwarten
- MFM Impulsabstände mit einem 8-Bit Timer ermitten und
in Zellwerte umrechnen (1,2 oder 3)
- eventuell auftretende MFM-Schutzverlezungen "Lücken" ignorieren,
der Timer läuft über und meldet
sowieso die nicht korrekte Zellwerte (Zeiten)
- nach dem Sektor-ID Muster suchen "23232132321323211111112"
- 6 Bytes decodieren (z.B. Spur-Nr, Head, logische Sektor Nummer, CRC)
nach dem Verfahren "...wenn Merkbit, dann schreibe.." und
das Ergebnis im SRAM speichern
- nach dem DATEN-ID Muster suchen "2323213232132321111131"
- 512 Bytes + 2 x CRC decodieren
nach dem Verfahren "...wenn Merkbit, dann schreibe.." und
das Ergebnis im SRAM speichern
- das ganze 18 mal fleißig in den 200ms wiederholen,
der 22MHz getaktete µC schafft das
- Fehlerprüfung z.B. sind bei allen Sektor-IDs
die logischen Sektor Nummern (1-2-3...18) korrekt, wenn ja,
dann erfreut uns eine freudig leuchtende grüne LED ^^
Die gespeicherten Daten stellt uns der RS232 Pin zur Verfügung und im
Display werden die ersten Bytes des logischen Sektors angezeigt.
Protokollaufbau 1+18x(6+512+2)=9.361 Bytes
2Ah Dummy (Start-Byte)
6 Bytes Sektor-ID
512 Bytes Data
2 Bytes CRC (Data)
6 Bytes Sektor-ID
512 Bytes Data
2 Bytes CRC (Data)
usw ...
- Spur read
- Messung maximale Anzahl der MFM-Impulse pro Umdrehung aller 80 Spuren
- Messung Anzahl der Impulse pro Umdrehung einer Spur
- Drehzahlmessung
- Spur Step +/-
- Spur NULL anfahren
- Head-Umschaltung
- usw.
Leider noch ohne CRC-Prüfung.
Wenn jemand möchte, der kann uns gern unterstützen :-)
Anmerkung:
Die SD-Card Anbindung ist schon vorbereitet^^
Das Laufwerk schaltet automatisch bei Inaktivität nach 60 s ab.
>kannst du die ersten Sektoren der Disk (Track 0, Seite 0) lesen und die>6.200 Bytes zum Spielen hier posten?
hab ich mit angehängt, würdest Du dafür die CRC-Routine schreiben ?
> Im Anhang ist eine CRC16-CCITT Routine
Du verwendest eine Tabelle... interessant.
Könntest Du mal bitte kurz und knapp erklären, wie diese Routinen
prinzipiell funktionieren?
C ist nicht gerade meine Stärke, ich könnte sie dann in Assembler
umfummeln :-)
Ich bin super extrem maximal begeistert,
nach diesem Decodierverfahren (Zeitmessung zwischen den MFM-Impulsen)
lässt sich in 2:30 Min eine Diskette auf eine SD-Card kopieren.
Ist schon seltsam,
wenn sich plötzlich eine 64GB SDHC mit 1,44 MB meldet^^
Bin gerade am grübeln, eigentlich benötigt die Schaltung nur einen
Taster und 2 LEDs und schon ist ein kostengünstiger Disketten-SD-Adapter
aufgebaut :-)
Rufus Τ. F. schrieb:> Kein 1:1-Sektor-Abbild erzeugen, sondern Image-Dateien. Dann nämlich> kann man die SD-Karte auch mit einem PC ohne Spezialprogramm lesen.
Es geht vermutlich noch einfacher:
Einfach einen µC nehmen, der über USB verfügt und die Lesedaten darüber
in den PC schaufeln, so als Dump per USB-VCP und über's Terminalprogramm
oder etwas, das man sich am PC dafür mal eben selber geschrieben hat.
Das schätze ich einfacher ein als neben der Floppy-Dekodierung auch noch
eine SD-Karte an einem ATmega zu betreiben.
W.S.
W.S. schrieb:> über's Terminalprogramm oder etwas, das man sich am PC dafür mal eben> selber geschrieben hat.
Welchen Teil von
> ohne Spezialprogramm
hast Du jetzt ignoriert?
Willst Du über das Terminalprogramm einen Hexdump transportieren, oder
gehst Du davon aus, daß man auf dem AVR so etwas wie XYZ-Modem zum
sauberen und verlustfreien Transport von Binärdaten durch
Terminalprogramme hindurch implementiert?
Das fertige Gerät :-)
Nach ca. 2 Minuten ist eine Diskette auf eine SD-Card
auch SDHC, mit FAT12, 1,44 MB, kopiert.
Man könnte auch auf das LCD versichten,
benötigt wird nur die Taste am Pin17, um den Kopiervorgang zu starten.
Hinweis:
Die 5V Stromversorgung könnte kurzzeitig, vorallem beim Start des
Diskettenlaufwerkes und anfahren einer Spur, mit ca. 1,5A belastet
werden.
Die SD-Schachtbeleuchtung sieht immer wieder schick aus ^^
Menueführung u.a. folgendes:
- Floppy Coppy
- Floppy Sektoren read
- Floppy Spur read
- Anzeige des Sektoren-Caches
- Messung der Zeitstempel einer kompletten Spur und Ausgabe per RS232
- Messung Anzahl der Daten-Impulse pro Umdrehung
- Drehzahlmessung
- Sektor Spur Head +/-
- Laufwerks-Umschaltung
- alle 17 Pin-Zustände anzeigen (bei Motor off--> alle HIGH)
Bernhard
DAS mag ich nachbauen!
Daher ein paar Fragen zum Schaltplan:
- 5 LEDs an Floppystiftleiste 8, 24, 26, 30, 34 ohne Widerstand.
Das sind welche mit eingebautem Widerstand (z.B. Reichelt LED 3MM 5V
RT)?
- PB2, PB3 LED-Widerstaende: wohl Standard 330 Ohm
- XTAL Kondensatoren: 2x 22pF
- PB4 LED-Widerstand 330 Ohm?
- PB6 an MISO@SDHC: Widerstand ist 470 Ohm?
Passt das?
Danke & Viele Gruesse!
Tiramisu schrieb:> - 5 LEDs an Floppystiftleiste 8, 24, 26, 30, 34 ohne Widerstand.
Das dürfte nur schludrig gezeichnet sein, wenn Du genau hinsiehst, hängt
das eine Ende der LEDs in der Luft.
>Das dürfte nur schludrig gezeichnet sein, wenn Du genau hinsiehst, hängt>das eine Ende der LEDs in der Luft.
Mir ist klar, dass die LEDs direkt am Floppyinterface nur
zu Debug- oder Show-Zwecken gut sind und keine funktionale Voraussetzung
sind.
Allerdings ist die Anzahl der LEDs des physikalischen Aufbaus (->Bilder,
ohne die Netzteilplatine) acht, die "LED-Lufthaenger" sind also
vermutlich
tatsaechlich verbaut.
Lass' die betreffenden LEDs einfach weg, solange Bernhard keine
Aufklärung liefert. Die betreffenden Leitungen würde ich nicht ohne Not
mit LEDs belasten - und wenn, dann mit "high-efficiency"-LEDs, und so
dimensionierten Vorwiderständen, daß maximal 1 mA oder eher weniger
fließt.
>die "LED-Lufthaenger" die "LED-Lufthaenger" sind also>vermutlich tatsaechlich verbaut.
ja, aber nicht zwingend notwendig,
dient nur zu "Debug- oder Show-Zwecken"^^
Die rote und die grüne (PB2, PB3) zeigen an,
ob die SD-Card korrekt initialisiert wurde, oder ob ein anderer
erkannter Fehler vorliegt.
Cornelius schrieb:> Wäre interessant, ob ein 12€ Salea-Clone reicht.
Warum nicht. Eine MFM-Diskette ("double density") macht 250 kbit/s, eine
MFM-HD-Diskette 500 kbit/s. Die Saleae-Clones schaffen 10-20 MHz, je
nachdem was sonst noch so am USB dranhängt.
>Mit einem Logikanalysator geht es scheinbar auch
Im Menue "Messung der Zeitstempel... Ausgabe per RS232"
habe ich diese Funktion mit eingebaut,
interessant gestaltet sich dann die Ausertung der übertragenen Daten
z.B. MFM-Decodierung, CRC ^^
Rufus Τ. F. schrieb:> Über welches Signal sollte das geschehen?
Bei manchen Laufwerken kann man sich den Mikroschalter auf Pin 2, 4 oder
34 des Steckers legen. Darüber kann das DOS dann den Diskettentyp
erkennen.
Die Maschine des TO kann/könnte HD und DD einfach anhand der
Taktfrequenz unterscheiden. Bei DD haben die Pulse 4, 6 und 8 µs
Abstand, bei HD 2, 3 und 4 µs.
PCs machen es durch Ausprobieren. DD lesen, geht nicht, muss wohl HD
sein. Geht auch nicht, Fehlermeldung ausgeben.
Der Mikroschalter bei 3,5" schaltet nur den Schreibstrom und die
Deemphasis um, und bei 5,25" muss das auch noch der Host machen (über
Pin 2 beim PC, andere System nutzen die Pins 2-6 und 34 auch mal
anders).
ich glaube bei den Teac 3,5" war das Pin2, so hatte ich am Atari ST die
Taktfrequenz vom WD1772-2 von 8MHz auf 16MHz umgeschaltet.
Zuerst mit Anzapfen vom 16MHz Systemtakt, später per GAL mit
Frequenzverdoppelung, Gatterlaufzeit + XOR.
Joachim B. schrieb:> ich glaube bei den Teac 3,5" war das Pin2,
...wenn Du es passend gejumpert hast. Pin 2 kann neben Ready und Disk
Changed als HD select-Eingang dienen oder den über Mikroschalter
erkannten Zustand ausgeben.
Die früheren Teac FD-235 hatten gefühlt 50 Jumper, über die man die von
Shugart seinerzeit nicht ganz so eindeutig definierten Pins
konfigurieren konnte. Später wurden das immer weniger, und die letzten
Revisionen der Leiterplatte hatten quasi die MS-DOS PC-Konfiguration
festverdrahtet. Beim PC ist Pin 2 ein Eingang, über den auf HD
umgeschaltet werden kann. 5,25er sind drauf angewiesen, 3,5er haben
meist den Pin ignoriert und ihren Mikroschalter abgefragt.
Das Projekt ist klasse, gefällt mir richtig gut.
Bernhard S. schrieb:> Nach ca. 2 Minuten ist eine Diskette auf eine SD-Card auch SDHC, mit> FAT12, 1,44 MB, kopiert.>> Man könnte auch auf das LCD versichten, benötigt wird nur die Taste am> Pin17, um den Kopiervorgang zu starten.
Wie aufwendig wäre es denn so etwas mit USB 3 Anbindung zu bauen?
Dann könnte man die extra Stromversorgung, das Display, den Button und
den SD Kartenleser weglassen.
Steuerung könnte dann allein über eine Software am PC erfolgen.
Und noch eine weitere Frage, könnte man damit auch Amiga Disketten
lesen?
Nano schrieb:> Und noch eine weitere Frage, könnte man damit auch Amiga Disketten> lesen?
theoretisch, aber der alte Amiga hatte nur DD und ein ganz anderes
Verfahren, in Software evt. machbar.
Ich hatte es leichter weil am Atari die "normalen" 8/16 MHz genutzt
wurden und sie direkt austauschbar waren, DD=720KB HD=1,44MB, Amiga
machte ja mit ihren DD=8xx KB Sonderlocken und ob es mit dem PC-Emulator
Laufwerke gab die beides konnten weiss ich nicht.
Hallo,
der Amiga hat MFM benutzt, allerdings mit 11 Sektoren/Track, daher die
880kB.
HD war ein Kompromiss, da die Datenaufbereitung durch Paula (Custom-IC)
erledigt wurde und die nicht schnell genug war, hat man bei den
HD-Laufwerken die einfach die Drehzahl auf DD-Datenrate bei HD
reduziert.
Prinzipiell müßte sich sich also schon lesen lassen, sowohl DD als auch
HD.
PC-HD-Laufwerke ließen sich am Amiga nicht als HD-Laufwerke einsetzen,
es gab wohl einige wenige Typen, wo daa das Laufwerk hardwaremäßig
modifizoeren konnte.
Kopierschutzmethoden gab es beim Amiga auf Disk recht wirkungsvolle,
weil man prinzipiell beliebige Daten auf den Track schreiben konnte.
PC-Laufwerke können Amiga Disketten prinzipiell lesen, allerdings kommen
die PC-Floppycontroller mit der Sektoranzahl nicht zurecht.
Gruß aus Berlin
Michael
Bernhard S. schrieb:> Für konstruktive Hinweise bin ich sehr dankbar.
denn hau rein, eine Software die alle Disketten lesen kann wäre toll
DD, Amiga usw. was gibts denn noch?
DD ist ja geklärt, Amiga im Prinzip auch
Sehr interessantes Projekt. Ich waere an einem Komplementaeren
interessiert.
Es gibt viele Messgeraete, die haben Floppies drin und ein DOS, oder
WinNT. Aber niemand hat mehr Floppies. Das Projekt waere also, die MFM
Signal des Controllers auszuwerten und eine SD Karte als (Multi-)Floppy
erscheinen zu lassen.
Abgesehen vom Floppy Laufwerk ist zB so ein 15 Jahre alter 40GHz
Spektrum- oder Networkanalyzer fuer +50kEuro eigentlich neuwertig und
macht nochmals 20 Jahre.
Der Markt fuer 1000er Stueckzahlen waere da.
Hallo,
Name H. schrieb:> Es gibt viele Messgeraete, die haben Floppies drin und ein DOS, oder> WinNT. Aber niemand hat mehr Floppies. Das Projekt waere also, die MFM> Signal des Controllers auszuwerten und eine SD Karte als (Multi-)Floppy> erscheinen zu lassen.
da müßte er dann mit den Gotek-Laufwerken konkurieren...
Die können das (fast) alles schon.
https://www.ebay.de/itm/163436923406
Gruß aus Berlin
Michael
Nano schrieb:> Wie aufwendig wäre es denn so etwas mit USB 3 Anbindung zu bauen?
Wozu USB3? Ist Dir USB2 für Diskettenlaufwerke zu langsam?
> Steuerung könnte dann allein über eine Software am PC erfolgen.
Als kommerzielles Produkt macht das "Kryoflux".
> Und noch eine weitere Frage, könnte man damit auch Amiga Disketten> lesen?
Ich will keine Reklame dafür machen, aber das Ding kann sogar
GCR-Disketten lesen.
Was ungeschickt gelöst ist, ist die fehlende Stromversorgung für
Diskettenlaufwerke, und die Software ist auch etwas ... seltsam.
Rufus Τ. F. schrieb:> Was ungeschickt gelöst ist, ist die fehlende Stromversorgung für> Diskettenlaufwerke, und die Software ist auch etwas ... seltsam.
die Neueren brauchten eh nur 5V, das geht ja siehe USB Floppy LW
Wer unbedingt 12V benötigt, da müsste man probieren ob srepup zu 12V
reicht oder nicht.
Ich kann es kaum probieren noch müsste alte PC schlachten, aber
mittlerweile mangels funktionierender Disketten ist meine Motivation
gering.
Joachim B. schrieb:> Wer unbedingt 12V benötigt, da müsste man probieren ob srepup zu 12V> reicht oder nicht.
Nun, aus der USB-Versorgung lassen sich 5.25"-Laufwerke nicht speisen,
die brauchen dafür entschieden zu viel. Aber auch herkömmliche
3.5"-Laufwerke brauchen dafür zu viel; in USB-Diskettenlaufwerken sind
Notebook-Laufwerke mit besonders geringer Stromaufnahme verbaut.
Obendrein gibt es ältere 3.5"-Diskettenlaufwerke, die auch 12V
benötigen.
Das ist aber nicht der Punkt; die Platine hat eine Buchse für einen
Hohlstecker, an dem eine Spannung > 5V angelegt werden kann.
Gut wäre es, wenn das wie bei USB-Gehäusen für 3.5"-Platten gelöst wäre;
12V werden an den 12V-Anschluss des Laufwerks durchgereicht, 5V werden
per Step-Down daraus erzeugt.
Und wenn man das Ding mit einem Notebook-3.5"-Laufwerk betreibt, setzt
man einen Jumper, und das Ding speist sich komplett über USB ...
Name H. schrieb:> Das Projekt waere also, die MFM> Signal des Controllers auszuwerten und eine SD Karte als (Multi-)Floppy> erscheinen zu lassen.
Sowas habe ich seit Jahren in Benutzung.
Suchmaschine->HxC2001
Michael U. schrieb:> der Amiga hat MFM benutzt, allerdings mit 11 Sektoren/Track, daher die> 880kB.
Interessant wird's beim Macintosh. Der codierte in GCR und nutzte für
die verschiedenen Bereiche der Diskette verschiedene Motordrehzahlen. So
konnte man auf den mechanisch längeren äußeren Spuren mehr Sektoren
unterbringen.
D.h. idealerweise ist der Pulsabstandsmessalgorithmus so flexibel, dass
er mit beliebigen Datenraten zurechtkommt. Das erschlägt dann nicht nur
das DD / DDauf5,25"HD / HD-Thema (250, 300 oder 500 kbit/s), sondern
auch solche Sonderfälle.
Die Decodierverfahren FM, MFM, RLL, GCR sind ja unabhängig davon. FM
könnte man daran erkennen dass er nur 1T und 2T Abstände gibt, bei MFM
kommt 3T dazu. GCR und RLL können noch längere Flusswechselabstände
haben, da wird's dann schwierig.
Rufus Τ. F. schrieb:> Nano schrieb:> Wie aufwendig wäre es denn so etwas mit USB 3 Anbindung zu bauen?>> Wozu USB3? Ist Dir USB2 für Diskettenlaufwerke zu langsam?>
Das Laufwerk benötigt doch 1,5 A, das kann USB 2 mit seinen
standardisierten 0,5A max nicht liefern, USB 3 schon, da ist es zum
Laden oder für Festplatten vorgesehen.
Um die Geschwindigkeit geht es nicht.
Nano schrieb:> USB 3 schon, da ist es zum Laden oder für Festplatten vorgesehen.
USB 3 liefert an Geräte maximal 900 mA.
Im Ladebetrieb kann auch USB2 mehr liefern, dann aber ist --wie bei USB3
auch-- keine Datenübertragung mehr drin.
Nano schrieb:> Das Laufwerk benötigt doch 1,5 A, das kann USB 2 mit seinen> standardisierten 0,5A max nicht liefern
nur halten sich nicht alle Geräte daran, es gibt viele die legen einfach
+5V an den USB Port, bis eine Leiterbahn abbrennt
Rufus Τ. F. schrieb:> Im Ladebetrieb kann auch USB2 mehr liefern
ja wenn die Geräte so und billigst gebaut sind und auf USB Controller
verzichten.
Alles schon erlebt!
MSI s262, Raspberry PI 1B
Joachim B. schrieb:> ja wenn die Geräte so und billigst gebaut sind
Das ist auch spezifikationskonform möglich; die "USB Battery Charger
Specification" ist ernstgemeint.
Dann aber ist, wie ich schon erwähnte, keine Datenübertragung möglich,
die Betrachtung also recht sinnlos.
Rufus Τ. F. schrieb:> Dann aber ist, wie ich schon erwähnte, keine Datenübertragung möglich,> die Betrachtung also recht sinnlos.
Gilt das immer oder könnte man wenigstens die Datenübertragung auf USB
1.1 runterschalten und diese beim Laden nutzen?
Ich frage, weil vielleicht hat man eine Möglichkeit geschaffen, dass das
Ladegerät mit dem Computer Ladezustandsdaten austauschen kann und wenn
USB 1.1 da weniger Störanfällig wäre, dann würde das ja für so etwas
reichen.
Nano schrieb:> Gilt das immer oder könnte man wenigstens die Datenübertragung auf USB> 1.1 runterschalten und diese beim Laden nutzen?
Nein.
Diese Diskussion bitte bei entsprechendem Interesse in einem anderen
Thread im passenden Forenbereich fortsetzen.
Hier geht es um das Projekt eines MFM-Diskettencontrollers.
Jetzt habe ich extra vorher nach Floppy im Forum gesucht um mir die
Arbeit zu sparen und da ich gestern nicht fündig wurde habe ich heute
den ganzen Tag damit verbracht selbst eine MFM Leseroutine zu schreiben.
Eigentlich klappt soweit alles nur das mit dem CRC wollte einfach nicht
stimmen. Also nochmals ins Forum und CRC Floppy gesucht und dann kommt
dieses Projekt zum Vorschein.
Superprojekt und erst noch in meiner Lieblingsprogrammiersprache!!!
Ich wollte jetzt mal schauen wie du die CRC berechnest, aber ich habe
nicht gefunden wo du das machst.
Meine CRC Routine berechnet leider nicht das gleiche was ich von der
Floppy lese. Ich nehme die gleiche Routine die ich auch bei meinen
SD-Card lese routine nehme nur. Brauchen die Floppy nicht das gleiche
Polynom wie die SD-Karten?
Meine Leseroutine unterscheidet sich ein bisschen von deinem Ansatz.
Auch ich verwende einen Timer aber ich decodiere MFM direkt. Das spart
ziemlich viel RAM.
Ahhh, lesen und suchen scheint bei mir im Moment nicht so richtig zu
funktionieren. Oben hat ja Benni den entscheidenden Hinweis gegeben. In
die CRC Berechnung fliessen auch die 3 Sync Marks und das ID byte ein.
Das erklärt mir jetzt auch warum in den Datenblätter zu Floppy
Controller ICs immer steht es müssen immer 3 Sync Marks sein. Jetzt
stimmen meine CRC mit den CRC auf der Floppy überein. Es ist also das
gleiche Polynom wie bei SD-Karten. Nach einem Track Read sieht das
Resultat jetzt endlich richtig aus.
1
Buff Mark Track Sector Side Length HCRC HCRC(c) CRC CRC(c)
> Auch ich verwende einen Timer aber ich decodiere MFM direkt. Das spart> ziemlich viel RAM.
Respekt!
An diese Variante draute ich mich nicht.
In meiner Version werden zuerst alle Zeitstempel einer Spur eingelesen
und anschließend, in aller Ruhe, decodiert.
> Ich wollte jetzt mal schauen wie du die CRC berechnest, aber ich habe> nicht gefunden wo du das machst.
Die CRC-Berechng ist leider noch nicht implementiert.
.
Peter S. schrieb:> Eigentlich klappt soweit alles nur das mit dem CRC wollte einfach nicht> stimmen.> Brauchen die Floppy nicht das gleiche Polynom wie die SD-Karten?
Floppy: // CRC16 CCITT X^16 x^12 + x^5 + 1
> Auch ich verwende einen Timer aber ich decodiere MFM direkt. Das spart> ziemlich viel RAM.
Kannst du deine Timerroutine posten?
Ja sicher, hier ist das Projekt, mit den letzten Korrekturen von heute
Morgen :-) (waren aber nicht relevant für die Funktion eher kosmetischer
Natur)
Es ist im Moment noch alles Work in Progress. D.h. weder der Aufbau noch
das Program sind sonderlich gut dokumentiert. Die Timerroutine selbst
ist ja nicht der Trick, das geht genau gleich wie mit dem Program von
Bernhard, also warten bis RD low ist, dann Timer lesen und auf Null
zurücksetzen und das Interval auswerten. Das macht auch der Amiga Floppy
Reader von Rob Smith so. Aber anstelle das Resultat in einen Wert
(1,2,3) umzuwandeln interpretiere ich direkt was das Datenmässig
bedeutet. Dieser Teil ist weil jeder Zyklus zählt ziemlicher
Spaghetticode da ich hier eine Statemachine ohne Tabelle implementiere
(so viele States hat das MFM decoding ja nicht).
Sonst einfach fragen wenn etwas nicht klar ist.
Das CPLD auf dem angehängten Bild ist im Moment noch nicht benutzt, es
braucht also nur den Atmega1284P. Das Ziel ist es die "Leseroutine" in
das CPLD zu packen (d.h. Synchronisation, MFM dekodierung und Byte Wide
Interface zum AVR).
Aber zuerst mache ich mich an eine Sector Write Routine, das verspricht
spannend zu werden (aber lange nicht so kompliziert wie die
Leseroutine).
Peter S. schrieb:> Das Ziel ist es die "Leseroutine" in das CPLD zu packen (d.h.> Synchronisation, MFM dekodierung und Byte Wide Interface zum AVR).
D.h. Dein CPLD wird so etwas wie ein FDC? Früher konnte man so etwas in
jedem Computer finden ...
Nein nicht ganz, das CPLD wird so etwas wie ein Digitaler Datenseparator
mit Bytewide Interface. Für einen FDC hat es zu wenig Resourcen. Das
Ziel ist es zuerst eine Version für 500kHz Datenrate (Floppy) zu
entwickeln und dann mit Faktor 10 zu beschleunigen, damit ich MFM Disks
lesen/schreiben kann. Tönt jetzt verwegen aber der Takt bleibt ja im
CPLD, gegen aussen hin hat es ja nur eine 5Mbps serielle Schnittstelle
zur HD und ein Bytewide Interface zum AVR.
Peter S. schrieb:> damit ich MFM Disks
Du meinst Festplatten?
Ui. Dann solltest Du das Ding gleich noch etwas flotter anlegen, denn
viele MFM-Platten wurden zum Ende hin mit RLL-Controllern betrieben (wie
dem WD1006SR2), obwohl das natürlich nicht offiziell spezifiziert war.
Wenn Du so etwas auslesen können möchtest, solltest Du also auch dieses
Aufzeichnungsverfahren verarbeiten können.
Der Festplatte selbst wird man nicht ansehen können, wie sie in der
Praxis genutzt wurde, und daß jemand über ein Vierteljahrhundert lang
den kompletten Krempel aufhebt ...
(Wobei: Meine zweite Festplatte habe ich aufgehoben, inklusisve des
Controllers. Nur kann man den nirgendwo mehr 'reinstecken. Ist eine
ST125, die ich mit einem RLL-Controller als ST138R betrieben hatte ...)
Ja Festplatten, und nein keine RLL "nur" MFM, Stichwort RQDX3 und
PDP-11. Noch laufen sie aber wer weiss wie lange noch. Einen MFM
Harddiskemulator habe ich schon mal angeschafft.
Write Sector funktioniert, dh. ich kann einen Sector schreiben und kann
danach die Floppy wieder vollständig lesen und der Inhalt des
geschriebenen Sektors ist korrekt, inkl. CRC :-). Der Code allerdings
braucht dringend eine Aufräumaktion.
Peter S. schrieb:> Write Sector funktioniert, dh. ich kann einen Sector schreiben und kann> danach die Floppy wieder vollständig lesen und der Inhalt des> geschriebenen Sektors ist korrekt, inkl. CRC :-). Der Code allerdings> braucht dringend eine Aufräumaktion.
Bitte die erweiterte Version posten.
Hier also die 16MHz Version. Für alle die es ausprobieren wollen:
Wie man den Atmega1248P mit dem Floppy Drive verbindet entnimmt man der
Dokumentation. Das Program hat eine Art User-Interface (USART0 38400baud
8p1n) das dem Apple II Monitor nachempfunden ist (.<+-MV) und ein paar
neue commandos hat (P füllt den angegebenen Bereich mit 0, 1, 2 3, etc,
X gibt 16 bytes im hexdump -C Format). Dazu füge ich dann immer wieder
Applikationsspezifische Kommandos hinzu
1
O Toggle Motor On
2
S Toggle Drive Select
3
nnT Seek to track, wobei man zuerst mit 0T kalibrieren sollte
4
R Liest den Track von Head 0 und dekodiert MFM und legt as ab 0x1000
5
im RAM ab wobie weils 8 bytes header und dann 520 bytes Daten mit CRC
6
und Füllbytes sind
7
K Analysiert den gelesenen Track und zeigt ein paar infos an
8
s<nW Schreibt den Buffer ab addresse n in den Sector s
Hier der Auszug einer "Sitzung"
1
*0t
2
3
*4t
4
Seek from 0x00 to 0x04
5
6
*r
7
8
*k
9
Buff Mark Trk Side Sect Leng HCRC HCRC(c) CRC CRC(c) Miss Miss
Ich habe den Aktuellen Inhalt des Projektes angehängt. (Die inlude
Dateien sind immer noch die gleichen wie im früher angehängten Archiv).
Der K Befehl zeigt den CRC wie er gelesen wurde und wie er sein sollte
(c) wie calculated. Miss bezieht sich auf die innerste Leseschlaufe.
Dort wird Miss incrementiert wenn die Verarbeitung zu lange geht, d.h.
nicht abgeschlossen ist bevor der nächste RD Impuls kommt.
Steht das Projekt oder tut ihr noch was?
Was geht denn nun?
MFM lesen und schreiben, gut.
Aber gehen da nur 3 1/2" Disketten Laufwerke oder auch die 5 1/4"?
Und welche Density?
Für die Gotek-Geräte gibt es FlashFloppy
(https://github.com/keirf/FlashFloppy) als Open Source. Da ist die
gesamte Software für verschiedenste Diskettenformate bereits
implementiert, sowohl lesend als auch schreibend und zuverlässig.
Das ist zwar die andere Richtung, aber umdrehen sollte eigentlich kein
Problem sein. Der Vorteil der Goteks ist, dass die mit ihrem STM32 mehr
Rechenleistung und RAM haben als ein AVR, was vieles vereinfacht.
Ich weiß, der Thread ist alt, aber FlashFloppy wurde hier noch nicht
erwähnt (oder ich hab es nicht gefunden).
Klar haben die STM32 mehr Rechenleistung und RAM als ein AVR. Aber ein
AVR reicht völlig. Und vor allem macht die Herausforderung, etwas auf
einem in die Jahre gekommenen 8-bit Prozessor zu programmieren wo andere
alle sofort zum 32-bit MCU greifen, viel Spass.
Ich hab übrigens meine Write Sector Routine umgebaut, so dass diese
jetzt die WD Pulse auch Timer gestützt generiert und man keinen Code
mehr braucht, bei dem man Cyclen zählen muss.
Es funktioniert auch mit 5 1/4 Zoll Laufwerken. Im HD Modus
unterscheiden sich die ja von den 3 1/2 nur durch die Anzahl der
Sektoren pro Track. Wenn man hingegen 360kbyte Floppy lesen will, dann
muss man aufpassen. Die Datenrate ist dann nur noch 250kbps, d.h. man
muss die Timerkonstanten alle verdoppeln. Aber wenn man 360kbyte Floppys
auf einem HD (PC-AT) Laufwerk lesen will, dann muss man noch ein
Double-Stepping einführen. Schreiben sollte man 360kbyte Floppies auf
PC-AT Laufwerken hingegen wegen der unterschiedlichen
Schreibkopfgeometrie nicht.
Peter S. schrieb:> Klar haben die STM32 mehr Rechenleistung und RAM als ein AVR.> Aber ein AVR reicht völlig.
Nachweislich. :-)
Ich dachte allerdings eher daran, dass man besser an Daten von schlecht
lesbaren Disketten rankommen kann (z.B. die Spur mehrfach lesen und die
Rohdaten erst korrelieren). Dazu braucht es in erster Linie RAM, der bei
den AVRs leider sehr dünn ist.
Alternative Diskettenformate (z.B. für Kopierschutz, diverses CP/M) sind
auch eine Herausforderung, je nachdem, wie verrückt die Autoren waren.
> Und vor allem macht die Herausforderung, etwas auf einem> in die Jahre gekommenen 8-bit Prozessor zu programmieren> wo andere alle sofort zum 32-bit MCU greifen, viel Spass.
Dem stimme ich allerdings uneingeschränkt zu.
Wenn man schlecht lesbare Floppys restaurieren will, dann ist die
digitale Floppy Schnittstelle der falsche Ort. Hier lohnt sich ein etwas
aufwändigerer Aufbau mit einem ADC. Da gibt es sogar spezialisiert
Hardware und Software dazu.
Versuchsaufbau.jpg
(230 KB)
Schaltung.png
(65 KB)
MFM_Decodierung.png
(110 KB)
MFM_Floppy.jpg
(53 KB)
Menue_Read_Sektor.jpg
(85 KB)
Read_Ergebnis.jpg
(190 KB)
STATISTIK_Impulslaenge.jpg
(120 KB)
Zellen_Bitstrom.png
(3,7 KB)
