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_66 H. (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.

[Peter S. (cbscpe)]

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.

[Peter S. (cbscpe)]

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.

Buff Mark Track Sector Side Length HCRC HCRC(c) CRC CRC(c) 0x1008 0xFE 0x20 0x00 0x0C 0x02 0x8B7D 0x8B7D 0x3C90 0x3C90 0x1218 0xFE 0x20 0x00 0x0D 0x02 0xB84C 0xB84C 0xE287 0xE287 0x1428 0xFE 0x20 0x00 0x0E 0x02 0xED1F 0xED1F 0x5AC2 0x5AC2 0x1638 0xFE 0x20 0x00 0x0F 0x02 0xDE2E 0xDE2E 0x6708 0x6708 0x1848 0xFE 0x20 0x00 0x10 0x02 0xCD63 0xCD63 0x79BE 0x79BE 0x1A58 0xFE 0x20 0x00 0x11 0x02 0xFE52 0xFE52 0x533B 0x533B 0x1C68 0xFE 0x20 0x00 0x12 0x02 0xAB01 0xAB01 0x778F 0x778F 0x1E78 0xFE 0x20 0x00 0x01 0x02 0xFD21 0xFD21 0x86EF 0x86EF 0x2088 0xFE 0x20 0x00 0x02 0x02 0xA872 0xA872 0xB50F 0xB50F 0x2298 0xFE 0x20 0x00 0x03 0x02 0x9B43 0x9B43 0xD53A 0xD53A 0x24A8 0xFE 0x20 0x00 0x04 0x02 0x02D4 0x02D4 0x4605 0x4605 0x26B8 0xFE 0x20 0x00 0x05 0x02 0x31E5 0x31E5 0x5674 0x5674 0x28C8 0xFE 0x20 0x00 0x06 0x02 0x64B6 0x64B6 0x0A66 0x0A66 0x2AD8 0xFE 0x20 0x00 0x07 0x02 0x5787 0x5787 0xD2C7 0xD2C7 0x2CE8 0xFE 0x20 0x00 0x08 0x02 0x47B9 0x47B9 0xAA7B 0xAA7B 0x2EF8 0xFE 0x20 0x00 0x09 0x02 0x7488 0x7488 0xF30A 0xF30A 0x3108 0xFE 0x20 0x00 0x0A 0x02 0x21DB 0x21DB 0x4514 0x4514 0x3318 0xFE 0x20 0x00 0x0B 0x02 0x12EA 0x12EA 0x4788 0x4788

[Bernhard S. (bernhard)]

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

.

[Benni (Gast)]

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?

[Peter S. (cbscpe)]

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

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

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

[Peter S. (cbscpe)]

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.

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

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

[Peter S. (cbscpe)]

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.

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

Ah, also kein PC-Krempel.
Auf jeden Fall: Hut ab.

[Peter S. (cbscpe)]

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. (cbscpe)]

Und mit ein bisschen Optimieren läuft das ganze jetzt auch mit 16MHz 
statt 22M.1184MHz.

[Benni (Gast)]

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.

[Peter S. (cbscpe)]

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

O Toggle Motor On S Toggle Drive Select nnT Seek to track, wobei man zuerst mit 0T kalibrieren sollte R Liest den Track von Head 0 und dekodiert MFM und legt as ab 0x1000 im RAM ab wobie weils 8 bytes header und dann 520 bytes Daten mit CRC und Füllbytes sind K Analysiert den gelesenen Track und zeigt ein paar infos an s<nW Schreibt den Buffer ab addresse n in den Sector s

Hier der Auszug einer "Sitzung"

