www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Floppysimulation, möglich?


Autor: greg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

glaubt ihr, dass es möglich ist, ein Floppylaufwerk mit Hilfe eines 
Mikrocontrollers zu simulieren? Ist ein UART dafür geeignet, den 
Datenstrom auszugeben?

Letztendlich soll ein AVR mit externem SRAM jeweils einen Track von 
einem Image auf SD-Card buffern und nach MFM wandeln, dann nur noch über 
den UART ausgeben.

Theoretisch sollte das klappen, oder liegt bei mir ein großer Denkfehler 
vor?

Autor: Bernd Rüter (Firma: Promaxx.net) (bigwumpus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein UART ist dafür denkbar ungeeignet. Der kann Start- und Stop-Bit 
ausgeben und dazwischen noch ein paar Bits im richtigen Schrittakt.

Wir haben uns sowas letztes Jahr mal angedacht.
So als Tip:
1. Schritt: versuche mal das Timing von MFM-codierten Datenströmen zu 
verstehen.
2. Schritt: was steht eigentlich zwischen den Sektoren in den GAPs auf 
der Scheibe ? Was sendet der Floppy-Controller da ?
3. Schritt: versuche mal das Phänomen der Pre-Compensation zu 
durchleuchten und zu verstehen, wann sie eingesetzt wird.

Die Daten kannst Du in Flash-RAMs ablegen (Dataflash) oder sogar in 
SRAMs zwischenspeichern.

Die eine Entwicklung ging dahin, das MFM-Timing (Decodierung) über einen 
extra AVR zu regeln, so daß der 2. AVR nur noch Daten packt.

Ein zweiter Experte (mehr wird es in D wohl nicht geben) riet zur Lösung 
über programmierbare Logikbausteine wegen der Geschwindigkeit. Ich hatte 
auch das Gefühl, daß der die Lösung bauen könnte, aber der wollte nicht 
die Zeit darin investieren.

Autor: Hans Wilhelm (hans-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
darf ich mal fragen was das ganze bringen soll ???

das klingt vllt jetzt böse sollts aber nicht sein... aber wär vllt 
sinnvoll zu wissen warum man ein floppy simulieren soll bzw welche 
hardware das simulierte floppy vorgesetzt bekommen soll...

73

Autor: Marcus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anwendungen gibt es dafür schon:

Es gibt z.B. einen Haufen älterer Meßgeräte (Tektronix, Agilent) die
auch heute noch 5-8000 EUR kosten aber nur Floppy Laufwerke und kein
CD oder LAN haben. Wenn man also von der lästigen Floppy weg will ist
das schon eine Überlegung wert.


Gruß, Marcus

Autor: Henrik J. (henrikj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaub auch. Oder man bedenke, dass mein Windows immernoch bei der 
Installation den Raid Treiber auf Disk verlangt. Ich hab kein FDD mehr. 
Das war echt Aufwand.
Und son kleiner AVR mit den Daten auf ner 1024MB SD Karte als Floppy 
getarnt, wäre echt nett.

Autor: greg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hans, das soll eine virtuelle externe Floppy für einen Amiga werden. Das 
hat schon seinen Sinn. Damit soll man dann die ganze alte Software 
benutzen können, die nur von Floppy direkt läuft.

Bernd, was ist da am Timing besonderes zu verstehen? MFM verdoppelt die 
Datenmenge (und Kodierrate), aber was ist da am Timing sonst besonders? 
[Da der Amiga auch andere, beliebige Kodierschemata erlaubt, überlege 
ich auch, ob man nicht die Daten raw speichern soll]

Zum 2. Schritt: weiß ich noch nicht, versuche ich herauszufinden. Zum 
3., Precompensation nutzt der Amiga anscheinend nicht. (Oder 
interpretiere ich das hier falsch: 
http://lclevy.club.fr/adflib/adf_info.html#p2 "Precompensation time: 
0ms")

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So eine Schaltung wäre für diverse ältere Geräte interessant. Ich hab 
auch noch Messgeräte mit Floppys drin und auch Musikinstrumente. Das 
Zeug ist noch echt Klasse und ich würde es auch sehr vorziehen von den 
alten Disketten wegzukommen wenn das mit vertretbarem Aufwand möglich 
wäre. Die Ansätze die bereits existieren waren ja noch nocht das gelbe 
vom Ei. Hiermit mein ich z.B. den FlashPath-Adapter für 
Smartmediakarten. Wäre ja auch viel schöner einen Adapter zu bauen den 
man statt des Diskettenlaufwerks einbauen könnte.

bye

Frank

Autor: rene (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab auch so ein Projekt angedacht und bisher Material gesammelt. 
Ziel war /ist auch eine Hardware, die anstelle einer Floppy eingesteckt, 
wie eine Floppy reagiert. Was leider nicht mehr wirklich erhaeltlich 
ist, ist wie der Datenstrom codiert wird. Der Datenstrom des PC internen 
Floppy controller muesste zuerst decodiert werden, dann auf ein 
SD/MMC/CF oder USBstick umgebogen werden und sektoren wieder in einen 
seriellen Datenstrom codiert werden. Viel zu tun sollte es nicht sein. 
Zielpreis fuer so ein Geraet koennte 100Euro in Stueckzahlen sein. Das 
gibt der Markt her.

Die Writeprecompensation kompensiert, dass innen auf der Floppy weniger 
Sektoren sind, daher auch weniger Signal induziert wird.

rene

Autor: greg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, habe mich nun nochmal mit Hilfe eines Floppylaufwerk-Datenblattes 
schlau gemacht, wie die Signale aussehen, die ein Laufwerk so ausgibt. 
Tatsächlich scheint ein UART nicht optimal dafür zu sein (ob der kurzen 
Impulse bei Flanken), unmöglich ist es aber nicht.

Mit Timern, die dann diese Impulse absetzen, bin ich aber wahrscheinlich 
um einiges besser bedient.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dokumentation gibt es dafuer schon, man braucht sich ja nur mal die 
alten Datenblaetter der Floppycontroller anzuschauen. Ausserdem stand in 
der C't auch so einiges.

Ich glaub auch nicht das dies unmoeglich ist, aber ich wuerde es mir 
nicht antun. Ein weiteres Problem ist das Floppys keineswegs 
PC-Kompatibel sein muessen, gerade bei Anwendungen in alten 
Messgeraeten.

Ich vermute mal das es einfacher ist in so einem Falle die Firmware zu 
dissassemblieren und zu patchen als sich sowas anzutun.

Olaf


Autor: Wegstaben Verbuchsler (wegstabenverbuchsler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also wenn ich in google als Suchbegriff floppy-emulator eingebe, dann 
gibts gleich auf der ersten Ergebniss-Seite auf den letzten 2 Links 
Hinweise drauf, daß es auch Hardware-Emulatoren gibt für Amiga und 
Atari.

warum also das Rad neu erfinden?




Autor: rene (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@greg
Du hast ein Floppycontroller datenblatt ? Besteht eine Moeglichkeit, 
dies zu bekommen ? Es geht mir um Messgeraete mit Windows NT4 
Betriebssystem. Das FAT sollte auch machbar sein. Die Modulation sollte 
auch machbar sein, aber da war noch was mit gaps, sektor-crc, und 
dergleichen.
rene

Autor: greg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rene, ich hab das Datenblatt eines Floppylaufwerks: 
http://www.teac.de/dspd/downloads/datasheets/dl_fd...

Da ist auch beschrieben, wie die Modulation auszusehen hat usw.

Ach, und dazu, dass es sowas schon gibt: ich hab einfach Lust darauf, 
mich selbst mit sowas zu beschäftigen. :) Ich seh aber auch jetzt erst, 
dass jemand schonmal so etwas gebaut hat.

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich könnte noch mit PC intern 2.0 aushelfen habe aber wenig Zeit. Darin 
ist sehr viel zu den Kommunikationsabläufen beschrieben. Auch zum 
Protokoll des "Shugertbus". Diese Schnittstelle ist der Schlüssel wenn 
du den Controller nicht antasten magst. Ich  habe auch noch älter 
Literatur dazu , aus Z80 Zeiten, dort ist alles haarklein beschrieben 
weil wir Ossis unsere Floppycontroller aus TTL Gräbern selbstgestrickt 
haben um so eine Floppy z.B. an den Specki zu bringen. Das war 
gewissermaßen der umgekehrte Fall an der selben Schnittstelle. den 
Shugartbus gab’s in 2 Versionen. 1.0 und 2.0

Zuden Atarifloppyssimulatoren:  Die Atarifloppys besaßen einen internen 
Controller. Der wird gleich mit simuliert und so die einfacher zu 
bedienende Schnittstelle des seriellen Ataribusses benutzt an welchem 
der Controller angeschlossen ist. Diese entspricht in allen Parametern 
der UART des µC besitzt jedoch eine 2 zusätzliche Handshakeleitungen 
(Interrupt  und Command , wobei nur die Letztere wirklich benötigt wird, 
da das BS die Interruptleitung zwar unterstützt , es aber keine HW gab 
die dies nutzte so auch die Floppys nicht.)
Ich denke jedoch ihr wollt den Controlller unangetastet lassen? Dann ist 
dies nicht Euer weg.

Alternativ jedoch ließe sich vielleicht eine Rs232 nachrüsten. Da muss 
mann abwägen was leichter geht. Ansonsten beschäftigt euch mit dem 
Shugartbusprotokoll und dem MFM Datastream

http://de.wikipedia.org/wiki/Alan_Shugart

> Die Bezeichnung Shugart wird auch für den de-facto-Standard für 
>Diskettenlaufwerk-Interfaces verwendet:

>50 pin: 8"
>34 pin: 5¼", 3½", 3"


Mit freundlichen Grüßen Winne

P.S. so ich Zeit finde helfe ich gern und suche einiges aus meinen 
„Schätzen.“ Leider habe ich

Autor: Hauke Sattler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Ich hatte mich mit dem Bernd vor einiger Zeit mal mit einer Floppy 
Emulation Beschäftigt.

Ich muß erstmal mit ein paar Irrtümern aufräumen.

@Henrik Jahnke
Direkt von SD-Karte geht nicht, da diese eine zu hohe Latenzzeit im 
Random lesen hat (krischer Punkt ist hier die einzuhaltende maximale 
Kopfwechselzeit der Floppy) Besser ist hier eine DataFlashkarte von 
Atmel.

@greg
1. Der UART ist absolut ungeeignet dazu (wegen Start und Stopbits).
Besser wäre es eine SPI Schnittstelle dafür zu missbrauchen. Dies hat 
jedoch einen nicht unerheblichen Umrechnungsoverhead zur Folge
(1 Datenbyte müseen in 2-4 SPI bytes Umgerechnet werden).
Weiterhin ist der der SPI nicht gepuffert, es muß also immer exakt im 
richtigen Moment ein neues Byte im Register landen (Timingfehler sind 
praktisch nicht zu vermeiden)

2. Der Amiga (zumindest in seinem nativen Format) verwendet kein MFM 
oder FM sondern eine Commondore eigenes Sonderformat der GCR Codierung.
GCR ist relativ gut dokumentiert, nur zu den Gaps und Markern ist sehr 
schlecht was zu finden. Weiterhin konnte der Amiga die 500 kHz MFM 
Codierung gar nicht verarbeiten, weil dafür Paula und ihre Nachfolger zu 
langsam waren. Dies Problem sollte dann mit dem AAA Chipsatz behoben 
werden, dummerweise ging Commondore vorher Pleite.

@rene
Mit
"Die Writeprecompensation kompensiert, dass innen auf der Floppy weniger 
Sektoren sind, daher auch weniger Signal induziert wird"
hast du nen paar Sachen durcheinander gebracht.

1. Wenn innen weniger Sektoren sind nenn man das Bitzone Recording
Man verringert auf den inneren Spuren (Zylindern) die 
Schreibgeschwindigkeit (und damit auch die Datendichte) weil die Bits 
dort physikalisch viel dichter gepackt sind. Commondore, Ostkomputer 
(KC...) und Festplatten machen dies. Auf PC Floppys wird das 
normalerweise nicht gemacht, es ist aber möglich.

2. Precompensation nennt man einen notwendigen Kniff um das 
Wiederauslesen der Daten zu Vereinfachen.
Der Spalt der Schreibkopfes hat ja eine endliche Breite. Dadurch kommt 
es ,daß Polaritätswechsel (und damit die FM/MFM Impulse) auf dem Medium 
scheinbar auseinander rücken. (Angeblich sollen die Polaritätswechsel 
nach dem Schreiben auch noch wandern) Um diesen Phänomenen 
entgegenzuwirken, werden beim Schreiben, die eng aneinander liegenden 
Impulse noch enger gemacht, und die weiten noch weiter gemacht.
Wann was wieviel ist jedoch so gut wie undokumentiert.

Außerdem hatte hatte ich in meinen Versuchen heraus gefunden, daß manche 
Floppycontroller wohl mitten im Byte anfangen zu schreiben.
Deshalb ist die Auswertung der Schreibdaten, welche vom Floppycontroller 
kommen alles andere als trivial.


Leider ist das Projekt aus Arbeitszeitgründen ein wenig versandet. (µC 
sind nen Hobby von mir und wenn man manchmal pro Monat 200 Überstunden 
hat dann bleibt da nicht genug Muße für so ein Umfangreiches Projekt)

Weiterhin wollten mögliche Interresenten alle möglichen Variationen
(Read only, Read+Write, Netzwerkanbindung über TP, COM und Modem)
Das war zu Aufwändig für ein Hobbyprojekt so nebenbei. (Ich möchte nicht 
wissen wieviele Projekte sterben nur weil sie zu ambitioniert sind)

Zuletzt habe ich noch vor ca 1-2 Monaten erfahren das irgend eine 
amerikanische Firma ein "Patent für Vefahren zur Nachbildung einer 
Floppy auf elektronischem Wege" (oder so ähnlich, Mail muß ich mal 
raussuchen) hält, aber nie ein Produkt rausgebracht hat.
Das heißt, die Vermarktung eines solchen Adapters könnte Probleme 
machen.

cu
Hauke Sattler

P.S.
Wer Rechtschreibfehler findet darf sie behalten

P.P.S.
Bernd, habt ihr noch das "alte" Büro? Ich will euch demnächst mal euer 
Osci wieder vorbei bringen.

Autor: greg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hauke:

1. OK, daran hab ich nicht gedacht, sehr dumm! Ich dachte bei den Atmels 
ließe sich das vollkommen Ausschalten. SPI brauche ich (eigentlich) auch 
schon für SD/MMC. Das nächste Byte nachzuschieben sollte doch allerdings 
bei genügend hohem Takt per IRQ kein Problem sein.

2. Das stimmt nicht. Amiga-Disketten im Standardformat verwenden sehr 
wohl MFM, kodiert mit 500Khz (unkodiert 250Khz). Die vorherigen Floppys 
für Commodores 8-Bitter verwendeten GCR.
Mehr dazu unter http://lclevy.club.fr/adflib/adf_info.html#p2
Da Paula aber sehr einfach gehalten ist, erledigt der Controller nicht 
die MFM-Kodierung/Dekodierung selbst (muss durch CPU oder Blitter 
gemacht werden) und damit sind auch andere Kodierungen als MFM möglich. 
Dennoch ist MFM Standard.

Autor: Hauke Sattler (hauke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@greg

Ok.
Den Blitter Trick kannte ich noch nicht.
Ich wußte nur noch lediglich, das wenn man PC-Formatierte Floppies im 
Amiga verwenden wollte, die Floppy erstmal als PC-Laufwerk mounten 
mußte.
Und dies ging auch nur mit DD Floppies (720kB Formatiert)
1,44Mb Floppies konnte man nicht verwenden.

Ach ja, zum Thema per Interupt nachschieben:
Durch den Interupt hast du schon mindestens vier Takte Zeitverzögerung, 
und da ist der Weitersprung aus dem Interruptvektor noch nicht 
mitgerechnet. Reeller sind hier eher 6-8 Takte bis der SPI wieder läuft.
Bei 16MHz ergeben sich dadurch schon 375-500 ns Verzögerung.
Wenn ich mir mein Floppydatenblatt 
(http://www.citizen.co.uk/pdf/x1de00a.pdf) anschaue dann steht da auf 
Seite 5 (§2.4.5.) was von 8µS+-40ns (maximale Pause bei 250kHz MFM) . 
Sprich du würdest im Idealfall (4 Takte= 250ns) schon einen mehr als 
6mal höheren Fehler haben als maximal zulässig.
Damit ist irq-SPI zur MFM erzeugung definitiv essig.
Ich mache die MFM/FM erzeugung rein in Software.

cu
Hauke

P.S.
Ich habe grad nochmal genau nachgeschaut.
Die Amiga hatten anscheinend wirklich MFM als native Kodierung, jedoch 
war das Format ein vollig anderes als bei DOS oder CPM.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

> Die Amiga hatten anscheinend wirklich MFM als native Kodierung, jedoch
> war das Format ein vollig anderes als bei DOS oder CPM.

Bei welchem CP/M? :-) Da gab es doch auch hunderte von verschiedenen
Formaten....

Das einzige worauf man bei Non-DOS Hardware hoffen darf ist eine gewisse 
Grundkompatibilitaet wenn der Hersteller einen Standardfloppycontroller
verwendet hat. Aber auch darauf ist kein Verlass. Man denke nur an die
Eigenbauloesung beim Apple][. Und besonders faszienierend wenn man es
wie hier schonmal erwaehnt auch fuer alte Spiele nutzen moechte. Da
wurde ja nochmal besonders fies an der Hardware rumprogrammiert um einen
Kopierschutz zu realisieren. Ich erinnere mich da noch an !/2 oder 1/4
Spuren...

Olaf

Autor: Zwölf Mal Acht (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das wie von Hauke beschriebene enge Timing wuerde dann schon auf einen 
hardwarebasierten MFM Modulator in Form eines CPLD hinweisen. Zumindest 
fuer einen Prototypen wuerde das dann Sinn machen.

nw

Autor: Hauke Sattler (hauke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In Assembler und mit der Richtigen Taktfrequenz ist MFM encoden auf dem 
AVR kein Problem. Man muß nur genau die benötigten Takte im Auge 
behalten. Dann erhält man ein MFM Signal welches erheblich genauer ist 
als jede Floppy. Die Schwierigkeit sind die ganzen Randbedingungen und 
Zusatzsignale die man auch noch beachten muß.

Ich habe jedoch auch mal nen MFM<->8bit rar. decoder/encoder auf nem 
Xilinx (mit dem ISE Webpack) gemacht. Device war glaub ich nen 9572 
CPLD.
Hab das jedoch nicht weiterverfolgt.

cu
Hauke

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

> In Assembler und mit der Richtigen Taktfrequenz ist MFM encoden auf dem
> AVR kein Problem. Man muß nur genau die benötigten Takte im Auge

Also ganz so einfach ist das nicht. Ober wieso hat man im PC einen extra
Controller verwendet und den noch an DMA gehangen?
DAs ist auf jedenfall schon eine Aufgabe an der man wachsen kann. .-)

Olaf

Autor: greg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hauke:
Hm, aber so eng ist das Timing nicht, plusminus 40ns? Das sind eher 
plusminus 500ns, vielleicht mehr. In einem Datenblatt eines 
Floppylaufwerkes sehe ich hier plusminus 750ns für DD. Man sollte eben 
auch daran, denken, dass die Floppys nicht immer so genau mit der 
Nenndrehzahl rotieren. MFM ist ja gerade auch dafür da, damit solche 
Toleranzen nicht sofort zu verlorenen Bits u.ä. führen!

Hauptproblem bei der Kompatibilität zwischen Amiga/PC ist der Start des 
Tracks. Beim PC wird das Indexloch verwendet, der Amiga macht dies über 
ein Sync-Word, was an jedem Sektorbeginn steht. Außerdem werden die 
Sektoren ohne Gaps einfach hintereinandergeschrieben. Das bietet sich 
ganz gut an, da man in der Regel immer einen ganzen Track in einem 
Rutsch liest.

Autor: greg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hauke:
hab mir mal dein Datenblatt angeschaut. Das geht dort ums Schreiben auf 
Diskette, nicht ums Lesen. Da sollten die Timings natürlich genau 
hinhauen, wenn man auf ein echtes physikalisches Medium schreibt. Sonst 
könnten sich beim Lesen unter anderen Bedingungen die Toleranzen 
aufaddieren und Laufwerke könnten nicht mehr funktionieren, die 
eigentlich innerhalb der Spezifikationen laufen. Für ein Laufwerk, das 
keine physikalisch vorhandenen Datenträger hat, ist das aber irrelevant.

Autor: Hauke Sattler (hauke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du schaust dir die Angelegenheit vom falschen Ende an.
Es soll doch ein Floppy Simulator sein. Sprich es wird das Laufwerk und 
nicht der von dir besagte extra Controller mit DMA simuliert.
Und im Vergleich zum Controller ist das Laufwerk dumm wie Brot. In einer 
Floppy sind üblicherweise nur ein paar wenige Gatter drin. Der Rest ist 
Analogelektronik und Mechanik.

cu
Hauke

Autor: Hauke Sattler (hauke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Letzterer Beitrag war an Olaf gerichtet

Autor: Hauke Sattler (hauke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@greg
Stimmt schon mit der ungenauen Nenndrehzahl. Nur muß man dabeisagen daß 
sich diese Drehzahl von Bit zu Bit gesehen, quasi konstant bleibt (auch 
eine Floppy hat eine Trägheit).

Bei SPI wäre das Problem das man ein Bit mit der richtigen 
Geschwindigkeit und ein Bit mit der zu langsamen Geschwindigkeit hat.
(oder 3 bit richtig und 1 zu lang aber in diesem Modus wären die 
Pulslängen wieder kritisch).
Das liegt daran das der SPI auf fest auf 8 bit eingestellt ist.

Um 8bit in MFM zu codieren braucht man 16 "Halbbitzellen"
(den Begriff hab ich mir ausgedacht, also bitte nicht schimpfen)
In jedem dieser Halbbitzellen kann entwerden ein Impuls mit einer Länge 
zwischen 200 und 1000 ns sein (ideal 500ns), oder gar kein Impuls.

Eine Halbbitzelle hat in 500kHz MFM genau 1000ns. Nun kann man pro 
Halbbitzelle ein oder zwei SPI-bits vorsehen (bei 2bit wird der Impuls 
500ns bei 1bit 1000ns also grenzwertig).

Mit einem SPI-Byte können also 8 oder 4 Halbbit zellen, bzw. 4 oder 2 
Bitzellen erzeugt werden.
Nach jedem gesendeten SPI-Byte würde Interuptbedingt ein Fehler 
auftreten.
Das beteutet (im 4Bitzellen/Byte Modus):
Bit
Bit
Bit
Bit
Pause (durch Interuptverzögerung)

oder von der Controler aus gesehen:
Richtiges Timing
Richtiges Timing
Richtiges Timing
zu langsames Timing (um mindestens 250ns)

Der PLL des Controllers könnte sich also nie richtig einschwingen.
Wenn ich mir das Datenblatt von dem Intel 82077 FDD Controller anschaue 
dann steht da:
"3.2.2 LOCKTIME (tLOCK)
The lock, or settling time of the data PLL is designed
to be 64 bit times. This corresponds to 8 sync bytes
in the MFM mode. This value assumes that the sync
field jitter is 5% the bit cell or less. This level of jitter
should be easily achieved for a constant bit pattern,
since intersymbol interference should be equal, thus
nearly eliminating random bit shifting."

5% der Bitzelle(2µS bei 500kHz) wären 100ns

Wenn man mal einen "PLL lock" erreicht hat dann kann der Jitter (also 
Bit zu Bit Zeitfehler) größer sein.
"3.2.1 JITTER TOLERANCE
The jitter immunity of the system is dominated by the
data PLL's response to phase impulses. This is measured
as a percentage of the theoretical data window
by dividing the maximum readable bit shift by a
(/4 bitcell distance. For instance, if the maximum allowable
bit shift is 300 ns for a 500 Kbps data
stream, the jitter tolerance is 60%."

300ns das wären 4,8 Takte bei 16MHz, das ist extrem knapp um einen 
Interrupt auszuführen.

Ich will dich nicht angreifen greg, aber SPI oder UART sind für MFM nun 
mal leider nicht zu gebrauchen. Ich hoffe ich habe dir hiermit 
veranschaulichen können warum ich dieser Meinung bin.

cu
Hauke

P.S.
Das FDD Controller Datenblatt findet man unter
http://www.cs.york.ac.uk/rtslab/demos/readme/docs/...

Autor: greg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit UART und SPI habe ich ja auch schon abgeschlossen. Ich werde das 
timerbasiert per Software machen. Jemand hat sowas schon bei 8 Mhz 
hinbekommen.

Autor: rene (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank Hauke, das war sehr instruktiv soweit. Man kann sich das 
Ganze zumindest langsam vorstellen. Die Logik ist 5V TTL, scheint es, 
und die kleinen Details kommen dann schon noch, ein paar Messzyklen 
sollte man planen. Wenn was am Kopf vorbei kommt, ist das dann lsb 
first, oder msb first ? Ist das FAT auf seite 0, seite 1 oder beiden, 
usw.
Man wird zuerst eine Elektronik haben muessen, die die Signale lesen 
kann, dann kann man eine existierende Floppy anzapfen, mitverfolgen und 
verstehen.

Wenn man einen ganzen Track lesen oder schreinem will, resp koennen 
soll, muss man 12.k bytes RAM dafuer haben. Dazu kommen noch ein Paar 
andere Variablen, das FAT, usw. Da ist dann schon nichts mehr mit AVR & 
dsPIC ... zumindest im internen RAM.

Rene

Autor: Hauke Sattler (hauke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@rene
Welche Variante möchtest du nun?
AVR an Floppy (AVR ist Floppycontroller)
oder
Floppycontroller an AVR (AVR ist Solid State Floppy)

Nur letzterer Fall hat mich bisher interessiert.

> Die Logik ist 5V TTL, scheint es,
Sie ist es

> Wenn was am Kopf vorbei kommt,
es kommt nichts am Kopf vorbei, denn der AVR ist ja der Kopf.
Da eine echte Floppy eine Anlauf- und Bremsverzögerung hat, ist es 
prinzipiell egal an welcher Stelle des Tracks die Floppy anfängt zu 
drehen.
Der Controller sucht sich das entsprechende Bitmuster schon raus.

> ist das dann lsb first, oder msb first
Ich meine es ist MSB First aber da bin ich nur zu 70-80% sicher (die 
Datenblätter wiedersprechnen sich teilweise)

> ? Ist das FAT auf seite 0, seite 1 oder beiden,
Hängt sehr vom Format ab, in manchen Formaten sind Seite 0 und Seite 1 
auch vertauscht. Da es dann auch noch so viele Formate gibt (mit 
unterschiedlichen anzahlen von Bytes/Sektor) ist das nur Fallabhängig zu 
beantworten.

> Man wird zuerst eine Elektronik haben muessen, die die Signale lesen
kann, dann kann man eine existierende Floppy anzapfen, mitverfolgen und
verstehen.
Steckbrett&STK500 reicht

> Wenn man einen ganzen Track lesen oder schreinem will, resp koennen
> soll, muss man 12.k bytes RAM dafuer haben.
Du meinst bestimmt lesen lassen scheiben lassen will.
Wenn man eine Read only Floppy macht, dann reicht nen AVR mit 1k RAM.
Bei einer RW Floppy braucht man mehr als 12500 Byte.

Das liegt daran, daß der Track nicht in reinem MFM kodiert ist. Sektor 
und Indexmarker werden durch spezelle Bitkombinationen markiert 
(weglassen von eigendlich notwendigen Pulsen). Die Art und Position 
dieser Informationen muß auch irgendwo hinterlegt werden.
Wenn man es richtig machen wollte müßte man für jede Halbbitzelle ein 
Datenbit nehmen. Das würde 25000 Byte/Track ergeben.
Da diese Zusatzinformationen jedoch relativ selten sind (ca 
60Stück/Track) kann man diese recht gut kompremieren.
Ich komme deshalb mit etwas über 13000Byte/Track hin (hab da noch ein 
wenig Luft für Sonderfälle)

Leider ist die zulässige Zeit für einen Kopfwechsel lediglich 100µS 
(viel zu kurz für einen Datentransfer von oder zum Flash). Man müßte 
also immer beide Seiten einer Spur im RAM haben, was den Speicherbedarf 
nochmal verdoppelt.

Jetzt kommt allerdings das Problem welches ich zur Zeit habe.
Die Zeit welche der Controller der Floppy für einen Spurwechsel 
zugesteht (üblicherweise 3ms, maximal aber 4ms) ist zu kurz um die Daten 
vom RAM in ein Flash reinzubekommen (zumindest bei den AVR möglichen SPI 
Frequenzen)
Dann muß man ja auch noch die Daten des neuen Tracks vom Flash in RAM 
schaufeln (es kann ja sein das nur ein einzelner Sektor geschrieben 
wird).

Als wenn das nicht schon genug wäre, können die meisten Flashbausteine 
nur blockweise beschrieben (und oft auch nur blockweise gelesen) werden. 
Wobei die Blockgröße eher selten mit der Sektorgröße übereinstimmen 
dürfte.

Es würden also jede Menge Datenübertragungen anfallen, für die der AVR 
einfach nicht die Zeit oder Geschwindigkeit hat. Ich glaube nicht, daß 
ein PIC (die handelsüblichen µC, nicht die PIC-DSP Monster) das besser 
kann.
Und von ARM und AVR32 lass ich bislang die Finger.

Aus diesem Grunde muß ich zur Zeit bei einer simulierten RW Floppy das 
gesammte Medium im RAM behalten (ca. 2,5MB) was reichlich Bausteine 
verschlingt.

Bei einer Read only Floppy (sieht für den Controller wie ein 
schreibgeschütztes Medium aus) komme ich ohne XRAM und einer kleinen 
Menge internem RAM aus.

cu
Hauke

Autor: rene (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Hauke,
ich moechte eine Solidstate floppy bestehened aus Flash(noch zu 
bestimmender Art) an verschiedene Messgeraete anschliessen die zZ noch 
eine Floppy haben. Das Betriebssystem ist meist ein WinNT4.0 und die 
Floppy jeweils HD. Aber die  Formate unterscheiden sich nur wenig, dh 
wenn's mal laufen wuerde koennte man das DD Format auch noch 
unterstuetzen, wenn das denn sein muesste. Aeh, ja. Und ein Mediachange 
waere dann ein Knopf an der Frontplatte des neuen Laufwerks. Dh ein Mal 
druecken und eine neue Floppy ist da - und eingelegt. Je nach 
verwendetem Datenformat passen nicht so viele Messungen auf eine 
originale Floppy. Mit einem 1 GB Flash waeren so 700 Floppies auf's Mal 
moeglich.

Dass die Kopfwechsel 100us, und Spurwechsel nur 4ms dauern duerfen, ist 
etwas kurz. Wobei ich das Flash ja noch lesen kann wenn der Kopf schon 
zu lesen beginnt. Solange das flash zu lesen schneller ist als die 
Lesekopfsignale zu erzeugen, hab ich kein Problem. Ich bevorzuge an 
einen Lesekopf zu denken, denn dessen gelesene Signale muss ich ja 
erzeugen. Ist Sektor 0 (oder 1) fest bein Indexloch ? Merkt der 
Controller, wenn ich bei einem Kopf- oder Spurwechsel zuerst mal 
nichtssagenden Nach- & Vorspann bringe ? Oder muss ich dann bereits den 
naechsten Sektor bringen. Ich erinnere mich schwach an Interleaving und 
solche Dinge. War aber moeglicherweise im Zusammenhang mit den ersten 
HDs.

rene

Autor: Wegstaben Verbuchsler (wegstabenverbuchsler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wäre folgender Gedanke:


Es wird ein altes 3,5" Diskettenlaufwerk ausgeweidet.

Für die ursprüngliche Aufgabenstellung ....

"Letztendlich soll ein AVR mit externem SRAM jeweils einen Track von
einem Image auf SD-Card buffern und nach MFM wandeln, dann nur noch über
den UART ausgeben."


.... mag sich der auf dem Laufwerk befindliche Controller kümmern. Der 
ganze mechanische Teil wird entfernt, und ein AVR braucht "nur noch" 
Motor und Sensorik und Kopf zu simulieren.

Die angewandte Modulation und Spur,Sektore etc. Befüllung mag dann das 
ursprüngliche Gerät machen wie es will. Af die SD-Karte kommen nur noch 
die rohen Bits drauf.

Unterschiedliche Datenträger (SS, DS,HD etc) ließen sich natürlich durch 
den AVRauch recht einfach simulieren.

Autor: greg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Äh, dir ist klar, dass Floppylaufwerke "dumm" sind, und man dass sowieso 
schon machen muss, wie du sagst?

Die Elektronik auf den Laufwerken kümmert sich eher um die 
Drehzahlregulierung und Lowlevel-Verstärkung/Aufbereitung der analogen 
Sensorwerte. Sonst macht die gar_ _nichts! Wie die Modulation 
auszusehen hat, wie viele Sektoren du in welchem Format hast usw., das 
macht alleine der Floppycontroller auf dem Mainboard! Dein Ansatz bringt 
genau gar nichts.

Autor: Hauke Sattler (hauke)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Wegstaben Verbuchsler & rene

Ich muß dem zustimmen.
Auf der Floppy ist folgende Logic drauf:
- Spur 0 Erkennung
- Spurwechsel Endabschaltung
- Bufferschaltung für IO um Floppy zu (de)aktivieren
- Unterdückung der Schreibpulse bei Schreibschutz
- Disk in (ready) Signal nach erstem Stepimpuls bei eingelegter Diskette
- Ein paar Schmitt Trigger und Monoflops für saubere Signale
Das wars.

Das was auf der Diskette an Daten landet ist reine sache des 
Controllers.
Man könnte theoretisch eine Floppy auch mit nem langsamen UART 
beschreiben und auslesen. Das Laufwerk würde dann die Pegelwechsel des 
UART auf das Medium schreiben, nur wäre die Disk dann ausschließlich auf 
diesem System verwendbar.

@rene
Der erste Sektor kann am kurz nach dem Indexloch sein, muß aber nicht.
Laut dem DOS Format soll nach dem Indexloch erstmal der Indexheader 
kommen. Dann der erste Sektorheader und dann der erste Sektor. (alles 
noch natürlich mit dem entsprechen Gap und Sync Bereichen dazwischen)

> Merkt der Controller, wenn ich bei einem Kopf- oder Spurwechsel zuerst
> mal nichtssagenden Nach- & Vorspann bringe ? Oder muss ich dann bereits
> den naechsten Sektor bringen.
Eigendlich eine gute Idee, nur nicht alle Controller verwenden 
Interleaving. Das ist nicht zwingend. Es kann sein daß der Controller 
direkt den nächsten Sektor verlangt. Und was Passiert wenn der 
Controller mehrere Sektoren oder Spuren oder Seiten aufmal schreibt? Ich 
kenne genügend Geräte die Sich ihre Diskette selbst Formatieren wollen.
Dann werden gleich alles Spuren neu geschrieben. So kann leicht 
passieren das man mit dem Wegpuffern gar nicht mehr hinterherkommt.

Spätestens wenn der Controller ein Verify machen will (also die gerade 
geschriebene Spur kontrollieren will) müssen die Daten beihnahe sofort 
nach dem Schreiben anliegen (spätestens 1300µS bzw. 690µS nach schließen 
des Schreibgates müssen alle Signale wieder valid sein).

Alleine schon das lesen von einer MMC Karte ist nicht ohne. Es kann gut 
sein das mitten aus einem MMC-Block anfangen muß zu lesen. Bei 1024Byte 
Blöcken müßte man erstmal 512Byte auslesen und verwerfen. Ohne 
Leselatenzen, Header und sonstigen Overhead wären das mindestenz schon 
512 µS bevor das erste nutzbare Byte von der MMC gelesen werden kann. 
Zuviel z.B.für den Kopfwechsel.
Bei der Readonly Floppy verwende ich daher Dataflash von Atmel. Die 
können auch mitten im Block anfangen zu lesen und sind ausreichend 
schnell.
Nachteil ist, das die relativ klein und beim schreiben noch langsamer 
als eine MMC sind.

cu
Hauke

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

> Man könnte theoretisch eine Floppy auch mit nem langsamen UART
> beschreiben und auslesen. Das Laufwerk würde dann die Pegelwechsel des
> UART auf das Medium schreiben, nur wäre die Disk dann ausschließlich auf
> diesem System verwendbar.

Nicht nur theoretisch. Sony hat in ihrer ersten Digitalcamera Mavica die 
Bilder Analog als Videosignal auf eine 2" (oder 1.8") Floppy 
geschrieben.

Olaf

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.