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?
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.
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
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
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.
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")
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
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
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.
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
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?
@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
rene, ich hab das Datenblatt eines Floppylaufwerks: http://www.teac.de/dspd/downloads/datasheets/dl_fd05hf8630.pdf 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.
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
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.
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.
@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.
> 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
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
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
> 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
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.
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.
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
@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/pdf/82077AA_FloppyControllerDatasheet.pdf
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.
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
@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
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
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.
Ä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.
@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
> 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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.