Beiträge von Kuhrator

    Eine Implosion hatte ich nur einmal mit einer Combivion Bildröhre (31cm) hinbekommen. Einschuss mit dem Luftgewehr genau mittig von vorn. Nach vorn ist aber da nichts gross zu sehen gewesen, aber hinten sah es dann nicht ganz so gut aus. Bildröhre war übrigens schon vorher defekt und Zeilentrafo (ÜHA78) war schon raus. Würde ich aber wegen der Sauerei heute nicht mehr machen. Ging damals aber auch um die Frage der Gefahr bei Implosion.

    Gruß Jörg

    Das hätte ich ja gerne gesehen. 8o

    Sowas macht man als Fernsehtechniker doch eher selten. :D

    Noch ein kurzer Nachtrag von mir, falls nicht schon irgendwo geschrieben: Zum Entladen nehme ich immer das Masseband das um die Bildroehre geht (ueber den Graphitbelag der Bildroehre). Grund ist, das man das Massekabel vom Chassis abziehen kann. Wenn man dann das Chassis als Masse nimmt, entlaedt man die Bildroehre nicht, sondern hat auf dem Schraubendreher, der unter dem Anodenclip haengt ziemlich viele KV - je nach Geraet koennen das bis zu 20KV - 30KV sein.

    EDIT: bzgl Implosionen haette ich da wenig Angst - in meiner Fernsehtechnikerzeit habe ich es zweimal geschafft einen Bildroehrenhals abzubrechen, was nur ein kurzes lautes Zischen gibt. Bildroehre ist mir keine implodiert. Nur ein Kollege hat das mal geschafft, als er eine Bildroehere vorm Bauch getragen hat, die er nicht entladen hat. Hat dann mal nen Funken zum Bauch gegeben, und dreimal duerft ihr raten, was dann mit der Bildroehre passiert ist... Ist aber niemand dabei zu Schaden gekommen.

    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.

    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.

    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

    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:

    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.

    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...

    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.

    Waere es fuer die Besitzer der HP 9000 825/840 Systeme moeglich, die ganzen EPROMS auszulesen? Ich hab bisher HP 9000/300 in MAME eingebaut, sowie HP 9000/700 in QEMU so weit gebracht, das HP-UX mit X11 laeuft. So ein HP 9000 PA-RISC 1.0 System waere noch was - nur leider habe ich keinerlei Hardware, Doku bzw. Firmware um sowas in Angriff zu nehmen.

    Uff, dazu müsste ich den Rechner von der Wand fahren, was angesichts der ganzen Kabel nicht so einfach ist. Beim den CIO-Bus-Rechnern müsstest du aber auch die I/O-Karten emulieren, z.B. den MUX und den HP-IB-Controller. HW-Doku dazu gibt es keine.

    Ok, ich hatte die Hoffnung, das man die Karten vielleicht einfach rausziehen koennte. Aber wenn das aufwaendig ist, dann nicht. Wann ich dafuer Zeit haette ist ja auch noch eine andere Frage...

    Waere es fuer die Besitzer der HP 9000 825/840 Systeme moeglich, die ganzen EPROMS auszulesen? Ich hab bisher HP 9000/300 in MAME eingebaut, sowie HP 9000/700 in QEMU so weit gebracht, das HP-UX mit X11 laeuft. So ein HP 9000 PA-RISC 1.0 System waere noch was - nur leider habe ich keinerlei Hardware, Doku bzw. Firmware um sowas in Angriff zu nehmen.

    Ich waere da vorsichtig. Drezahlregeler geht gar nicht, da der wie schon beschrieben nicht die Spannung regelt, sondern Teile des Sinus wegschneidet.

    Aber auch mit Trenntrafo ist das nicht ohne. Es gibt einige Schaltnetzteilarten, die weniger Netzspannung mit mehr Stromaufnahme kompensieren. Das

    machen prinzipiell alle Schaltnetzteile, aber manche sehr extrem. D.h, das Netzteil laeuft schon bei weiter unter 100V los, zieht aber einen immensen Strom. Wenn man das laenger als ein paar Sekunden so betreibt, kann das durchaus zu Schaeden fuehren.

    Von daher entweder 100W Gluehlampe in Reihe, oder Mut zum Feuerwerk und einfach mit 230V einschalten. :evil:

    Ja, auf HPMUSEUM gibt es etliche Schaltplaene von Tony Duell, der hat sehr viel gezeichnet. Hat mir schon sehr oft geholfen, weil es da einige Schaltplaene von HP Geraeten gibt, die es sonst nirgends anders gibt...

    Habe gerade erst den anderen Thread gelesen, der am Anfang verlinkt ist. Haette ich vielleicht gleich machen sollen, dort habt ihr das Image ja schon komplett gebootet bekommen, und das Menu sieht besser aus als bei mir - dann ist die Onboard Grafik vielleicht doch anders, als die 98544. Oder ich mache irgendwas falsch beim starten. Aber ist dann ja auch nicht so wichtig :)

    So, auf meiner /340 mit HPDrive kann man das Image booten, allerdings muss dafuer die emulierte 9153C die GPIB ID 1 haben. Damit kann man dann auch ein paar Programme ausfuehren, sieht aber nicht wirklich viel ausser ein paar Rahmen. Ich vermute, das ich die falsche Grafikkarte habe. (98544, Monochrom.) Waere mal interessant, das mit einer 98550A zu testen, so eine habe ich aber nicht.

    Das klappt im Moment nicht, weil das original vermutlich mit einer GPIB Platte lief. MAME kann aber nur SCSI Platten emulieren. Dafuer ist in Pascal aber kein Treiber drin. Ich kann mal versuchen, das image mit HPDrive auf meiner echten 340 zu booten. Mal sehen, was da passiert. Wird aber erst heute Abend.

    EDIT: ok, das Image hat ja schon 9153C im Namen :)