Floppy MFM Decoder selber bauen AVR ATmega Assembler Beispiele FDD Diskette

[Bernhard S. (bernhard)]

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

[Rufus Τ. F. (rufus) (Moderator)]

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.ä.

[Bernhard S. (bernhard)]

> 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

MFM_ZEIT: ldi ZL, LOW(580) ; Anzahl BYTES ldi ZH,HIGH(580) 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

TIMER0_INITIALISIERUNG: ; TCCR0A – Timer/Counter Control Register A ldi temp, (0<<COM0A1)| (0<<COM0A0)|(0<<COM0B1)|(0<<COM0B0)|(0<<WGM01)|(0<<WGM00) OUT TCCR0A,temp

ggf. die Zeitgrenzen anpassen

; Umrechnung von Zeiten- in Zellenwerte ldi temp2,1 ; Zelle1 cpi temp1,54 brlo MFN_ZEIT_w ldi temp2,2 ; Zelle2 cpi temp1,75 brlo MFN_ZEIT_w ldi temp2,3 ; Zelle2 MFN_ZEIT_w: 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:

TABELLE_ID_SECTOR: .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 TABELLE_ID_DATA: .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?

[Rufus Τ. F. (rufus) (Moderator)]

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.

[Benni (Gast)]

Kannst du die ersten Sektoren der Disk (Track 0, Seite 0) lesen und die 
16.200 Bytes zum Spielen hier posten?

[G. H. (schufti)]

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.

[Bernhard S. (bernhard)]

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 ?

[Benni (Gast)]

> ... würdest Du dafür die CRC-Routine schreiben?

Im Anhang ist eine CRC16-CCITT Routine mit einem Aufruf der Daten eines 
ID-Records.

ID-Record: a1 a1 a1 fe 14 00 01 02 CRC: 1b 39

[Bernhard S. (bernhard)]

> 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 :-)

[Benni (Gast)]

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

[Bernhard S. (bernhard)]

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 :-)

[Bernhard S. (bernhard)]

...und so sieht es in der Praxis aus...

[Tiramisu (Gast)]

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!

[W.S. (Gast)]

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.

[Rufus Τ. F. (rufus) (Moderator)]

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?

[Bernhard S. (bernhard)]

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

[Rufus Τ. F. (rufus) (Moderator)]

"fertsch" - sehr schön.

[Tiramisu (Gast)]

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!

[Rufus Τ. F. (rufus) (Moderator)]

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.

[Tiramisu (Gast)]

>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.

[Rufus Τ. F. (rufus) (Moderator)]

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.

[Bernhard S. (bernhard)]

>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 (Gast)]

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.

[soul e. (souleye)]

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.

[Bernhard S. (bernhard)]

>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 ^^

[Joachim B. (jar)]

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

[Rufus Τ. F. (rufus) (Moderator)]

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

[soul e. (souleye)]

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.

[Rufus Τ. F. (rufus) (Moderator)]

soul e. schrieb:
> Die Maschine des TO kann/könnte HD und DD einfach anhand der
> Taktfrequenz unterscheiden.

So macht das wohl Kryoflux.

[soul e. (souleye)]

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).

[Joachim B. (jar)]

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.

[soul e. (souleye)]

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.

[Joachim B. (jar)]

soul e. schrieb:
> Beim PC ist Pin 2 ein Eingang, über den auf HD

destawegen hatte ich mich beim Atari ST daran orientiert. :)

[Nano (Gast)]

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?

[Joachim B. (jar)]

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.

[Michael U. (amiga)]

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

[Joachim B. (jar)]

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

[Name H. (hacky)]

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.

[Michael U. (amiga)]

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.
Ebay-Artikel Nr. 163436923406

Gruß aus Berlin
Michael

[Rufus Τ. F. (rufus) (Moderator)]

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.

[Joachim B. (jar)]

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.

[Rufus Τ. F. (rufus) (Moderator)]

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 ...

[Route 6. (route_66)]

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

[soul e. (souleye)]

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.

[Nano (Gast)]

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.

[Rufus Τ. F. (rufus) (Moderator)]

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 (Gast)]

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.

[Joachim B. (jar)]

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

[Rufus Τ. F. (rufus) (Moderator)]

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.

[Nano (Gast)]

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.

[Rufus Τ. F. (rufus) (Moderator)]

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.