Hallo Leute, anbei mein Schaltplan für ein "USB-Diskettenlaufwerk". Bitte gerne kritisieren. Würde mich über Verbesserungsvorschläge freuen. Grüße Count Omega
Angehängte Dateien:
-
Schaltplan.jpg
160 KB
Beitrag #6498704 wurde von einem Moderator gelöscht.
ja, das ist mir bekannt. Ich will das ganze aber selber aufbauen, um hierbei etwas zu lernen.
Matthias G. schrieb: > anbei mein Schaltplan für ein "USB-Diskettenlaufwerk". Bitte gerne > kritisieren. Würde mich über Verbesserungsvorschläge freuen. Also mal abgesehen davon, dass es USB-Diskettenlaufwarke ja bereits für kleines Geld zu kaufen gibt, ist die Schaltung völliger Overkill für den Zweck. Drei ICs und einer davon noch ein fetter PIC32... Soll da nebenbei noch Counterstrike drauf laufen oder was war der Plan?
Kann man diesen WD Controller überhaupt noch kaufen? Ich habe damit in dem 90er Jahren experimentiert.
Beitrag #6498724 wurde von einem Moderator gelöscht.
Beitrag #6498725 wurde von einem Moderator gelöscht.
Matthias G. schrieb: > Würde mich über Verbesserungsvorschläge freuen. Erstmal das Thema "Kontrast von Schaltplänen" überdenken. Wozu der uralte Floppycontroller? Kann man das nicht sinnvollerweise direkt mit dem schnellen PIC + ggf. ein wenig Glue Logic in einem CPLD machen? Und warum das Ganze? Das gibt es schon fertig für einen brauchbaren preis. Just for fun? Herausforderung? Lernprojekt?
Mit FPGAs/PLDs habe ich keine Erfahrung. Die Schaltung ist als Freizeitprojekt gedacht. Zudem habe ich noch ein paar 3,5" Disketten rumliegen.
Matthias G. schrieb: > Mit FPGAs/PLDs habe ich keine Erfahrung. Ist hierfür auch vollkommen unnötig. Das Problem kann man mit einem USB-fähigen 8-Bitter (z.B. ATMega32U2) und ein bissel Analogscheiß umfassend abhandeln. Gut, man muss natürlich wirklich Programmieren können, der 32U2 wäre hart an der Grenze seine Leistungsfähigkeit, jedenfalls bei HD-Disks. DD ist easy, das kann man im Halbschlaf runterprogrammieren. Wie ich sagte: völliger Overkill. FPGA genauso wie PIC32+Uralt-WD.
c-hater schrieb: > Gut, man muss natürlich wirklich Programmieren können, der 32U2 wäre > hart an der Grenze seine Leistungsfähigkeit, jedenfalls bei HD-Disks. DD > ist easy, das kann man im Halbschlaf runterprogrammieren. Naja, wenn man's halt auf die harte Tour will. Mount Everes geht auch ohne Zusatzsauerstoff, aber auch mit ist es ausreichend herausfordernd. Ich bin ja weiß Gott kein Befürworter von Overkill und sinnlosen Materialschlachten, aber bei den heute verfügbaren Mikrocontrollern würde ich mals sicher NICHT den wählen, der es nur mit Ach und Krach schafft. Man darf sich auch mal ein paar Reserven gönnen. Lieber das Ding erstmal mit einem deutlich überdimensionierten Controller stabil zu Laufen bringen, da hat man genug zu tun. Optimieren kann man dann immer noch, wenn es denn wirklich sinnvoll ist.
Matthias G. schrieb: > Mit FPGAs/PLDs habe ich keine Erfahrung. Du willst ja was lernen. Ob man das wirklich braucht, weiß ich nicht. Muss man mal genauer analysieren. Ich hab mal was von max. 1 Mbit/s gehört, die der Controller schlucken muss. Das kann ein moderner Mikrocontroller leicht, vor allem mit etwas Hardwareunterstützung in Form von SPI, DMA & Co. Und wenn es ECHT eine kniffelige Logik gibt, die man in Software nur sehr aufwändig nachbilden kann, dann bleiben noch diskrete Logik-ICs. > Die Schaltung ist als > Freizeitprojekt gedacht. Das spricht auch nicht gegen CPLD & Co. > Zudem habe ich noch ein paar 3,5" Disketten > rumliegen. Ja und? Du brauchst einen lauffähigen PC, der die Laufwerke noch anspricht, da musst du ran und messen und testen. Die Disketten allein nützen wenig ;-)
Angehängte Dateien:
Matthias G. schrieb: > Schaltplan.jpg Wer soll sich durch solchen JPG-Matsch durchwühlen. Die verschiedenen Bildformate haben alle bestimmte Stärken und Schwächen. Unscharfe Linien/Schrift und bis zur Unkenntlichkeit vermatschte kleine Strukturen lassen JPG für solche Schaltpläne, dazu noch bei derart knapper Auflösung, eher ungeeignet erscheinen.
Beitrag #6498882 wurde von einem Moderator gelöscht.
Beitrag #6498888 wurde von einem Moderator gelöscht.
Matthias G. schrieb: > Hier eine hoffentlich bessere Version. Besser, aber noch nicht gut. Die Auflösung ist immer noch grenzwertig. Da sollte man besser die doppelte Auflösung beim Drucken einstellen. Oder wenn möglich gleich als Vektorgrafik als PDF drucken. Das sieht nach KiCAD aus, richtig? Ähhh, ach so. In welche Richtung soll das eigentlich gehen? Wie es scheint, willst du NICHT wie es mehrfach zu kaufen gibt ein Floppy emulieren, um eben dieses in einem alten PC/Gerät zu ersetzen, sondern du willst mit dem Ding ein Floppy ansteuern, quasi den PC ersetzen. Richtig? Denn genau dafür ist der WD-IC da, damit kann man keinen Floppyemulator bauen.
Matthias G. schrieb: > Hier eine hoffentlich bessere Version. Noch was. Ein Schaltplan, zum ein so einfacher, enthält SIGNALE in Form von Linien, nicht Dutzende Labels! Schaltplan richtig zeichnen
Beitrag #6498906 wurde von einem Moderator gelöscht.
Stefan ⛄ F. schrieb: > Das kann doch billig fertig kaufen! Mehr noch, das kann man kostenlos auf dem Schrott finden. Wer verwendet denn heute noch Disketten? Also abgesehen von Vintage-Gerätschaft, die das Laufwerk dann aber eingebaut hat. Ich habe vor 2 Jahren mal ausgemistet und neben zwei alten Laptops auch dito USB-Diskettenlaufwerke rausgeworfen (zu verwenden im im Multifunktions Akku/CDROM/Disketten Schacht oder Betrieb mit mini-B USB-Kabel). Stand einen halben Tag im Pappkarton auf dem Bürgersteig vor dem Haus, bis es einen "Bewunderer" gefunden hatte.
Angehängte Dateien:
-
WRnpC.png
77 KB
Meine Bauteiledatenbank gibt folgende Infos: IC number: 37C65 IC function: FDC (Floppy Disk Controller) Related components: FDC9268, µPD765 Component documentation IC number Manufacturer Documentation WD37C65 Western Digital Not available FDC37C65 SMC (now SMSC) Not available Component versions Component Package CBM part number CBM part description WD37C65 40-Pin DIP 390304-01 IC, WD37C65 WD37C65A 40-Pin DIP 390304-02 IC, WD37C65A WD37C65B, FDC37C65B 40-Pin DIP 390304-03 37C65B FDC WD37C65C-PL 40-Pin DIP WD37C65 44-Pin PLCC 390304-04 WD37C65 FCC Controller PLCC Pkg WD37C65C-JM 44-Pin PLCC Positions Device Position Component Package A2286 sandwich board U71 WD37C65, FDC37C65B, WD37C65C DIP A2386 U501 WD37C65C PLCC PC30-III U1001 WD37C65, WD37C65A, WD37C65B DIP PC40-III U1001 WD37C65, WD37C65A, WD37C65B, FDC37C65B DIP PC60-III U127 WD37C65B DIP SL286/SL386SX main board U305 WD37C65 PLCC Und hier ein paar Topics zu dem Teil, auch mit kpl. Schaltplan: https://electronics.stackexchange.com/questions/365610/wd37c65-identify-type-of-floppy-disk-drive https://electronics.stackexchange.com/questions/490296/floppy-disk-to-usb-controller-with-%c2%b5c https://electronics.stackexchange.com/questions/292040/arduino-writing-to-a-3%c2%bd-floppy-disk
:
Bearbeitet durch User
Falk B. schrieb: > Das sieht nach KiCAD aus, richtig? Der direkte Export von KiCad in eine Bilddatei funktioniert für mich nicht zufriedenstellend. Ich exportiere immer als Postscript und dann wandle ich dieses ggf. mit Gimp in eine Rastergrafik mit (mindestens) 300dpi um.
Stefan ⛄ F. schrieb: > Das kann doch billig fertig kaufen! Wozu braucht man so was noch? Wer es bis heute nicht geschafft hat seine Disketten auf ein Zeitgemässes Medium zu kopieren, der schafft es eh nicht mehr.
Stefan ⛄ F. schrieb: > Das kann doch billig fertig kaufen! Aber die meisten gekauften können keine 3,5"-Disketten mit 720k lesen. Und schon gar keine im Amiga oder Atari ST-Format. 5,25"-Floppys mit USB-Anschluss gibt es m.W. gar nicht zu kaufen (nur als Speziallösungen wie Kryoflux). Und über 8" wollen wir gar nicht reden. Insofern wäre ein universeller Controller mit Kompatibilität zu µPD765 oder WD2793 schon eine tolle Sache. Mac, Apple II und C64 erwischt man damit nicht, die muss man wirklich als Rohdaten einlesen -- siehe Kryoflux. Für die gesamte CP/M-Welt wäre das Projekt aber eine tolle Sache. BTW: falls jemand einen IDE (P-ATA) nach USB-Konverter kennt, der auch Platten mit C-H-S-Adressierung beherrscht (20 .. 500 MB), oder dem ich die Geometrie irgendwie mitgeben kann (notfalls über eine RS-232 an der Seite, oder über einen zweiten Endpoint als virtueller Comport), bitte melden. Dem kann man dann einen WD1003 nachschalten und so auch MFM-Platten ansprechen.
Soul E. schrieb: > Aber die meisten gekauften können keine 3,5"-Disketten mit 720k lesen. > Und schon gar keine im Amiga oder Atari ST-Format. 5,25"-Floppys mit > USB-Anschluss gibt es m.W. gar nicht zu kaufen (nur als Speziallösungen > wie Kryoflux). Und über 8" wollen wir gar nicht reden. Insofern wäre ein > universeller Controller mit Kompatibilität zu µPD765 oder WD2793 schon > eine tolle Sache. Atari ST-Disketten hatten das normale DOS-FAT-Format, nur an einigen Stellen im Bootblock abweichende Einträge. Das native 880k Amiga-Diskettenformat kann ein normaler Diskettencontroller nicht verarbeiten, weil der Amiga keine einzelnen Sektoren schreiben kann, sondern nur ganze Tracks auf einen Rusch - und damit ist die Lücke zwischen den Sektoren für normale Controller zu klein. Dafür braucht man Spezialhardware. Der Amiga kann aber problemlos 720k DOS-Disketten lesen und schreiben. fchk
Soul E. schrieb: > BTW: falls jemand einen IDE (P-ATA) nach USB-Konverter kennt, der auch > Platten mit C-H-S-Adressierung beherrscht (20 .. 500 MB), Eine 500MB habe ich gerade an so einem Universl Adapter für dreifuffzig getestet. Geht.* Alte 2,5" Platten (40MB) gehen nicht direkt am 44 Pin Anschluß. Die brauchen wohl 12V. Mit einem Adapter am 40 Pin Anschluß und ext NT sollte es gehen. *Hab schnell wieder abgeschaltet, denn es klapperte innen verdächtig und laut. Hat 20 Jahre im Regal gelegen.
Soul E. schrieb: > Aber die meisten gekauften können keine 3,5"-Disketten mit 720k lesen. Das ist DD und damit die ideale Spielwiese für die Lösung mit Mega32U2. Das geht damit noch ganz entspannt. Genau für sowas (Amiga-Disketten) habe ich das mal gemacht. Aber nur Q&D für eine einmalige Anwendung. Ist aber mittlerweile auch schon wieder ca. 10 Jahre her. Mein Gott, die Zeit rast.
fchk schrieb: > Das native 880k Amiga-Diskettenformat kann ein normaler > Diskettencontroller nicht verarbeiten, weil der Amiga keine einzelnen > Sektoren schreiben kann, sondern nur ganze Tracks auf einen Rusch Der Amiga konnte durchaus auch einzelne Sektoren schreiben (das wurde z.B. genutzt, um DD-Disketten im DOS-Format zu beschreiben), hat das aber bei seinem nativen Format nicht getan, weil es ineffizient war. TrackAtOnce liefert einfach mal mehr Speicherkapazität auf dem Medium. Eben weil es keine Sektorlücken geben muss, sondern deren Platz auf dem Medium sinnvoller für Daten genutzt wird.
c-hater schrieb: > Eben weil es keine Sektorlücken geben muss, sondern deren Platz auf dem > Medium sinnvoller für Daten genutzt wird. Der Amiga war zu seiner Zeit schon ein geiles Teil und sehr innovativ! Aber das ist verdammt lange her! 8-0
Falk B. schrieb: > Wozu der uralte Floppycontroller? Kann man das nicht sinnvollerweise > direkt mit dem schnellen PIC + ggf. ein wenig Glue Logic in einem CPLD > machen? Die verbreiteten Goteks benutzen einen STM32 dafür und sind damit - je nach Format und Besonderheiten - schon sehr beschäftigt. Im Prinzip könnte man die Decodierung in einem CPLD machen, aber der Controller ist bekannt, recht gut ansteuerbar und definitiv als Hobbyprojekt geeignet. c-hater schrieb: > Ist hierfür auch vollkommen unnötig. Das Problem kann man mit einem > USB-fähigen 8-Bitter (z.B. ATMega32U2) und ein bissel Analogscheiß > umfassend abhandeln. In meiner Welt hat so ein Atmega schlicht nicht genug RAM, um sowas halbwegs sinnvoll zu machen. Eine Spur einer HD-Diskette enthält 18 Sektoren, also 9 KB dekodierte Daten. Mit dem mickrigen 1 KB SRAM musst du jeden Sektor einzeln in Echtzeit verarbeiten und um Schreibzugriffe dann noch an die richtige Stelle zu stopfen... Dir ist zugute zu halten, dass du nicht explizit gesagt hast, wieviel dein "bissel Analogscheiß" ist, aber dein Vorschlag ist reichlich daneben. Wie vieles, leider. > DD ist easy, das kann man im Halbschlaf runterprogrammieren. Um sich ein decodiertes Image zu ziehen, ja. Ohne Kopierschutz. Schreibzugriffe sind schwierig, da muss man schon was können. HD und Datendurchsatz (also 45-50 KB/s) kannst du vergessen. AVRs sind für sowas schlicht zu klein. Gib denen 32 KB internes SRAM und die Welt sähe anders aus. fchk schrieb: > Atari ST-Disketten hatten das normale DOS-FAT-Format, nur an einigen > Stellen im Bootblock abweichende Einträge. Das sind aber DD-Disketten und daran scheitern die meisten USB-Laufwerke. Die können ausschließlich 3.5" HD-Disketten mit 1.44 MB. Ältere UFI-Laufwerke können etwas mehr. Ich hab hier eins von Sony und damit erfolgreich 720 KB-Disketten gelesen und geschrieben. Allerdings mag Linux so langsame Blockdevices nicht besonders. :-) Soul E. schrieb: > Mac, Apple II und C64 erwischt man damit nicht, die muss man wirklich > als Rohdaten einlesen -- siehe Kryoflux. Für die gesamte CP/M-Welt wäre > das Projekt aber eine tolle Sache. Der Wildwuchs bei CP/M ist deutlich größer als 128 Byte/Sektor, da braucht man dann auch schonmal ein Kryoflux.
S. R. schrieb: > AVRs sind für sowas schlicht zu klein. > Gib denen 32 KB internes SRAM und die Welt sähe anders aus. Man kann externen SRAM anflanschen, dann hat man ~60kB. Been there, done that. Damit hab ich 22kB/s von/zu SD-Karte auf DMX512 umgesetzt. Bei 16 MHz Takt lag die mittlere CPU-Last bei ca. 30%.
Falk B. schrieb: > Man kann externen SRAM anflanschen, dann hat man ~60kB. > Been there, done that. Damit hab ich 22kB/s von/zu SD-Karte > auf DMX512 umgesetzt. Bei 16 MHz Takt lag die mittlere > CPU-Last bei ca. 30%. Am ATmega32U2, den unser allseits beliebter Hassprediger vorgeschlagen hat, geht das allerdings nicht direkt, weil dem das XMEM fehlt. Überhaupt scheint die XMEM-Schnittstelle nur bei älteren AVRs vorhanden zu sein, nicht zusammen mit USB. Überhaupt habe ich mir schon öfter mal klassische AVRs mit mehr internem RAM gewünscht. Gibt es leider nicht, bei 16 KB ist Schluss.
Beitrag #6500325 wurde vom Autor gelöscht.
Kree schrieb: > Es ist keine SW dabei. > Also ist das Projekt sowieso fürn A.... Ist ja hier auch nicht die Codesammlung. So wie ich es verstanden habe, fragt Matthias ja auch erstmal nur, ob die HW so laufen würde. Wenn er später die entstandene SW hier veröffentlichen würde, wäre es nett, und eine Verschiebung in die Codesammlung wert. Zum eigentlichen Thema: Als ich mich vor 30 Jahren, mit dem Thema 8272 (der sollte kompatibel zum '765 sein) beschäftigt habe, war noch eine externe PLL, für die Taktrückgewinnung aus den vom Laufwerk gelesenen Daten erforderlich. Die Unterlagen dafür sind mir aber leider verschütt gegangen...
Angehängte Dateien:
-
Zwischenablage01.png
310 KB
So um hier mal noch einiges zu erklären: Die Schaltung sollte so funktionieren, dass anschließend das Diskettenlaufwerk als USB-Gerät funktioniert. Ich hätte zuerst die Hardware erstellt und mich dann noch um die Software gekümmert. Die Daten/Steuersignale sollen über die Pegelwandler an den µC und dann über PMP an USB übergeben werden.
Matthias G. schrieb: > So um hier mal noch einiges zu erklären: Na immerhin ist die Auflösung jetzt gut ;-) Das Grundproblem (keine Signale, nur Labels) bleibt. Naja. Trotzdem viel Spass und Erkenntnisgewinn bei dem Projekt.
Also Disketten lesen und schreiben, auch 3 1/2 HD, geht mit einem 16MHz Atmega ohne Zusatzhardware. D.h. auf den Floppy Controller kann man sicher verzichten. Ich nehme an es geht darum mit eigener Windows/Linux Software via USB auf die Sektoren einer Floppy zugreifen zu können. Dann spielt es auch keine Rolle wenn der Atmega während dem lesen oder schreiben von der Floppy ausgelastet ist. Die Erfahrung zeigt, mit einem Atmega bei dem ein ganzer Track im Speicher Platz hat vereinfacht die Aufgabe stark. Ich habe dazu einen Atmega1284P verwendet der hat immerhin 16kbyte SRAM.
Peter S. schrieb: > Also Disketten lesen und schreiben, auch 3 1/2 HD, geht mit einem 16MHz > Atmega ohne Zusatzhardware. D.h. auf den Floppy Controller kann man > sicher verzichten. Genau so ist das. Der Trick ist einfach: den Trackbuffer stellt der Host bereit. Ganz genau so ist es übrigens auch beim Amiga gelöst. Nur Leute, die nur in den Kategorien von C und sektororientierten Linux-Blockdevices denken können, haben ein Problem damit... Arme, geistig Behinderte. Schränken sich selbst unnötig ein und sind auf ihren "Wissensstand" dann auch noch stolz... Aber dem kann abgeholfen werden, lieber Herr Svenska! Zieh' dir einfach mal den Code des trackdisk.device rein. Das ist C und für ein zumindest stark unixoid gefärbtes OS gedacht... Für das ich übrigens schon vor 30 Jahren sehr erfolgreich programmiert habe... Und nein: der Analogscheiß hat nix mit dem Buffer zu schaffen. Der ist nur nötig, um auch HD und Rotz wie GCR bestmöglich zu unterstützen...
Stefan ⛄ F. schrieb: > Hat man das oft zu dir gesagt oder warum bist du so? Wer mir an's Bein pisst, dem piss' ich an's Bein. So einfach ist das. Nix "Hassprediger", nur Verkünder der reinen und ungeschminkten Wahrheit. Das Problem ist nur: sie passt vielen nicht. Das ist aber nicht meine Schuld...
c-hater schrieb: > Wer mir an's Bein pisst, dem piss' ich an's Bein. So einfach ist das. wie ein räudiger Straßenköter. Wer fragt einen dreckigen Penner nach dem Weg? Keiner! Obwohl er die Straßen mit Sicherheit besser kennt, als jeder andere. Wer unangenehm auftritt, auf dessen Rat legt kaum jemand wert. (Soll nicht heißen dass du ein dreckiger Penner bist. Viele davon sind sehr freundlich und unfreiwillig in diese Lage gekommen).
Peter S. schrieb: > Also Disketten lesen und schreiben, auch 3 1/2 HD, geht mit einem 16MHz > Atmega ohne Zusatzhardware. Hast du dafür bitte ein Beispiel?
Stefan ⛄ F. schrieb: > Wer unangenehm auftritt, auf dessen Rat legt kaum jemand wert. Nun, wie man aus vielen Diskussionen ersehen kann, gibt es wohl auch viele Leute, die auf den Rat von Leuten, die "angenehm" auftreten, sehr gut verzichten können, ihn sich sogar ausdrücklich verbitten... Meine Meinung ist: wichtiger als "angenehmes" Aufteten sind immer harte Fakten, denn am Ende will jeder (ernsthafte) Fragesteller ein Problem lösen. Dabei hilft "angenehmes" Auftreten exakt NULL, Fakten aber schon eher. Wenn auch oft nichtmal die, weil der Fragesteller zu blöd ist, sie nutzbringend zu verwerten, weil er sie entweder erst garnicht versteht oder zumindest nicht in der Lage ist, die gewonnene Erkenntnis zu Code werden zu lassen. Das ist dann Schicksal...
c-hater schrieb: > Und nein: der Analogscheiß hat nix mit dem Buffer zu schaffen. Der ist > nur nötig, um auch HD und Rotz wie GCR bestmöglich zu unterstützen... Das möchte ich noch etwas ergänzen: Im Kern handelt es sich bei dem "Analogscheiß" um einen simplen Tiefpass mit steuerbarer Zeitkonstante. Wer sich jemals ernsthaft mit den Floppy-Speicherverfahren beschäftigt hat, wird natürlich schnell erkennen, warum das wichtig ist, um die verschiedenen Formate jeweils bestmöglich zu unterstützen. Man muss aber auch noch ergänzen: notfalls (dann natürlich mit deutlich erhöhter Fehlerrate) geht es auch ohne dies.
Hier hab ich das mal in groben Zügen festgehalten. Die Feinheiten sind im Sourcecode. Schau unter MFM Reader und MFM Writer. Dort gibt es jeweils eine Lösung nur in Software und dann noch eine mit etwas Hardware in Form eines kleinen CPLD. www.5volts.ch Der Trackbuffer ist nur eine Hilfe und wird in meinem Projekt nicht vom Host geliefert, für was auch. Die Routinen können auch für das Lesen von einzelnen Sectoren verwendet werden. Nötig ist der Trackbuffer nicht. Ich hatte auch mal vor Jahren ein kleines Projekt gemacht um Apple II GCR Disketten zu lesen aber das habe ich leider nicht dokumentiert. Vielleicht finde ich den Sourcecode noch aber lesbar dürfte er nicht sein das war noch zu meinen Anfangszeiten mit AVR prozessoren.
c-hater schrieb: > c-hater schrieb: > >> Und nein: der Analogscheiß hat nix mit dem Buffer zu schaffen. Der ist >> nur nötig, um auch HD und Rotz wie GCR bestmöglich zu unterstützen... > > Das möchte ich noch etwas ergänzen: Im Kern handelt es sich bei dem > "Analogscheiß" um einen simplen Tiefpass mit steuerbarer Zeitkonstante. > > Wer sich jemals ernsthaft mit den Floppy-Speicherverfahren beschäftigt > hat, wird natürlich schnell erkennen, warum das wichtig ist, um die > verschiedenen Formate jeweils bestmöglich zu unterstützen. > > Man muss aber auch noch ergänzen: notfalls (dann natürlich mit deutlich > erhöhter Fehlerrate) geht es auch ohne dies. Die Schnittstellen für Floppy und HD sind digital, da braucht es nichts mit Analog. Meist sind das Open Collector Signale, nur die Lese und Schreib Daten der HD verwenden differenzielle Signale verwendet RS485/422
Warum soll man sich den Krampf eines USB-Diskettencontrollers antun? Gut, wer so etwas machen will, sollte sich selbst durchbeissen und nicht andere fragen. Ansonsten nimmt man ein 286/386 Board und steckt es an sein USB an. Ist doch auch eine Art Microkontroller. Es braucht kaum jemand.
Man macht solche Dinge weil man sie evtl. braucht um Vintage Computer am Leben zu erhalten und man mit einem solchen Gerät Floppys sichern kann. Und es macht Spass. Ich plane übrigens auch so ein Floppy Dingens (daher meine MFM Projekte) nur wird mein Gerät kein USB haben sondern eine SD-Card die FAT-32 formatiert ist und das direkt Floppy Images kopieren soll.
Peter S. schrieb: > Man macht solche Dinge weil man sie evtl. braucht um Vintage Computer am > Leben zu erhalten und man mit einem solchen Gerät Floppys sichern kann Dann muß es aber auch Sonderformate unterstützen. Auf mehreren Ebenen. Auf der Bit-Ebene nicht nur FM/MFM, sondern auch z.B. GCR. Und eine Ebene höher verschiedene Sektor-Größen auf der gleiche Scheibe. Oder sogar verschiedene Schreibdichten. Für so etwas gibt es schon Projekte. Was der TE da bauen will, wird das alles nicht können, schon weil da ein WD37C65 drin werkelt.
Axel S. schrieb: > Dann muß es aber auch Sonderformate unterstützen. Auf mehreren Ebenen. Es wäre schon lustig, eine Apple II- oder C64-Diskette ganz einfach transparent als Laufwerk "A:" ansprechen zu können. Ohne Umweg über Images, Fishwings etc.
c-hater schrieb: > Nix "Hassprediger", nur Verkünder der reinen > und ungeschminkten Wahrheit. Das behaupten die Hassprediger bestimmter Religionen auch von sich... was meine Aussage schlicht bestätigt, mehr nicht. Übrigens ist eine Aussage "das geht problemlos, man muss nur was können, und wer es nicht kann ist schlicht zu doof" nichtmal hilfreich. Das ist aber deine Standardaussage - in der Regel nicht hilfreich, dafür beleidigend und vor allem "ich bin besser als du". Hassprediger eben. Ich bleibe dabei.
:
Bearbeitet durch User
Kann ich hier noch Hilfestellung erwarten? Ich würde gerne wissen, ob die Schaltung letztendlich so funktionieren würde. Und würdet ihr ISCP der Programmierung auf einer externen Brennerplatine vorziehen?
Matthias G. schrieb: > Kann ich hier noch Hilfestellung erwarten? Ich würde gerne wissen, ob > die Schaltung letztendlich so funktionieren würde. Vermutlich schon. Hmm, wozu der Trick mit dem Inverter und RD WR? Du hast noch einen Kanal an K3 frei, nutze den für getrennte RD und WR Signale. Das KANN mit dem Inverter funktionieren, muss nicht. > Und würdet ihr ISCP > der Programmierung auf einer externen Brennerplatine vorziehen? Aber sicher! Willst du bei jeder Änderung der Software den IC aus der Fassung ziehen und neu programmieren, so wie vor 30 Jahren mit EPROMs?
Ah ok danke. Ich dachte mir, da beim WD35C RD und WR lowaktiv sind dass ich das eine Signal durch Invertierung des anderen erzeugen kann.
Und tu dir einen Gefallen und zeichne normale Signale und keine Labels! Mach eine Kopie deines Schaltplans, zeichne K3 auf Signale um und vergleiche! Pack K3 unter K2. Und warum eigentlich K2, K3? Ich würde die IC2 und IC3 nennen.
Angehängte Dateien:
Matthias G. schrieb: > Ich dachte mir, da beim WD35C RD und WR lowaktiv sind dass > ich das eine Signal durch Invertierung des anderen erzeugen kann. Schau lieber mal ins Datenblatt, insbesondere tAR und tRA sowie tAW und tWA.
Interessatn wäre für mich eher, ob dieser von vielen hier kritisierte Overkill, das LAufwerk vol unterstützt. Viele Diagnosetools arbeiten nicht auf USB Floppys da der direktet Zugriff fehlt? Würde das denn bei dieser Lösung, da ein echter Controller verbau ist funktionieren? Und wozu die immer wiederkehrende Frage nach dem Sinn? Haben hier 50% der Forenteilnehmer sich das Hirn schon weggekifft?
Matthias G. schrieb: > Kann ich hier noch Hilfestellung erwarten? Ich würde gerne wissen, ob > die Schaltung letztendlich so funktionieren würde Die Frage ist vergleichsweise irrelevant. Ob der Krempel am Ende funktioniert und evtl. gar einen Mehrwert gegenüber handelsüblichen USB-Floppies darstellt, hängt von der Software ab.
Axel S. schrieb: > Die Frage ist vergleichsweise irrelevant. Ob der Krempel am Ende > funktioniert und evtl. gar einen Mehrwert gegenüber handelsüblichen > USB-Floppies darstellt, hängt von der Software ab. Darum geht es gar nicht. Der Weg ist das Ziel! Beitrag "Re: Diskette zu USB" "Die Schaltung ist als Freizeitprojekt gedacht."
Falk B. schrieb: > Darum geht es gar nicht. Der Weg ist das Ziel! Wenn ich freie Zeit totzuschlagen hätte, würden mir auf Anhieb ca. 10 sinnvollere Projekte einfallen. Selbst der stupide Nachbau der FluxEngine würde mir da sinnvoller erscheinen. YMMV.
Spanabhebende Datenverarbeitung war schon immer ein faszinierendes Thema. Da ein paar Experimente machen und was zum laufen bringen macht Spaß. Auch wenn die Technologie an sich veraltet ist. Ich habe auch lieber eine Floppy im PC als einen Gotek im Oszi 🤠
Und man darf nicht vergessen, die Floppy-Elektronik und die Mechanik kann man nicht einfach mit irgendwas nachbilden. Wenn ich mich recht erinnere, gehen am AMIGA nur bestimmte Laufwerke von bestimmten Herstellern. Das mit irgendwelchen 0815 PC-Floppys nachzubilden ist Super-Sportlich.
c-hater schrieb: > Meine Meinung ist: wichtiger als "angenehmes" Aufteten sind immer harte > Fakten, denn am Ende will jeder (ernsthafte) Fragesteller ein Problem > lösen. Die meisten werden sich für deine "harten Fakten" nicht sonderlich interessieren und auch keine große Lust auf Diskussion haben, wenn du sie dabei gleichzeitig dauernd mit Fäkal-Ausdrücken bewirfst. Wir sind hier schließlich nicht in einem Affenkäfig. Man muss nicht überschwänglich freundlich sein, es reicht schon, einfach restpektvoll mit anderen umzugehen. Leider ist das absolut nicht deine Stärke. Und nein, wenn jemand weniger weiß oder eine andere Meinung vertritt als du, ist das kein Grund, den Respekt komplett über Bord zu werfen. > Dabei hilft "angenehmes" Auftreten exakt NULL, Dass das deine Einstellung ist, merkt man sehr oft.
Rolf M. schrieb: > Die meisten werden sich für deine "harten Fakten" nicht sonderlich > interessieren Das steht ihnen natürlich frei. Wenn sie aber ihr Problem lösen wollen, sollten sie sich dafür interessieren... > und auch keine große Lust auf Diskussion haben, wenn du > sie dabei gleichzeitig dauernd mit Fäkal-Ausdrücken bewirfst. Wo in diesem Thread soll das denn gewesen sein?
na toll, man schaut mal wieder kurz rein und wie üblich die sinnlosen Diskussion ganz nach mikrocontroller Manier von Leuten die selbst in Leben nicht gebacken bekommen aber meinen anderen erzählen zu müssen, wie sie ihr Hobby gestallten müssten und ihre zeit investieren sollen. Gib es auf solch ein diesem Forum irgend etwas Sinnvolles zu erwarten, es ist eine Spielwiese. Willst du ernsthafte Antworten uind brauchbare Infos schau mal im Eda Board https://www.edaboard.com/
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.