Hallo. Ich möchte gerne ein Diskettenlaufwerk mit einen avr Controller ansteuern. Wer kann mir helfen und einen C-Code zeigen. Ich habe schon einige Internetseiten angesehen, aber keinen Code gefunden.
Josef P. schrieb: > Hallo. Ich möchte gerne ein Diskettenlaufwerk mit einen avr > Controller > ansteuern. Wer kann mir helfen und einen C-Code zeigen. > Ich habe schon einige Internetseiten angesehen, aber keinen Code > gefunden. Siehe: https://dse-faq.elektronik-kompendium.de/dse-faq.htm#F.7.6
MaWin schrieb: > Siehe: https://dse-faq.elektronik-kompendium.de/dse-faq.htm#F.7.6 Ist bei genauerer Betrachtung doch ein wenig veraltet. Mit neueren AVR8 rückt ein Floppycontroller selbst für HD und schreibend in den Bereich des Möglichen (vor allem dank CCL). Für DD und rein lesend war es schon vor 20 Jahren möglich. Aber OK: wer sich für das Ansprechen von Floppylaufwerken tatsächlich interessiert, muss wohl allein herausbekommen, wie's geht. Schlicht deshalb, weil sich außer ihm aus guten Gründen praktisch kein Schwein mehr dafür interessiert.
Es gibt auch Diskettenlaufwerke mit USB-Anschluss. Ist vielleicht einfacher, als diese 34 polige Buchse zu bedienen.
PittyJ schrieb: > Es gibt auch Diskettenlaufwerke mit USB-Anschluss. > Ist vielleicht einfacher, als diese 34 polige Buchse zu bedienen. Nein, nicht für einen AVR8. USB-Host mit Fullspeed liegt jenseits seiner Möglichkeiten.
Josef P. schrieb: > Hallo. Ich möchte gerne ein Diskettenlaufwerk mit einen avr Controller > ansteuern. Bei einer Standardfloppy eigentlich ganz einfach: 8" Scheibendurchmesser mit 77 Spuren und ein- oder zwei Seiten. Achtung der Antriebsmotor braucht normalerweise AC, also 230 V oder 110 V. Die Elektronik +/-5 V und 24V für den Schrittmotor. Softsektoriert oder hardsektoriert? Signale zum / vom Laufwerk: Step, Direction, TG43, Read, Write, Side, Track 0, Write Gate, Drive select, ggf.Index. Alles überschaubar und bis auf Read / Write zeitunkritisch. Welches Datenformat soll's denn werden, single density FM oder MFM, M²M, GCR? https://www.retrotechnology.com/herbs_stuff/m2fm.html https://en.wikipedia.org/wiki/List_of_floppy_disk_formats Nur Sektoren lesen/schreiben oder wird ein Filesystem benötigt? z.B. https://stardot.org.uk/forums/viewtopic.php?t=9114 Butzo*aussen
Klaus B. schrieb: > Bei einer Standardfloppy eigentlich ganz einfach: > > 8" Scheibendurchmesser mit 77 Spuren und ein- oder zwei Seiten. Achtung > der Antriebsmotor braucht normalerweise AC, also 230 V oder 110 V. Die > Elektronik +/-5 V und 24V für den Schrittmotor. > ... > > Butzo*aussen Dazu noch einen Intel 8272 und fertig ist die Laube. Pech, wenn man keinen hat.
c-hater schrieb: > PittyJ schrieb: >> Es gibt auch Diskettenlaufwerke mit USB-Anschluss. >> Ist vielleicht einfacher, als diese 34 polige Buchse zu bedienen. > > Nein, nicht für einen AVR8. USB-Host mit Fullspeed liegt jenseits seiner > Möglichkeiten. Es war nicht die Rede von einem AVR8. Es ging allgemein um einen nicht näher spezifizierten "avr Controller". Und bei avr findet man dann das: https://ww1.microchip.com/downloads/en/DeviceDoc/doc8486.pdf
PICklig schrieb: > Dazu noch einen Intel 8272 und fertig ist die Laube. > Pech, wenn man keinen hat. Pah! Ein Steve Wozniak hat nur ein PROM und einen Zähler gebraucht :-) https://de.wikipedia.org/wiki/Integrated_Woz_Machine Würde persönlich erstmal die Baugröße 8", 5", 3.5", 3" auswählen und mit dem Lesen der uPD765 und WD1793 Doku anfangen. Butzo*aussen
PICklig schrieb: > Dazu noch einen Intel 8272 und fertig ist die Laube. > Pech, wenn man keinen hat. Digikey ersäuft dermassen in verschiedenen Floppy-Disk Controllern und den teils erforderlichen Datenseparatoren, dass sie welche verkaufen müssen.
:
Bearbeitet durch User
PittyJ schrieb: > Es gibt auch Diskettenlaufwerke mit USB-Anschluss. > Ist vielleicht einfacher, als diese 34 polige Buchse zu bedienen. Ich suche am AVR immer noch den USB-Stöpsel.
Thomas R. schrieb: > Ich suche am AVR immer noch den USB-Stöpsel. Wurde vorhin verlinkt: "Atmel AVR4950: ASF - USB Host Stack" https://ww1.microchip.com/downloads/en/DeviceDoc/doc8486.pdf
(prx) A. K. schrieb: > PICklig schrieb: >> Dazu noch einen Intel 8272 und fertig ist die Laube. >> Pech, wenn man keinen hat. > > Digikey ersäuft dermassen in verschiedenen Floppy-Disk Controllern und > den teils erforderlichen Datenseparatoren, dass sie welche verkaufen > müssen. Nur über Marketplace, und keine einzelnen. :-(
Angehängte Dateien:
Klaus B. schrieb: > Pah! > Ein Steve Wozniak hat nur ein PROM und einen Zähler gebraucht :-) > https://de.wikipedia.org/wiki/Integrated_Woz_Machine 2 PROMs. c-hater schrieb: > Ist bei genauerer Betrachtung doch ein wenig veraltet. Mit neueren AVR8 Welchen, den 100 MHz Typen ? Muss man wohl noch ewig drauf warten. 16msps schafft kein 20 MHz Controller. Selbst wenn man per 10 MHz SPI einliest und die Bytes durch tabellengesteuerte state machines jagt, reicht es nicht. Sicher, man kann es auch schlechter machen und mit Glück immer noch manchmal Daten lesen. PICklig schrieb: > Dazu noch einen Intel 8272 und C-hater redete von veraltet, was ist das denn dann erst, Archäologie ?
MaWin schrieb: > Klaus B. schrieb: >> Pah! >> Ein Steve Wozniak hat nur ein PROM und einen Zähler gebraucht :-) >> https://de.wikipedia.org/wiki/Integrated_Woz_Machine > > 2 PROMs. Nein nur eines. Das andere enthielt den Bootloader, war für die Funktion des Controllers aber nicht nötig.
Klaus B. schrieb: > Pah! > Ein Steve Wozniak hat nur ein PROM und einen Zähler gebraucht :-) > https://de.wikipedia.org/wiki/Integrated_Woz_Machine Hier etwas mehr Input wie die Floppys angesteuert wurden: https://mirrors.apple2.org.za/Apple%20II%20Documentation%20Project/Books/Beneath%20Apple%20DOS.pdf
> und C-hater redete von veraltet, was ist das denn dann erst, Archäologie
?
Wenn du persönliche Probleme mit dem 8272 hast, kannst du die für dich
behalten.
Entscheidend ist doch immer, dass es funktioniert.
Dazu vielleicht noch einen 16C50 von GI.
PICklig schrieb: > Dazu noch einen Intel 8272 und fertig ist die Laube. > Pech, wenn man keinen hat. Wobei der 8272 ein Nachbau des NEC µPD765 war. Peripherie war nicht Intels stärkste Seite.
:
Bearbeitet durch User
Josef P. schrieb: > Hallo. Ich möchte gerne ein Diskettenlaufwerk mit einen avr Controller > ansteuern du willst also das hier nachbauen? https://www.youtube.com/watch?v=G-X-p0C0Uas
PICklig schrieb: > Wenn du persönliche Probleme mit dem 8272 hast, kannst du die für dich > behalten. > Entscheidend ist doch immer, dass es funktioniert. Der i8272 braucht Treiber und Datenseparatoren, das ist schon seit 1995 überflüssig mit NS SuperFDC PC8477B. Da ein AVR auch Treiber und Datenseparator bräuchte, sind es mit einem PC8477B sogar weniger Chips.
Klaus B. schrieb: > 8" Scheibendurchmesser mit 77 Spuren und ein- oder zwei > Seiten. Achtung der Antriebsmotor braucht normalerweise AC, > also 230 V oder 110 V. 8" Laufwerke die schon 230V brauchen - gibts sowas tatsächlich?
mIstA schrieb: > 8" Laufwerke die schon 230V brauchen - gibts sowas tatsächlich? Dieser Art von Motor ist der feine Unterschied herzlich egal.
MaWin schrieb: > Der i8272 braucht Treiber und Datenseparatoren, das ist schon seit 1995 > überflüssig mit NS SuperFDC PC8477B. Das war schon viel früher überflüssig; schon der WD1772 brauchte den Kram nicht. Den fand man beispielsweise im Atari ST. Wenn man das HD-Format braucht, ist ein WD3765 zu empfehlen, den gab es auch schon gegen Ende der 80er Jahre. Zu finden war der auf unzähligen MFM- und RLL-Festplattencontroller für ATs, so z.B. auf dem WD100. Solange man aber nicht weiß, was der Threadersteller wirklich anfangen will, brauchen wir uns eigentlich auch keinen Kopf zu zerbrechen.
Angehängte Dateien:
-
SA800.PNG
45 KB
mIstA schrieb: > Klaus B. schrieb: >> 8" Scheibendurchmesser mit 77 Spuren und ein- oder zwei >> Seiten. Achtung der Antriebsmotor braucht normalerweise AC, >> also 230 V oder 110 V. > > 8" Laufwerke die schon 230V brauchen - gibts sowas tatsächlich? Siehe Anhang.
8"-Laufwerke brauchen immer einen direkten Netzanschluss. Erst 5.25"-Laufwerke konnten die Drehzahl mit Gleichstromtechnik genau genug regeln. Selbst aktuelle Retrotechnik benutzt immer einen FDC, der den ganzen schnellen Kram erledigt. Alte Technik ebenfalls. Es gab zwar vollständig diskret aufgebaute Floppy-Controller, aber die arbeiten durchgängig mit hardsektorisierten Disketten (NorthStar und so). Ein klassischer AVR8 ist für die Decodierung von HD (also 500 Kbps) eigentlich zu langsam, aber ich erinnere mich dunkel an ein Projekt, was die 250 Kbps einer DD-Diskette geschafft hat. Man kann zusätzliche Hardware mit Software kombinieren, wie Apple oder Commodore das getan haben, aber den Aufwand empfehle ich nicht.
S. R. schrieb: > 8"-Laufwerke brauchen immer einen direkten Netzanschluss. Erst > 5.25"-Laufwerke konnten die Drehzahl mit Gleichstromtechnik genau genug > regeln. Davon weiß das 8"-Laufwerk in meinem Schrank offenbar nichts; das braucht nur 24V. Beschreibung hier: https://retrocmp.de/fdd/nec/nec-fd1165_pd.pdf
Helmut P. schrieb: >> 8"-Laufwerke brauchen immer einen direkten Netzanschluss. Erst >> 5.25"-Laufwerke konnten die Drehzahl mit Gleichstromtechnik genau >> genug regeln. > > Davon weiß das 8"-Laufwerk in meinem Schrank offenbar nichts; > das braucht nur 24V. Beeindruckend. Muss eins der letzten Generation sein. Ist aber auch egal, der TO hat in seinem Leben nur einen Beitrag verfasst und ist inzwischen über alle Berge.
Ich lasse mir hier den i8272 nicht madig machen. Sein formschoenes 40 pinniges DIP-Gehaeuse passt immerhin in jeden mindestens 40 poligen zoelligen DIL-Sockel. Das kannst du ja mit deinem Super-IO-Kaefer auch mal versuchen. Und schon alleine wenn Mann mal GCR formatierte Disketten lesen will. Der i8272 legt einem da keine Steine in den Weg. Einen MFM-Dekoder kann man ja aehnlich einem Dekoder fuer "Conditioned Di-Phase" noch mit allereinfachsten Standardbauelementen zusammenbauen. Bei GCR muesst ich nochmal nachsehen.
Klaus B. schrieb: > mit dem Lesen der uPD765 und WD1793 Doku anfangen. WD1772-2 nicht vergessen https://www-user.tu-chemnitz.de/~heha/basteln/PC/usbfloppy/floppy.chm/ http://info-coach.fr/atari/hardware/FD-Hard.php Scheibenkleister http://www.robert-tolksdorf.de/papers/mags/Scheiben.pdf https://www.eurobuch.de/buch/isbn/3927065005.html https://shop.digitalretro.ch/products/scheibenkleister-massenspeicher-am-atari-st
:
Bearbeitet durch User
DDR-8-Zoll Floppys hatten einen 220v Antrieb. Und als Steuerung nen ausgewachsenen K...-Rechner in Einschubtechnik mit U880, U552, entsprechenden RAM und U856 Serial Interfacce und U855 Parallel Interface. Alles riesengroß. in Nachttischgröße. mfg
PICklig schrieb: > Ich lasse mir hier den i8272 nicht madig machen. Soll's ja geben. Leute die prinzipiell nicht klüger werden wollen.
Klaus B. schrieb: > Bei einer Standardfloppy eigentlich ganz einfach: > > 8" Scheibendurchmesser mit 77 Spuren und ein- oder zwei Seiten. Achtung > der Antriebsmotor braucht normalerweise AC, also 230 V oder 110 V. Die > Elektronik +/-5 V und 24V für den Schrittmotor. Und dann wär da noch das Filesystem ...
Lotta . schrieb: > Alles riesengroß. in Nachttischgröße. Ich weis ja nicht wie groß bei Dir die Nachttische sind, aber bei mir sind diese schon noch größer als so ein altes Floppy. Bei 2 Maßen war halt eine Mindestgröße erforderlich - so ne 8" Disk ist nun mal 20x20cm groß. Auch das mit dem Parallel und Serieninterface ist so nicht richtig. Die Floppy's Robotron hatten einen Bus der elektrisch mit dem Shugart-Bus kompatibel war allerdings hat man keinen international kompatiblen Stecker benutzt. In der DDR war das EFS-System üblich. Eine schöne Übersicht über die in der DDR verwendeten Floppylaufwerke gibt es hier https://www.robotrontechnik.de/index.htm?/html/komponenten/fs.htm
Zeno schrieb: > Lotta . schrieb: >> Alles riesengroß. in Nachttischgröße. > Ich weis ja nicht wie groß bei Dir die Nachttische sind, aber bei mir > sind diese schon noch größer als so ein altes Floppy. Ich glaube, Lotta meinte hier den Controller. Und das war eine K1520-Vollformatplatine, dicht gepackt. Später mit dem U8272 mit bisschen Takt/Datenseparator hätte das auf ein Viertel der Fläche gepasst...
Angehängte Dateien:
-
BlueDisk_AppleII.jpg
81 KB
BlueDisk ... einige Apple-User werden ihn kennen ... Vor langer langer Zeit gab es mal einen MFM-Controller für die AppleII - Serie. Darauf sass der Intel 82077, der einzige Chip der damals mit einigermassen vertretbaren Aufwand eine Implementierung zuliess. Diesen 82077 könnte man heutzutage auch leicht dazu verwenden mit einem Atmel-Controller etwas Floppy-Controller-mässiges aufzubauen. Der Aufwand wäre im Vergleich zur AppleII - Implementierung relativ gering. BlueDisk konnte übrigens nicht nur HD Disketten lesen und schreiben sondern auch die sehr seltenen 2.8MB Disketten (EHD? wenn man das entsprechende Laufwerk dazu hatte).
Ingo W. schrieb: > Ich glaube, Lotta meinte hier den Controller. Und das war eine > K1520-Vollformatplatine, dicht gepackt. Später mit dem U8272 mit > bisschen Takt/Datenseparator hätte das auf ein Viertel der Fläche > gepasst... Naja, aber aber so grß wie ein Nachttisch war's trotzdem nicht. Hier https://www.robotrontechnik.de/index.htm?/html/komponenten/fs.htm mal ein paar Bildle vom 5120. Da ist der komplette Rechner vielleicht so groß wie ein kleiner Nachttisch. Richtig groß (und schwer) waren die Dualfloppys vom E60/E100 (sowjetische PDP11 Clone). Das erste was in unseren Geräten eingesetzt wurde war ca. 50cm breit (2x 8" nebeneinander), geschätzt 40cm hoch und auch 50cm tief. Das Nachfolgemodell war nicht mehr so hoch, "nur noch" ca. 20cm aber dafür fast doppelt so tief, so das der Elektronikschrank wo das Ding eingebaut war eine "Rucksackrückwand" bekommen mußte. Das ist jetzt aber fast 40 Jahre her - war halt eine andere Zeit.
Angehängte Dateien:
Disque Bleu schrieb: > der einzige Chip > der damals mit einigermassen vertretbaren Aufwand eine > Implementierung zuliess. Diesen 82077 könnte man heutzutage > auch leicht dazu verwenden mit einem Atmel-Controller etwas > Floppy-Controller-mässiges aufzubauen. Wozu, wenn es single Chip Lösungen im Computerschrott gibt ? Hier machen Viele den Eindruck, seit 1989 nichts mehr hinzugelernt zu haben.
Ts... Was Opa und ich da auseinandergenommen hatten war ein Beistellgerät, ca.. 40 - 50 Cm hoch, oben war die Floppy drinne darunter war der Rechnereischub mit Rückverdrahtung und darunter ein mächtig gewaltiger Schaltnetzteileinschub. Das Laufwerk war nicht mehr vollständig, irgend ein Modellbauer hat die Mechanik geerbt, die Steuerung hab ich noch irgendwo, weil mich das Einschubsystem gereizt hat. Das ganze war nen Teil eines Entwicklerrechners oder Steuerrechners von CEKO, dem Telefonabhörsystem der DDR. Damit wurden die Leitungen nach dem Westen überwacht und abgehört. Mit hunderten ferngesteuerter Tonbandgeräte! ;-O Außerdem haben sich die "Kundschafter" gegenseitig belauert, über nen "Harmoniumadapter", der im Telefon eingebaut war und mittels ZF übertragen hat und der Gegenstelle zur Auswertung. (zur Loyalitätsüberprüfung der IM) mfg
Ich habe mal einen Floppy-Controller-Adapter für 5"1/4 an einen PocketBeagle gebaut. Erwarteter Vorteil von diesem Ansatz: man schreibt nur einen Floppy-Low-Level-Treiber (Spur suchen und Sektor(en) lesen/schreiben) und um den Rest (Dateisystem) kümmert sich das Linux. Wenn man will kann die Floppy dann als USB-Memory präsentiert werden. Ich hatte dann nur das Problem dass mein letztes noch vorhandenes 5"1/4-Laufwerk nicht mehr funktioniert hat. Ich konnte zwar die Spuren auswählen, aber keine Daten sehen. Und so blieb das Projekt (wollte kein "neues altes" Laufwerk kaufen und auch mangels Priorität) bisher unvollendet. Warum nicht ein externe 3,5-Zoll-Laufwerk mit USB-Anschluss zerlegen und dort das 5"1/4-Laufwerk anflanschen? Nach meinen Erkenntnisse sind weder Stecker noch Signale noch Software kompatibel.
Nikolaus S. schrieb: > Warum nicht ein externe 3,5-Zoll-Laufwerk mit USB-Anschluss zerlegen und > dort das 5"1/4-Laufwerk anflanschen? Geht nicht. 5.25"-Laufwerke mit "HD" nutzen eine andere Drehzahl als 3.5"-Laufwerke mit HD (und haben deswegen eine geringere Kapazität). 3.5"-Laufwerke drehen mit 300 min-1, 5.25"-HD-Laufwerke drehen mit 360 min-1. Ein "richtiger" FDC wie der WD3765 kann damit umgehen, aber die Dinger in den USB-Diskettenlaufwerken können das nicht, die können noch nicht mal DD-Disketten ("720k") lesen. > Nach meinen Erkenntnisse sind weder > Stecker noch Signale noch Software kompatibel. Stecker und Signale sind adaptierbar, die Software hingegen --s.o.-- nicht, es sei denn, es gelänge, die Firmware des USB-FDC zu verändern. Henrik Haftmann hat sich mit dem Thema eingehender auseinandergesetzt: https://www-user.tu-chemnitz.de/~heha/basteln/PC/usbfloppy/ -- aber irgendwann zwischendrin aufgehört.
Ich hatte mal ein Floppy Laufwerk mittels WS37C65 an einen Parallel-Port des PC angeschlossen. Der Chip war gut dokumentiert und daher relativ einfach zu verwenden. Das geht sicher auch an einem Mikrocontroller. http://bitsavers.informatik.uni-stuttgart.de/components/westernDigital/_dataBooks/1991_SystemLogic_Imaging_Storage/31_WD37C65C.pdf Allerdings sind heute eher Mikro-SD Karten angesagt.
Stefan ⛄ F. schrieb: > Ich hatte mal ein Floppy Laufwerk mittels WS37C65 an einen Parallel-Port > des PC angeschlossen. Der Chip war gut dokumentiert und daher relativ > einfach zu verwenden. Angeschlossen schon, aber ich wette dass du über den Parallelport keinen einzigen Sektor erfolgreich gelesen oder geschrieben hast.
Stefan ⛄ F. schrieb: > Floppy Laufwerk mittels WS37C65 ... angeschlossen Sorry, der Chip heisst WD37C65
Disque Bleu schrieb: > aber ich wette dass du über den Parallelport > keinen einzigen Sektor erfolgreich gelesen oder geschrieben hast. Doch das ging. Allerdings war das Timing problematisch, hatte mich deswegen auf 720MB Disketten beschränkt.
MaWin schrieb: > Welchen, den 100 MHz Typen ? Muss man wohl noch ewig drauf warten. > 16msps schafft kein 20 MHz Controller. Selbst wenn man per 10 MHz SPI > einliest und die Bytes durch tabellengesteuerte state machines jagt, > reicht es nicht. Entweder hast du meinen Hinweis auf CCL überlesen oder du weisst nicht einmal, was das ist, weil deine AVR8-Kompetenz auf dem Stand von vor 5..10 Jahren eingefroren ist. Und was den Takt betrifft: ganz offiziell können die AVR8 heutzutage 24MHz, inoffiziell sogar 32MHz. Verstehst du jetzt das mögliche Grundkonzept? Um das klarzustellen: Ich habe es nicht umgesetzt, weil Disketten für mich seit vielen Jahren (eigentlich sogar Jahrzehnten) ziemlich bis vollkommen irrelevant sind. Ich besitze inzwischen weder Disketten noch Laufwerke dafür mehr. Ich halte es aber für durchaus möglich, mit den Features der neueren AVR8 einen HD-fähigen Floppycontroller umzusetzen. Konkret mit einem AVR128D(x)48 oder-64. Ich sehe eben bloß keinen Sinn darin, das tun zu wollen.
MaWin schrieb: > Hier machen Viele den Eindruck, seit 1989 nichts mehr hinzugelernt zu > haben. Was Floppies betrifft gab es ja seitdem auch nichts mehr dazuzulernen. Halt wieder das übliche sinnfreie und unqualifizierte MaWin-Geschwafel. Ich habe eine grössere Stückzahl Messmaschinen auf Z80-Basis mit Floppy-Interface mit dem Controller SAB2797 ausgeliefert. Dazugelernt habe ich seitdem zu Floppies tatsächlich nichts mehr, die funktionieren auch heute noch einwandfrei. Vorher, in der Steinzeit, habe ich auch noch Floppy-Controller für 8 Zoll gebaut mit Datenseparator aus Standard-TTL, weil der bei BASF nicht im Laufwerk enthalten war. Die Steuerung mit 2 x 8-Zoll-Floppy konnte man nicht alleine an der Maschine montieren, die wog wohl mehr als 20 kg und war nicht besonders handlich. Georg
Georg schrieb: > mit Datenseparator aus Standard-TTL, weil der bei BASF nicht > im Laufwerk enthalten war Der war meines Wissens noch nie im Laufwerk enthalten, so man das übliche Interface nutzte. Auch bei den Floppy-Controller ICs wie dem erwähnten µPD765 war der nicht drin. Controller mit integriertem Datenseparator kamen erst deutlich später. Für FM reichte ein Monoflop. BTDT, Controller-Karte für 1 MHz 6502 gebaut, für Laufwerk von BASF. Für MFM war der Prozessor sowieso zu langsam. Bei MFM war es komplizierter weshalb die Karte beim 68000 ein entsprechendes IC bekam.
:
Bearbeitet durch User
Der TE hat sich nie wieder gemeldet. Der verarscht uns doch. Einfach ein paar Bröckchen hinwerfen, und hier wird diskutiert für nichts und wieder nichts.
PittyJ schrieb: > Der TE hat sich nie wieder gemeldet. > Der verarscht uns doch. > Einfach ein paar Bröckchen hinwerfen, und hier wird diskutiert für > nichts und wieder nichts. Naja, das typische Traffic-Troll-Konzept halt, sehr leicht erkennbar. Ist aber nicht unbedingt immer vollkommen kontraproduktiv. Manchmal tauchen im Verlauf der Threads auch durchaus nützliche Informationen auf. Aber klar: in der weit überwiegenden Mehrzahl sind diese Threads vollkommen nutzlose Gülle. Ich habe keine Ahnung, was die Trolle antreibt, sowas immer wieder anzukurbeln. Vermutlich einfach nur, weil es geht. Die sollen sich einfach eine Freundin suchen und die "gewogen" halten. Dann sind sie sinnvoller beschäftigt. Ooops, ich habe das Risiko übersehen, dass sie sich dann vermehren könnten. "Begabung" verrerbt sich ja mit einer gewissen statistischen Signifikanz. Diese Aussicht wäre natürlich auch wieder nicht so schön...
c-hater schrieb: > Die sollen sich einfach eine Freundin suchen Das haben sie wahrscheinlich schon ausprobiert. Und sind daraufhin auf ein einfacheres Publikum für ihre Scherze ausgewichen.
Georg schrieb: > Was Floppies betrifft gab es ja seitdem auch nichts mehr dazuzulernen. Offenkundig doch, modernere bequemere Chips die du nie kennengelernt hast wegen Lernblockade.
MaWin schrieb: > Offenkundig doch, modernere bequemere Chips die du nie kennengelernt > hast wegen Lernblockade. Also ungefähr so, wie du neuere AVR8 und deren neue Fähigkeiten konsequent ignorierst? Auch Lernblockade?
c-hater schrieb: > Also ungefähr so, wie du neuere AVR8 und deren neue Fähigkeiten > konsequent ignorierst? Auch Lernblockade? Ich warte auf deinen Diskettenlaufwerksansteuercode, darf auch gern Assembler sein und blocking.
MaWin schrieb: > c-hater schrieb: >> Also ungefähr so, wie du neuere AVR8 und deren neue Fähigkeiten >> konsequent ignorierst? Auch Lernblockade? > > Ich warte auf deinen Diskettenlaufwerksansteuercode, darf auch gern > Assembler sein und blocking. Wie ich bereits ausgeführt habe, sehe ich keinerlei Nutzen darin, sowas heute noch umzusetzen. Wenn du einen Nutzen darin siehst, bin ich gern bereit, diese Entwicklung als Auftragsarbeit zu liefern. Die Frage wäre also nur noch: was drückst du dafür ab? Ach so: für deine Bereitschaft, bei Lieferung öffentlich zu erklären, dass es 1. geht und du 2. selber unfähig warst, es umzusetzen, würde ich dir 1/3 der Vertragssumme erlassen. Das wäre mir der Spaß wert. Ich bin alt genug, die wahren Genüsse des Lebens schätzen zu lernen ;o)
Beitrag "Floppy FDD Diskette an AVR Mikrocontroller ATmega Beispiele Assembler" (link in haftmann-material gefunden, link auf haftmann-material is hier irgendwo weiter oben im thread)
An sich ist es sowieso egal. Wer heutzutage sowas für Retro entwickeln möchte, nimmt einen der üblichen Controllerbausteine. Natürlich keine SuperIO-Bausteine, sondern das in DIP und verfügbare Material. Alle anderen nehmen direkt eine SD-Karte oder - ganz aktuell - einen CH375 für USB-Zugriff. Wenn man ein Floppy-Interface hat, dann lautet das Zauberwort "Gotek". Da steckt meist ein STM32 (oder Klon) drin und das ist auch ungefähr die Leistungsklasse, in der man die gesamte Diskettenwelt mit Software und in Echtzeit erschlagen kann. Mit einem AVR und ohne zusätzliche Hardware macht das keinen Spaß. Ich gebe aber unserem Hassprediger recht, dass es vermutlich geht.
Josef P. schrieb: > Ich habe schon einige Internetseiten angesehen, aber keinen Code > gefunden. Der Grund warum du keinen Code findest ist, dass es besser geeignete MCUs dafür gibt. schau mal hier: https://github.com/keirf/Greaseweazle Michael
S. R. schrieb: > Mit einem AVR und ohne zusätzliche Hardware macht das keinen Spaß. Der Spaß ist doch nicht, EINFACHE Sachen umzusetzen. Das kann doch jeder, wo soll da der Spaß herkommen? Ich hab' was geschafft, was jeder andere auch schaffen könnte? Nö, der Spaß ist, Sachen an der Grenze des jeweils Machbaren umzusetzen. Was natürlich vor allem damit anfängt, erstmal zu erkennen, was (und wie genau es) machbar ist. Das ist eigentlich die Phase, wo es wirklich noch reiner Spaß ist. Die Umsetzung ist dann natürlich auch schon wieder was hart an der Grenze zu Arbeit. Man muß wirklich gerne programmieren, um das dann durchzuziehen. Oder sich halt dafür bezahlen lassen, wenn irgendwie möglich. Daher wohl der Begriff "Schmerzensgeld" ;o
Floppies, auch 3 1/2 HD, lesen und schreiben geht mit einem AVR Prozessor ohne grösseren Handstand. Ich hatte damals einen Atmega1284P genommen, weil der hat genug RAM und läuft auch mit 20MHz. Später fand ich dann heraus 16MHz reichen völlig und man könnte es sicher auch mit weniger RAM machen (habe ich dann nicht mehr ausprobiert). Zuerst mal Sektoren lesen https://www.5volts.ch/posts/mfmreader/ Dann Sektoren schreiben mit abgezählten Zyklen (sehr hässlich) https://www.5volts.ch/posts/mfmwriter/ Und dann noch Sektoren schreiben mit Hilfe eines Timers (viel übersichtlicher) https://www.5volts.ch/posts/mfmwriter2/ Das einzige Manko, es ist in Assembler. Eigentlich sollte das die Grundlage für einen Floppy Controller Nachbau eines PDP-11 geben aber ich habe leider kein erschwingliches 8" Laufwerk mehr gefunden um das Projekt weiter zu führen.
Peter S. schrieb: > Das einzige Manko, es ist in Assembler. Nein, das ist kein Manko. Ein echtes Manko ist, wenn ein Assemblerprogrammierer nicht die tatsächlichen Mankos seiner Lösung zu erkennen vermag... 1. Du brauchst ein zusätzliches CPLD zum Lesen. 2. Das Schreiben ist nahezu "blocking". Sprich: Solange dein Floppy-Code läuft, ist (fast) nix anderes möglich. Und genau diese beiden Mankos könnte man halt mit den neuen Features z.B. eines AVR128DB48 beheben. "CPLD" hat der nämlich in Form der CCL bereits eingebaut und außerdem gute (De)Serializer, die sich wiederum sehr gut mit dem CCL verheiraten lassen. Das zusammen führt dazu, dass z.B. eine echte "Fullspeed"-Bridge möglich wird, d.h.: bidirektionaler Datentransfer mit der vollen möglichen Geschwindigkeit des Laufwerks, z.B. von/zu einem SPI- oder UART-Interface.
Beitrag #7147332 wurde vom Autor gelöscht.
c-hater schrieb: > Peter S. schrieb: > >> Das einzige Manko, es ist in Assembler. > > Nein, das ist kein Manko. > > Ein echtes Manko ist, wenn ein Assemblerprogrammierer nicht die > tatsächlichen Mankos seiner Lösung zu erkennen vermag... > > 1. Du brauchst ein zusätzliches CPLD zum Lesen. > > 2. Das Schreiben ist nahezu "blocking". Sprich: Solange dein > Floppy-Code läuft, ist (fast) nix anderes möglich. > > Und genau diese beiden Mankos könnte man halt mit den neuen Features > z.B. eines AVR128DB48 beheben. "CPLD" hat der nämlich in Form der CCL > bereits eingebaut und außerdem gute (De)Serializer, die sich wiederum > sehr gut mit dem CCL verheiraten lassen. > > Das zusammen führt dazu, dass z.B. eine echte "Fullspeed"-Bridge möglich > wird, d.h.: bidirektionaler Datentransfer mit der vollen möglichen > Geschwindigkeit des Laufwerks, z.B. von/zu einem SPI- oder > UART-Interface. 1. Das vorgestellte Projekt ist das erste Projekt ohne CPLD. Das Projekt mit CPLD ist (noch) nicht veröffentlicht 2. Das Schreiben ist nicht nur nahezu sondern wirklich blocking, das Lesen übrigens auch 3. Du hast dich mit den CCL auseinandergesetzt? Ich glaube kaum, denn sonst wüsstest du, dass diese bei einer MFM dekodierung kaum gewinnbringend eingesetzt werden können, der Code bleibt blocking, habe es selbst ausprobiert 4. Was wirklich nötig wäre um so eine Aufgabe non-blocking zu machen wäre DMA, das haben die AVR128Dx leider nicht Also zuerst lesen und dann meckern. Und zeig doch einfach mal wie du das gemacht hast Peter
c-hater schrieb: > Nein, das ist kein Manko. Das war natürlich Ironie und gerade von dir hätte ich erwartet dass du sie erkennt.
c-hater schrieb: > Nö, der Spaß ist, Sachen an der Grenze des jeweils Machbaren umzusetzen. > Was natürlich vor allem damit anfängt, erstmal zu erkennen, was (und wie > genau es) machbar ist. Das ist eigentlich die Phase, wo es wirklich noch > reiner Spaß ist. Ja. Aber man macht so ein Projekt ja nicht, um so ein Projekt zu machen. In der Regel will man damit auch etwas bezwecken. Sei es, um seine PDP-8 (oder deren Emulation) aufzuhübschen, oder die alten Disketten auszulesen oder irgendwas in der Art. Da hilft einem ein Controller, der exakt auf Kante genäht und zu 98% mit der Auslastung des Algorithmus beschäftigt ist, nicht mehr weiter. Bringt ja auch nichts, wenn der zwar die Diskette lesen und schreiben kann, dann aber ewig mit der Datenübertragung zu PDP oder Z80 beschäftigt ist. Peter S. schrieb: > Und zeig doch einfach mal wie du das gemacht hast Kanner nich. Oder vielleicht kanners doch, aber tuts nicht. Vom Ergebnis her ist das identisch.
Peter S. schrieb: > 3. Du hast dich mit den CCL auseinandergesetzt? Ja, sehr intensiv, wenn auch nicht unter dem Aspekt, ein Floppy-Interface damit bauen zu wollen. Die Erkenntnis, dass auch das damit möglich wäre, ist nur ein (für mich völlig nutzloses) Abfallprodukt. > Ich glaube kaum, denn > sonst wüsstest du, dass diese bei einer MFM dekodierung kaum > gewinnbringend eingesetzt werden können Das sehe ich definitiv völlig anders. Und wenn DU dich tatsächlich damit auseinandergesetzt hättest, würdest auch du das anders sehen... > der Code bleibt blocking Ähem nein. > 4. Was wirklich nötig wäre um so eine Aufgabe non-blocking zu machen > wäre DMA, das haben die AVR128Dx leider nicht Das stimmt, DMA hat er nicht. Ist hier aber auch garnicht nötig. Um BYTES mit der nötigen Rate zu schaufeln, reicht es völlig. Mit den BITS muss er sich dank CCL+SPI ja nicht mehr beschäftigen. > Also zuerst lesen und dann meckern. Und zeig doch einfach mal wie du das > gemacht hast Ich habe ausdrücklich gesagt, das ich es eben nicht gemacht habe. Ich könnte es aber jederzeit tun. Es muss mich bloß jemand dafür bezahlen, weil ich es weder für mich selber noch im Geschäft brauche. Wenn es also irgendwer braucht, steht es ihm frei, die Lösung bei mir zu kaufen. Dann kann er sie meinetwegen auch veröffentlichen. Solange der Urheber genannt und die eigene Unfähigkeit öffentlich dargelegt wird. Diesbezüglich biete ich dir dieselben Konditionen, wie ich sie MaWin angeboten habe. Der scheint allerdings auf Floppy auch nicht so wirklich scharf zu sein. Was ich allerdings durchaus verstehen kann, ich selber bin es ja auch nicht. Aber für Geld...
Geiles Thema! Wenn der TO jetzt ne alte Floppykarte mit ISA-Bus nehmen würde, veieinfacht sich die Sache dann? Die haben ja auch DMA gebraucht, oder irre ich mich da? mfg
> Wenn der TO jetzt ne alte Floppykarte mit ISA-Bus > nehmen würde, veieinfacht sich die Sache dann? Hehe - so war die erste Generation von Festplattencontrollern für den Amiga aufgebaut: eine ISA-Karte mit OMTI-5520-Controller (MFM, später 5527 für RLL) und ein einfacher Adapter für ISA- nach Zorro-Bus. Der Grund für die ISA-Karten war aber nur, dass die, im Gegensatz zu den einzelnen Chips, spottbillig und überall verfügbar waren. Könnte heutzutage bei den Floppycontrollern ähnlich sein ;-)
Lotta . schrieb: > Geiles Thema! Und, hast du irgendeinen Beitrag gelesen und dir irgendein Bild angesehen oder Link gefolgt ?
Lotta . schrieb: > Wenn der TO jetzt ne alte Floppykarte mit ISA-Bus > nehmen würde, veieinfacht sich die Sache dann? Das ist ja das, was man mit dem WD37C65 (und ähnlichen) bekommt. Ein direktes paralleles µC Interface wie am ISA Bus. Den zweiten Chip dieser Karten (Adress Decoder) brauchen wir am Mikrocontroller nicht. Seine Kern-Funktion war, beim den gewünschten Sektor zu finden und dessen Bits in Bytes umzuwandeln (bzw. anders herum beim Schreiben). Also primär ein Schieberegister mit der dazu nötigen Takt- und Zeitsteuerung. Das Einzige was ich an diesem Chip vermisse ist ein Pufferspeicher. Wenn er den Sektor gefunden hat, löst er einen Interrupt oder DMA aus und dann muss der Mikrocontroller die Daten so schnell übertragen, wie sich durch die Rotation der Disk ergibt. > Die haben ja auch DMA gebraucht, oder irre ich mich da? Nicht zwingend, geht auch ohne. Aber dann ist das Timing anspuchsvoll. Nochmal der Link zum Datenblatt: http://bitsavers.informatik.uni-stuttgart.de/components/westernDigital/_dataBooks/1991_SystemLogic_Imaging_Storage/31_WD37C65C.pdf
Stefan ⛄ F. schrieb: > Nicht zwingend, geht auch ohne. Aber dann ist das Timing anspuchsvoll. Mit DD-Disketten (250 kBit/sec) haben das so langsame Geräte wie z.B. der Atari ST (mit 8 MHz getakteter 68k) oder auch noch langsamere 8-Bit-Systeme hinbekommen. Und wenn pro Byte ein Interrupt ausgelöst wird, sollte das auch bei HD (500 kBit/sec) ein typischer µC der Jetztzeit hinbekommen, den abzuarbeiten. Die Interruptrate liegt bei 62.5 kHz. Das schafft ein AVR, der kann mit der Rate einen Sektorpuffer beschreiben bzw. auslesen.
Lotta . schrieb: > Die haben ja auch DMA gebraucht, oder irre ich mich da? Gebraucht nicht unbedingt, aber auf dem ISA-Bus war DMA ja ohne Problem verfügbar. Das ist bei einfachen Controllern nicht so. Georg
Georg schrieb: > Lotta . schrieb: >> Die haben ja auch DMA gebraucht, oder irre ich mich da? > > Gebraucht nicht unbedingt, aber auf dem ISA-Bus war DMA ja ohne Problem > verfügbar. Das ist bei einfachen Controllern nicht so. Der IBM PC/XT war zu langsam, um die Daten zu Fuß über den ISA-Bus abzuholen. So ein Floppycontroller hat keinen Puffer, da muss man mehr oder weniger in Echtzeit abholen. Schon beim IBM/AT mit 6 bzw 8 MHz war DMA nicht mehr nötig, da wäre es auch mit PIO gegangen. Aus Kompatibilitätsgründen hat man es aber beibehalten. Die meisten Festplattencontroller liefen aber mit PIO, und so kam es zu der absurden Situation, dass die "langsame" Floppy schneller angebunden war als die Winchesterlaufwerke. DMA kam dann zu Pentium II-Zeiten wieder in Mode, mit den ATA-Laufwerken.
DerEgon schrieb: > Mit DD-Disketten (250 kBit/sec) haben das so langsame Geräte wie z.B. > der Atari ST (mit 8 MHz getakteter 68k) oder auch noch langsamere > 8-Bit-Systeme hinbekommen. > Und wenn pro Byte ein Interrupt ausgelöst wird, sollte das auch bei HD > (500 kBit/sec) ein typischer µC der Jetztzeit hinbekommen, den > abzuarbeiten. > Die Interruptrate liegt bei 62.5 kHz. Das schafft ein AVR, der kann mit > der Rate einen Sektorpuffer beschreiben bzw. auslesen. Du hast nicht verstanden, dass ein uC, wenn er ohne externen Datenseparator und ohne externe PLL auskommen soll, eine PLL in Software machen muss um den Drehzahlschwankungen folgen zu können und man dafür eine 16 mal so hohe Samplerate des Datenstroms als notwendig für ausreichend zuverlässige Lesefähigkeiten erachtet. 8-fach mag auch noch irgendwie gehen mit Abstrichen an Zuverlässigkeit, aber 4-fach reicht sicher nicht. Ebenso ist dir offenbar unklar, dass beim Schreiben nicht einfach ein Datenstrom mit z.B. 500kbps geschrieben wird, sondern die Flankenwechsel als PreShift um +/-125/250ns verschoben werden müssen, was auch 8MHz entspricht. Anders gesagt: du hast keine Ahnung von Floppy-Technik und solltest lieber Schweigen als Unsinn vom Stapel zu lassen. Alte Floppy-Controller ohne Spezial IC machten das mit einem Haufen an Zusatz-Schaltkreisen.
Soul E. schrieb: > Der IBM PC/XT war zu langsam, um die Daten zu Fuß über den ISA-Bus > abzuholen. 32 kHz Interruptrate mit einem 4.77-MHz-Prozessor bedienen, der pro Speicherzugriff vier Taktzyklen braucht (und hatte der nicht sogar noch Waitstates bei I/O-Zugriffen?) ... das ist halt deutlich langsamer als ein mit auch nur 1 MHz getakteter AVR. Allein das Auslösen eines Interrupts über den Interruptcontroller dürfte bei der PC-Hardwarearchitektur eine deutliche Latenz mit sich gebracht haben. Tatsächlich wurde auf dem PC/XT sogar so verhältnismäßig langsames wie die UART aus Angst nicht im Interrupt betrieben, jedenfalls nicht von den dafür zuständigen Routinen im BIOS.
Soul E. schrieb: > Die meisten Festplattencontroller liefen aber mit PIO, und > so kam es zu der absurden Situation, dass die "langsame" Floppy > schneller angebunden war als die Winchesterlaufwerke. Der HDD Controller des PC/XT verwendete DMA. Allerdings lief das genau wie bei der Floppy über den langsamen DMA Controller, nicht über Bus Master DMA wie beim Adaptec AHA1542 SCSI Adapter.
:
Bearbeitet durch User
MaWin schrieb: > Lotta . schrieb: >> Geiles Thema! > > Und, hast du irgendeinen Beitrag gelesen und dir irgendein Bild > angesehen oder Link gefolgt ? Ja! Ob ich ihn total verstanden hab, weiß ich aber nicht. Die Beiträge im Forum lese ich aber normalerweise 3 mal: mit positiver Einstellung mit negativer Einstellung zwischen den Zeilen. Denn ich hab gelernt, das unter mancher knarzig-teerigen Federung der OM's hier ne dicke Goldschicht zu finden ist, wenn frau den Teer erstmal durchstoßen hat. ;-)) mfg
(prx) A. K. schrieb: > nicht über Bus > Master DMA wie beim Adaptec AHA1542 SCSI Adapter. Den hätte man im PC oder XT nicht betreiben können. Ich bin mir auch nicht sicher, ob das Hardwaredesign des PC bzw. XT überhaupt so etwas wie Busmaster-DMA zugelassen hätte; an Karten, die so etwas nutzten, könnte ich mich erinnern. Da der Festplattencontroller beim XT nichts standardisiertes war, sondern jeder Controller sein eigenes Süppchen gekocht hat (anders als beim AT mit dem WD1003, der in irgendeiner Form auch in heutigen SATA-Controllern drinsteckt), gab es natürlich etliche Möglichkeiten. Einig waren sie sich aber alle in einem: Sie waren langsam. Die hypothetisch möglichen 500 kByte/sec Übertragungsrate erreichten MFM-Platten nur mit späteteren Controllern wie dem WD1006 (der ein RAM als Puffer für mehrere aufeinanderfolgende Sektoren verwendete und deswegen den "Interleave"-Betrieb unnötig machte).
Zu XT-Zeiten war 1:7 oder 1:11 Interleaving nicht ungewöhnlich. Da kommt dann mit jeder Umdrehung der Magnetscheibe ein Sektor. Und der wurde im Controller zwischengespeichert und konnte in Ruhe abgeholt werden.
Soul E. schrieb: > Zu XT-Zeiten war 1:7 oder 1:11 Interleaving nicht ungewöhnlich. Und damit werden aus den 500 kByte/sec Datenrate, die die Festplatte an den Controller liefert, mal eben knapp 72 kByte/sec oder sogar nur 45 kByte/sec. Heute bezeichnen wir Internetzugänge, die 500 kByte/sec liefern, als "Holzklasse".
MaWin schrieb: > Du hast nicht verstanden, dass ein uC, wenn er ohne externen > Datenseparator und ohne externe PLL auskommen soll, eine PLL in Software > machen muss um den Drehzahlschwankungen folgen zu können Nein, das muss er eben nicht. Man kann eine PLL mit den Möglichkeiten der CCL der neuen AVRs rein in "Hardware" umsetzen. Der MCU-Core hat damit nur zu einem Zeitpunkt was zu schaffen, nämlich bei der Konfiguration der CCL. Das ist, was du scheinbar nicht zu begreifen vermagst. CCL ist de facto ein sehr primitiver FPGA. Aber eben nicht zu primitiv für den konkreten Zweck, aus dem Lesesignal eines Floppylaufwerks einen sauberen decodierten Bitstream und den dazu passenden Takt zu erzeugen und das an eine der SPI-Einheiten eines AVR128Dx zu verfüttern. Erst dann kommt die MCU in's Spiel, die die fertigen Bytes von der SPI-Einheit abholen und weiter leiten muss. Dein reines C-Gefrickele hat dir scheinbar jede ernsthafte Kompetenz geraubt. Witzig ist dabei: Diese Sache wäre sogar in C problemlos umsetzbar, da die SPI-ISR selbst in dem gräßlich ineffizientem C implementiert locker schnell genug für die anfallende Datenrate wäre...
MaWin schrieb: > Du hast nicht verstanden, dass ein uC, wenn er ohne externen > Datenseparator und ohne externe PLL auskommen soll, eine PLL in Software > machen muss um den Drehzahlschwankungen folgen zu können und man dafür > eine 16 mal so hohe Samplerate des Datenstroms als notwendig für > ausreichend zuverlässige Lesefähigkeiten erachtet. 8-fach mag auch noch > irgendwie gehen mit Abstrichen an Zuverlässigkeit, aber 4-fach reicht > sicher nicht. Und Du hast nicht verstanden, daß "DerEgon" sich auf die Nutzung eines FDC und den da rausfallenden Datenstrom bezieht.
c-hater schrieb: > Dein reines C-Gefrickele hat dir scheinbar jede ernsthafte Kompetenz > geraubt. Pädagogisch bist du ein trauriger Blindgänger. Wenn du jemand persönlich beleidigst, verschließt er sich vor dir. Das ist ganz normales menschliches Verhalten. Darum sind deine ganzen Ratschläge in diesem Forum vollkommen sinnlos. Das Einzige, was wirksam bleibt, ist schlechte Stimmung.
c-hater schrieb: > Nein, das muss er eben nicht. Man kann eine PLL mit den Möglichkeiten > der CCL der neuen AVRs rein in "Hardware" umsetzen Nur zu. Bei maximal 9 Gattern die auch noch dieselben Inputs sharen. Übrigens unterlag DerEgon der irrigen Annahme, bloss weil ein alter 8 bit uC auch irgendwie Floppies lesen konnte, müsste das ein AVR auch schaffen, und hat übersehen, dass der AVR das aber ohne Zusatzhardware (ausser Treibern) hinkriegen soll. Ein WD37C65 oder GM82C765 ist jedoch eindeutig die bessere Losung - der enthält die Treiber schon.
Stefan ⛄ F. schrieb: > Wenn du jemand persönlich beleidigst, verschließt er sich vor dir. Du hast das immer noch nicht begriffen: Ein Nennung offensichtlicher Tatsachen ist keine Beleidigung. Allenfalls kann sie als Beleidigung empfunden werden. Wenn man aber nichts mehr schreiben darf, was irgendeine Mimose möglicherweise als Beleidigung empfindet, ist das Internet de facto tot...
Nee, Du. Zwischendrin ging es darum, daß der olle PC für die Ansteuerung seines FDC ausgerechnet DMA brauchte, und daß ohne DMA das Timing besonders kritisch wäre. Und ich bezog mich explizit darauf, daß ein popliger AVR bei der Interruptbehandlung Kreise um den ollen PC rennt und die Interrupts eines FDCs bedienen kann. Aus der Fragestellung des Threadstarters abzuleiten, daß unbedingt auf einen FDC verzichtet werden muss, ist allerdings auch nur einiger Leute Interpretation.
Beitrag #7150879 wurde von einem Moderator gelöscht.
... und irgendwann kommt raus, dass der TO eigentlich nur den Kopfmotor rattern lassen wollte ;-)
Beitrag #7150917 wurde von einem Moderator gelöscht.
Beitrag #7150949 wurde von einem Moderator gelöscht.
Beitrag #7150964 wurde von einem Moderator gelöscht.
Beitrag #7150971 wurde von einem Moderator gelöscht.
Beitrag #7150974 wurde von einem Moderator gelöscht.
Beitrag #7150980 wurde von einem Moderator gelöscht.
Beitrag #7150984 wurde von einem Moderator gelöscht.
Stefan ⛄ F. schrieb im Beitrag #7150984:
> Gerne.
Na toll. Und was genau ist jetzt dein Beitrag? Rein technisch?
Geht's mit einem AVR128Dx? Ja oder nein, was sagst du? Wenn ja: warum?
Wenn nein, warum nicht?
Das ist, was man Fakten nennt und worüber zu diskutieren wirklich
lohnt. Alles andere ist sinnleerer Bullshit, vollkommen huppse...
c-hater schrieb: > was genau ist jetzt dein Beitrag? Rein technisch? Das findest du selbst heraus indem du dir einfach mal meine Beiträge zum Thema anschaust.
Mich würde eigentlich doch noch interessieren ob es noch andere geschafft haben ohne CPLD und ohne FDC HD-Disketten zu lesen und zu schreiben. Die CCL des AVR128Dx könnte man evtl. beim Schreiben eines Sektors verwenden um die NOR Logik nachzubilden um aus den Rohdaten einen MFM Datenstrom zu generieren. Aber leider scheitert die Idee mit dem SPI auf dem AVR128Dx daran, dass das SPI die Bytes nicht nahtlos schreibt. D.h. zwischen zwei Bytes, auch im buffered Mode, macht der AVR128Dx eine Pause von einem Bit, das ist natürlich ärgerlich und verhindert mit SPI und CCL einen MFM Datenstrom zu erzeugen. Man könnte das SPI Datenregister natürlich auch bitsynchron schreiben, aber dann wird das mit dem blockfreien schreiben nichts und man gewinnt also genau nichts. Lesen ist eine ganz andere Liga, ist übrigens wesentlich komplizierter als Schreiben eines Sektors, hier muss man sich mit dem MFM Datenstrom synchronisieren damit man die Clock und Daten bits auseinanderhalten kann. Dazu muss man die SYNC bytes erkennen und sich darauf synchronisieren. Da reichen die CCLs definitiv nicht aus, denn ein CCL ist nur in etwa das gleiche wie 2 LUT eines FPGA, da kann man keine Statemachine bauen die ein 8-bit SYNC Byte erkennt, dazu braucht man mindestens 16 LUT. Das SPI ist hier auch nicht hilfreich, weil man müsste einen Clock für das SPI generieren, der mit der evtl. schwankenden Datenrate synchronisiert ist. Da reichen die 3 CCL auch wieder nicht. Im CPLD habe ich dazu eine Statemachine mit 4 Flip-Flops, und das nur weil ich statt 16-fach nur 8-fach oversample (es hat sich gezeigt, das Floppies meist genügend stabil laufen, so dass 16-fach oversampling nicht nötig ist wie das in den meisten FDCs mit digitalem Dataseparator gemacht wurde). Sonst würde es 5 Flip-Flps brauchen. Die CCLS des AVR128Dx stellen aber nur total 3 zur Verfügung. Leider hat sich der OP nicht mehr gemeldet und so wissen wir bis heute nicht ob er nur die Floppies ansteuern will um den Kopf zu bewegen und den Motor anzusteuern oder ob er wirklich die Daten lesen und schreiben will. Ich nehme aber an das Zweite ist der Fall, denn für das erste gibt es jede Menge Beispiele im Internet. Vielleicht werde ich mir mal die Zeit nehmen und das Projekt mit dem CPLD ins Netz stellen. Hier sieht das Ganze natürlich wesentlich entspannter aus. Eigentlich bildet das CPLD einfach nur den Datenpfad eines FDC ab, d.h. er ist in der Lage aus Bytes einen MFM Datenstrom zu erzeugen und aus einem MFM Datenstrom das SYNC Byte zu erkennen und wenn er synchronisiert ist den MFM Datenstrom in Bytes umzuwandeln. Hier muss der AVR natürlich nur alle 16usec (bei 3 1/2 HD Floppies) ein Byte liefern oder abholen, das geht natürlich auch in einer Interruptroutine. Wobei der AVR dann trotzdem ziemlich ausgelastet ist und man natürlich nicht allzu lange Zeit nach dem Interrupt hat das nächste Byte zu liefern. Das CPLD ist in Leserichtung nur einmal gepuffert und in Schreibrichtung gar nicht, d.h. hier dient das 8-bit Interface als Puffer. Hier würde sich natürlich der Level1 Interrupt des AVR128Dx anbieten damit man die Reaktionszeit garantieren kann. Meine CPLD Lösung braucht 143 LUTs und 53 Flip-Flops. Spezialisten bringen das sicher auf etwas weniger, aber wir sind weit entfernt von den 6 LUT und 3 Flip-Flops im AVR128Dx. Die Signale DIR, STEP, HS, DSx, MOTON, TRACK0, WG etc. werden aber weiterhin rein in der AVR Firmware bedient. Auch ein Format eines Track muss man zu Fuss machen. Hier auch noch etwas Zusatzinformation zum Ursprünglich geplanten Projekt, einem Floppy Disk Controller für einen PDP-11. Hier ist es eigentlich absolut unwichtig ob der AVR die Floppies Blocking oder Nonblocking lesen oder schreiben kann. Im Fall eines PDP-11 schreibt das Betriebssystem nur die Information über den gewünschten Sektor in die Controller Register und auch eine DMA Adresse. Anschliessend setzt der PDP-11 das GO bit im Controller und ab dann ist das BUSY bit im Controller gesetzt und regiert nicht mehr auf PDP-11 Zugriffe. D.h. der AVR hat mehr oder weniger alle Zeit der Welt sich nur mit dem Floppy abzugeben, den Sektor zu lesen oder schreiben, und danach oder davor die Daten via DMA in den PDP-11 Speicher zu schreiben/lesen. Anschliessend aktiviert er wieder das Controller Interface, d.h. löscht das BUSY bit, für die PDP-11 ist das dann die Information ob die Controller Register einen Status zeigen und dass er wieder einen neuen Befehl schreiben kann. Der AVR kann das alles sequentiell machen, da braucht es kein non-blocking Floppy Interface. Ähnlich ist das auch auf meinem RLV12 Emulator umgesetzt. Die bekannten Betriebssystem auf der PDP-11 funktionieren damit ohne Probleme.
S. R. schrieb: > ... ist auch ungefähr die Leistungsklasse ... Ich frag mich sowieso wieso niemand bisher "Use the right tool for the job" geflucht hat? (Na ja, eigentlich dreht sich ja der ganze Thread um das Thema, mehr oder weniger). Was will jetzt Josef noch mal genau, ich bin durcheinander? **g**
:
Bearbeitet durch User
Lotta . schrieb: > Die haben ja auch DMA gebraucht, oder irre ich mich da? Ja und nein. Weder der PCjr noch frühe Tandy-Systeme hatten einen DMA-Controller, also war er für DD-Formate nie zwingend nötig. HD-Formate können diese Systeme nicht verarbeiten. Andererseits war DMA auf dem ursprünglichen PC/XT schneller als die CPU und für den Speicherrefresh ohnehin vorhanden, also hat IBM ihn auch für Disketten und Festplatten benutzt. Aus Kompatiblitätsgründen wurde das dann beibehalten, solange PCs mit Floppy-Controllern existierten. DerEgon schrieb: > Mit DD-Disketten (250 kBit/sec) haben das so langsame Geräte wie z.B. > der Atari ST (mit 8 MHz getakteter 68k) oder auch noch langsamere > 8-Bit-Systeme hinbekommen. Ein ZETA V2 (kein DMA) schafft mit seinem Z80 bei 8 MHz auch HD-Disketten, aber nicht bei 4 MHz.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.