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
:
Bearbeitet durch User
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.ä.
> Ist die Sektorgröße fest codiert, lässt sie sich anpassen?
lässt sich problemlos anpassen:
Im Beispiel 580 = ID-Data + 512 + CRC + ein paar Dummys
1 | |
2 | MFM_ZEIT: |
3 | ldi ZL, LOW(580) ; Anzahl BYTES |
4 | ldi ZH,HIGH(580) |
5 | call MFM_DECODIERUNG_XYZ ; DECODIERUNG (X=DATA Y=Ergebnis Z=AnzBytes |
> 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
1 | |
2 | TIMER0_INITIALISIERUNG: |
3 | ; TCCR0A – Timer/Counter Control Register A |
4 | ldi temp, (0<<COM0A1)| (0<<COM0A0)|(0<<COM0B1)|(0<<COM0B0)|(0<<WGM01)|(0<<WGM00) |
5 | OUT TCCR0A,temp |
ggf. die Zeitgrenzen anpassen
1 | |
2 | ; Umrechnung von Zeiten- in Zellenwerte |
3 | ldi temp2,1 ; Zelle1 |
4 | cpi temp1,54 |
5 | brlo MFN_ZEIT_w |
6 | ldi temp2,2 ; Zelle2 |
7 | cpi temp1,75 |
8 | brlo MFN_ZEIT_w |
9 | ldi temp2,3 ; Zelle2 |
10 | MFN_ZEIT_w: |
11 | ST X+,temp2 ; Zeitstempel in Zellenwerten |
> 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:
1 | |
2 | |
3 | TABELLE_ID_SECTOR: |
4 | .db 1,1,1,1,1,1,1,2,3,2,3,2,1,3,2,3,2,1,3,2,3,2,1,1,1,1,1,1,1,2,0,0 |
5 | |
6 | TABELLE_ID_DATA: |
7 | .db 1,1,1,1,1,1,1,2,3,2,3,2,1,3,2,3,2,1,3,2,3,2,1,1,1,1,1,3,1,0,0,0 |
> 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?
:
Bearbeitet durch User
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.
Kannst du die ersten Sektoren der Disk (Track 0, Seite 0) lesen und die 16.200 Bytes zum Spielen hier posten?
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 ?
:
Bearbeitet durch User
> ... würdest Du dafür die CRC-Routine schreiben?
Im Anhang ist eine CRC16-CCITT Routine mit einem Aufruf der Daten eines
ID-Records.
1 | ID-Record: a1 a1 a1 fe 14 00 01 02 |
2 | CRC: 1b 39 |
> 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 :-)
Bernhard S. schrieb: > C ist nicht gerade meine Stärke, ich könnte sie dann in Assembler > umfummeln :-) Erklärung: http://www.ross.net/crc/download/crc_v3.txt
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 :-)
:
Bearbeitet durch User
...und so sieht es in der Praxis aus...
Gibt es zu dem Projekt aktuellere Quellen als das zip-file vom 02.10 (2018-10-02_V1_ok.zip)? Das LCD ist ein paralleles 0-8-15 LCD? Super Projekt!
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
:
Bearbeitet durch User
"fertsch" - sehr schön.
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.
Mit einem Logikanalysator geht es scheinbar auch: https://www.chzsoft.de/site/hardware/preserving-a-floppy-disk-with-a-logic-analyzer/ Wäre interessant, ob ein 12€ Salea-Clone reicht.
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 ^^
:
Bearbeitet durch User
Bernhard S. schrieb: > Das fertige Gerät :-) sehr schick, kann es nur HD oder auch DD, ich sehe gerade die HD Erkenung nicht am Bus
Joachim B. schrieb: > ich sehe gerade die HD Erkenung nicht am Bus Über welches Signal sollte das geschehen? In einem Manual eines 3.5"-Laufwerks konnte ich keinen Hinweis darauf finden: https://docs.sony.com/release/MPF920Z.pdf
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.
soul e. schrieb: > Die Maschine des TO kann/könnte HD und DD einfach anhand der > Taktfrequenz unterscheiden. So macht das wohl Kryoflux.
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.
:
Bearbeitet durch User
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.
soul e. schrieb: > Beim PC ist Pin 2 ein Eingang, über den auf HD destawegen hatte ich mich beim Atari ST daran orientiert. :)
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.
Hm, ach so dann habe ich das falsch verstanden. Dachte immer mit USB 3 würde mehr gehen. Vor allem über den neuen Steckertypen USB-C.
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
:
Bearbeitet durch User
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) |
2 | 0x1008 0xFE 0x20 0x00 0x0C 0x02 0x8B7D 0x8B7D 0x3C90 0x3C90 |
3 | 0x1218 0xFE 0x20 0x00 0x0D 0x02 0xB84C 0xB84C 0xE287 0xE287 |
4 | 0x1428 0xFE 0x20 0x00 0x0E 0x02 0xED1F 0xED1F 0x5AC2 0x5AC2 |
5 | 0x1638 0xFE 0x20 0x00 0x0F 0x02 0xDE2E 0xDE2E 0x6708 0x6708 |
6 | 0x1848 0xFE 0x20 0x00 0x10 0x02 0xCD63 0xCD63 0x79BE 0x79BE |
7 | 0x1A58 0xFE 0x20 0x00 0x11 0x02 0xFE52 0xFE52 0x533B 0x533B |
8 | 0x1C68 0xFE 0x20 0x00 0x12 0x02 0xAB01 0xAB01 0x778F 0x778F |
9 | 0x1E78 0xFE 0x20 0x00 0x01 0x02 0xFD21 0xFD21 0x86EF 0x86EF |
10 | 0x2088 0xFE 0x20 0x00 0x02 0x02 0xA872 0xA872 0xB50F 0xB50F |
11 | 0x2298 0xFE 0x20 0x00 0x03 0x02 0x9B43 0x9B43 0xD53A 0xD53A |
12 | 0x24A8 0xFE 0x20 0x00 0x04 0x02 0x02D4 0x02D4 0x4605 0x4605 |
13 | 0x26B8 0xFE 0x20 0x00 0x05 0x02 0x31E5 0x31E5 0x5674 0x5674 |
14 | 0x28C8 0xFE 0x20 0x00 0x06 0x02 0x64B6 0x64B6 0x0A66 0x0A66 |
15 | 0x2AD8 0xFE 0x20 0x00 0x07 0x02 0x5787 0x5787 0xD2C7 0xD2C7 |
16 | 0x2CE8 0xFE 0x20 0x00 0x08 0x02 0x47B9 0x47B9 0xAA7B 0xAA7B |
17 | 0x2EF8 0xFE 0x20 0x00 0x09 0x02 0x7488 0x7488 0xF30A 0xF30A |
18 | 0x3108 0xFE 0x20 0x00 0x0A 0x02 0x21DB 0x21DB 0x4514 0x4514 |
19 | 0x3318 0xFE 0x20 0x00 0x0B 0x02 0x12EA 0x12EA 0x4788 0x4788 |
> 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.
Ah, also kein PC-Krempel. Auf jeden Fall: Hut ab.
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.
Und mit ein bisschen Optimieren läuft das ganze jetzt auch mit 16MHz statt 22M.1184MHz.
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 |
10 | 0x1008 0xFE 0x04 0x00 0x11 0x02 0x03ED 0x03ED 0x2BF6 0x2BF6 0x00 0x00 |
11 | 0x1218 0xFE 0x04 0x00 0x12 0x02 0x56BE 0x56BE 0x2BF6 0x2BF6 0x00 0x00 |
12 | 0x1428 0xFE 0x04 0x00 0x01 0x02 0x009E 0x009E 0x2BF6 0x2BF6 0x00 0x00 |
13 | 0x1638 0xFE 0x04 0x00 0x02 0x02 0x55CD 0x55CD 0x2BF6 0x2BF6 0x00 0x00 |
14 | 0x1848 0xFE 0x04 0x00 0x03 0x02 0x66FC 0x66FC 0x2BF6 0x2BF6 0x00 0x00 |
15 | 0x1A58 0xFE 0x04 0x00 0x04 0x02 0xFF6B 0xFF6B 0x2BF6 0x2BF6 0x00 0x00 |
16 | 0x1C68 0xFE 0x04 0x00 0x05 0x02 0xCC5A 0xCC5A 0x2BF6 0x2BF6 0x00 0x00 |
17 | 0x1E78 0xFE 0x04 0x00 0x06 0x02 0x9909 0x9909 0x2BF6 0x2BF6 0x00 0x00 |
18 | 0x2088 0xFE 0x04 0x00 0x07 0x02 0xAA38 0xAA38 0x2BF6 0x2BF6 0x00 0x00 |
19 | 0x2298 0xFE 0x04 0x00 0x08 0x02 0xBA06 0xBA06 0x2BF6 0x2BF6 0x00 0x00 |
20 | 0x24A8 0xFE 0x04 0x00 0x09 0x02 0x8937 0x8937 0x2BF6 0x2BF6 0x00 0x00 |
21 | 0x26B8 0xFE 0x04 0x00 0x0A 0x02 0xDC64 0xDC64 0x2BF6 0x2BF6 0x00 0x00 |
22 | 0x28C8 0xFE 0x04 0x00 0x0B 0x02 0xEF55 0xEF55 0x2BF6 0x2BF6 0x00 0x00 |
23 | 0x2AD8 0xFE 0x04 0x00 0x0C 0x02 0x76C2 0x76C2 0x2BF6 0x2BF6 0x00 0x00 |
24 | 0x2CE8 0xFE 0x04 0x00 0x0D 0x02 0x45F3 0x45F3 0x2BF6 0x2BF6 0x00 0x00 |
25 | 0x2EF8 0xFE 0x04 0x00 0x0E 0x02 0x10A0 0x10A0 0x2BF6 0x2BF6 0x00 0x00 |
26 | 0x3108 0xFE 0x04 0x00 0x0F 0x02 0x2391 0x2391 0x2BF6 0x2BF6 0x00 0x00 |
27 | 0x3318 0xFE 0x04 0x00 0x10 0x02 0x30DC 0x30DC 0x2BF6 0x2BF6 0x00 0x00 |
28 | |
29 | *800.9ffp |
30 | |
31 | *9<800w |
32 | |
33 | *r |
34 | |
35 | *k |
36 | Buff Mark Trk Side Sect Leng HCRC HCRC(c) CRC CRC(c) Miss Miss |
37 | 0x1008 0xFE 0x04 0x00 0x01 0x02 0x009E 0x009E 0x2BF6 0x2BF6 0x00 0x00 |
38 | 0x1218 0xFE 0x04 0x00 0x02 0x02 0x55CD 0x55CD 0x2BF6 0x2BF6 0x00 0x00 |
39 | 0x1428 0xFE 0x04 0x00 0x03 0x02 0x66FC 0x66FC 0x2BF6 0x2BF6 0x00 0x00 |
40 | 0x1638 0xFE 0x04 0x00 0x04 0x02 0xFF6B 0xFF6B 0x2BF6 0x2BF6 0x00 0x00 |
41 | 0x1848 0xFE 0x04 0x00 0x05 0x02 0xCC5A 0xCC5A 0x2BF6 0x2BF6 0x00 0x00 |
42 | 0x1A58 0xFE 0x04 0x00 0x06 0x02 0x9909 0x9909 0x2BF6 0x2BF6 0x00 0x00 |
43 | 0x1C68 0xFE 0x04 0x00 0x07 0x02 0xAA38 0xAA38 0x2BF6 0x2BF6 0x00 0x00 |
44 | 0x1E78 0xFE 0x04 0x00 0x08 0x02 0xBA06 0xBA06 0x2BF6 0x2BF6 0x00 0x00 |
45 | 0x2088 0xFE 0x04 0x00 0x09 0x02 0x8937 0x8937 0x9AB4 0x9AB4 0x00 0x00 |
46 | 0x2298 0xFE 0x04 0x00 0x0A 0x02 0xDC64 0xDC64 0x2BF6 0x2BF6 0x00 0x00 |
47 | 0x24A8 0xFE 0x04 0x00 0x0B 0x02 0xEF55 0xEF55 0x2BF6 0x2BF6 0x00 0x00 |
48 | 0x26B8 0xFE 0x04 0x00 0x0C 0x02 0x76C2 0x76C2 0x2BF6 0x2BF6 0x00 0x00 |
49 | 0x28C8 0xFE 0x04 0x00 0x0D 0x02 0x45F3 0x45F3 0x2BF6 0x2BF6 0x00 0x00 |
50 | 0x2AD8 0xFE 0x04 0x00 0x0E 0x02 0x10A0 0x10A0 0x2BF6 0x2BF6 0x00 0x00 |
51 | 0x2CE8 0xFE 0x04 0x00 0x0F 0x02 0x2391 0x2391 0x2BF6 0x2BF6 0x00 0x00 |
52 | 0x2EF8 0xFE 0x04 0x00 0x10 0x02 0x30DC 0x30DC 0x2BF6 0x2BF6 0x00 0x00 |
53 | 0x3108 0xFE 0x04 0x00 0x11 0x02 0x03ED 0x03ED 0x2BF6 0x2BF6 0x00 0x00 |
54 | 0x3318 0xFE 0x04 0x00 0x12 0x02 0x56BE 0x56BE 0x2BF6 0x2BF6 0x00 0x00 |
55 | *2089<800.9ffv |
56 | |
57 | * |
58 | *800.83f |
59 | |
60 | 0800 - 00 01 02 03 04 05 06 07 |
61 | 0808 - 08 09 0A 0B 0C 0D 0E 0F |
62 | 0810 - 10 11 12 13 14 15 16 17 |
63 | 0818 - 18 19 1A 1B 1C 1D 1E 1F |
64 | 0820 - 20 21 22 23 24 25 26 27 |
65 | 0828 - 28 29 2A 2B 2C 2D 2E 2F |
66 | 0830 - 30 31 32 33 34 35 36 37 |
67 | 0838 - 38 39 3A 3B 3C 3D 3E 3F |
68 | * |
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?
> auch die 5 1/4
ja, nur der Assembler-Code müsste hierzu noch angepasst werden ^^
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.
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.