USB Floppy Projekt mit 82077SL FDC

    Mich hat heute mein 5.25" USB Floppy Projekt gluecklich gemacht - ich habe die erste Diskette lesen koennen. Das ganze ist aufgebaut mit einem STM32 Bluepill Board, und einem Intel 82077SL Controller. Ich wollte eine USB Floppy haben, die wie die normalen 3.5" USB Floppies ueber ein ganz normales USB Mass storage device angesprochen wird, damit man keine Treiber/Software benoetigt.


    Ich habe allerdings einige Stunden debugged, warum einen Track lesen 2.5s gedauert hat. Lag am Ende nur daran, das ich beim READ Kommando fuer den FDC 0 als Inter-Sektor-Gap angegeben hat. Damit hat er den folgenden Sektor nicht wie erwartet direkt uebertragen, sondern geskippt, und erst bei der naechsten Umdrehung uebertragen. Mit dem richtigen Gap sieht die Datenrate besser aus:


    Code
    /tmp $ sudo dd if=/dev/sda of=/tmp/floppy.img
2400+0 records in
2400+0 records out
1228800 bytes (1.2 MB, 1.2 MiB) copied, 41.5496 s, 29.6 kB/s


    Ich denke viel schneller wird Floppy nicht werden...


    Jetzt gibt es aber noch jede Menge zu tun:


    - Handling von kaputten Sektoren

    - Schreiben von Disketten

    - Formatieren von Disketten

    - 360K Support


    evtl. andere (nicht IBM PC?) Floppyformate?


    Achja, und ich habe den Fehler gemacht defekte Floppies immer direkt zu entsorgen, so das ich keine Floppies mit defekten Sektoren habe - falls da jemand was uebrig hat, wuerde ich die gerne nehmen ;) Am besten nur mit einzelnen defekten Sektoren.

    Quote from Kuhrator

    STM32 Bluepill Board, und einem Intel 82077SL Controller. Ich wollte eine USB Floppy haben, die wie die normalen 3.5" USB Floppies ueber ein ganz normales USB Mass storage device angesprochen wird, damit man keine Treiber/Software benoetigt.


    Da gäbe es - wenn es kompatibler als normale USB Floppy ist - bestimmt auch noch andere Interessenten, die genau sowas gut finden würden.


    Quote from Kuhrator

    Ich denke viel schneller wird Floppy nicht werden...


    Ginge schon. So mal als Idee. Der STM32 hat ja vermutlich noch freie Pins. Wenn man da jetzt ein 1MB bzw 2MB SRAM anschließt, ließe sich der gesamte Inhalt cachen. Erstmal readonly. Und mit so einem seltsamen seriellen RAM IC wird es auch noch billig, aber evtl nicht viel schneller als die Floppy.

    In der erweiterten Variante könnte sowas auch mit einer Liste pro Floppy kommen, wo die zu cachenden Files bzw Sektoren drin stehen.


    Quote from Kuhrator

    evtl. andere (nicht IBM PC?) Floppyformate?


    Wäre bestimmt interessant.


    Atari (sollte nicht soweit weg sein)

    Acorn ADFS (ist halbwegs gut dokumentiert)

    Schneider Joyce / Amstrad PCW (holt potentiell zahlende Kundschaft ins Boot)

    MSX (weil es da auch ein paar Leute gibt)






    edit1:

    ist jetzt nur eine wilde Idee. Aber evtl wäre es auch interessant einen Modus unterhalb von USB zu haben. Sowas, wo man mit einer 8bit Leitung eine Sektornummer hinschicken kann und dann kommen die 256 / 512 /1024 Bytes (je nach Format) zurück, die da drinstehen. Sowas ließe sich dann abseits von USB benutzen und auch an einem C64 oder (you name it) relativ generisch anschließen.


    Wäre dann sowas wie eine 1581 für Preisbewußte und vmtl ein echtes Haben-Will-Objekt für Viele.




    edit2:

    und wegen den kaputten Floppies. Mach eine Suchanzeige im Marktplatz. Das liest hier bestimmt nicht jeder, der sowas liegen hat.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

    Ich bin mir im Moment nicht sicher, ob ich nicht auf einen andere Mikrocontroller umsteige. Der STM32F103 hat "nur" 20K SRAM (Haha, verwoehnte Goeren, beim 8051 hatte man nur 256 Byte!). Wenn man allerdings einen kompletten Track cachen moechte (mit Vorder/und Rueckseite, weil der 82077 das mit einem READ Kommando kann), ist man bei 15 * 2* 512 Byte = 15K. Da ist man schon nicht mehr so weit weg mit USB Buffer, Stack & Co von 20K.


    Mit groesseren Diskettenformaten (mehr Sektoren) wird das dann noch mehr... Also vielleicht jetzt noch auf einen anderen (ARM) Mikrocontroller mit mehr RAM umsteigen, bevor es spaeter noch mehr Aufwand ist?


    Ein Raspberry PI Pico 2 hat wohl 520KB SRAM, wenn ich das richtig gelesen habe. Mit dem habe ich aber noch nie was gemacht, aber das kann sich ja aendern...

    Quote from Kuhrator

    Ich bin mir im Moment nicht sicher, ob ich nicht auf einen andere Mikrocontroller umsteige. Der STM32F103 hat "nur" 20K SRAM (Haha, verwoehnte Goeren, beim 8051 hatte man nur 256 Byte!). Wenn man allerdings einen kompletten Track cachen moechte (mit Vorder/und Rueckseite, weil der 82077 das mit einem READ Kommando kann), ist man bei 15 * 2* 512 Byte = 15K. Da ist man schon nicht mehr so weit weg mit USB Buffer, Stack & Co von 20K.


    Mit groesseren Diskettenformaten (mehr Sektoren) wird das dann noch mehr... Also vielleicht jetzt noch auf einen anderen (ARM) Mikrocontroller mit mehr RAM umsteigen, bevor es spaeter noch mehr Aufwand ist?


    Ein Raspberry PI Pico 2 hat wohl 520KB SRAM, wenn ich das richtig gelesen habe. Mit dem habe ich aber noch nie was gemacht, aber das kann sich ja aendern...

    Ich würde aber auch auf Preis und Verfügbarkeit achten. So ein Pico ist billig und überall verfügbar.

    ::solder::Ich "darf" beruflich basteln...

    Quote from 1ST1

    Auch die hochformatierten Varianten mit 10/11, 20/22 Sektoren, die manche PCs noch hinbekommen.

    1ST1


    wo findet man diese Formate mit 22 Sektoren, ich nehme an es sind 22 x 512 Byte auf HD 3.5" gemeint?

    Gibt es davon auch Kryoflux-raw Images? Würden mich interessieren, Zwecks Analyse der Trackaufteilung (Gaps, etc.). Die sind ja dort nicht standardmäßig, sonst geht es sich das ja nicht aus.


    PAW

    Quote from PAW

    22 x 512 Byte auf HD 3.5" gemeint?

    Stimmt, du hast recht, bei 1.2 MB HD haben nicht so viele Sektoren, die Disks drehen ja nicht mit 300, sondern 320 ,somit nur 16 und 17 Sektoren. (Und bei 3.5 Zoll 19 und 20), also entsprechend 1 oder Sektoren mehr. Das erreicht man zum einen durch verkleinern der Lücken zwischen den Sektoren, verkürzen der Sektorheaders und teils auch mit Interleave, weil damalige Floppycontroller bei derart verkürzten Strukturen nicht schnell genug waren, um sich auf den direkt folgenden Sektor einzustellen.

    1ST1

    Quote from Kuhrator

    320 Umdrehungen? Du meinst vermutlich 300 bzw. 360?


    Ich habe irgendwo gelesen, das XT und AT unterschiedliche Drehzahlen fuer DD (360K 5.25") Disketten hatten - kann das jemand bestaetigen?

    Kuhrator


    360 rpm ist richtig! 320 rpm sind mir bislang noch nicht untergekommen.


    Die Laufwerke im IBM XT hatten 300 rpm und konnten nur DD, mit 250kbit/s Datenrate bei MFM Modulation.


    Die Laufwerke im IBM AT waren HD und liefen immer mit 360 rpm. Damit sie die DD Disketten lesen konnten wurde der Controller auf 300kbit/s gesetzt. Das entspricht dann der Geschwindigkeit von 250 kbit/sec bei 300 rpm. HD hatte eine Übertragungsrate von 500 kbit/sec.


    Frage noch zu Deinem Projekt: in welcher Form möchtest Du die ausgelesenen Daten weiterverarbeiten? Als Binär-Datei trackweise oder die ganze Diskette in einer Datei oder wie bei ImageDisk & Co.?




    Quote from 1ST1

    Stimmt, du hast recht, bei 1.2 MB HD haben nicht so viele Sektoren, die Disks drehen ja nicht mit 300, sondern 320 ,somit nur 16 und 17 Sektoren. (Und bei 3.5 Zoll 19 und 20), also entsprechend 1 oder Sektoren mehr. Das erreicht man zum einen durch verkleinern der Lücken zwischen den Sektoren, verkürzen der Sektorheaders und teils auch mit Interleave, weil damalige Floppycontroller bei derart verkürzten Strukturen nicht schnell genug waren, um sich auf den direkt folgenden Sektor einzustellen.

    1ST1


    Das beantwortet nicht meine Frage. Die Lücken zwischen den Sektoren werden als Gaps bezeichnet und müssen natürlich kleiner sein, wenn mehr drauf passen soll. Die Frage ist halt nur wie klein? Sind sie zu klein, dann lassen sich die Daten der einzelnen Sektoren nicht mehr richtig in die formatierte Diskette eintragen. Schreibt dann womöglich in den nächsten Sektorheader.


    Die Frage war, ob Du ein System kennst, dass 22 x 512 Bytes verwendet? Und wenn ja, ob jemand davon Kryoflux raw-Images hat?


    PAW


    Ah, ok. Danke fuer die Erklaerung. Ich hatte sowas schon vermutet, als ich im Datasheet von 300 KBit gelesen hatte. War mir bisher nicht bewusst, als ich meinen ersten PC hatte (~1990) waren schon ueberall 3.5" Laufwerke drin, und 5 1/4 war eigentlich immer HD. Deshalb hatte ich mit 5.25" DD wenig zu tun. HP hat sowas aehnliches bei ihren HP 9122 Laufwerken gemacht: Die DD Disketten liefen urspruenglich mit 600 RPM. Um die mit normalen HD Laufwerken lesen/schreiben zu koennen, haben sie dann einfach die Datenrate angepasst...


    Die Daten moechte ich eigentlich gar nicht trackweise auslesen/schreiben - das soll nur eine 5.25" USB Floppy werden, die sich genauso wie die ganzen 0815 3.5" USB Floppies verhaelt. Also anstecken, Laufwerk erscheint, Dateien draufkopieren, fertig.


    Um Disketten sektor/track/flux weise auszulesen gibt es ja schon genug, siehe kryoflux, greazeweazel etc.

    Quote from PAW

    dann lassen sich die Daten der einzelnen Sektoren nicht mehr richtig in die formatierte Diskette eintragen. Schreibt dann womöglich in den nächsten Sektorheader.

    Deswegen haben die hochformatierten Disks mit 2 Sektoren mehr ja Interleave 2:1. Wobei bei HD evtl. ja sogar 4 Sektoren mehr gehen. Im Scheibenkleister wird das ziemlich genauj für 720kB-Laufwerke beschrieben, bei HD wurde das aber auch praktiziert.

    1ST1

    Quote from Kuhrator

    Die Daten moechte ich eigentlich gar nicht trackweise auslesen/schreiben - das soll nur eine 5.25" USB Floppy werden, die sich genauso wie die ganzen 0815 3.5" USB Floppies verhaelt. Also anstecken, Laufwerk erscheint, Dateien draufkopieren, fertig.

    Das hört sich einfach an, ist es aber meiner Meinung nach nicht. Dazu benötigst Du einen speziellen Windowstreiber (falls Du das in Windows einbinden willst), damit Du die Floppy über die USB-Schnittstelle als Laufwerk anzeigen kannst. Falls Du so einen Treiber zum Laufen bringst, wäre das auch für mein FLUXCOPY interessant.


    PAW

    Quote from PAW
    Quote from Kuhrator

    Die Daten moechte ich eigentlich gar nicht trackweise auslesen/schreiben - das soll nur eine 5.25" USB Floppy werden, die sich genauso wie die ganzen 0815 3.5" USB Floppies verhaelt. Also anstecken, Laufwerk erscheint, Dateien draufkopieren, fertig.

    Das hört sich einfach an, ist es aber meiner Meinung nach nicht. Dazu benötigst Du einen speziellen Windowstreiber (falls Du das in Windows einbinden willst), damit Du die Floppy über die USB-Schnittstelle als Laufwerk anzeigen kannst. Falls Du so einen Treiber zum Laufen bringst, wäre das auch für mein FLUXCOPY interessant.


    PAW

    Man kann sich's einfach machen. Wenn es nicht so wichtig ist, dass das Laufwerk als Floppy-Drive sichtbar ist, dann kann man das Laufwerk einfach als USB-Massenspeicher mit LBA exponieren. Spezielle Treiber auf der Windows-Seite braucht man dann nicht, das Laufwerk sieht dann einfach aus wie ein USB-Stick. Ein paar Sachen gehen dann natürlich nicht mehr.


    Die meisten billigen China-Floppies, die man derzeit kaufen kann, machen das auch so.

    Genau das ist mein Plan. Die Treiber sind unter allen gaengigen Betriebssystemen schon vorhanden, da USB Sticks genau das gleiche Protokoll verwenden.


    Unter Linux sieht das dann auch genau wie eine SCSI Festplatte aus, und unter Windows ist das nicht anders:

    Kuhrator


    Hört sich ja interessant an! Falls Du es zum Laufen bringst, lass es mich bitte wissen.


    PAW


    P.S. vielleicht magst Du diesen Dialog in einen eigenen Thread/Projekt auslagern lassen, damit das nicht verloren geht.

    Auslesen, formatieren, schreiben und verify mit WinImage sollte aber schon laufen...

    ::solder::Ich "darf" beruflich basteln...

    Kuhrator , was macht den ein "mount /dev/sda /mnt"? Das USB-Gerät muss doch erst mal nichts vom Dateisystem kennen. Das, was du ja schon selber sagtest, was wichtiger ist, das beim Formatieren die richtigen Parameter von deinem USB-Gerät verwendet werden...


    Mein 3,5"-Disk-USB-Laufwerk gibt sich auch als SCSI-Gerät zu erkennen: /dev/sdb ... da funktioniert ein "mount /dev/sdb /mnt" sofort.


    Ich würde mich für einen solchen USB-Adapter auch sofort melden... :) ...


    Frage: Könnte dein Adapter dann auch zwei oder mehr Laufwerke "händeln"?

    sudo mount /dev/sda /mnt funktioniert, ich habe das bisher nur nie gemacht, weil ich erstmal sektorweise vergleichen wollte was daraus kommt. Interessant ist, das Windows auch direkt auf die Floppy ohne Rueckfrage geschrieben hat - zumindestens ist das 'System Volume Information' wohl eher nicht von DOS :D


    Super, danke fuer's verschieben. Ich habe den Code mal auf github gepushed. Wie bereits am Anfang schon geschrieben, ist das im Moment mehr ein Proof-Of-Concept als richtiger Code. Der Code ist hier: https://github.com/svenschnelle/usbfloppy/tree/main


    Das interessante File ist main.c, dort steht am Anfang welche GPIO Pins an welche Pins vom 82077 gehen. Die 82077 Beschaltung ist 1:1 aus dem Datasheet.

    Alle anderen Floppyroutinen sind auch in main.c. Ich bin ab Dienstag erstmal zwei Wochen in Urlaub, danach wuerde ich dann mit Kicad mal eine Raspberry Pi Pico 2 Variante zeichnen, und hoffen, das die dann irgendwann verfuegbar sind.

    Super Idee und Gratulation zum Erfolg.


    Die Intel-FDC liegen hier auch rum. Bluepill muss ich wohl nachbestellen, oder warten auf den Pico ;)


    Den Code habe ich mir angeschaut, finde ich aber schwer nachzuvollziehen, da einfach alles in main.c drin ist, inklusive einer eigenen Version von printf() ;) Evnetuell könntest du das noch sinnvoll struktieren.

    Sun SPARCstation 5 Model 110 | DEC AlphaServer 300 Model 4/266
    Highscreen Tower 486DX-33 | Highscreen Indus 500ZE-90

    Commodore 64 | Commodore Amiga 500

    Ja, der Code ist grausam im Moment. Die ganzen fdc routinen wuerde ich in ein extra File packen, wenn ich das mit dem Pico nochmal implementiere. Der Grund fuer die eigene printf() (und andere libc Funktionen) ist, das dass binary mit mit der newlib libc vom arm-none-eabi-gcc ueber die 64KB gross war, und nicht mehr in den Flash gepasst hat. Und da printf() nicht wirklich kompliziert ist (zumindestens eine minimale Version), habe ich das erstmal selber implementiert.

    Quote from Pyewacket
    Quote from Toast_r

    Done. :)


    Großartiges Projekt! :thumbup:

    Da der 82077SL auch FM und 128 Byte Sektoren kann, hege ich die vage Hoffnung, daß daraus etwas erwachsen kann, mit dem noch viel mehr geht. :sabber:

    Ist der Chip noch regulär lieferbar oder nur noch als NOS erhältlich?

    Ich denke den gibt es nur noch NOS - ich habe ein paar bei ebay in Polen gekauft. Der PC8477 koennte auch gehen, sieht zumindestens Pinkomatibel aus.