Wir haben Messgeräte, welche ein Diskettenalufwerk haben und sonst keinen Anschluß. Um Messwerte abzuspeichern ist seither alles auf Diskette abgespeichert worden und hinterher war die rennerei irgenwo ein Rechner zu finden, der noch ein D-Laufwerk besitzt. Gibt es eventuell eine Möglichkeit an den diskettenkontroller ein Pseudolaufwerk anzuschliesen, das dann auf ein anderes Speichermedium abspeichert oder über ein Netzwerk etwas ablegt? Oder gibt es eine Art Diskettenersatz, das man dann reinschiebt und eine Diskette vorgaukelt?
So ein Teil würde mich auch interessieren, habe aber ebenfalls noch nix gefunden.
externe usb-diskettenlaufwerke kosten ja nix mehr, sehe daher das problem nicht...
Beitrag "Re: 3,5" Floppy auslesen" "zur Zeit progge ich mir nen FDD emulator auf AVR basis..." Beitrag "Re: Floppy mal anders" "Floppy mal anders" Beitrag "Re: Diskettenlaufwerk ersetzen" da hab ich auch was gefunden Beitrag "Re: Floppysimulation, möglich?" "Floppysimulation, möglich?" hier einfach mit "Suchen" nach floppy emulator gefunden
es geht wohl um das Umgekehrte!! Man will keine Diskette mehr
Ich schon. Die Disketten machen immer wieder Probleme und es gibt häufig Datenverlust.
Ich hab mal die Daten zusammengetragen, um ein SD/ USBStick device zu bauen, das haette Diskettenlaufwerk kompatibel sein sollen. Leider konnte ich nicht alle Daten zusammenkriegen. Wie muss man das Disketten Laufwerk ansteuern ? Vorher macht das Ganze wenig Sinn. Der Rest ist nicht allzu schwierig.
Was mich interessieren würde wäre ein Gerät das man statt der Diskette in das Laufwerk einlegt und das die Daten dann in irgend einer Form ausgibt, da das eingebaute Diskettenlaufwerk bei den zwar alten, aber immer noch sehr guten Messgeräten nicht so einfach getauscht werden kann.
Das Diskettelaufwerk kann man immer tauschen. 4 Schrauben und draussen ist's. Der Stecker ist genormt, Es gibt wenig Disketten formate, die sollten moeglich sein.
wenn es ein nettes Gerät bzw. noch besser ein nettes Projekt gäbe das man einfach anstelle des Diskettenlaufwerkes einbaut und dann vorne den USB-Stick einsteckt wäre das natürlich auch eine Lösung.
Hi, SONY hatte sowas für die ersten Digitalkameras im Angebot. MemeroyStick<-> Diskette. Sah aus, wie ne normale Floppy. Da konnte man den MeneoryStick reinmachen und alles zusammen ins D-LW stecken. XlR.
> Was mich interessieren würde wäre ein Gerät das man > statt der Diskette in das Laufwerk einlegt und das die > Daten dann in irgend einer Form ausgibt, da das eingebaute > Diskettenlaufwerk bei den zwar alten, aber immer noch sehr > guten Messgeräten nicht so einfach getauscht werden kann. Es gab mal spezielle Adapter, mit denen man SmartMedia-Karten in Diskettenlaufwerken auslesen konnte, aber das funktionierte nur mit spezieller Software, die den Diskettencontroller entsprechend ansteuerte. Möglich, wenn auch etwas kompliziert, wäre es, das Diskettenlaufwerk selbst zu ersetzen und an dessen definierter Schnittstelle, dem Shugart-Bus anzusetzen. Allerdings werden die darauf übertragenen Daten MF-moduliert übertragen, was die Angelegenheit etwas verkompliziert. Prinzipiell bräuchte man 160 Speicherabbilder einer Diskettenspur (2 Seiten à 80 Spuren), die je nach Format mit 500 kBit/sec oder 250 kBit/sec beschrieben und ausgelesen werden können müssen und Platz für 1/50 oder 1/60 der Sekundenkapazität aufweisen (es gibt Diskettenlaufwerke mit 300 und welche mit 360 Umdrehungen/Sekunde). Das Lesen ist noch relativ einfach, die Daten der aktuellen Spur und Seite werden "abgespielt" und zu Beginn der Spur wird für eine gewisse Zeitdauer das Indexsignal aktiviert. Der hierfür zu verwendende Takt kann freilaufend sein, darf aber nicht allzusehr vom vom Laufwerk erwarteten Takt abweichen. Das Beschreiben ist schon komplizierter, weil hier der Schreibtakt des Diskettencontrollers aus den MF-modulierten Daten rekonstruiert werden muss, um die Daten relativ zur aktuellen "Kopfposition" abspeichern zu können. Gleichzeitig müssen die bereits gespeicherten Daten ausgelesen werden können (da so ein Diskettencontroller recht schnell zwischen Lesen zum Auffinden des richtigen Sektors und Beschreiben desselbigens umschalten kann). Eine Möglichkeit wäre es, für die Takterzeugung eine PLL zu verwenden, die beim Schreiben mit dem Floppycontrollertakt synchronisiert wird. Die restlichen Dinge wie Auswahl der gewünschten Spur und Seite sind relativ einfach hinzubekommen (Step- und Direction-Signal auswerten, Spur0-Signal gegebenenfalls aktivieren, und HeadSelect ebenfalls auswerten). Damit sollten zumindest Standardformate (720k oder 1.44 MByte) realisierbar sein, heimtückisch werden Spezialformate, bei denen auf einer Spur die Datendichte umgeschaltet wird (ja, sowas gibt es!). Was dieses "Diskettenlaufwerk" jedoch ganz und gar nicht bietet, ist ein einfacher Zugriff auf die gespeicherten Daten, diese sind ein Rohabbild der auf der Diskette gespeicherten Daten, mit Sektormarkierungen etc.
Angehängte Dateien:
-
Floppybus.png
19 KB
im Hardwarebook: http://pf.ku.sk/lajciak/technickevybavenie/hwbook/hwbook2.pdf auf Seite 212 ist die Belegung des 34-poligen Floppykabels gezeigt, hier angehängt
Wie schon gesagt waere die Schreibsimulation eines Diskettenlaufwerkes genuegend. Dh, das Geraet wuerde auf den Shugartbus schreiben, das Device wuerde das decodieren und als File aus einen USBStick oder Schreiben.
Angehängte Dateien:
-
mfm-E5.PNG
29 KB
Das Floppyformat ist im floppy user guide ganz gut beschrieben: http://www.moria.de/~michael/floppy/floppy.ps Ich habe noch ein paar Logicanalyzer-Screenshots vom MFM-Datenstrom, als ich mein altes Laufwerk letztens repariert habe. Das erste hier zeigt das Datenbyte 0xE5 (Formatier-Füllbyte unter CP/M), die Markierungen zeigen die Byte- und Bitslot-Grenzen. M1 und M2 markieren den Byteslot, die grauen Markierungen sind die Grenzen der Bitslots. Hmm, wenn ich mir das Bild nochmal genau ansehen, ist das Byte wohl eher 0xE4 statt 0xE5...
Angehängte Dateien:
-
mfm-preindexgap.PNG
28 KB
Hier der zweite LA-Schuss, in diesem Falle ist es die preindex gap. Man erkennt zur linken gut die lange Folge von Nullbytes, die letztlich eine Folge konstanter Frequenz und Phase bieten, auf die sich die PLL im Floppycontroller synchronisieren kann. Danach ist die index mark, gebildet von einem Byte 0xC2, bei dem der Taktimpuls im 0-Bit 3 (zwischen der 4. und der 5. grauen Markierung) fehlt. Laut MFM-Regeln müsste ein reguläres 0-Bit an dieser Stelle einen Impuls am Anfang des Bitslots aufzeichnen, aber bei der index mark wird dieser Impuls zur Synchronisation weggelassen. Das Ganze sind übrigens Daten einer 5,25-Zoll-DD-Floppy, wie man an Hand der 4 µs Periodendauer (= 250 kHz Aufzeichnungsfrequenz) sehen kann. Muss man also für 3,5 Zoll HD entsprechend umrechnen. In der oberen Zeile ist auch erkennbar, dass das Indexloch zu dieser Zeit noch in der Lichtschranke sichtbar ist. Das vorige Bild dagegen war irgendwo aus der Mitte einer Spur genommen, da war das Indexloch nicht aktiv.
Vieleicht kann man so ein Teil billig bei Ebay schießen. http://www1.shopping.com/xPO-Sony-Memory-Stick-MSAC-FD2M Bei Sony wird vor allem die Vergrößerung des Speichervolumens eine Rolle gespielt haben. Wenn es so nicht funktioniert, kann man es ja ggf nach den eigenen Wünschen umbauen.
nop(); wrote: > Wie schon gesagt waere die Schreibsimulation eines Diskettenlaufwerkes > genuegend. Nein, du musst immer auch die Daten generieren können. Das Schreiben funktioniert ja so, dass der Floppycontroller erst einmal den Datenstrom mitliest, bis er die entsprechende Sektormarke (mit der passenden sector ID) gefunden hat, erst danach schaltet er auf Schreiben um. Außerdem werden deine Messgeräte vermutlich nicht einfach rohe Daten auf die Medien schreiben wollen (sowas habe ich nur bei Textimaschinen mal gesehen), sondern sie werden ein FAT- Dateisystem erwarten.
So etwas wie der von tex erwähnte Adapter funktioniert nur mit geeigneter Software, die den Diskettencontroller entsprechend ansteuert, ganz genauso wie die SmartMedia-Adapter"disketten" von Olympus. Somit ist es in irgendwelchen Messgeräten nutzlos, denn denen wird man kaum die ensprechende Software beischnallen können.
Ja, sicher, die Messgeraete schreiben im FAT format, dh , sie lesen zuerst das directory von der Diskette.
<< Adapter funktioniert nur mit geeigneter Software >> Vermutlich, darum ja der Hinweis des Probierens. Nun die praktische Lösung. soweit ich das in Erinnerung habe, setzt der Lesekopf des FD-Laufwerks immer an der gleichen Stelle auf. Eigentlich solte es ihm dann erst einmal egal sein, ob er an der Stelle eine hauchdünne Schicht CRO2 vorfindet, oder 2 hauchdünn gewickelte Spulenkörper. Nun etwas reine blöde Mechanik. Der kopf fährt über die Diskette und erwartet, durch das drehen nach einer bestimmten Zeit Daten, deren Auftreten er selbst durch die Rotation steuert. Was die Daten bedeuten ist dabei erst einmal ganz egal. Was ich also brauche, ist eine Spule, welche sich mit dem Lesekopf bewegt und ihm eine CHO2-Schicht vorgaukelt und ein häufchen elektronik, dass 1.5 MB Daten speichern kann und diese exakt einer Position aus Drehwinkel der Disk und Stellung des RW-Kopfes zuordnen kann.
Das Format ist völlig irrelevant, bereits zum Beschreiben eines beliebigen Sektors muss die Diskette gelesen werden können, da sonst das Auffinden des Sektors in der Spur nicht möglich ist. Dabei werden Sektormarkierungen auf der Diskette gelesen. Diese werden beim Formatieren auf die Diskette aufgebracht - und das ist der einzige Moment, in dem die Diskette beschrieben wird, ohne auch gelesen zu werden. Das war früher (so ganz knapp nach der Steinzeit) noch anders, da gab es tatsächlich "hartsektorierte" Disketten. Der Aufwand, eine Diskette mechanisch nachzubauen (Spule etc.) dürfte einige Größenordnungen heftiger sein als die Emulation eines Diskettenlaufwerks am Shugart-Bus.
<< da sonst das Auffinden des Sektors in der Spur nicht möglich ist. >> Schon, wir reden doch aber immernoch über magnetisierte und nicht magnetisierte Bereiche, also über "Speicherzellen" die 1 oder 0 abhängig von Drehwinkel der Scheibe und der Position des Lesekopfes sind, oder?
Nein, magnetisiert sind die alle, aber entweder in die eine oder in die andere Richtung. Wenn du dir die Bilder oben anguckst siehst du, wie die Magnetisierung bei einer MFM-Floppy aussieht bzw. das Signal, dass die Mimik im Floppy-Laufwerk am Shugart-Bus aus der Magnetschicht rekonstruiert.
ich setze hier gerne VirtualFloppy ein: http://www.pctipp.ch/downloads/dl/32764.asp damit erstelle ich mir auch Floppyimages, die ich dann mit vmware einbinden kann. einfach auf eine virt. Floppy Daten loggen, dann die Datei per USB-Stick, Mail, etc. zum Zielsystem tragen und auswerten.
Hallo! Das hatte ich damals gefunden als, ich auch sowas gesucht habe... http://www.torlus.com/floppy/ gruß, Bjoern
Ja, genau, VirtualFloppy, das ist die Lösung. Super. Äh. Und wie setzt man VirtualFloppy beispielsweise bei einem zehn Jahre alten Agilent-Oszilloskop ein?!
Rufus t. Firefly wrote: > Und wie setzt man VirtualFloppy beispielsweise bei einem zehn Jahre > alten Agilent-Oszilloskop ein?! Gar nicht. Du schenkst mir das 10 Jahre alte Agilent, kaufst dir ein neues (das dann Ethernet, USB und was weiß ich nicht gleich von Haus aus mitbringt), und ich benutze das Agilent mit stinknormalen Floppies, weil es mich gar nicht stört, eine solche für die Datenübertragung zu verwenden. ;-)
Das Teil ist so alt, da steht noch HP drauf. Und es hat leider keine anderen Schnittstellen zur Aussenwelt, nur das Diskettenlaufwerk. Und es kommt doch recht häufig vor, das Daten fehlerhaft sind. Vom Problem Disketten zu beschaffen mal ganz abgesehen. Das Diskettenlaufwerk ersetzen wäre eine sehr gute Idee, optimal wäre es natürlich, wen am Messgerät nix herummgeschraubt wird. Das Laufwerk ausbauen müsste aber auch gehen. USB Host für einen Stick wäre toll, eine COM Schnittstelle würde es aber auch tun.
Ich habe gehört, dass es solche Teile gibt. Es soll zwar nicht mit USB arbeiten, aber mittels einer CF-Karte soll man 50-100 Disketten emulieren können. Man stellt vorne am Display ein, mit welcher "Pseudo" Diskette man arbeiten will, und dann arbeitet der Emulator, als wenn eine 1,44MB Diskette drin wäre. Ich hab so ein Teil schonmal geshen. Klingt ganz gut, wenn man jedes Diskettenlaufwerk damit ersetzen könnte. Bei den vielen Steuerungen, die eine Laufwerk haben, sollte das ein Riesengeschäft werden, der das verteibt.
Es muss ja nur geschrieben werden, oder? Dann lass das Laufwerk + Diskette drin (evtl noch staubdicht versiegeln) und sniffe den Datenstrom mit während das Oszi schreibt, oder bau einen Umschalter/Ausschalter und einen kleinen Embedded-PC ein um die Daten sofort nach dem Aus/Umschalten runter kopieren zu können. Letztere ist vermutlich die teuerste, aber dafür die einfachste Lösung. Gruß Roland
Eigentlich müsstest du die Daten auch wesentlich vorher abgreifen können, ich kann mir nicht vorstellen dass in dem Gerät ein Floppy-Controller verbaut ist, der einen Datensatz automatisch in ein Dateisystem sortiert und wegschreibt. D.h. irgendwo vor dem Controller müssen die Rohdaten digital durchlaufen, die du sicherlich wesentlich einfacher abgreifen kannst.
Obwohl ich (wie Jörg) Floppies gerne verwendete - In der Tat, das wäre mal ein lohnendes Projekt! Eigentlich dürfte das nicht sooo schwer sein. Evtl. einen Gegen-Controller aufbauen, der genau das macht, wenn eine Floppy formatiert wird. Das ist ja das Signal, das das Gerät bei einer neuformatierten Floppy erwartet. Seinerzeit habe ich viel mit dem WD2797 gemacht, der dürfte sich dafür eignen.
eProfi wrote: > Obwohl ich (wie Jörg) Floppies gerne verwendete - > In der Tat, das wäre mal ein lohnendes Projekt! > > Eigentlich dürfte das nicht sooo schwer sein. Dass Du Dich da mal nicht taeuschst. Waere das so einfach gaebe es genug Geraete auf dem Markt, denn ein gewisser Anwendungsbedarf (gerade in der Industrie) ist da sicher vorhanden.
Also eine Floppy hat eine Datenrate von < 1MBit. Man müsste doch mit einem etwas schnelleren Controller die Daten abgreifen können. Es geht ja nicht darum, den Floppycontroller nachzubauen, sondern quasi das Floppylaufwerk und das hat meines Wissens sehr wenig Intelligenz wen man sich mal die Pinbelegung des Floppykabels anschaut gibt es dort Pins für z.B. Schrittimpuls für den Schreib-/Lesekopf und Richtung. Das Interface ist nichtmal parallel.
hallo, gib bei google mal vfdwin.exe ein. dort findest du ein virtuelles disk-laufwerk, funktioniert bei mir bestens... tauschi
Ich habe mir über dass Problem auch schon ein paar mal den Kopf zerbrochen. Dass Problem ist, dass bei den meißten Maschinen eine eigene Art die Daten zu speichern verwendet wird. Da funktionieren die aktuell am Markt oder bei Bastlern verfügbaren Emulatoren meißtens nicht, da sie nur für die Verwendung bei PC's, Amigas,... ausgelegt sind. Dass bedeutet dass für jede Maschine eine eigene Software entwickelt werden muß. Und dass ist doch etwas teuer.
Der Thread ist schon so alt, dass zwar nicht mehr HP draufsteht, aber ob das Thema wirklich noch wichtig ist?
Name wrote: > Dass Problem ist, dass bei den meißten Maschinen eine eigene Art die > Daten zu speichern verwendet wird. Weiter oben stand, dass die benannten Geraete ganz normal am PC lesbares FAT (einschliesslich dem normalen Unterbau) schreiben. Wenn man die Daten auf den PC transportieren will, ergibt ein eigenes Format auch wenig Sinn.
A. K. wrote: > Der Thread ist schon so alt, dass zwar nicht mehr HP draufsteht, aber ob > das Thema wirklich noch wichtig ist? Naja, prinzipiell würde es mich für meinen HP1652B schon auch irgendwie interessieren. Gerade die DD-Disketten, die er haben möchte, werden auch in meinem Reservoir langsam knapp, und dann braucht er auch noch ein völlig ulkiges Format, dessen Generierung mir bislang unter FreeBSD noch nicht gelungen ist (obwohl ich sie dort prinzpiell auslesen kann). Solange ich aber noch paar Medien habe, hat das keine zu hohe Priorität. Sooo oft brauche ich den LA ohnehin nun auch wieder nicht.
Siggi wrote: > Weiter oben steht dieser Link http://www.rothfus.com/SVD/index.php. Ist > das nicht schon die Lösung? Zumindest für den HP1652 wären die 256 KiB nicht ausreichend.
> Weiter oben steht dieser Link http://www.rothfus.com/SVD/index.php. > Ist das nicht schon die Lösung? Nein, das ist nur ein Emulator eines "GRE"-Diskettenlaufwerks mit gerade mal 35 Spuren und einem Kopf, wie es im AppleII verwendet wurde. Was nötig ist, ist ein Emulator eines HD-MFM-Diskettenlaufwerks mit 80 Spuren und zwei Köpfen. Das sind brutto 2 MByte Kapazität und ein komplett anderes Aufzeichnungsverfahren als das des Ur-Apples.
Liege ich jetzt komplett falsch oder verhält sich ein Floppylaufwerk gegenüber dem Floppykontroller prinzipiell "nur" wie ein linearer Speicher mit 1Bit Datenbreite und einem Zähler zur Adresscodierung? Mit dem Pin "Track 00" wird der Schreib-/Lesekopf auf Spur 00 zurückgesetzt, also der Adresscounter auf 0 gesetzt. DIR Steuert die Bewegungsrichtung des Lese-/Schreibkopfes. Dann geht es jeweils einen Schritt weiter (STEP = Schrittimpuls für den Schreib-/Lesekopf) Write Data und Read Data dienen zum Lesen / schreiben. Dinge wie Disk Change = Keine Diskette im Laufwerk können ruhig weggelassen werden denn Speicher ist ja quasi immer da. http://www.lukasbit.de/computer/pinbelegung.php#floppy
Lukas Slz wrote:
> Liege ich jetzt komplett falsch
Ja.
> Mit dem Pin "Track 00" wird der Schreib-/Lesekopf auf Spur 00 > zurückgesetzt, also der Adresscounter auf 0 gesetzt. Nein, das ist ein Ausgang, mit dem das Diskettenlaufwerk bekannt gibt, daß der Kopf auf Spur 0 liegt. Ansonsten hast Du im Prinzip recht, Du musst noch den Indeximpuls bedenken und die Tatsache, daß die Daten auf der Diskette MFM-codiert gespeichert werden. Die Nutzdaten machen nur einen recht kleinen Teil davon aus. Die Position eines Sektors in einer Spur wird durch die vergangene Zeit nach dem Indeximpuls definiert, die Diskette dreht sich mit 300 oder 360 Umdrehungen pro Minute.
Wenn man Speicher verwendet, der 10-20mal so schnell ist wie der Bitstrom der Floppy und eine entsprechend vielfache Kapazität hat, dann wird es tatsächlich einfach. Mit einem entsprechend hohem autonom erzeugtem Takt kann man dann das Datensignal der Track zyklisch speichern oder wiedergeben, und dazu noch am Anfang der Track den Indexpuls erzeugen. Um die Bitcodierung muss man sich dann nicht mehr kümmern. Ist ein bischen sowas wie Daten auf einem DSO speichern ;-).
Hi Ich hatte mich vor einiger Zeit mit dem Thema SSFDD (Solid State Floppy Disk Drive) beschäftigt und einige Sachen geproggt. Das Problem ist, dass das Floppylaufwerk (mit eingelegter Floppy) eine Art Analogen Speicher für den FDC darstellt. Die Pegel sind zwar Digital (High oder Low) aber die zeitliche Auflösung ist Analog. Diese zeitliche analoge Aufzeichnung ist beim Lesen kein Problem. D.h. ein nur Lese SSFDD ist verhältnismäßig simpel. Beim Schreiben (Daten vom FDC zum FDD) ist das schon sehr viel komplizierter, da sich der FDC nicht immer an das Timing halten kann. Das kommt daher, weil eng zusammenliegende Pulse beim Auslesen zum scheinbaren auseinderwandern neigen. Damit die Disketten aber trotzdem sicher gelesen werden können, werden schon beim Schreiben eng zusammenliegende Pulse noch enger aneinander gerückt. Beim Lesen sind sie damit an der richtigen Position. Das nennt sich Precompeansation. Weiterhin habe ich beim Schniffen von Disketten herausgefunden, dass manche FDDs mitten in einem Byte anfangen zu schreiben. Deshalb ist es ungemein schwierig die empfangenden Daten zu interpretieren (zumindest in Echtzeit) Ein weiteres Problem ist, das es dem Floppy Controller im Prinzip erlaubt ist: - ein einzelnes Bit zu Schreiben - die Spur oder den Kopf zu wechseln - dort wieder ein Bit zu schreiben - wieder die Spur oder den Kopf zu wechseln - usw. Um dies in einem Flashspeicher zu machen müßte man einen Block im RAM puffern, das Bit ändern, den Block löschen, und den geänderten Block zurück ins Flash schreiben. Bei Handelsüblichen Flashbausteinen dauert das Einlesen, Löschen und Neuspeichern schlichtweg zu lange (länger als die zulässige Spurwechsel und Ausschwingzeit). Meine Lösung ist das ich die komplette Diskette in einem RAM puffere. In einem AVR läuft ein MFM Codec Programm. Dies kümmert sich um das synchronisieren, das gelesen werden und das geschrieben werden. In einem zweiten AVR läuft die Verwaltung, Speicheransteuerung, Steuersignale usw. Das MFM Codec Programm ist im Prinzip fertig. Es verträgt alle FM/MFM/RLL/GCR Formate mit 125/250/500kHz Aufzeichnungstakt. An der Variante für 300kHz arbeite ich noch (ist nur für 1,2MB 5,25" wichtig) Was mit fehlt ist eine Möglichekeit an einen µC (am besten AVR) 4MB RAM anzuschließen kann. Die 4MB ergeben sich aus den oben angesprochenen Problemen mit der zeitlich analogen Aufzeichnung bei 500kHz MFM (1,44MB 3,5") Es gibt zwar recht grosse SRAM Bausteine, aber die sind doch recht teuer. Ich will kein SSFDD welches >200 Euro kostet. Den Monster-RAM Artikel (DRAM an AVR) kennen ich auch. Aber es sind schlichtweg kaum noch (asynchrone) DRAM Bausteine auf dem Markt. PSRAM kommt nicht in Frage, weil ich BGA (geschweige denn FBGA) nicht löten kann. XMega AVR wären eine Möglichkeit, aber die Infos zur Speicheransteuerung sind mir noch zu spärlich. Um Hilfe, Vorschläge und Anregungen wäre ich hier dankbar. Wenn man das Diskettenimage erstmal im RAM hat, ist die Extraktion von Dateien verhältnissmäßig einfach. Eine Datei in ein Diskettenimage einzupflegen geht auch. Den Transport der Dateien in und aus dem RAM (LAN, Modem, RS232, Flash, CFcard, USB usw.) wäre dann eine gesonderte Aufgabe. cu bis dann Hauke Sattler
Eine Anmerkung zu meinen beiden Vorpostern. Die Indexmarke und Die Position des Ersten Sektors muss nicht miteinander in Beziehung stehen. Manche FDC nutzen das Indexsignal nur um zu sehen ob sich das Laufwerk dreht. Wo welche Sektor steht, ist dann nur noch reine Softwaresache. Ich glaube es war bei Apple oder Atari wo das Indexsignal nichtmals mehr angeschlossen war. Weiterhin mag der Absolute Anteil an Nutzdaten nicht gross sein, aber er ist sehr ungleichmäßig verteilt. In den Headern, Pausen und Syncpausen ist fast nicht enthalten. Im eigendlichen Datenbereich ist der Anteil an Nutzdaten sehr hoch. (FM=50%, GCR=80%, MFM<100%) Das macht die Auswerung der Daten nicht einfach. bis dann Hauke Sattler
Hallo, vor x-Jahren habe ich mal einen Floppyersatz für Brauereien entwickelt und gebaut. Die Floppy wurde komplett durch Speicher ersetzt. Das Computer-System merkte nicht ob eine echte oder die nachgebildete Floppy angeschlossen war. Allerdings war als Schnittstelle zum nachgebildeten Laufwerk der damals übliche Flopykontroller zwischengeschaltet. Der eigentliche Speicher war das kurzzeitig moderne Bubble-Memory von Texas. Betrieben wurde das Ganze mit einem Z80. Also machbar ist so ein System auf jeden Fall. Gruss Gerd
Hauke Sattler wrote: > Es gibt zwar recht grosse SRAM Bausteine, aber die sind doch recht > teuer. Reichelt: 628512-55 M EUR 2,95 Da passen 512 KiB rein. Mit memory banking sollte man davon einige an einen ATmega1281 anklemmen können (oder ATmega128, bleibt sich gleich). Würde ich als größenordnungsmäßig für erschwinglich halten. Als stable storage könnte man ja eine SD-Karte über SPI benutzen, auf die man die Daten dann draufschreibt. Ja, fände ich nicht uninteressant, ich würde mich ggf. mit am Projekt beteiligen.
4x 628512-55 M + µC + SD-Slot Mega128 ist zwar nicht unbedingt gut geeignet, da er nur 64K externes RAM direkt ansteuern kann, aber bei den ARM gibt es jede Menge interessanter Bauteile die auch nicht schwerer zu löten sind als ein Mega128. Kling doch nach einer Idee... Wäre auch dabei
Lukas Slz wrote: > Mega128 ist zwar nicht unbedingt gut geeignet, da er nur 64K externes > RAM direkt ansteuern kann, ... Naja, für so ein simples Datengrab kann man diese bequem in 32 Bänke je 32 KiB unterteilen (jeweils den oberen halben Adressraum benutzen). Da müssen ja keine C-Variablen drin liegen oder sowas, sondern es werden nur lange, zusammen hängende Blöcke geschrieben. Darin sehe ich nun wirklich das kleinste Problem.
@Jörg Wunsch @Lukas Slz Es wären 8 x 628512-55 M (ich brauche 4MB) Das bedeutet es würden insgesammt 9 Bausteine (man darf das Adresslatch nicht vergessen) am Daten/Adressbus hängen. Ich habe ernsthafte Zweifel ob das gut geht. (Ich meine wegen Fan out usw.) Rein statisch betrachtet sollte der AVR die Bausteine treiben können. Ob das XRAM Interface das dann aber bei x MHz Taktfrequenz schaft wage ich zu beweifeln. Korrigiert mich wenn ich hier falsch liegen sollte. cu Hauke
Versuch macht kluch... Wurstkäse, ähem, worst case muss halt noch ein Bustreiber mit rein. Sowas war in der prä-CMOS-Ära gang und gäbe. Soll ich mal eine Platine dafür entwerfen und bauen?
Gibts keine geeigneteren RAM-Bausteine? Muss ja nicht unbedingt SRAM sein...
@Jörg wäre echt lieb von dir. Wegen Bustreiber: Das müsste dann aber ein bidirektionaler sein. Und den dann wieder mit der AVR-XRAM logic zu verheiraten ist noch mal ein eigenens TTL Grab. Versteh mich nicht falsch, ich habe die 8x512k auch schon Früher als Option gesehen. Aber ich bin Aufgrund der Fan-Out-Geschichte davon zurückgeschreckt. Weiterhin fand ich es echt grausig 8xSRAM auf einer Eagle light Version zu verdrahten (so das alles noch auf die Platine passt) @Lukas Es gibt größere SRAMs, nur sind die halt sehr teuer. z.B. BSI BS62LV1600ECP55 - SRAM - 2MB X 8 für 34,80 (als ich das letzte mal geschaut hatte waren die noch weit über 50Euro) Alternativen zu SRAM gibt es leider nicht. DRAM (Refresh-Problematik, und Lieferbarkeit) PSRAM (FBGA Lötproblematik) SDRAM (Bekommt man nicht an den AVR dran) FLASH/EEPROM (zu langsam beim Schreiben) cu Hauke
Einfach übereinanderstapeln ;) bzgl Fanout... die AVR können ja bis zu 20mA locker treiben, und wenn man /OE zur Bankumschaltung zwischen den großen RAMs nuzt hat man ja nur einen der "aktiv" den Bus belastet...
Hauke Sattler wrote: > Das müsste dann aber ein bidirektionaler sein. Und den dann wieder mit > der AVR-XRAM logic zu verheiraten ist noch mal ein eigenens TTL Grab. Könnte man notfalls über ein kleines CPLD machen. Aber ich bin eigentlich noch ganz guter Dinge, dass das auch ohne geht. Die SRAMs haben laut Datenblatt 6 pF Eingangskapazität, das mach bei 8 Stück dann 48 pF. Legen wir noch bisschen was für die Platine drauf und nehmen 100 pF Last an. Der ATmega128 kann bei 5 V initial etwa 70 mA treiben, wobei der Strom dann langsam abnimmt (aber eigentlich erst, wenn die Last schon sicher auf den neuen Pegel geschaltet hat). Nehmen wir mal 50 mA an, dann wären das 2 ns/V Anstiegszeit, also nach 6 ns müsste der Logikpegel auf der sicheren Seite (1/3 bzw. 2/3 Vcc) liegen. Ich denke, dass das ausreichend ist für einen 55-ns-SRAM. Der ATmega muss natürlich gut abgeblockt werden, denn all die vielen Milliampers dafür kommen ausschließlich aus den Abblockkondensatoren. > Weiterhin fand ich es echt grausig 8xSRAM auf einer > Eagle light Version zu verdrahten (so das alles noch auf die Platine > passt) Naja, ich habe BAE, damit kann ich eine Eurokarte vollpacken. Sollte aber eigentlich kleiner gehen. Eventuell lässt man sie ja auch fertigen statt es selbst zu machen, dann werden die Vias schöner (und man kann mehr davon setzen). Was muss denn noch so alles mit drauf? Kannst mir das auch per email schreiben.
Ich Will den Experten ja nicht widersprechen, aber glaubt ihr nicht, das ab einer gewissen Datenmenge (wie eben hier) DRAM sinnvoller, billiger und hier sogar einfacher wäre? Beitrag "2MB DRAM an AVR"
Der Haken ist, dass du praktisch keinen (normalen, asynchronen) dRAM mehr einfach so irgendwo kaufen kannst. Damit kann man natürlich auck kein Projekt aufsetzen, da man sich nicht drauf einstellen kann, welche Bauteiltypen etc. der Anwender dann tatsächlich zur Verfügung hat. Was vielleicht gehen könnte ist, dass man eine SIMM-Fassung vorsieht. Alte SIMMs bekommt man zuweilen irgendwo hinterher geworfen, und die haben in aller Regel dann mehr als 1 MiB. Müsste man nur nochmal in den Kisten kramen, die ersten hatten 8 bit breite Busse, die wären hier am besten geeignet. Aber selbst Fassungen dafür zu erhalten dürfte nicht trivial sein: Ablöten von Mainboards birgt ein hohes Zerstörungsrisiko.
Was höchstens noch eine Frage wäre: bekommt man eine SDRAM-Ansteuerung in ein kleines CPLD rein? XC9536 bekommt man recht günstig, und SDRAMs sind auch einzeln erhältlich.
Es gab auch Typen die so Stiffte drann hatten... Also könnte man doch auch einfach ne Stiftleiste dranlöten... hab sowas gerade bei mir aufm Schreibtisch liegen sind 3x Panasonic MN414400ASJ-07 drauf... nur leider kein Datenblatt dafür :-\
Läubi Mail@laeubi.de wrote:
> Es gab auch Typen die so Stiffte drann hatten...
SIPPs (oder SIPs?), sind noch älter und damit noch seltener. Außerdem
dürfte deren Ära mit Erreichen der 1-MiB-Grenze zu Ende gewesen sein,
d. h. du brauchst auch schon wieder zwei Stück davon. Ich denke nicht,
dass der Aufwand dann wirklich noch geringer ist als mit 8 x
628512-55 (auch wenn der Beschaffungspreis sicher geringer ist).
Wir haben ein Produkt im Angebot welches sich exakt wie ein Diskettenlaufwerk verhält (inkl. aller Anschlüsse!) nur anstatt der Diskette befindet sich eine Compact Flash im Laufwerk. Falls weitere Interesse besteht könnt ihr ja mal hier nachfragen! mfg. muhkuh
http://en.wikipedia.org/wiki/SIMM die 30pin version... 1MB max stimmt schon, aber wenn kriegt man halt nen ganzen Berg davon, hab bestimmt noch so 10-20 hier rumliegen udn immer mal dran gedacht an nen AVR zu hängen, bin ich aber nie zu gekommen.
Die Idee ein CPLD und SDRAM zu verwenden würde ich unterstützen da man das Teil auch in anderen Projekten gut verwenden könnte, wo viel, aber nicht unbedingt extrem schnelles RAM gebraucht wird.
Läubi Mail@laeubi.de wrote: > 1MB max stimmt > bzw... Laut Wikipedia: 30-pin SIMM: 256 KB, 1 MB, 4 MB, 16 MB Wie stellt der PC eigentlich fest viel RAM ein Baustein hat??
Läubi Mail@laeubi.de wrote:
> Wie stellt der PC eigentlich fest viel RAM ein Baustein hat??
Bei diesen alten Teilen: indem der Benutzer ihm das im BIOS-Setup
eingibt...
Nur mal so als Idee: Die AT90USB1287 können USB Host machen und damit auch einen USB-Stick ansprechen. Schließlich will man das System nicht unbedingt für eine Quelle und x PCs aufbauen. Ein USB-Stick würde das ganze als Transportmedium sicherlich vereinfachen und nur einen Aufbau für jedes Quellsystem erforderlich machen. Ich würde meinem Agilent MSO soetwas auch gerne spendieren. Allerdings sind, dank Cardreader, auch andere Speichermedien durchaus eine Lösung, also SD oder ähnliche. Aber auch hier sind die Flash-Zeiten identisch lange. Die AT90USBs haben einen eigenen Puffer für die USB Pakete, man hat also wärend des versendens eines Paketes Zeit weiter den Floppy-Stream zu dekodieren. Bei SD-Cards muss man sich selbst um den zeitigen Transport kümmern. Hier würden erst die xmegas helfen, mit ihrem DMA. Natürlich besteht immer noch das Problem, dass Sticks ihre Flash-Zeit brauchen. Hier könnte man aber mal Überlegungen anstellen, ob es nicht mit wenig Dual-Ported RAM oder einer pfiffigen Synchronisierung getan ist. Es gab auch mal Kombinationen von altem EDO RAM mit einem AVR, der das Refresh per Timer-Interrupt gamcht hat. Ich habe noch Tonnen von diesen kleinen Riegelchen herum fliegen und auch SIM Sockel dafür, im standard Raster. Außerdem gab es, meine ich, auf der XilinX Seite mal AppNotes oder Beispielprojekte in denen NRZI und ähnliche Bitstreams in einem CPLD und nicht gleich in einem FPGA gelöst wurden. Ein CPLD ist immerhin noch in PLCC verfügbar und damit, dank Sockel, auch Lochrasterfähig. Damit kann man dann den zeitkritischsten Teil dorthin auslagern und dem AVR etwas mehr Koordinations-Aufgaben anvertrauen. Es steht aber immer noch die Frage im Raum, ob man das alles wirklich vollends allgemein verwendbar machen möchte, oder ob man es nicht auf ein paar Quellsysteme reduzieren kann. Wenn sich herausstellt, dass alle unsere mit dem System auszustattenden Geräte ähnliche Floppycontroller verwenden, dann bin ich für die einfachere Lösung, nämlich dessen /CS fest auf high zu legen und dem Emulator davor zu kontaktieren. Das würde erheblich schneller zu realisieren sein. So viele verschiedene Floppy-Chips gab es eigentlich nicht und viele davon haben ihre Innereien und ihr Verhalten vom alten, wie hieß er noch? Intel 751er? geerbt. Gruß, Ulrich
NE765. Aber ob man wirklich freiwillig in so 'ner alten Kiste von einer A3-Format-großen Platine einen DIP40 auslöten will und dabei riskieren, dass man irgendwo in einer Innenlage was abreißt? In Fassungen dürften die Teile bei industriellen Messgeräten in aller Regel nicht stecken. Außerdem gab es noch irgendeinen WD-Controller, der wohl deutlich intelligenter war als der dumme NE765 (aka. i8272). Der war zwar nicht PeeCee-kompatibel, aber in so einem Messgerät könnte er dank seiner besseren Handhabbarkeit durchaus eher seinen Platz gefunden haben.
@Ulrich P. Glaube mir ich habe mir sehr genaue Überlegungen gemacht bezüglich Pufferung im RAM und Speicherung im Flash. Die Situation Lesen Speichern Trackwechsel Lesen Speichern hat allen Varianten das Genick gebrochen. Ich habe auch Überlegungen zum Dekodieren im CPLD gemacht. Das Ergebniss war nicht fehlertolerant genug. Aber das war nicht die Frage, das Codieren und Dekodieren habe ich schon gelöst. Was noch fehlt ist, jede Stelle des Images Byteweise zugänglich zu machen. Beim lesen ist das kein Problem mit Flash. Leider läßt sich Flashspeicher jedoch nur Blockweise beschreiben, und ist damit nicht Byteweise zugänglich. Die Frage ob man den FDC umgehen soll, kann ich nur strikt verneinen. Viele werden an ihren Meßgeräten nicht rumlöten wollen. Zum zweiten ist es üblich das der FDC in der restlichen Elektronik/Chipsatz mit integriert ist. Es gibt also in dem Sinne keine /CS Leitung mehr (zumindest außerghalb der Chips). Ein CPLD SDRAM Controller wäre sehr nett, nur wer kennt sich mit dieser Materie genügend aus? cu Hauke
muhkuh wrote:
> Falls weitere Interesse besteht könnt ihr ja mal hier nachfragen!
Na, dann rueck doch einfach damit raus ;-)
Also für meine Seite sollte das Teil ein "Standard" 3,5" 1,44MB Floppylaufwerk emulieren, und zwar so, das auf der Messgeräteseite keine Modifikationen außer dem Austausch des Laufwerks nötig sind. Ein CPLD-SDRAM-Controller welcher den Anschluss von viel Speicher mit wenig Pins und Aufwand auf der AVR-Seite erledigt würde mich auch noch für andere Projekte interessieren. Ich würde gerne mithelfen, wenn ich kann...
Hi! Ich wollte nur mal eine Reihe von Gedankengängen anwerfen. Da ich mein Agilent MSO aus eigener Tasche bezahlt habe, wäre ich ebenfalls sehr an einer auf dessen Seite lötfreien Alternative interessiert. Es geht also, dank der bereits funktionierenden Bitream Kodierung / Dekodierung nur noch um eine elegante Pufferung im RAM und die Weiterverarbeitung durch einen Zielspeicher-Controller? Welche Geschwindigkeiten müssen denn nun in Sachen RAM Zugriff erreicht werden können? Wenn der eine AVR den Bitstream in ein olles EDO RAM schreibt, dann kann sich der zweite darum kümmern diese Daten auf ein Zielmedium zu bekommen und auch den Refresh zu generieren. Ein CPLD wäre da vielleicht nicht mal nötig.
Update Ich habe nochmal gesucht. Es gibt mitlerweile anscheinend eine günstige 2MB SRAM Variante. BS62LV1600EIP55 - SRAM-16M (2MX8BIT)3V 55NS, TSOP44 Die kostest bei Farnell "nur" 18,88 als Einzelstückpreis. Das ist noch bezahlbar. TSOP44 sollte auch noch lötbar sein. Und nur zwei Speicherbausteine sollte auch noch verträglich für den Bus sein. Ich werde mal meinen ganzen Kram nochmal durchgehen und schauen ob das RAM geeignet ist. @Jörg Wunsch reicht es dir, wenn ich eine Eagle-SCH-Datei mache, damit du etwas daraus Routen kannst? Würde ein Testaufbau werden, an dem man die Software weiterentwickeln kann. cu Hauke
Jörg Wunsch wrote: > Außerdem gab es noch irgendeinen WD-Controller, der wohl deutlich > intelligenter war als der dumme NE765 (aka. i8272). Intelligenter als der NEC µPD765 war der WD179x durchaus nicht, im Gegenteil. Den WD1791 hat Segor übrigens noch auf Lager.
Das ganze ist mit einem FPGA realisiert und ein wenig hühnerfutter drum rum und natürlich Spannungsregler, nichts Weltbewegendes. Fragt mal bei www.sigmatek-automation.at nach dem Compact Flash Floppy an. Weiss die genaue Bezeichnung jetzt nicht CFF0xx wobei xx für eine Zahl steht. Glaube es heißt CFF011. Funktioniert aber in PC's und auch in unseren Steuerungen, ist zu 100% Kompatibel mit nem normalen Floppy und kann alle gewünschten Speichergrößen der Floppys also HD, 2HD usw.. Mit auf der Front befindlichen Tastern kann ein neus Laufwerk auf der CF-Karte ausgwählt werden. Es sind bis zu 99 Laufwerke möglich, sofern die Speicherkapazität ausreicht. mfg. muhkuh
Wie wäre es, einen mittelgrossen ARM mit SDRAM Controller einzusetzen? Aber selbst der hat wahrscheinlich ZIEMLICH zu tun, wenn er 1 MBit/s in reiner Software dekodieren soll, zumal der AMT nicht so dolle schnell beim IO.-Zugriff ist. Da muss wohl ein kleiner CPLD her, der erstmal in Byte/Words seriell-parallel wandelt. Aber Zur Entwicklung würde ich erstmal nur Eval-Boards nehmen, und am Ende alles in eine fertige Form giessen. Denn ich befürchte dass es da noch einige Unklarheiten und Überaschungen geben wird. MFG Falk
Weiss nicht wie es mit Speichergrösse und Preis aussieht, aber wäre FRAM nicht was?
Zum Codieren und Dekodieren ist so ein kleiner Bitschubser besser. Wenn ich mich recht erinnere, das ist beim ARM die Anbindung der Ports recht indirekt. Was meinen Lösungsansatz angeht so ist der µC mit dem Speicher eine reine Datenkippe. Hat bisher kaum Aufgaben. Es sollte daher kein Problem darstellen, die Datenwandlung von und in das Floppyimage in diesem Controller zu machen. cu Hauke
@ Hauke Sattler (hauke) >reine Datenkippe. Hat bisher kaum Aufgaben. Es sollte daher kein Problem >darstellen, die Datenwandlung von und in das Floppyimage in diesem >Controller zu machen. Naja, aber auch bei 20 MHz hat ein AVR mit 1 Mbit/s schon GUT zu tun. Ob es reicht? MFG Falk
Hauke Sattler wrote: > Es gibt mitlerweile anscheinend eine günstige 2MB SRAM Variante. > BS62LV1600EIP55 - SRAM-16M (2MX8BIT)3V 55NS, TSOP44 > Die kostest bei Farnell "nur" 18,88 als Einzelstückpreis. > Das ist noch bezahlbar. Naja, immer noch doppelt so viel wie die andere Variante. > TSOP44 sollte auch noch lötbar sein. Ja, das geht schon noch. > Und nur zwei Speicherbausteine sollte auch noch verträglich für den Bus > sein. Wie schon geschrieben, ich denke nicht, dass das bei genügend kurzen Leitungen ein wirkliches Problem wird. > @Jörg Wunsch reicht es dir, wenn ich eine Eagle-SCH-Datei mache, damit > du etwas daraus Routen kannst? Eagle nützt mir nix, ich mache BAE. Du kannst mir ein PDF mit dem Stromlaufplan schicken. Weiß nicht, ob dein Adler eine Netzliste ausgeben kann, sowas kann BAE importieren, habe ich aber auch noch nie gemacht. Keine Ahnung, wie viel das einem die Arbeit erleichtern würde. Ich kann's aber auch einfach komplett neu zeichnen, da genügt sogar eine Bleistiftskizze.
Hi Mein bisheriger Plan war: ATmega16 (Codec) ATmega64 (IO und Mem Controller) 2xBSI 2MB RAM Bausteine und ein paar latches und Logicgatter zur Bustrennung zum Schugart Bus. Jetzt bin ich den Codec Sourcecode nochmal durchgegangen und denke das man das auch auf einen ATMega8 bekommt. Statt dem Mega64 köönte man auch einen ATmega325/645 nehmen. Was denkt ihr was für Schittstellen sonst noch sinnvoll wären. (SPI wird schon gebraucht) cu Hauke
Jörg Wunsch wrote: > Läubi Mail@laeubi.de wrote: > >> Wie stellt der PC eigentlich fest viel RAM ein Baustein hat?? > > Bei diesen alten Teilen: indem der Benutzer ihm das im BIOS-Setup > eingibt... Beim Atari STE per Software. muhkuh (Gast) wrote: > sitzt ein kleiner chip (eeprom) drauf :) Nicht bei 30 pol Simm und auch nicht bei 72 pol.
Hauke Sattler wrote: > Mein bisheriger Plan war: > ATmega16 (Codec) > ATmega64 (IO und Mem Controller) > 2xBSI 2MB RAM Bausteine Eigentlich finde ich die schwierigere Beschaffbarkeit dieser RAMs (Farnell liefert nicht an privat) sowie den doppelten Preis gegenüber der 8 x 512 KiB Lösung schon ungünstig. > und ein paar latches und Logicgatter zur Bustrennung zum Schugart Bus. Braucht man die wirklich? OC-Ausgänge kann man auch mit einem AVR emulieren. > Jetzt bin ich den Codec Sourcecode nochmal durchgegangen und denke das > man das auch auf einen ATMega8 bekommt. Lohnt nicht. Der lässt sich nicht debuggen. Wenn schon, dann ATmega88, dann hat man auch Reserven bezüglich Aufrüstbarkeit (mittlerweile bis zum ATmega328P). Allerdings finde ich das Debuggen über JTAG schöner als über debugWIRE, und die paar Cent Preisunterschied zwischen einem ATmega88 und ATmega16 machen den Kohl nicht fett. Die RAMs sind ohnehin teurer (egal, welche Variante). > Statt dem Mega64 köönte man auch > einen ATmega325/645 nehmen. Wie das? Die haben doch kein XMEM-Interface.
> Eigentlich finde ich die schwierigere Beschaffbarkeit dieser RAMs > (Farnell liefert nicht an privat) sowie den doppelten Preis > gegenüber der 8 x 512 KiB Lösung schon ungünstig. Die Speicherausstattung kann man ja variabel gestalten. Bei nur Lese SSFDD braucht man eh keinen externen Speicher. >> und ein paar latches und Logicgatter zur Bustrennung zum Schugart Bus. > > Braucht man die wirklich? OC-Ausgänge kann man auch mit einem AVR > emulieren. Der Problem sind die Latenzzeiten. Die Interrupt Reaktionszeit ist länger als die zugelassene Zeit für das an und abwählen der Floppy (500nS). Bei 16Mhz bleiben mir nur 8 Takte, das ist verdammt knapp. Zum zweiten wollte ich die beiden Latches gesockelt einbauen. Falls man sich mit dem Kabel verhaut, dann grillt man Latches für nen paar Cent und nicht den 64 poligen SMD-verlöteten AVR. >> Jetzt bin ich den Codec Sourcecode nochmal durchgegangen und denke das >> man das auch auf einen ATMega8 bekommt. > > Lohnt nicht. Der lässt sich nicht debuggen. Wenn schon, dann ATmega88, > dann hat man auch Reserven bezüglich Aufrüstbarkeit (mittlerweile bis > zum ATmega328P). Allerdings finde ich das Debuggen über JTAG schöner > als über debugWIRE, und die paar Cent Preisunterschied zwischen einem > ATmega88 und ATmega16 machen den Kohl nicht fett. Die RAMs sind ohnehin > teurer (egal, welche Variante). Es ging mir mehr um die Baugröße. Der Mega8/48/88/168 ist schlichtweg kompakter und einfacher zu löten (wegen weniger pins) >> Statt dem Mega64 köönte man auch >> einen ATmega325/645 nehmen. > > Wie das? Die haben doch kein XMEM-Interface. Knick in der Optik. Ich meinte den Mega1281/2561 cu Hauke
Jungs, baut erstmal was auf nem Evalboard auf, dann werdet ihr wahrscheinlich merken dass ein AVR mit der MFM (De)kodierung + Datenabtransport nicht nachkommt. 1MBit/s sind kein Pappenstil, auch wenn der Igor-Plug 1,5 Mbit/s schafft (sind ja nur kurze Pakete). MfG Falk
Hauke Sattler wrote: > Die Speicherausstattung kann man ja variabel gestalten. Hmm, OK. >>> und ein paar latches und Logicgatter zur Bustrennung zum Schugart Bus. >> >> Braucht man die wirklich? OC-Ausgänge kann man auch mit einem AVR >> emulieren. > Der Problem sind die Latenzzeiten. Die Interrupt Reaktionszeit ist > länger als die zugelassene Zeit für das an und abwählen der Floppy > (500nS). Verstanden, ja. Sind übrigens 500 ns, das andere wären Nanosiemens. > Es ging mir mehr um die Baugröße. Der Mega8/48/88/168 ist schlichtweg > kompakter und einfacher zu löten (wegen weniger pins) Naja, bei 0,8 mm Pinabstand lötet es sich noch ganz bequem, und den Baugrößenunterschied der beiden TQFPs finde ich nicht so dramatisch. DILs willst du ja sicher sowieso nicht benutzen. > Knick in der Optik. > Ich meinte den Mega1281/2561 OK, wobei die ja pinkompatibel zum ATmega64/128 sind.
Falk Brunner wrote:
> Jungs, baut erstmal was auf nem Evalboard auf, ...
Das Ding ist dann das Evalboard. Für den nötigen XRAM braucht man
ohnehin eine Platine, dann kommt's auch nicht drauf an, ob man gleich
alles auf die gleiche Platine pappt. Das Shugart-Businterface müsste
man ja auch wieder irgendwo aufbauen.
Kleb nen USB Floppydrive an das Oszi und schon haste USB Abschluß. Must halt nur die Diskette kurz umstecken, ist quasi ne galvanische Datentrennung .... :D:D Aber mal im Ernst: Wenn es ein Problem sein sollte, daß man keinen PC in der Firma mehr mit Diskettenlaufwerk hat, dann kauft man eben ein externes und lässt es beim Gerät .... Dei Einkauf und Dein Chef danken es Dir ....
Und was macht man, wenn das interne Diskettenlaufwerk im tollen Oszilloskop die Grätsche macht? Und das kein 1.44MB-HD-Laufwerk war, sondern ein altes 720kB-DD-Laufwerk? Da hilft ein USB-Laufwerk irgendwie gar nicht.
@Outi Outlaw Der Grund ist vermutlich, dass man die Dinger weg haben will :) Sie sind unhandlich und gehen oft kaputt (Datenverlust) Das CFF011 von muhkuh sollte aber das sein was ihr sucht: http://www.motioncontrol.be/default.aspx?_vs=0_N&lev=18069577&part=T08241I0300xPCH Gruß Roland
@Jörg Wunsch (dl8dtl) (Moderator) >> Jungs, baut erstmal was auf nem Evalboard auf, ... >Das Ding ist dann das Evalboard. Für den nötigen XRAM braucht man >ohnehin eine Platine, dann kommt's auch nicht drauf an, ob man gleich Naja, ich kenn ja nicht euren Stand im Detail, aber so wie ich es sehe ist der Knackpunkt im Moment bei der Dekodierung von MFM + Speicherung. Das kann man aber erstmal problemlos für einen Sektor auf einem einfachen AVR ohe XMEM testen, 512 Byte hat selbst ein Mega8. UNd für ne Spur mit 11 Sektoren, naja Mist, dann muss XMEM her ;-) Aber ich wünsch euch viel Erfolg, bin mal gespannt was draus wird. Abo MFG Falk
@Roland: Das Agilent hat aber ein Slimline Floppy, da pass das CFF011 einfach nicht rein. Aus technischer Sicht unerheblich, aber das Auge (m)isst halt mit, ist schwarz auf einer komplette beige Frontblende ebenfalls .... Gruß, Ulrich
nochmal zur ZugriffsZeit: Es gibt das HLD(Head Loaded)-Signal (von FDD zum FDC), wenn das im Gerät genutzt wird, hat man genug Zeit, Daten auf einen Stick o.ä. zu schreiben. Solange das Signal nicht aktiv ist, wartet der FDC (zumindest war es ursprünglich so vorgesehen). Dass auf eine Floppy bitweise zugegriffen wird, habe ich noch nicht erlebt. Normalerweise immer Sektorweise (daher kommen auch die klassischen 512 Byte / Sektor). Das Index-Signal ist manchmal beim Formatieren wichtig. Aber das brauchen wir gar nicht. Wir simulieren (zunächst) einfach fertig formatierte Disketten. Das ist zwar nicht 100% kompatibel, aber 99%.
Falk Brunner wrote: > @Jörg Wunsch (dl8dtl) (Moderator) > Naja, ich kenn ja nicht euren Stand im Detail, aber so wie ich es sehe > ist der Knackpunkt im Moment bei der Dekodierung von MFM + Speicherung. Nun, Hauke schrob weiter oben aber bereits: Das MFM Codec Programm ist im Prinzip fertig. Es verträgt alle FM/MFM/RLL/GCR Formate mit 125/250/500kHz Aufzeichnungstakt. An der Variante für 300kHz arbeite ich noch (ist nur für 1,2MB 5,25" wichtig)
eProfi wrote: > Es gibt das HLD(Head Loaded)-Signal (von FDD zum FDC), wenn das im Gerät > genutzt wird, hat man genug Zeit, Daten auf einen Stick o.ä. zu > schreiben. Herr Profi, wann hast du das letzte Mal mit Floppies dein Geld verdient? (Was anderes heißt "Profi" ja nicht.) Das Signal geht genau in die andere Richtung, und es diente dazu, bei den 8"-Floppies die Köpfe anzulegen. Seit 5,25" werden die Köpfe aber beim Einschieben des Mediums angelegt, sodass das Signal überflüssig ist. Die FDCs generieren es trotzdem noch, und man muss die entsprechenden Timings daher auch setzen. > Dass auf eine Floppy bitweise zugegriffen wird, habe ich noch nicht > erlebt. Der Controller kennt auf der Floppyseite nur Bits. Sektoren macht er erst selbst da draus, und beim Überschreiben eines Sektors muss er halt die Sektor-ID lesen und erkennen, danach dann die Daten neu schreiben. Auf Grund von Drehzahlschwankungen sind dabei die genauen Zeitpunkte nicht konstant, und wenn man das dann wieder ausliest, dann kann es schon passieren, dass das nächste Synchronfeld irgendwo mitten in einem Bit anfängt. > Normalerweise immer Sektorweise (daher kommen auch die klassischen 512 > Byte / Sektor). Was die nun damit zu tun haben, das musst du uns noch erklären. Wenn überhaupt, dann wären ,,klassisch'' in diesem Zusammenhang am ehesten Sektoren von 128 Bytes zu nennen. Ansonsten war da bis zu 1024 Bytes alles mögliche üblich (ich glaube teilweise sogar bis 4096 Bytes). > Das Index-Signal ist manchmal beim Formatieren wichtig. > Aber das brauchen wir gar nicht. Wir simulieren (zunächst) einfach > fertig formatierte Disketten. Das ist zwar nicht 100% kompatibel, aber > 99%. Also inkompatibel. Aber das Indexsignal ist ohnehin das geringste Problem.
Hallo erstmal Leider gibt es viel zu viele unterschiedliche Dokumentationen zum Thema Floppy. Was ich hier sage stellt daher nur das dar was ich aus den 160MB an Dokus habe herausziehen können. eProfi wrote: > nochmal zur ZugriffsZeit: > Es gibt das HLD(Head Loaded)-Signal (von FDD zum FDC), wenn das im Gerät > genutzt wird, hat man genug Zeit, Daten auf einen Stick o.ä. zu > schreiben. > Solange das Signal nicht aktiv ist, wartet der FDC (zumindest war es > ursprünglich so vorgesehen). > Meines Wissens war das Headloaded Signal nur bei 8 Zoll Floppies in Verwendung. Und dort ging es von FDC zum FDD (also genau in die falsche Richtung) Der Pin wird heuzutage für das Density-Select Signal genutzt (von FDC zum FDD). > Dass auf eine Floppy bitweise zugegriffen wird, habe ich noch nicht > erlebt. > Normalerweise immer Sektorweise (daher kommen auch die klassischen 512 > Byte / Sektor). > Es wird üblicherweise nicht bitweise zugegriffen, es ist aber erlaubt. Was aber ohne weiteres möglich ist, dass nur die Header der Sektoren auf verschiedenen Spuren geändert werden (z.B. beim Löschen einer fragmentierten Datei). > Das Index-Signal ist manchmal beim Formatieren wichtig. > Aber das brauchen wir gar nicht. Wir simulieren (zunächst) einfach > fertig formatierte Disketten. Das ist zwar nicht 100% kompatibel, aber > 99%. cu Bis dann Hauke Sattler
Hallo, ich habe mir nicht die Arbeit gemacht den ganzen Thread durchzulesen und weiss nicht ob das schon jemand vorgeschlagen hat: Vielelicht wuerde ein USB Floppy Drive die Loesung sein: http://www.lacie.com/products/product.htm?pid=10086 Wenn das Instrument FAT formatierte Floppies schreibt, dann ware das Problem mit dem USB Floppy Drive geloest. Ich habe so ein Geraet und es funktioniert super. Hat bei mir $70 gekostet. MFG, Gerhard
Im Atari 1040 mußte der Floppycontroller gegen eine schnellere Spezialausführung (ausgesuchte Exemplare?) gewechselt werden, wenn man ein HD-Laufwerk anstelle des DD einbauen wollte. Ich meine er war pinkompatibel zum WD2797: http://www.alldatasheet.com/datasheet-pdf/pdf/90425/ETC/WD2797.html
@ Gerhard. (Gast) Leider ist eben dies nicht die Lösung. Die älteren Geräte welche heutzutage noch zwingend auf Floppy angewiesen sind, haben in der Regel keinen USB Anschluss. Und den USB->Floppy Adapter an den Shugart-Bus des Zielgerätes anzuschließen würde vermutlich zum Exitus von beiden Floppycontrollern führen. cu Hauke Sattler
Hallo Hauke, Der USB Floppy Drive war gedacht an PCs angeschlossen zu werden die kein Floppy Drive mehr eingebaut haben. Solange das Instrument FAT formatiert Disketten verarbeiten kann, waere das die Loesung da alle modernen PCs USB Anschluesse haben. So hatte ich das gemeint. Sollte Dein Instrument nur HP Formatierte Disketten verarbeiten, gibt es auch noch eine Loesung in der Form von HP-LIF Utilities. Damit kann man mit einem PC HP Disketten lesen und umwandeln. Nur weiss ich nicht ob die noch auf einem Windows PC funktionieren. Dazu brauchst moeglicherweise einen wirklichen MS-DOS PC, -(. MFG, Gerhard
> ich habe mir nicht die Arbeit gemacht den ganzen Thread durchzulesen das ist genau das Problem. Du verstehst gar nicht was hier gesucht wird. > und weiss nicht ob das schon jemand vorgeschlagen hat: ja > Vielelicht wuerde ein USB Floppy Drive die Loesung sein: nein.
AJAX hieß der Chip, oder WD1772-02-02 http://de.wikipedia.org/wiki/Atari_ST Floppy-Controller WD1772: MFM-Controller für Laufwerke mit Standard-Shugart-Bus; neuere TT030 und Mega STE sowie alle Falcon 030 wurden mit HD-Diskettenlaufwerken und dem voll kompatiblen, aber auch bei höheren Taktfrequenzen (16 MHz und 32 MHz) stabil laufenden AJAX ausgeliefert. Im Datenblatt vom WD2797 lese ich höchstens 3-6 MHz, ist der so viel älter?
Ok Hatten wir ganz aneinander vorbeigeredet. Ich denke es geht hier vielen leuten nicht darum ihren PC wiedr Floppy tauglich zu machen. Dazu ist deine Lösung in der Tat sehr gut geeignet. Eine Frage ist natürlich wie die Sache der USB-Floppyunterstützung unter einem DOS Emulator aussieht. Meine Zielsetzung war es vielmehr die Floppy als Medium selber zu ersetzen. Weiterhin sollte aber eine 100% Kompatiblität zum Zielsystem beibehalten werden. Das ist dort wichtig, wo z.B. noch Floppy zur Maschienensteuerung verwendet werden. Es ist mittlerweile schon schwierig noch neuwertige Medien zu bekommen (3,5" DD oder 5,25"). Manchen Geräte (CNC-Maschienen, Webstühle, Druckmaschinen, Analysegeräte) sind halt in der Ersatzanschaffung extrem teuer. Andererseit möchten manche von euch sicherlich ungern euer heissgeliebtes DSO, Logiganalysator oder Signalgenerator wegwerfen, nur weil die Floppy nicht mehr will. cu bis dann Hauke
Danke fuer die Kommentare. Ich muss mich leider mehr auf meine Arbeit konzentrieren im Moment und tut mir leid dass ich da etwas "daneben" gehauen habe. Eine selbstgebaute Ersatzloesung fuer solche Anwendungen waere natuerlich eine feine Sache. Werde spaeter wiedre reinschauen wen nich mehr Zeit habe. Schoenen Abend allerseits, Gerhard
@Gerhard. (Gast) >ich habe mir nicht die Arbeit gemacht den ganzen Thread durchzulesen und Ein immer wieder gern gemachter Fehler. >Vielelicht wuerde ein USB Floppy Drive die Loesung sein: Nein, weil ein Floppy in einem (alten) Gerät ersetzt werden soll. Und ausserdem die Herausforderung sonst fehlt ;-) MFG Falk
Hallo Falk, ein universeller Floppy Emulator ware natuerlich ein tolles Projekt das mich auch sehr interessiert. Ich werde mir den Thread heute Abend nochmals in Ruhe vornehmen da mir das Thema auch sehr wichtig ist. Aber jetzt geht es leider nicht da die Arbeit ruft...; -) MFG, Gerhard
> Das Signal geht genau in die andere Richtung, und es diente dazu, > bei den 8"-Floppies die Köpfe anzulegen. > Seit 5,25" werden die Köpfe aber beim Einschieben > des Mediums angelegt, sodass das Signal überflüssig ist. <Pedanterie>Es gab sogar 3.5"-Laufwerke mit Kopflademagneten. Ich habe in irgendeiner Schublade noch mein erstes, vom Taschengeld gekauftes 720k-Diskettenlaufwerk, ein FD1035 von NEC. Das hat damals 280 DEM gekostet und machte beim Kopfladen/-entladen immer so schön "pling". Achja, und es ist 1.6" hoch, also so hoch, wie ein normales CD-Laufwerk. </Pedanterie>
OK, die kannte ich wirklich nicht, aber auf jeden Fall ist das kein "Warte mal ein wenig!"-Signal des Laufwerks, sondern ein Signal des Controllers.
Ich glaube das einzige "Warte ein wenig" Signal welches es bei der Floppy gibt, ist "Diskette nicht eingelegt" Signal.
<Pedanterie>Mein FD1035 hat 'nur' 640 KByte</Pedanterie>
Hauke Sattler wrote: > Ich glaube das einzige "Warte ein wenig" Signal welches es bei der > Floppy gibt, ist "Diskette nicht eingelegt" Signal. ...das aber beim IBM PeeCee großzügiger Weise am FDC fest auf high (oder low?) verdrahtet ist, weshalb dort dann prinzipiell der FDC in einen Timeout läuft, aus dem er sich nur durch einen Hardware- Reset wieder beseitigen ließ. :-/ Könnte natürlich beim Messgeräten wirklich ausgewertet werden. Fehlen des Signals ist aber ein tödlicher Fehler beim versuchten Floppyzugriff.
Richtig, das Laufwerk meldet insgesamt nur folgende Signale an den Controller: Spur 0 Schreibschutz Index Lesedaten Diskettenwechsel
Hallo, vieleicht übersehe ich etwas aber bei der Elektronikapotheke gibts für 19.95€ ein Floppylaufwerk mit kartenleser. Ich weiss zwar nicht ob diese Teile auch das standard-Floppykabel haben, aber ich vermute es. Wenn das jemanden vor dem stundenlangen Bastleln gerettet haben sollte, so kann er mir danken, indem er mir ein solches Teil schenkt, da ich auch einen Diskettenfressenden HP LA habe. http://de.shopping.com/xDN-diskettenlaufwerke--conrad_de Nr. 3 und 4
@DerArmeExstudent: Die Dinger werden, wie in den technischen Daten angegeben, mit nem Floppy Kabel und nem USB-Kabel angeschlossen. Passt also auch nicht zum Problem des Threaderöffners. jjk
DerArmeExstudent wrote: > Hallo, vieleicht übersehe ich etwas aber bei der Elektronikapotheke > gibts für 19.95€ ein Floppylaufwerk mit kartenleser. Das scheint mir aber einfach nur eine Baueinheit aus einem echten 3,5"-Floppylaufwerk zuzüglich eines SD- etc. Kartenlesers zu sein.
Ok, das Thema ist ja hochinteressant... Vorschlag: - Ein SD-Card-Leser/Schreiber (einfacher ala USB-Host), der ein Diskettenlaufwerk emuliert. - Auf der Karte sind eine Maximalzahl von Diskettenimages gespeichert. Der Dateiname mag vielleicht DISKxxx.IMG lauten. Die Imagenummer kann per Up/Down-Taster am Gerät ausgewählt werden. - Vielleicht gibt es sogar einen Auswerftaster, der das Vorhandensein einer Diskette umschaltet. So ein Gerät könnte alle Diskettenlaufwerke im Umkreis verüberflüssigen!
3. Harmonischer wrote: > - Ein SD-Card-Leser/Schreiber (einfacher ala USB-Host), der ein > Diskettenlaufwerk emuliert. OK, fein, und was bauen wir dann am Nachmittag? (Falls du den Spaß nicht verstehen solltest: genau darum geht es im ganzen Thread, wie man eben dieses Gerät realisiert.)
> Hallo, vieleicht übersehe ich etwas aber bei der Elektronikapotheke > gibts für 19.95€ ein Floppylaufwerk mit kartenleser. Das ist zwar nett, aber nicht unbedingt nützlich. Das ist ein 1.44MB-HD-Diskettenlaufwerk. In älteren Geräte findet man aber häufig 720k-Laufwerke, und an den dafür vorgesehenen Controllern funktionieren HD-Laufwerke nicht so ohne weiteres. Außerdem ist für den Einsatz in PCs die Definition des Shugart-Busses "angeglichen" worden; nicht jeder Controller kommt damit klar.
Ich habe so ein Floppy/Flashcard Combilaufwerk. Innen drin ist nur ein Slimline Floppy (über 34Pol Shugard) und ein Slimline Mehrfach-Flashcardleser (über USB). Die Beiden sind nichtmals elektrisch miteinander verbunden. Was ich beisteuern kann: Umwandlung des rohen Floppydatenstroms von und in einen syncronisierten Bitdatenstrom. (fertig für FM/MFM/RLL/GCR mit 125/250/500kHz) Umwandlung des Bitdatenstroms von und in ein Diskettenimage. (Sollte relativ einfach sein) Umwandlung des Images von und in ein formatiertes Sektorimage (Bei üblichen Datenformaten) Zusätzlich: Umwandlung von einem formatiertes Sektorimage direkt in den rohen Floppydatenstrom. (hatte ich in der frühzeit des Projektes schonmal geproggt) Wie man die Daten in und aus dem XRAM bekommt (von USB, CFcard usw.) müssten dann andere beisteuern. cu Hauke
Hast du schon das Überschreiben einzelner Sektoren probiert? Die Ansteuerung einer MMC/SD-Karte selbst dürfte in zahllosen Projekten bereits existieren, einschließlich einfacher FAT-Implementierungen. Ich würde wohl eine Datei pro Floppyimage benutzen. Irgendwie müsste man natürlich das auszuwählende Image noch selektieren können. Eigentlich müssten dafür die Pollin-Drehencoder ganz nett brauchbar sein, zusammen mit einer kleinen 7-Segment-Anzeige. Wem eine Nummer des Floppy-Images nicht genügt, der kann ja ein LCD spendieren und komplette Namen anzeigen.
Roland Praml wrote: > Das CFF011 von muhkuh sollte aber das sein was ihr sucht: > http://www.motioncontrol.be/default.aspx?_vs=0_N&lev=18069577&part=T08241I0300xPCH Könnte sein. Keine Ahnung, wie gut die Beschaffbarkeit wirklich ist. Der einzige Preis, den ich so dafür finden konnte, war mit EUR 250 angegeben (vermutlich zuzüglich Märchensteuer und Versand, meine Holländisch-Kenntnisse bewegen sich nur minimal über dem Nullpunkt).
Jörg Wunsch wrote: > meine Holländisch-Kenntnisse bewegen sich nur minimal über dem > Nullpunkt dito, aber die google Übersetzung lässt vermuten dass das Teil genau das macht was man so bräuchte:
1 | Die CFF011, die CompactFlash-Diskette bietet einen Ersatz für alle |
2 | bestehenden 3/5''Floppy-Laufwerke. Das Laufwerk schreibt alle Daten auf |
3 | einer Standard-Compact-Flash. Durch die Erhöhung der Kapazität der |
4 | Compact-Flash-Karte kann mehrere Disketten. Mit Hilfe der Taste drücken |
5 | und das Display in der Front, die verschiedenen "Disketten" gewählt. Mit |
6 | einer LED auf der Vorderseite zeigt an, ob es ein schreiben oder lesen von |
7 | der Compact Flash. Das Laufwerk kann sowohl horizontale als auch vertikale |
8 | Montage. |
Leider ist der Preis doch ganz schön heftig.
Hallo zusammen, ich verfolge Euren Thread jetzt schon seit ein paar Tagen und habe parallel dazu auch im Internet recherchiert. Hintergrund: Eine Bekannte hat ein Stickstudio und benötigt jetzt langsam auch einen Ersatz für die in den Maschinen eingebauten 720 kByte FDDs. Ich bin auf folgende Seite gestossen: http://torlus.com/floppy Es gibt da zwei Geräte (Stand-Alone mit SD-Card und mit USB-Anschluss für einen PC als FDD-Server) incl. Schaltpläne, Sourcen und Hexfiles. Das scheint mir die optimale Lösung des Problems zu sein und kostengünstig (da DIY) ist es ausserdem. Viele Grüsse Werner
@arm-fan welchen denn von den 40 Beiträgen zum 21.06.2007 ?
Wegstaben Verbuchsler wrote: > welchen denn von den 40 Beiträgen zum 21.06.2007 ? Mensch, das war doch die Preisfrage des heutigen Tags! . . . . . . . . . . . Beitrag "Re: Ersatz einer Diskette im Diskettenlaufwerk??"
Jörg Wunsch wrote: >> - Ein SD-Card-Leser/Schreiber (einfacher ala USB-Host), der ein >> Diskettenlaufwerk emuliert. >OK, fein, und was bauen wir dann am Nachmittag? >(Falls du den Spaß nicht verstehen solltest: genau darum geht es >im ganzen Thread, wie man eben dieses Gerät realisiert.) Ja ne, haha, ich dachte mir, bevor ich nur die Hälfte schreibe, schreibe ich auch, worauf sich der Rest beziehen soll. Schließlich dient 60% des in einem Forum Geschriebenen dazu, den Wissensstand verschiedener Poster zu synchronisieren ;-) Das mit dem Nachmittag bleibt ein Problem...
Hab ein's im Büro liegen von den CFF011 ^^ Gebaut werden die nicht in Holland sondern in Salzburg Österreich. Ist nur eine unserer Niederlassungen in Holland. Was es nun wirklich kostet kann ich nicht sagen, die Preise variieren natürlich je nach Abnahmemenge. Bin aber auch kein Verkäufer bei uns.
@Mukuh Dann verteil mal ein paar Geheimnisse aus der Kiste, dann kann man auch sehen, wie man das Teil vielleicht nur durch Änderungen, Optimierungen und / oder dem Einsatz von neuen Chips auf einen neuen Stand bringen kann. Naja, ein Rabatt für alle, die etwas dazu beisteuern wäre auch nicht schlecht :) Aber generell diskutieren wir hier alles noch einmal, dass im HxC Forum schon diskutiert wurde. Dort werden aber auch noch ganz andere Probleme gewälzt, nämlich u.A. auch das Problem, dass gängige kleine Microcontroller eine kleine Ewigkeit brauchen um Daten auf ein entsprechendes Medium zu schreiben. Ein SPI macht am AVR irgendwo 1..2MBit und das bedeutet für ein 1.2MB Floppy Image 20..30s Arbeit. Möchte man das verringern, dann muss man ein richtiges SD-Interface nutzen, das aber braucht einen entsprechen ausgerüsteten Controller und leider auch eine dieser ferflixten SD-Lizenzen. Das gleiche gilt für eine xD Card. lediglich bei CF-Karten kann men ohne Lizenz schneller schreiben, braucht aber einen Controller, der genug I/Os oder einen externen Daten-/Adressbus hat. Und auch ein ATmega128x ist da nicht das gelbe vom Ei, weil man für die Zugriffe jede Menge Ports schubsen muss. Also auf den xmega warten und dann gleich DMA einsetzen. ( Und da gab es auch noch Restriktionen, der DMA kann da auch nicht überall eingesetzt werden) Gruß, Ulrich
>... > Aber generell diskutieren wir hier alles noch einmal, dass im HxC Forum > schon diskutiert wurde. Dort werden aber auch noch ganz andere Probleme > gewälzt, nämlich u.A. auch das Problem, dass gängige kleine > Microcontroller eine kleine Ewigkeit brauchen um Daten auf ein > entsprechendes Medium zu schreiben. Ein SPI macht am AVR irgendwo > 1..2MBit und das bedeutet für ein 1.2MB Floppy Image 20..30s Arbeit. Gar so schlimm ist es nicht. Kommt aber auch sehr auf die Karte an. Benchmark vom Guru: http://elm-chan.org/fsw/ff/img/rwtest.png Etwas älter und noch nicht mal mit maximal möglichem SPI-Takt für AVR. Wenn richtig erinnert, gibt Holger Klabunde auch ein paar Messergebnisse auf seinen Seiten. Ausser AVR gibt es ja noch anders. AT91SAM7 z.B. schiebt über SPI mehr als 1MByte/sec auf eine ExtreMemory 2GB "Performance" SD-Karte. Sehr beeindruckende neue Benchmarks von Chan für LPC2k mit MCI: http://elm-chan.org/fsw/ff/img/rwtest2.png Alles auch keine großen Controller und auch nicht wirklich schwer zu beschaffen (Reichelt, Conrad...). Aber o.k. reiner "DIP-only" Lochrasterverhau als Testaufbau ist mit AT91SAM7/SPI oder LPC23xx/24xx/MCI nicht möglich (mit ATmega128 oder Xmega aber ebenso wenig). > Möchte man das verringern, dann muss man ein richtiges SD-Interface > nutzen, das aber braucht einen entsprechen ausgerüsteten Controller und > leider auch eine dieser ferflixten SD-Lizenzen. Das gleiche gilt für > eine xD Card. Betr. Übertragungsraten: s.o. Betr. "ferflixten SD-Lizenzen": wo steht das? Habe vor einiger Zeit heftig gegoogelt aber nichts eindeutiges zur "4-bit-Bus"-Lizenz gefunden (viele "may"s). Ehedem war die Mitgliedschaft in der SD-Association wohl erforderlich, um die technische Beschreibung einzusehen (für die vollständige wohl immer noch so) aber auch der 4-bit Bus ist inzwischen in frei zugänglichen Texten dokumentiert und es gibt auch Code (nicht nur in/für Linux). So ich das richtig verstanden habe, will man sich hier für ein nicht-kommerzielles Projekt zusammentun, ob das bei der SD Association jemanden interessiert? > lediglich bei CF-Karten kann men ohne Lizenz schneller schreiben, > braucht aber einen Controller, der genug I/Os oder einen externen > Daten-/Adressbus hat. Und auch ein ATmega128x ist da nicht das gelbe vom > Ei, weil man für die Zugriffe jede Menge Ports schubsen muss. Also auf > den xmega warten und dann gleich DMA einsetzen. ( Und da gab es auch > noch Restriktionen, der DMA kann da auch nicht überall eingesetzt > werden) Mangels Floppy know-how kann ich zwar nichts zu dem Projekt beitragen aber CF-Karte erscheint mir angesichts überschaubaren Datenmengen für Floppy-Images und verfügbaren schnelleren Controllern und Karten zu viel Aufwand. Breite parallele Busse sterben aus. PATA und IEEE1284 Geräte sind nur noch "legacy". Selbst kleine Display-Module kommen inzwischen oft zumindest mit optionalem SPI-Interface und offensichtlich sind SD/SDHC-Karten inzwischen auf für höherpreisige Digitalkameras Mittel der Wahl statt CF.
Martin Thomas wrote: > ... aber auch der 4-bit Bus ist inzwischen > in frei zugänglichen Texten dokumentiert und es gibt auch Code (nicht > nur in/für Linux). Hast du auf Anhieb einen Pointer dafür? (Also nicht erst gugeln, das kann ich auch selbst.) Mich interessiert insbesondere die controller- basierte Variante.
Hi! Ich bin mir da noch nicht so ganz sicher, dass das SD Interface wirklich frei ist. Ich kann mich gut erinnern, dass es hier im Forum einige Diskussionen bzgl. der Lizenzen und Patente rund um eine SD-Card gegeben hat. Ich habe ein paar davon verfolgt, die aber nie zu einer endgültigen Aussage gekommen sind. Eine Anfrage bei Elektor ergab dazu, dass man aufgrund dieser Unsicherheit auf einen Einsatz des 4-Bit Interfaces verzichtet. Aber, wie Du schon sagst, auch das 1-Bit Interface ist, bei Einsatz eines passenden Prozessors, performant genug. Es ist halt eine gewisse Ladezeit einzukalkulieren, wenn man die Karte einsteckt und das Image erst ins xRAM transferiert werden muss. Gruß, Ulrich
Ulrich P. wrote: > Aber, > wie Du schon sagst, auch das 1-Bit Interface ist, bei Einsatz eines > passenden Prozessors, performant genug. Selbst beim AVR kein zu großes Problem. Haukes Ansatz arbeitet mit 15 MHz CPU-Takt, d. h. man kann mit 7,5 MHz SPI-Takt fahren. Da wir von Floppy-Datenströmen mit maximal 500 kbps sprechen, die noch einen Sektorierungs-Overhead aufweisen, liegt die benötigte Datenrate eher bei 400 kbps, d. h. mehr als eine Größenordnung unter der rohen SPI-Rate. > Es ist halt eine gewisse > Ladezeit einzukalkulieren, wenn man die Karte einsteckt und das Image > erst ins xRAM transferiert werden muss. Davor kann der Emulator einfach noch behaupten, noch keine Floppy zu haben. Eine mechanische Floppy musste ja auch nicht immer im Schacht stecken. Den 4-bit-Mode würde ich aber trotzdem nicht ganz aus den Augen verlieren wollen.
Das CFF is brandneu und auf dem aktuellsten Stand. Da wird nichts gändert. Ist als ersatz für Floppys in Industriesteuerungen gedacht!
/* Haukes Ansatz arbeitet mit 15 MHz CPU-Takt */ Wo steht mehr zu Haukes Ansatz?
Ach so - dachte schon, dass ich etwas überlesen habe.
Jörg Wunsch wrote: > Martin Thomas wrote: > >> ... aber auch der 4-bit Bus ist inzwischen >> in frei zugänglichen Texten dokumentiert und es gibt auch Code (nicht >> nur in/für Linux). > > Hast du auf Anhieb einen Pointer dafür? (Also nicht erst gugeln, das > kann ich auch selbst.) Mich interessiert insbesondere die controller- > basierte Variante. Ich habe mich bis dato nur mit dem LPC23xx/24xx MCI beschäftigt, dies bietet "4-bit"-Modus. Dieses MCI basiert auf der ARM Primecell PL180. Die IDs und das/die API sind identisch. Dokumention zur Primecell findet sich bei arm.com, ist allerdings ziemlich knapp bringt kaum zusätzliche Information zum NXP manual. Code dafür findet sich im "sample bundle" für LPC23xx/24xx von standardics.nxp.com, von keil.com in einem Beispiel (ziemlich ähnlich NXP, scheinbar gleicher Ursprung) und ganz neu und wie immer bis zum Anschlag optimiert von Chan (Link zu Chan's Seite s.o.). Zusammen mit dem Sandisk Product-Manual Version 2.?, den freien Dokumenaten von sdcard.org, dem LPC23xx-Manual und der PL180-Dokumention konnte ich den Beispielcodes ganz gut folgen. Gebe aber zu, nicht alles bis ins Detail verstanden zu haben, da der Philips - äh - NXP MCI-Code mir ausgereicht hat. Habe den eigentlich mehr oder weniger nur an GNU-Tools angepasst und Chans Fat-Library drüber gestülpt. Jetzt wo Chan auch den LPC/MCI low-level-Code bereitstellt, werde ich wohl beim nächsten LPC23xx/SD-Card-Projekt diesen ausprobieren. LPC23xx "muss" auch nicht auf 4-bit umgestellt werden. Man kann auch bei 1-bit-Bus bleiben In Linux ist der PL180-Treiber in linux/drivers/mmc/host/mmci.h/.c aber darüber weiss ich nicht viel. Für diverse Controller gibt es noch eigene Treiber (z.B. AT91SAM9, Samsung ARM). In LPC24xx-BSPs für uCLinux sind ebenfalls Treiber, aber nicht genau angeschaut. Weiterhin gibt es noch in den Software-Packages von Atmel für die "größeren" ARM-Controller MCI-Treiber, dies aber auch nur oberflächlich angeschaut. Sieht sehr ähnlich aus sie bei LPC/MCI mglw. identische Primecell oder eine ähnliche von ARM drin. Weiterhin sind, wen recht erinnert, auch in den AVR32-software-packages MCI-Treiber (4-bit). Treiber für "exotische" Hardware findet man auch in libfat aus DevkitPro (sf.net) aber das ist schon recht speziell, zumindest konnte ich nicht viel daraus lernen. Sind auch nur einige "4-bit". Die "Homebrew"-Interfaces (die meisten sind wohl nur dazu gedacht Spielmodule zu kopieren und nicht wirklich dokumentiert) bieten wohl stellenweise eine Art BIOS, das viel vorkaut. Der Fat-"Überbau" in libfat ist allerdings schick inkl. Caching und LFN (aber bei LFN gibt es dann noch eine weitere Lizenz-Grauzone).
Martin Thomas wrote: > bis ins Detail verstanden zu haben, da der Philips - äh - NXP MCI-Code > mir ausgereicht hat. Habe den eigentlich mehr oder weniger nur an NXP == Not eXactly Philips ;) Insider-Gag, aber ich find ihn gut :)
"Herr Profi, wann hast du das letzte Mal mit Floppies dein Geld
verdient? (Was anderes heißt "Profi" ja nicht.)"
Lieber Herr Jörg Wunsch,
das ist wahrlich schon ziemlich lange her, so ca. 1980-85. Ich habe
tatächlich noch einige 8"-Laufwerke mit 50-pol-Shugart-Bus zuhause.
"Ich glaube das einzige "Warte ein wenig" Signal welches es bei der
Floppy gibt, ist "Diskette nicht eingelegt" Signal."
Ich hatte die Bezeichnung des Signals nicht mehr parat, aber mit der
Beschreibung "head loaded" (nicht "head load") hättest Du draufkommen
können, dass ich das Signal "ready" (Pin 34) meine.
"> Normalerweise immer Sektorweise (daher kommen auch die klassischen
512
> Byte / Sektor).
Was die nun damit zu tun haben, das musst du uns noch erklären."
Ich habe mich unglücklich ausgedrückt: ich meinte:
Zwischen FDC und Controller werden die Daten sektor- oder trackweise
ausgetauscht, nicht bitweise. Du kannst also nicht befehlen:
überschreibe das Bit 12345 mit 0 (oder 1).
Mit den 128- 4096 Bytes/Sektor hast Du Recht.
noch zur Info: der WD2797 ist praktisch ein WD1797 mit eingebautem
PLL-Datenseparator.
Im Anhang findet Ihr nebeneinander die Pinbelgung von
- Shugart26
- Shugart34
- IBM-PC34
- FTAPE37
- Shugart50
(mein Beitrag in de.wikipedia.org/wiki/Shugart-Bus)
Hallo, sucht Ihr sowas hier ^--. Ich habe davon zwei, die nie richtig funktioniert haben. Also habe ich mal eines geöffnet. weiter Bilder, wenn Interesse.
Nein, FlashPath funktioniert AFAIK nur mit spezieller Software und ist kein Ersatz für eine Diskette. Gesucht wird vielmehr etwas, was an das 34polige Kabel des Diskettenlaufwerkscontrollers angeschlossen werden kann und sich elektrisch genauso verhält, wie ein Diskettenlaufwerk mit einer eingelegten Diskette.
@eProfi Es ist leider Fakt das sehr viele Firmen etwas an den ursprünglichen Shugard drangestrickt haben. Da wir wenigstens die üblichen Floppy Formate unterstützen wollen (3,5"+5,25";SD+DD+HD;SS+DS), müssen wir mit den zu Verfügbaren Signalen auskommen. Und bei diesen ist leider kein Signal dabei welches dem Controller sagt: "mach mal langsam ich kommen nicht hinterher". Floppylaufwerke sind objektiv betrachtet unglaublich dumm. Weiterhin muss ich noch anfügen, das ihr bezüglich der Sektorengröße alle ein klein weinig falsch liegt. Er ist nicht 512Byte (bzw. 128,256...4096byte) gross. Er enthält halt nur 512byte (o.a.) an Nutzdaten. Der Sektor selber besteht zusätzlich noch aus Headern, CRCsummen, Pausen, Syncpausen usw. Daher ist es höchst unüblich das ein Sektor eine Größe von 2^n Byte hat. Deshalb ist es quasi unmöglich die Daten Sektorweise in ein Flash zu schreiben. Das geht höchstens Zylinderweise. Der Controller schreibt auch nicht unbedingt immer ganze Sektoren um. Es ist genauso üblich nur der Sektorheader geändert wird. cu bis dann Hauke P.S. Jörg und ich sind zur Zeit dabei, eine Entwicklerplatine zu machen. Wir bleiben also am Ball
Was ist denn mit den Produkten, die schon genannt wurden? Taugen die nix, oder ist das akademische Interesse am Problem so gross, dass es nochmal geloest werden soll?
Peter Stegemann wrote: > Was ist denn mit den Produkten, die schon genannt wurden? Taugen die > nix, oder ist das akademische Interesse am Problem so gross, dass es > nochmal geloest werden soll? Alles, was wirklich der Aufgabenstellung entspricht, ist preislich so hoch angesiedelt (ich habe EUR 300 in Erinnerung, möglicherweise noch zuzüglich Märchensteuer), dass es schon lohnt, mal über ein "open hardware / open software"-Projekt nachzudenken. Da Hauke den Code für den Codec schon einigermaßen in der Tüte hat, wollte ich ihm mindestens so weit assistieren, dass man den mal real testen kann. Danach kann man dann immer noch überlegen, ob man's bei dem Prototypen belässt und unter ,,Erfahrung gewonnen'' verbucht, oder ob es die Sache Wert ist, ein komplettes Projekt daraus zu machen.
Es ist ein bisschen was von allem. Viele der "fertigen" Lösungen schießen halt am eigendlichen Problem vorbei. (z.B. eine USB Floppy nehmen) Manche funtionieren nicht. (Flashkarten-Floppy-Combo) Manche brauchen spezielle Software oder sind selber Software. Das einzige was die eigendliche Aufgabenstellung trifft ist das CFF011 von muhkuh. Bei liegen die Spezifikationen jedoch ziemlich im dunkeln. Sprich wir wissen nicht was das Ding kann. Andererseit bezweiflich ich, dass die Firma sich von ein paar Hobbyisten in die Karten schauen lässt. Und als letztes ist da noch der sportliche Ehrgeiz. Mich beschäftigt diese Sache schon seit mehr als sechs Jahren. cu bis dann Hauke
>Alles, was wirklich der Aufgabenstellung entspricht, ist preislich >so hoch angesiedelt (ich habe EUR 300 in Erinnerung Warum ist das zu teuer ? Wenn dadurch die Neuanschaffung eines Messgerätes > 10000Euro vermieden werden kann, sind 300 Euro ein Witz ! Oder liege ich da falsch ? Gruß, Martin
Martin wrote:
> Warum ist das zu teuer ?
Weil's hier um Leute geht, die sich mit diesen Messgeräten nicht
ihre Brötchen verdienen, sondern die sie rein für ihr Hobby
benutzen.
Jörg Wunsch wrote: > Martin wrote: > >> Warum ist das zu teuer ? > > Weil's hier um Leute geht, die sich mit diesen Messgeräten nicht > ihre Brötchen verdienen, sondern die sie rein für ihr Hobby > benutzen. Schön für die, die sich für ihr Hobby Messgeräte > EUR 10000 leisten können. Dann hätte ich auch keine EUR 300 mehr übrig. Ja, ich weiss, manchmal bekommt man solche ehemals teuren, jetzt ausgemusterten Geräte sehr billig oder gar geschenkt, und dann sieht es anders aus. Und vor allem geht es doch um die Herausforderung, so etwas hinzukriegen.
Severino R. wrote: > Schön für die, die sich für ihr Hobby Messgeräte > EUR 10000 leisten > können. Huh? Wer hat das denn erzählt. Bitte geh 5 Beiträge zurück, und lies dir das alles nochmal langsam und in Ruhe durch. Es geht hier (zumindest in meinem Fall) um ein Messgerät, das mich EUR 80 (glaub ich) gekostet hat. Nein, es wäre für mich auch absolut kein Thema, dieses Gerät vielleicht nur wegen eines kaputten Floppylaufwerks oder fehlender Medien zu verschrotten und mir statt dessen eins für EUR 10000 zu kaufen. Das Geld habe ich nicht, und ich würde es auch nicht dafür ausgeben. Das bislang teuerste Messgerät war ein Oszi für EUR 800, aber der hat bei mir keine Floppy. Selbst da würde ich mir aber eine zusätzliche Investition von weiteren EUR 300 für einen Floppyersatz doch zweimal überlegen, da es im Vergleich zum Gesamtwert des Geräts einen recht erheblichen Preis darstellt. Wer das irgendwie in einer Produktionsumgebung machen will, keine Frage, für den ist es ganz sicher einfacher, das Teil für EUR 300 morgen und ohne weiteren Arbeitsaufwand in der Hand zu halten, statt darauf zu warten, ob's ein paar Hobbyisten in einigen Monaten vielleicht auch für EUR 100 auf die Reihe gebracht haben werden, wobei er es sich dann trotzdem noch selbst löten muss.
Jörg Wunsch wrote: > Severino R. wrote: > >> Schön für die, die sich für ihr Hobby Messgeräte > EUR 10000 leisten >> können. > > Huh? Wer hat das denn erzählt. Bitte geh 5 Beiträge zurück, und > lies dir das alles nochmal langsam und in Ruhe durch. > Martin hat angenommen, dass durch EUR 300 die Neuanschaffung von Messgeräten > EUR 10000 vermieden werden kann. Und ich wollte anmerken, dass es ja vielleicht auch um Hobbyisten geht, habe es aber leider unterlassen, den Ironie-Tag einzuschalten: <Ironie> ... </Ironie>. Im ganzen Thread geht es jedoch nicht eindeutig nur um Hobby-Anwendungen (der Thread ist ja auch von früher wieder aufgenommen worden). Ich verfolge die Sache ein wenig, weil ich einmal die geprüft hatten, ein 8"-Laufwerk durch etwas Moderneres abzulösen. Ist dann aber mangels konkretem Interesse nichts geworden.
Severino R. wrote: > Und ich wollte anmerken, dass es ja vielleicht auch um Hobbyisten geht, > habe es aber leider unterlassen, den Ironie-Tag einzuschalten: Mist, da muss ich meinen Ironiedetektor schon wieder in die Reparatur schaffen! :-)
@ : Severino R: 8"-Laufwerk durch 5 1/4" habe ich vor Jaaahren mal ersetzt. Es war nur ein zusätzlicher Adapter im Kabel nötig, da einige Drähte anders belegt waren (und der Stromstecker). Haken an der Sache ist jedoch, daß das historische Betriebssystem die "moderneren" Laufwerke noch erkennen muß. Das dürfte bei einigen alten Meßgeräten der Pferdefuß sein.
Hallo, bin auch ein "Bastler" mit TDS3032 Scope was nur über 3.5" Diskette kommuniziert. Das Handling mit Setups und Printouts über Diskette ist schon sehr umständlich und manchmal zeitraubend (wenn die Diskette nicht mehr will). Für eine bezahlbare Lösung würde ich mich auch interressieren. Gruß Norbert
OK, der Status ist, dass ein initiales Platinenlayout so weit fertig ist. Ich habe mich nach Diskussion mit Hauke dann doch für die etwas teureren 62LV1600 als SRAM entschieden, von denen man nur zwei Stück braucht statt der 8 x 512 KiB. Platinenlayouts hatte ich für beide routen lassen, aber die mit den 8 SRAMs ist dann fast 50 % größer, das geht dann auch nochmal ins Geld. Wenn die RAMs bei mir sind, möchte ich nochmal verifizieren, dass sie auch mit dem Layout zusammen passen :), danach kann ich die Platinen in Auftrag geben. Wenn alles gut geht, sollten dann noch rechtzeitig vor den Weihnachtsfeiertagen die ersten beiden Prototypen da sein, damit Hauke und ich etwas zum Testen haben. Das erste Ziel ist es, erst einmal nur die Kopplung des RAMs mit dem Codec zu implementieren und auf diese Weise eine Diskettennachbildung zu haben, die zwar noch nichts auf ein externes Medium schreibt, die ein FDC aber zumindest formatieren kann, um dann was aufzuzeichnen. Wenn das funktioniert, wäre der nächste Schritt, die Floppy-Rohdaten (also den reinen Bitstrom) auf einer SD-Karte abzulegen, damit sie sich die Informationen auch übers Ausschalten hinweg merkt. Danach wäre der Punkt, an dem man, basierend auf den bis dahin gewonnenen Erkenntnissen, andere Mitstreiter mit ins Boot nehmen kann. Die Floppy-Rohdaten müssten in irgendeiner Form dekodiert werden (erstmal als MFM, weitere Formate bei Bedarf später), entweder im AVR selbst (offline, also nicht live während der Codec arbeitet), oder vielleicht initial auf einem Hostcomputer (also Rohdaten auf der SD-Karte, und dann ein Programm, was daraus ein Floppy-Image erzeugt -- auf einem Hostcomputer lässt es sich leichter debuggen). Danach könnte man sich um Feinheiten wie mögliche Bedienelemente (Status- anzeigen auf LCD oder 7-Segment-Anzeige, rotary encoder oder Tipptasten zur Auswahl eines möglichen Floppy-Images etc.) Gedanken machen. Schließlich und endlich würde ich wohl das Platinenlayout nochmal überarbeiten (bspw. um die Bedienelemente mit einzubeziehen) und dann als Gerber-Dateien der Allgemeinheit bereit zu stellen. Nein, kein Eagle -- ich benutze BAE, und das brauche ich auch dafür: der Autorouter hat an den Prototypen teilweise einige Stunden gerechnet (vor allem natürlich an dem mit den 8 SRAMs), nein, das mache ich nicht freiwillig mit der Hand. Der Steuer-AVR ist jetzt erst mal ein 100pinniger (ATmega1280), damit man genügend freie Ports für die Peripherie hat. Das Auffächern der 100 Pins im 0,5-mm-Raster ist nicht ganz trivial und braucht einiges an Kupferfläche und Vias. Ein ATmega1281 könnte in der endgültigen Version gerade so hinkommen, aber es wird dann ziemlich knapp mit den Pins für die Peripherie, da der Controller ja auch den Shugart-Bus bedienen muss.
Ich bin heute zufällig über diesen Floppy-Emulator für 180 Euro gestolpert, der sich sogar parallel zum ursprünglichen Diskettenlaufwerk verwenden lassen soll: http://home.arcor.de/hdm-world/more_hdm-flash_de.htm Leider enthält die Beschreibung wenig bis keine technischen Details.
Ich denke, wir sollten nochmal den Einsatz eine FDCs überlegen. WD2797 oder der mit dem eingebauten Shugart-Bustreiber Sektor-Interleave beachten, evtl. automatisch so wählen, dass Files am Stück gelesen werden können. Das mit dem Ready ist meines Erachtens kein Problem, da der FDC retries macht, so lange er nichts lesen kann. Erst nach etlichen Versuchen gibt er auf. Das HDM-uniflash scheint ja das zu sein, was wir brauchen. Hersteller ist 2AVCom in der Ukraine. Vorgängerversionen waren HDM1 und HDM2 flash. http://88.198.8.78/UBB/showflat.php?Cat=0&Number=96236&page=0&fpart=2&vc=1 2004 hat das Teil 150 Euro gekostet, jetzt 180 Euro. ein Max hat es auch schon für 300 zu verkaufen versucht. Hier ein Foto, auf dem man ein wenig erkennen kann (das 2. Foto zeigt 6 ICs und einen Quarz): http://home.arcor.de/hdm-world/more_hdm-flash_de.htm Hier noch bessere Infos und gute Fotos direkt vom Hersteller: http://www.2av.com.ua/harde.htm Das Foto ist sogar verkleinert dargestellt, hier in Orignalgröße sind die Bezeichnungen von 4 ICs lesbar, leider nicht vom 4*13=72poligen Prozessor: http://www.2av.com.ua/uni2%202.jpg 74HC245, 74HC374, 74HC05, OKI M514256B-70J, ein 10 MHz Quarz Beteiligte Personen sind http://home.arcor.de/hdm-world/news%20von%20hdm_de.htm News HDM-World Firma 2AVCom wurde 1991 mit Hauptsitz in der Stadt Vinnitsa, Ukraine gegründet und hat heute neben einem gut ausgabauten internationalen Distributionsnetz in Rostock, Germany und Entwicklungszentren in der Ukraine, Russia, Deutschland und seit 1997 im Welt mit ingesamt über 20 Mitarbeitern. Seit 1999 bietet 2AVCom hochwertige Produkte unter dem Namen HDM-Flash, Mraer, MidiCom an, die sich besonders mit den Keyboards spielen können. 2AVCom bietet heute ein unfassandes Lieferprogramm in den Bereichen Midi, Audio und Digital-Audio Technologie. Unser Ziel ist es, Ihnen immer wieder die passenden Kreativ-Werkzeuge an die Hand zu geben - tools for you talents... Geschäftsführer 2AVCom Valeriy Schuryshyn Ansprechpartner in Deutschland: Sergiy Gulshani, Rostock Fon: +49 0 381 6374239 Mobil: +49 0 160 7842755 Habe mit ihm telefoniert, er sagt, es geht auch für CNC-Maschinen. Ab Lager lieferbar. Wenns was bringt, bestelle ich einfach so ein Teil, um zu sehen, was drauf ist. Scheinbar ist auch eine PC-Software dabei, mit der man Files auf die virtuellen Floppies auf der CF-Karte schreiben kann.
Hallo, wenn ich das richtig versteht wird ja eigentlich nur ein Diskettenlaufwerk gebraucht das nicht auf Diskette speichert, sondern z.B. auf einen USB-Stick, oder? Warum tauschst Du dann das Diskettenlaufwerk nicht einfach gegen den USB Disketten Emulator von ipcas? Hier der Link: http://www.ipcas.de/produkte/usb-floppy-laufwerk-usb-disketten-emulator-fdd-zu-udd.html Das Gerät hat einen ganz normalen Disketten-Laufwerks-Anschluss und kann bis zu 100 Disketten auf einem USB-Stick speichern. Treiber werden nicht benötigt. Einfach altes Diskettenlaufwerk ausbauen und das ipcas Diskettenlaufwerk einbauen. Fertig! Weil die Daten auf einem USB-Stick liegen, braucht man auch im PC kein Diskettenlaufwerk mehr. Gruß Daniel
Sehr schöne Ansätze hier. besitze einen Funktionsgenerator mit Floppy-Laufwerk, das würde ich auch gerne ersetzen, vorzugsweise durch USB-Stick. Bei meinem Gerät würde nur leider dieser ipacs nicht passen, es ist nämlich ein Notebook-FDD verbaut.
Erik D. wrote: > Bei meinem Gerät würde nur leider dieser ipacs nicht passen, es ist > nämlich ein Notebook-FDD verbaut. Vielleicht entwickelt ipcas auf diese Anregung hin ein solches Gerät. Der Spielraum zur Verkleinerung ist bestimmt gegeben.
... und z.B. schon ein Adapterkabel f. Notebook-FDD gesucht ?
Hallo, @ Thomas B: Ich werde die Anregung gerne weiter geben. @ oszi40: Einen Adapter von Slim Floppy auf 34pin habe ich hier gefunden: https://webshop.schneider-consulting.it/Slim-Floppy-Adapter-auf-34pin-Adapter-Slim-Floppy Gruß Daniel
Hallo! Gibt es schon was neues zu diesem Projekt? Ich bin auch auf der Suche nach einer Hardwarelösug in Form von USB-Sticks als Ersatz von alten 2.5" Floppy Drives. Die Lösung von Ipcas ist schon recht gut, allerdings ist die Bauform (3.5") für meine Anwendung zu groß. Der Preis von 500 EUR von Ipcas ist zwar hoch, aber für meinen Fall wäre das in Ordnung. Gibt es noch Alternativen dazu als 2.5" Bauhöhe? Max
2.5"-Diskettenlaufwerke? Die meinst Du ganz sicher nicht. Du meinst Slimline-3.5"-Laufwerke, die 0.5" hoch sind (wie sie z.B. in Notebooks zu finden sind). Ob jemand so etwas wie das Ersatzlaufwerk in der geringeren Bauhöhe baut, wage ich zu bezweifeln; schließlich ist das 'ne obskure Zwölfteldutzendanwendung.
Das hier könnte evtl. interessant sein: http://www.torlus.com/floppy/ (Die blauen, weißen und schwarzen stammen übrigens von mir ;-) Die USB Variante kann allerdings nur lesen! Die SD Card Version befindet sich noch in der Entwicklung!! (Ich bin nicht der Entwickler! Habe nur die USB Version gebaut) Peter
Ja, ich meinte Slimline Laufwerke. @Peter Sieg Gibt es Bezugsquellen und eine ausfürhliche Beschreibung dieser Platinen? Nur lesen von USB wäre für unsere Anwendung ok. In welcher Preisgegend liegen die Emulatoren ca.? Danke, Max
@Max: Ist alles Open Source/Hardware. Firmware der CPLD's (EPM7128) als auch Platinenlayouts sind verfügbar (auf der französchischen Seite des Entwicklers). Im Forum bekommt man auch schnell eine Antwort.. der Aufbau ist relativ einfach.. nur beim FT245RL muß man aufpassen ;-) Leider ist der CPLD 'relativ' teuer.. Ca. 20€ (Segor). Ich hatte Platinen+CPLD (programmiert) um die 30-35€ und einige, wenige Fertigplatinen für 80€.. aber inzwischen sind alle weg. Platinen hatte ich über pcbcart bestellt.. das lohnt aber erst ab mind. 10 Stück.. für 1-2 Platinen sind sicher lokalere Hersteller günstiger.. Peter
Hallo zusammen, ich habe das CFF011 gegoogelt und beim Hersteller sogar die technische Dokumentation gefunden. http://www.sigmatek-automation.com/produkte-quicksearch.html und damm im suchfeld "cff" eingeben und man bekommt alle infos die man als "normaler" user so braucht! gruß Eduard
gibt es für den professionellen Einsatz auch zu kaufen: Bis zu 100 Disketten über USB-Stick als 3,5"Floppy http://www.ipcas.de/produkte/usb-floppy-laufwerk-usb-disketten-emulator-fdd-zu-udd.html
Oder hier vier Stück "zum Preis von einem" (Gerät ca. 41 EUR, Versand ca. 11 EUR, EuSt. ca. 10 EUR, kein Zoll): http://shop.ebay.de/?_from=R40&_trksid=p3907.m38.l1313&_nkw=floppy+emulator&_sacat=See-All-Categories Falls der Links nicht geht: ebay-Suche nach "Floppy Emulator" (Anbieter: "i889900" im "TRY2B BEST"-Shop). Ein USB-Stick wird auch noch mitgeliefert. Ich habe davon bisher sieben Stück in Messgeräten von HP/Agilent, Tek und LeCroy sowie eines im PC verbaut. Probleme sind bisher niemals aufgetaucht. Bei der "100"-Disk/Partions-Version den Händler gleich bitten, die Partitionierungs-Software zu schicken, hatte er bei mir beim ersten "100er"-LW vergessen, war aber auf Nachfrege nach wenigen Stunen per Email da. Ich habe vom gleichen Händler auch einfachere Geräte, die nur eine Partition bzw. Diskette pro Stick unterstützen, ohne Ziffernanzeige und Taster - diese LWs kosteten ca. 20 Euro, sind bis auf eine kleine Zusatzplatine baugleich, und funktionieren ebenso problemlos. Ach ja: Bei mir dauerte der Versand (drei Bestellungen) immer ca. 2 bis knapp drei Wochen. MFG
@ Besucher http://shop.ebay.de/?_from=R40&_trksid=p3907.m38.l... das Teil aus Polen kostet aber 60 Euro ? auf allen Bilden ist ein USB-Kabel und kein USB-Stick angeschlossen, wie auch der Emulator hat auch eine USB-Geräte-Buchse und da passt doch kein Stick rein ?!
Der vom "Besucher" vorgestellte eBay-Link lässt einen bei einer Versteigerung eines "Lotharek" landen. "HxC Floppy emulator for Amiga/Atari ST/ ZX+3/CPC/PC" Dessen Emulator funktioniert nur, wenn ein PC an das Gerät angeschlossen ist und die Daten per USB zur Verfügung stellt, d.h., wenn eine zugehörige Software auf dem PC läuft. Deswegen hat das Ding ja auch eine USB-Device-Buchse. Internen Speicher, um Diskettenimages darauf abzulegen, hat das Ding nicht.
Ja, der 100er war wohl dieses Teil aus Fernost: http://cgi.ebay.de/3-5-1-44MB-USB-SSD-FLOPPY-DRIVE-EMULATOR-E100-Version_W0QQitemZ290394408261QQcmdZViewItemQQptZUK_Computing_FloppyDiskDrives_SM?hash=item439cdb0545
sowas vielleicht, weiß nicht ob die für alles funktionieren? http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=140385336301
Da hat man aber immer noch das Problem, dass ein Diskettenlaufwerk (welche vom aussterben bedroht sind) hat. Und diese sind wegen der Mechanik Verschleissteile. Ich würde auch eher nach einer Lösung suchen, welche vollelektronisch (ohne mechanische Komponenten) ist und damit das gesamte Floppy-Laufwerk austauschen.
Vorbeigeschaut schrieb: > sowas vielleicht, weiß nicht ob die für alles funktionieren? > > http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&item=140385336301 Nein, so etwas funktioniert NICHT. So ein Ding ist dafür da, um mit spezieller Software, die den Floppycontroller umprogrammiert, auf Memorysticks zugreifen zu können, aber eben NICHT, um Disketten zu ersetzen.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.