*0t *4t Seek from 0x00 to 0x04 *r *k Buff Mark Trk Side Sect Leng HCRC HCRC(c) CRC CRC(c) Miss Miss 0x1008 0xFE 0x04 0x00 0x11 0x02 0x03ED 0x03ED 0x2BF6 0x2BF6 0x00 0x00 0x1218 0xFE 0x04 0x00 0x12 0x02 0x56BE 0x56BE 0x2BF6 0x2BF6 0x00 0x00 0x1428 0xFE 0x04 0x00 0x01 0x02 0x009E 0x009E 0x2BF6 0x2BF6 0x00 0x00 0x1638 0xFE 0x04 0x00 0x02 0x02 0x55CD 0x55CD 0x2BF6 0x2BF6 0x00 0x00 0x1848 0xFE 0x04 0x00 0x03 0x02 0x66FC 0x66FC 0x2BF6 0x2BF6 0x00 0x00 0x1A58 0xFE 0x04 0x00 0x04 0x02 0xFF6B 0xFF6B 0x2BF6 0x2BF6 0x00 0x00 0x1C68 0xFE 0x04 0x00 0x05 0x02 0xCC5A 0xCC5A 0x2BF6 0x2BF6 0x00 0x00 0x1E78 0xFE 0x04 0x00 0x06 0x02 0x9909 0x9909 0x2BF6 0x2BF6 0x00 0x00 0x2088 0xFE 0x04 0x00 0x07 0x02 0xAA38 0xAA38 0x2BF6 0x2BF6 0x00 0x00 0x2298 0xFE 0x04 0x00 0x08 0x02 0xBA06 0xBA06 0x2BF6 0x2BF6 0x00 0x00 0x24A8 0xFE 0x04 0x00 0x09 0x02 0x8937 0x8937 0x2BF6 0x2BF6 0x00 0x00 0x26B8 0xFE 0x04 0x00 0x0A 0x02 0xDC64 0xDC64 0x2BF6 0x2BF6 0x00 0x00 0x28C8 0xFE 0x04 0x00 0x0B 0x02 0xEF55 0xEF55 0x2BF6 0x2BF6 0x00 0x00 0x2AD8 0xFE 0x04 0x00 0x0C 0x02 0x76C2 0x76C2 0x2BF6 0x2BF6 0x00 0x00 0x2CE8 0xFE 0x04 0x00 0x0D 0x02 0x45F3 0x45F3 0x2BF6 0x2BF6 0x00 0x00 0x2EF8 0xFE 0x04 0x00 0x0E 0x02 0x10A0 0x10A0 0x2BF6 0x2BF6 0x00 0x00 0x3108 0xFE 0x04 0x00 0x0F 0x02 0x2391 0x2391 0x2BF6 0x2BF6 0x00 0x00 0x3318 0xFE 0x04 0x00 0x10 0x02 0x30DC 0x30DC 0x2BF6 0x2BF6 0x00 0x00 *800.9ffp *9<800w *r *k Buff Mark Trk Side Sect Leng HCRC HCRC(c) CRC CRC(c) Miss Miss 0x1008 0xFE 0x04 0x00 0x01 0x02 0x009E 0x009E 0x2BF6 0x2BF6 0x00 0x00 0x1218 0xFE 0x04 0x00 0x02 0x02 0x55CD 0x55CD 0x2BF6 0x2BF6 0x00 0x00 0x1428 0xFE 0x04 0x00 0x03 0x02 0x66FC 0x66FC 0x2BF6 0x2BF6 0x00 0x00 0x1638 0xFE 0x04 0x00 0x04 0x02 0xFF6B 0xFF6B 0x2BF6 0x2BF6 0x00 0x00 0x1848 0xFE 0x04 0x00 0x05 0x02 0xCC5A 0xCC5A 0x2BF6 0x2BF6 0x00 0x00 0x1A58 0xFE 0x04 0x00 0x06 0x02 0x9909 0x9909 0x2BF6 0x2BF6 0x00 0x00 0x1C68 0xFE 0x04 0x00 0x07 0x02 0xAA38 0xAA38 0x2BF6 0x2BF6 0x00 0x00 0x1E78 0xFE 0x04 0x00 0x08 0x02 0xBA06 0xBA06 0x2BF6 0x2BF6 0x00 0x00 0x2088 0xFE 0x04 0x00 0x09 0x02 0x8937 0x8937 0x9AB4 0x9AB4 0x00 0x00 0x2298 0xFE 0x04 0x00 0x0A 0x02 0xDC64 0xDC64 0x2BF6 0x2BF6 0x00 0x00 0x24A8 0xFE 0x04 0x00 0x0B 0x02 0xEF55 0xEF55 0x2BF6 0x2BF6 0x00 0x00 0x26B8 0xFE 0x04 0x00 0x0C 0x02 0x76C2 0x76C2 0x2BF6 0x2BF6 0x00 0x00 0x28C8 0xFE 0x04 0x00 0x0D 0x02 0x45F3 0x45F3 0x2BF6 0x2BF6 0x00 0x00 0x2AD8 0xFE 0x04 0x00 0x0E 0x02 0x10A0 0x10A0 0x2BF6 0x2BF6 0x00 0x00 0x2CE8 0xFE 0x04 0x00 0x0F 0x02 0x2391 0x2391 0x2BF6 0x2BF6 0x00 0x00 0x2EF8 0xFE 0x04 0x00 0x10 0x02 0x30DC 0x30DC 0x2BF6 0x2BF6 0x00 0x00 0x3108 0xFE 0x04 0x00 0x11 0x02 0x03ED 0x03ED 0x2BF6 0x2BF6 0x00 0x00 0x3318 0xFE 0x04 0x00 0x12 0x02 0x56BE 0x56BE 0x2BF6 0x2BF6 0x00 0x00 *2089<800.9ffv * *800.83f 0800 - 00 01 02 03 04 05 06 07 0808 - 08 09 0A 0B 0C 0D 0E 0F 0810 - 10 11 12 13 14 15 16 17 0818 - 18 19 1A 1B 1C 1D 1E 1F 0820 - 20 21 22 23 24 25 26 27 0828 - 28 29 2A 2B 2C 2D 2E 2F 0830 - 30 31 32 33 34 35 36 37 0838 - 38 39 3A 3B 3C 3D 3E 3F *

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.

[Thomas W. (diddl)]

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?

[Bernhard S. (bernhard)]

> auch die 5 1/4

ja, nur der Assembler-Code müsste hierzu noch angepasst werden ^^

[S. R. (svenska)]

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

[Peter S. (cbscpe)]

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.

[S. R. (svenska)]

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.

[Peter S. (cbscpe)]

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.