Ich habe hier ein älteres HP 85053A Verification Kit. Das ist ein Satz von APC-3,5mm-Verifikationsstandards, um die Kalibrierung eines Vektor-Netzwerkanalysators zu prüfen. Das Kit enthält eine 7,5cm-Airline, einen so genannten Beatty-Standard und zwei präzise Abschwächer. Darüber hinaus enthält es drei 3.5"-DD-Disketten und ein Tape, welche die S-Parameter der Verfikationsstandards und entsprechende Unsicherheitsintervalle enthalten. Man vergleicht dann die S-Parameter auf den Disketten mit den an den Standards gemessenen zur Verifizierung. Gedacht ist das Kit insbesondere zur Verwendung mit einem HP 8510 VNA, der je nach Version ein 3.5"-Diskettenlaufwerk oder ein Tape-Laufwerk hat. Ich würde das Kit gern mit einem moderneren VNA verwenden und möchte daher die Disketten auslesen, um an die Daten zu kommen. Das Problem ist, dass keines meiner Diskettenlaufwerke mit den Disketten klarkommt. Probiert habe ich ein 3.5"-USB-Laufwerk, das anscheinend nur HD-Disketten frisst. Der VNA und mein Spektrumanalysator kommen mit den Disketten auch nicht klar. Ich bin mir nicht einmal sicher, ob die Disketten überhaupt DOS-Format (d.h. das 720kB-Format) haben. Soweit ich weiß, versteht z.B. der HP 8510C auch Disketten im 622kB-LIF-Format, das mit den HP 9000-Rechnern verwendet wurde. Ob die Disketten überhaupt noch lesbar sind, weiß ich natürlich auch nicht. Ein Tape-Laufwerk habe ich ebenso wenig. Was mache ich nun am besten? Einen alten Rechner mit einem 3.5"-DD-Laufwerk habe ich nicht. Gibt es billige USB-Laufwerke, die mit DD-Disketten klar kommen? Gibt es eine Möglichkeit, LIF-Disketten mit einem modernen Windows-PC zu lesen? Ich kenne die HP LIF-Utilities, die funktionieren aber m.W. nur auf historischer Hardware.
Mario H. schrieb: > Was mache ich nun am besten? Einen alten Rechner mit einem > 3.5"-DD-Laufwerk habe ich nicht. Versuch' auf ePay einen ollen Amiga mit funktionsfähigem Floppylaufwerk aufzutreiben. Flexiblere Hardware zum Floppy-Auslesen wirst du nicht finden, jedenfalls nicht für vergleichbares Geld. Ach ja: Programmieren solltest du schon können, sonst wirst du mit der Hardware wenig bis nichts anfangen können.
Du könntest ein 3.5"-Floppy an einen FPGA anschließen und damit die Rohdaten über den Shugart-Bus von dem Floppy lesen. Hier wird sowas gemacht: https://github.com/whitequark/Glasgow/tree/master/software/glasgow/applet/memory/floppy Die Glasgow-Hardware ist momentan leider noch in Entwicklung, wird wohl noch ein paar Monate dauern bis man den fertig kaufen kann. Wenn Du die Rohdaten hast, bräuchtest Du natürlich noch ein paar Infos über das konkret verwendete Diskettenformat um dann einen Konverter schreiben zu können.
:
Bearbeitet durch User
Mario H. schrieb: > enthält es drei 3.5"-DD-Disketten Es gibt einige exotische Diskettenformate. Hoffentlich ist es keins davon. Ein Versuch wäre, diese Disketten mit dem bekannten VGACOPY mal zu lesen um herauszufinden ob sie unter DOS überhaupt (noch) lesbar sind. https://moenk.de/pages/vgacopy.html
winzip schrieb: > Ein Versuch wäre, diese Disketten mit dem bekannten VGACOPY mal > zu lesen um herauszufinden ob sie unter DOS überhaupt (noch) lesbar > sind. Das setzt aber voraus, daß ein PC-Diskettencontroller mit denen überhaupt etwas anfangen kann. Die Sache mit dem LIF-Format etc. lässt mich daran etwas zweifeln.
Mario H. schrieb: > Ich kenne die HP LIF-Utilities, die funktionieren aber m.W. nur auf > historischer Hardware. War es nicht eher historische Software (MS-DOS)? Ich habe vor geraumer Zeit mal HP-LIF-Disketten gelesen … ich glaube, ich habe es tatsächlich unter DOS auf meinem alten Toshiba Libretto getan. (Wenn du willst, könnte ich das auch für dich versuchen, da kommt halt nur das Transportrisiko dazu, dass die Disketten dabei irgendwie beschädigt werden.) Alternativ auf irgendeinem unixoiden System einen Dump davon machen und dann ein DOS in einer VM starten und diesem das Floppy-Image mitgeben.
c-hater schrieb: > Flexiblere Hardware zum Floppy-Auslesen wirst du nicht finden, jedenfalls > nicht für vergleichbares Geld. Einen alternativen Kandidaten gäbe es schon, nämlich Kryoflux. Das ist ein USB-Diskettencontroller, der so ziemlich alles lesen kann, was man ihm vorwirft - man braucht nur ein funktionierendes Diskettenlaufwerk. Kryoflux kann auch GCR-Disketten lesen. Die Software kann ein "Roh-Image" der Diskette lesen, aus dem sich später (ohne die Diskette erneut lesen zu müssen) die Nutzdaten extrahieren lassen, auch wenn beim Erzeugen des "Roh-Images" Details wie Sektorgröße, -Anzahl oder auch Schreibdichte unbekannt sind. Dafür ist so ein "Roh-Image" erheblich größer als die Nutzdaten - knapp 40 MByte für eine doppelseitige 80-Spur-Diskette sind durchaus "drin".
Jörg W. schrieb: > War es nicht eher historische Software (MS-DOS)? Leider eher nicht, ich habe eine HP-Protokoll-Analysator, da waren ebensolche exotischen Disketten mit Zusatzprogrammen dabei. Die kann ich auch auf einem 486er-System mit MSDOS nicht lesen (Sektor not found). Da hilft wahrscheinlich auch keine unter DOS laufende Software wie z.B. die zum Lesen von CP/M-Floppies, Sektoren müssen schon sein. Was auch immer auf den HP-Disketten steht, die Dateinamen aus dem Handbuch sind auch nicht im 8.3-Format, sondern länger. Ich könnte zwar mit eigener Z80-Hardware einen ganzen Track als Roh-Datei auslesen, habe ich auch schon gemacht (vor langer Zeit), aber das hilft ja auch nicht weiter. Laut Handbuch wird empfohlen, die Disketten zur Sicherheit zu duplizieren, und das geht nur mit der eingebauten Routine "Copy Disk". Sowas wird beim Gerät des TO auch eingebaut sein, dann hat er wenigstens eine Sicherheitskopie, auch wenn die nirgends hin transportierbar ist. Georg
Zunächst vielen herzlichen Dank für die zahlreichen Anregungen. Rufus Τ. F. schrieb: > Einen alternativen Kandidaten gäbe es schon, nämlich Kryoflux. Der Kryoflux-Controller sieht wirklich interessant aus, und hätte gegenüber einem Amiga den Vorteil, nicht in die Systemprogrammierung dieses Schätzchens einsteigen zu müssen. Jörg W. schrieb: > Ich habe vor geraumer Zeit mal HP-LIF-Disketten gelesen … ich glaube, > ich habe es tatsächlich unter DOS auf meinem alten Toshiba Libretto > getan. (Wenn du willst, könnte ich das auch für dich versuchen, da kommt > halt nur das Transportrisiko dazu, dass die Disketten dabei irgendwie > beschädigt werden.) Vielen Dank für das Angebot, das ist wirklich sehr nett von Dir. Da das Transportrisiko überschaubar erscheint, wäre das einen Versuch wert. Ob die Disketten allerdings tatsächlich LIF-Format haben, kann ich nicht sagen. Das Handbuch zu dem Kit, das es bei Keysight zum Download gibt, ist uralt. Da ist nur von dem Tape die Rede. Und die HP 8510B/C können offenbar sowohl DOS als auch LIF lesen und schreiben.
georg schrieb: > Die kann ich auch auf einem 486er-System mit MSDOS nicht lesen (Sektor > not found). So extrem habe ich das nicht in Erinnerung. Hier gibt's ein paar Hintergründe über LIF: http://www.hp9845.net/9845/projects/hpdir/ Angeblich sollen HP-UX mit Floppylaufwerk mit diesen Floppys umgehen können: mit sowas könnte ich (in Form eine HP 1670x Logic Analyzers) auch noch dienen.
Rufus Τ. F. schrieb: > c-hater schrieb: >> Flexiblere Hardware zum Floppy-Auslesen wirst du nicht finden, jedenfalls >> nicht für vergleichbares Geld. > > Einen alternativen Kandidaten gäbe es schon, nämlich Kryoflux. Du hast da wohl den Preisapekt etwas aus den Augen verloren. Einen funktionsfähigen Amiga500 kannst du für 30..60 Euro bei ePay schießen und hast dann ein funktionsfähiges Computersystem samt aller nötigen Hardware. Kryoflux kostet allein das Board schon einen guten Hunni, dazu Laufwerk, Kabel usw... Und Programmieren muß man wohl für so ein Exotenformat in beiden Fällen, also auch hier kein echter Vorteil erkennbar. Wenn's mein Problem wäre, würde ich ganz klar die Amiga-Lösung bevorzugen.
Mario H. schrieb: > Der Kryoflux-Controller sieht wirklich interessant aus, und hätte > gegenüber einem Amiga den Vorteil, nicht in die Systemprogrammierung > dieses Schätzchens einsteigen zu müssen. Brauchst du nicht. Der Amiga ist einerseits einfach genug gestrickt und andererseits umfassend dokumentiert, so dass man ihn ziemlich problemlos "bare metal" programmieren kann. D.h.: Der Code zur Erlangung eines Image und zum Transfer dieses Image auf heutiges Rechengerät z.B. via UART würde wohl weniger als 200..300 Zeilen Assembler ausmachen.
Mario H. schrieb: > Was mache ich nun am besten? Einen alten Rechner mit einem > 3.5"-DD-Laufwerk habe ich nicht. Ach? Du hantierst mit einem Netzwerkanalysator und scheiterst an der Beschaffung eines Floppy. So alt muß ja ein Rechner nicht sein. Falls er kein Floppy mehr hat, so ist oft noch ein Stecker auf dem MB vorhanden. Bis vor 10 Jahren war das üblich.
georg schrieb: > Die kann ich auch auf einem 486er-System mit MSDOS nicht lesen (Sektor > not found). Da hilft wahrscheinlich auch keine unter DOS laufende > Software wie z.B. die zum Lesen von CP/M-Floppies, Sektoren müssen schon > sein. Sektoren werden auf den Disketten schon drauf sein, nur wenn diese eine andere Größe haben als die Software erwartet, kann es zu derartigen Fehlern kommen. c-hater schrieb: > Einen funktionsfähigen Amiga500 kannst du für 30..60 Euro bei ePay > schießen und hast dann ein funktionsfähiges Computersystem samt aller > nötigen Hardware. Das ist natürlich ein Argument ... > D.h.: Der Code zur Erlangung eines Image und zum Transfer dieses Image > auf heutiges Rechengerät z.B. via UART würde wohl weniger als 200..300 > Zeilen Assembler ausmachen. das Du hiermit komplett ins absurde verkehrst.
Ich habe noch einen funktionstüchtigen DOS-Rechner, auf dem sich SCOPY befindet. Damit kann man einige Floppy-Formate lesen. Ob das Passende dabei ist, weiß ich aber nicht. Das hier sieht ähnlich aus: http://www.mpm-kc85.de/html/SCopy.htm Gruß, WIRO
Die Disketten sind mittlerweile bei mir aufgeschlagen. Erstmal, die LIF utilities auf HP-UX sind der Meinung, dass es sich nicht um LIF-Medien handelt. Schade, wäre zu einfach gewesen (die Tools dafür sind dort wirklich alle da). Also mal ins FreeBSD reingeworfen. Davon abgesehen, dass es eine ganze Reihe von Lesefehlern gibt, was mich besonders stutzig macht: das Diskettenformat kennt keine Sektornummer 1 auf jeder Spur. Wenn ich die Sektor-IDs auslese, bekomme ich:
1 | uncle# fdread -I 26 -t 5 |
2 | C = 2, H = 1, R = 6, N = 1 |
3 | C = 2, H = 1, R = 14, N = 1 |
4 | C = 2, H = 1, R = 7, N = 1 |
5 | C = 2, H = 1, R = 15, N = 1 |
6 | C = 2, H = 1, R = 8, N = 1 |
7 | C = 2, H = 1, R = 16, N = 1 |
8 | C = 2, H = 1, R = 2, N = 1 |
9 | C = 2, H = 1, R = 10, N = 1 |
10 | C = 2, H = 1, R = 3, N = 1 |
11 | C = 2, H = 1, R = 11, N = 1 |
12 | C = 2, H = 1, R = 4, N = 1 |
13 | C = 2, H = 1, R = 5, N = 1 |
14 | C = 2, H = 1, R = 13, N = 1 |
15 | C = 2, H = 1, R = 6, N = 1 |
16 | C = 2, H = 1, R = 14, N = 1 |
17 | C = 2, H = 1, R = 7, N = 1 |
18 | C = 2, H = 1, R = 15, N = 1 |
19 | C = 2, H = 1, R = 10, N = 1 |
20 | C = 2, H = 1, R = 3, N = 1 |
21 | C = 2, H = 1, R = 5, N = 1 |
22 | C = 2, H = 1, R = 6, N = 1 |
23 | C = 2, H = 1, R = 14, N = 1 |
24 | C = 2, H = 1, R = 15, N = 1 |
25 | C = 2, H = 1, R = 16, N = 1 |
26 | C = 2, H = 1, R = 2, N = 1 |
27 | C = 2, H = 1, R = 10, N = 1 |
(N = 1 heißt, dass es mit 256 Byte / Sektor formatiert ist. C = 2 und H = 1 passt zur gewünschten Spur 5.) Es sind also Sektornummern 2 bis 16 vertreten – aber keine 1! Kommt das jemandem bekannt vor? Der Anfang einer Floppy sieht so aus:
1 | 00000000 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 |................| |
2 | * |
3 | 00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
4 | * |
5 | 00000200 4d 41 5f 46 49 4c 45 31 20 20 00 01 00 00 00 22 |MA_FILE1 ....."| |
6 | 00000210 00 00 00 80 08 01 25 22 23 10 80 01 00 00 00 00 |......%"#.......| |
7 | 00000220 44 4d 5f 46 49 4c 45 31 20 20 00 01 00 00 00 a2 |DM_FILE1 ......| |
8 | 00000230 00 00 00 20 08 01 25 22 23 16 80 01 00 00 00 00 |... ..%"#.......| |
9 | 00000240 4d 41 5f 46 49 4c 45 32 20 20 00 01 00 00 00 c2 |MA_FILE2 ......| |
10 | 00000250 00 00 00 80 08 01 25 22 24 42 80 01 00 00 00 00 |......%"$B......| |
11 | 00000260 44 4d 5f 46 49 4c 45 32 20 20 00 01 00 00 01 42 |DM_FILE2 .....B| |
12 | 00000270 00 00 00 20 08 01 25 22 24 49 80 01 00 00 00 00 |... ..%"$I......| |
13 | 00000280 4d 41 5f 46 49 4c 45 33 20 20 00 01 00 00 01 62 |MA_FILE3 .....b| |
14 | 00000290 00 00 00 80 08 01 25 22 26 17 80 01 00 00 00 00 |......%"&.......| |
15 | 000002a0 44 4d 5f 46 49 4c 45 33 20 20 00 01 00 00 01 e2 |DM_FILE3 ......| |
16 | 000002b0 00 00 00 20 08 01 25 22 26 24 80 01 00 00 00 00 |... ..%"&$......| |
17 | 000002c0 4d 41 5f 46 49 4c 45 34 20 20 00 01 00 00 02 02 |MA_FILE4 ......| |
18 | 000002d0 00 00 00 80 08 01 25 22 27 45 80 01 00 00 00 00 |......%"'E......| |
19 | 000002e0 44 4d 5f 46 49 4c 45 34 20 20 00 01 00 00 02 82 |DM_FILE4 ......| |
20 | 000002f0 00 00 00 20 08 01 25 22 27 52 80 01 00 00 00 00 |... ..%"'R......| |
21 | 00000300 00 00 00 00 00 00 00 00 00 00 ff ff 00 00 00 00 |................| |
22 | 00000310 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
23 | * |
24 | 00002000 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 f0 |................| |
25 | * |
26 | 00002100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
27 | * |
(Die 0xf0 im ersten Sektor sind synthetisiert, weil der sich ja nicht lesen lässt.) Was mich etwas stutzig macht ist, dass das jeweils 11. Byte des Dateinamens nicht mehr ASCII ist, sondern 0x00. Das spricht meiner Meinung nach gegen FAT, aber auch gegen CP/M. LIF müsste ich mir dahingehend nochmal ansehen, die Infos dazu sind nicht reichlich.
:
Bearbeitet durch Moderator
OK, bisschen was gefunden: http://www.hp9845.net/9845/projects/hpdir/ Demnach wird es schon LIF sein, 10 Zeichen lange Dateinamen passen. Die lifutils legen auch freiwillig Disketten mit 256-Byte-Sektorierung an, aber warum zum Geier™ fehlt konsequent auf jeder Spur Sektor #1? Habe noch einen 20 Jahre alten Laptop gefunden, auf dem die lifutils laufen (auf dem Libretto sind sie der Meinung, er hätte kein Flopppylaufwerk), aber direkt lesen sie Marios Floppies auch nicht.
Jörg W. schrieb: > aber warum zum Geier™ fehlt konsequent auf jeder Spur Sektor #1? Ich würde auf einen Kopierschutz auf dem Niveau des damals "hinreichenden" tippen. Willkürliche Verwürfelungen des Sektors waren Standardtricks, inbesondere solche, die gerade den "ersten" Sektor eines Tracks eliminierten. Sprich: der Trick wird wahrscheinlich sein, das korrekte Mapping zwischen den gelesenen und den logisch korrekten Sektornummern zu ermitteln. Mit ein wenig Glück ist es nur eine simple Verschiebung um eins. Es könnte aber auch etwas "intelligenteres" sein. Oft wurde das Schema der Verwürfelung auch noch von der Tracknummer abhängig gemacht. Letzlich: reine Fleißarbeit. Erzeuge alle möglichen Images (Zahl und Umfang ist hier noch überschaubar) und finde einen Weg, deren Nutzdaten automatisiert zu bewerten. Das geht natürlich umso schneller und effizienter, je mehr man über die Struktur der Nutzdaten weiss. Da die Typen damals im Umfeld knapper Ressourcen agieren mussten, kann man oft erfolgreich von der Vermutung ausgehen, dass nur der Disk-Treiber manipuliert wurde, das Filesystem aber dem Systemstandard entspricht. So würde ich jedenfalls erstmal ansetzen, wenn es mein Problem wäre...
c-hater schrieb: > Jörg W. schrieb: > >> aber warum zum Geier™ fehlt konsequent auf jeder Spur Sektor #1? > > Ich würde auf einen Kopierschutz auf dem Niveau des damals > "hinreichenden" tippen. Für irgendwelche Spiele kenne ich das – aber warum sollten HP-Messgeräte so einen Quatsch machen? Als sich aber auch 08/15-720-KB-Medien mit fehlenden Sektor 1 meldeten, habe ich nun mal das Laufwerk getauscht. Jetzt sieht das schon besser aus … die erste Floppy läuft zumindest bis ca. 500 KB durch, danach bringt sie durchaus „zeitgemäße“ Fehler (CRC, fehlende Adressmarken, …).
Interessant wäre es, so eine Diskette mal dem Kryoflux-Dingen vorzuwerfen. Vielleicht ist ja nur der Sektorheader "seltsam", und bringt den verwendeten FDC durcheinander. Jörg W. schrieb: > Als sich aber auch 08/15-720-KB-Medien mit fehlenden Sektor 1 meldeten, > habe ich nun mal das Laufwerk getauscht. Hmm. Kann man bei 3.5"-Laufwerken den Sensor zum Erzeugen des Indexpulses dejustieren? Anders als bei 5.25"-Disketten, wo das einfach ein Loch in der Diskette ist, ist das bei 3.5"-Laufwerken an den Spindelmotor gekoppelt, der ja mit seinem Mitnehmer definiert in den Blechkern der Diskette eingreift. Und je nach Ausführung des Sensors (Lichtschranke oder Hall-Sensor) wird das was sein, was bei der Herstellung irgendwie justiert werden muss. Ich könnte mir vorstellen, daß der verwendete FDC irritiert ist, wenn der Indeximpuls zu kurz vor Sektor 0 oder gar erst während seines Anfangs kommt.
Rufus Τ. F. schrieb: > Kann man bei 3.5"-Laufwerken den Sensor zum Erzeugen des Indexpulses > dejustieren? Keine Ahnung. Muss mir das Laufwerk vielleicht mal ansehen. Plausibel wäre die Erklärung ja zumindest.
Rufus Τ. F. schrieb: > Hmm. Kann man bei 3.5"-Laufwerken den Sensor zum Erzeugen des > Indexpulses dejustieren? Nö, sowas hab ich noch nie gesehen. Is einfach nur ein winziges Magnet am Motor und eine Spule auf der Platine.
Jörg W. schrieb: > Für irgendwelche Spiele kenne ich das – aber warum sollten HP-Messgeräte > so einen Quatsch machen? Weil auch bei HP oft Leute über Sachen entschieden haben, die einfach mal keine Ahnung haben, wäre das zumindest ein denkbare Möglichkeit. Stichwort: Vendor-LockIn. Und wenn es damals nur darum ging, die Verkaufschancen für irgendwelches Zubehör-Gebabel zu verbessern, wäre das für solche Wichser ein hinreichender und wichtiger Grund gewesen, solche Scheisse zu machen. Mein Gott, selbst heute noch trifft man sehr regelmäßig auf solchen Kram... Selbst in diesem Forum entblöden sich heute noch regelmäßig irgendwelche Idioten, die solche Konzepte verfolgen. Nur sind sie heute sogar dazu zu blöd dazu, sich alleine was auszudenken, wollen statt dessen irgendwelche "Libs", die das für sie erledigen, natürlich für lau... > Als sich aber auch 08/15-720-KB-Medien mit fehlenden Sektor 1 meldeten, > habe ich nun mal das Laufwerk getauscht. Jetzt sieht das schon besser > aus Naja, kaputte Hardware ist natürlich ebenfalls möglich. Bei dem, was du geposted hast, würde ich aber trotzdem erstmal bei meinem Ansatz bleiben. Zumindest solange, bis du einen vergleichbaren Dump, gewonnen mit der neuen Hardware geposted hast. Dann kann man weiter sehen...
c-hater schrieb: > Zumindest solange, bis du einen vergleichbaren Dump, gewonnen mit der > neuen Hardware geposted hast. Die neuen Dumps lassen sich durch die auf Github zu findenden lifutils zumindest lesen – bis auf das Ende von einer der drei Disketten, da scheint in der Tat ab Zylinder 66 der Record #7 Probleme zu bereiten. Das wäre durchaus nach 10 Jahren (die Daten scheinen von 2008 zu sein) kein so ungewöhnlicher Fehler.
Jörg W. schrieb: > Die neuen Dumps lassen sich durch die auf Github zu findenden lifutils > zumindest lesen Ausgabe von fdread -I 26 -t 5 wie im Vorposting (bloß halt mit der neuen Hardware) magst du nicht zeigen? > – bis auf das Ende von einer der drei Disketten, da > scheint in der Tat ab Zylinder 66 der Record #7 Probleme zu bereiten. > Das wäre durchaus nach 10 Jahren (die Daten scheinen von 2008 zu sein) > kein so ungewöhnlicher Fehler. Nö, natürlich nicht. Mit echten Schäden des Mediums muss man bei solchen Sachen natürlich immer rechnen. Aber: selbst das kann "Kopierschutz" sein. Auch nicht gerade ungewöhnlich, dass die Anwesenheit eines Lesefehlers an einer bestimmten Stelle des Mediums der Kopierschutz ist...
c-hater schrieb: >> Die neuen Dumps lassen sich durch die auf Github zu findenden lifutils >> zumindest lesen > > Ausgabe von fdread -I 26 -t 5 wie im Vorposting (bloß halt mit der neuen > Hardware) magst du nicht zeigen? uncle# fdread -I 30 C = 0, H = 0, R = 8, N = 1 C = 0, H = 0, R = 9, N = 1 C = 0, H = 0, R = 10, N = 1 C = 0, H = 0, R = 3, N = 1 C = 0, H = 0, R = 11, N = 1 C = 0, H = 0, R = 12, N = 1 C = 0, H = 0, R = 13, N = 1 C = 0, H = 0, R = 6, N = 1 C = 0, H = 0, R = 7, N = 1 C = 0, H = 0, R = 15, N = 1 C = 0, H = 0, R = 16, N = 1 C = 0, H = 0, R = 9, N = 1 C = 0, H = 0, R = 10, N = 1 C = 0, H = 0, R = 11, N = 1 C = 0, H = 0, R = 5, N = 1 C = 0, H = 0, R = 13, N = 1 C = 0, H = 0, R = 6, N = 1 C = 0, H = 0, R = 7, N = 1 C = 0, H = 0, R = 15, N = 1 C = 0, H = 0, R = 8, N = 1 C = 0, H = 0, R = 16, N = 1 C = 0, H = 0, R = 1, N = 1 C = 0, H = 0, R = 9, N = 1 C = 0, H = 0, R = 10, N = 1 C = 0, H = 0, R = 3, N = 1 C = 0, H = 0, R = 11, N = 1 C = 0, H = 0, R = 6, N = 1 C = 0, H = 0, R = 7, N = 1 C = 0, H = 0, R = 15, N = 1 C = 0, H = 0, R = 8, N = 1 Ist "nur" Spur 0 diesmal – und jetzt ist die Kiste schon wieder ausgeschaltet. Ist nur mein Bastelrechner. Das da oben stand noch im Scrollback buffer des Terminals. Interleaving 1:1 scheint bei LIF Standard gewesen zu sein (die DOS-Lifutils bieten das auch als Voreinstellung an). > Nö, natürlich nicht. Mit echten Schäden des Mediums muss man bei solchen > Sachen natürlich immer rechnen. Aber: selbst das kann "Kopierschutz" > sein. Auch nicht gerade ungewöhnlich, dass die Anwesenheit eines > Lesefehlers an einer bestimmten Stelle des Mediums der Kopierschutz > ist... Zwei der drei Floppies lassen sich ja problemlos bis zu Ende lesen.
Jörg W. schrieb: > habe ich nun mal das Laufwerk getauscht ggf. bringt ja auch ein reines 3.5"-DD-Laufwerk (720kb) dann noch den Rest?
Jörg W. schrieb: >> Ausgabe von fdread -I 26 -t 5 wie im Vorposting (bloß halt mit der neuen >> Hardware) magst du nicht zeigen? > > uncle# fdread -I 30 Hallo?! Ich bin ziemlich sicher, dass dir vollkommen klar ist, dass das völlig nutzlos war. Damit irgendein Erkenntnisgewinn wenigstens theoretisch möglich sein könnte, muss natürlich so viel wie möglich konstant bleiben. Insbesondere natürlich: gleiche Aufrufparameter und gleiches Medium... Beides ist nicht der Fall, dein Posting ist also ungefähr genauso nützlich wie Sackratten. Verarschen kann ich mich alleine...
c-hater schrieb: >> Für irgendwelche Spiele kenne ich das – aber warum sollten HP-Messgeräte >> so einen Quatsch machen? > > Weil auch bei HP oft Leute über Sachen entschieden haben, die einfach > mal keine Ahnung haben, wäre das zumindest ein denkbare Möglichkeit. > Stichwort: Vendor-LockIn. Und wenn es damals nur darum ging, die > Verkaufschancen für irgendwelches Zubehör-Gebabel zu verbessern, wäre > das für solche Wichser ein hinreichender und wichtiger Grund gewesen, > solche Scheisse zu machen. Die Daten auf den Disketten sind spezifisch für das Verifikationskit, und werden im Werk individuell ausgemessen. Auf den Disketten stehen deswegen auch die Seriennummern der Verifikationsstandards. Ein Kopierschutz wäre hier reichlich sinnlos. Außerdem ist das exotisches und ziemlich teures Hochfrequenz-Zeug. Aber wer weiß...
@TO Um LIF Disketten zu lesen brauchst Du die Lifutils von HP und einen PC der noch ein echtes Diskettenlaufwerk hat, also nicht so einen USB-Kram. Betriebssystem max. Windows 98. Es gibt auch noch eine andere Kopiersoftware (Name fällt mir gerade nicht ein), aber die braucht auch einen PC mit echtem Floppy und BS nicht höher als Win98. Weitere Möglichkeit wäre ein HP218 oder HP300'er Rechner, die können die Diskette direkt lesen. Dritte Möglichkeit wäre ein Rechnersystem mit HP Unix. Unter HP Unix gibt es Befehle mit denen man auf solche Disketten zugreifen kann. Da gibt es die Befehle lifls und lifcp. Wo wohnst Du denn? Ich hätte alle 3 Möglichkeiten zur Verfügung. Kennst Du jemanden der mit Zeiss Messmaschinen arbeitet? Wenn ja und er noch die Messsoftware UMESS300 oder UMESS-UX benutzt hast Du sehr gute Karten Deine Disketten auszulesen.
c-hater schrieb: > Ich bin ziemlich sicher, dass dir vollkommen klar ist, dass das völlig > nutzlos war. Ich bin mir ziemlich sicher, dass du dich einfach hoffnungslos im Ton vergriffen hast. Aber falls es dir bislang noch nicht klar geworden ist: das Problem hat sich erledigt. Ganz ohne irgendwelchen Kopierschutz etc. Zeno schrieb: > Um LIF Disketten zu lesen brauchst Du die Lifutils von HP und einen PC > der noch ein echtes Diskettenlaufwerk hat, also nicht so einen USB-Kram. Genau das habe ich versucht, ebenso HP-UX. Hat beides nicht funktioniert – wobei mir nicht mehr genau klar ist, wie man einem HP-UX beibringt, dass die Disketten mit 16 Sektoren pro Spur zu je 256 Byte formatiert sind. Vielleicht hätte es ja sonst geklappt. Aber auch für dich nochmal: mittlerweile sind die Disketten gelesen, der TO muss sich nun „nur noch“ aufmachen, die interessanten Informationen aus den enthaltenen Dateien zu gewinnen. Wilfried P. schrieb: > ggf. bringt ja auch ein reines 3.5"-DD-Laufwerk (720kb) dann > noch den Rest? Da wäre nur die Frage, woher man sowas bekommt. Reine DD-Laufwerke bei 5.25" waren ja lange Zeit gängig, bei 3.5" kam aber schon kurz danach HD auf. Ich kann mich nicht daran erinnern, jemals ein reines DD-Laufwerk dafür besessen zu haben.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Ich kann mich nicht daran erinnern, jemals ein reines DD-Laufwerk dafür > besessen zu haben. Ich habe noch eins, das hat mal richtig viel Geld gekostet - ein FD1035 von NEC. Ist 1.6" hoch - und hat noch einen Kopflademagneten. Allerdings wüsste ich nicht, welchen hier relevanten Unterschied man zwischen einem "HD"- und einem "DD"-Laufwerk entdecken will. Anders sieht es aus, wenn man Disketten begegnet, die mit einem 40-Spur-Laufwerk beschrieben wurden - so etwas gab es tatsächlich auch bei 3.5"-Laufwerken, zum Glück noch seltener als einseitige Laufwerke (deren Disketten bei modernen Laufwerken keine Probleme verursachen).
Jörg W. schrieb: > Genau das habe ich versucht, ebenso HP-UX. Hat beides nicht funktioniert > – wobei mir nicht mehr genau klar ist, wie man einem HP-UX beibringt, > dass die Disketten mit 16 Sektoren pro Spur zu je 256 Byte formatiert > sind. Vielleicht hätte es ja sonst geklappt. Ich meine mich erinnern zu können, das es darauf ankommt das richtige Devicefile anzugeben. Da gab es verschiedene Varianten in Abhängigkeit vom Diskettenformat. Müßte ich aber auch noch mal nach lesen. Ansonsten hätte ich auch noch einen alten HP gehabt der ausschließlich mit diesen Disketten arbeitet. Habe auch verschiedene Floppylaufwerke dazu. Aber wenn es gelöst ist, dann ist ja alles gut.
Jörg W. schrieb: > Ich kann mich nicht daran erinnern, jemals ein reines DD-Laufwerk > dafür besessen zu haben. Rufus Τ. F. schrieb: > so etwas gab es tatsächlich auch > bei 3.5"-Laufwerken, zum Glück noch seltener als einseitige Laufwerke ?-O KA, wie oft hab ich zu ´386/´486er Zeiten, Kollegen aus der Patsche geholfen habe, weil sie verzweifelt versuchten mit einer HD-Diskette, Daten von einem ´386er (DD-Laufwerk) auf einen ´486er (HD-L) zu transportieren. War immer lustig, da so ganz cold, ein Tape übers HD-Loch zu kleben. :)
Teo D. schrieb: > weil sie verzweifelt versuchten mit einer HD-Diskette, Daten von einem > ´386er (DD-Laufwerk) auf einen ´486er (HD-L) zu transportieren. 3.5"-DD-Laufwerke waren in PCs aber ziemlich ungebräuchlich. So etwas gab es AFAIK nur kurze Zeit im PS/2 Model 25 und 30 (und die waren keine '386, sondern nur marginal aufgemotze XTs mit einem 8086). Alle anderen 3.5"-Laufwerke waren HD-Laufwerke, und das auch schon deutlich vor '486er-Zeiten. ATs (also 286er) wurden zwar lange Zeit nicht mit den Dingern ausgeliefert, sie konnten sie aber ansteuern. Nur XTs (und die noch älteren PCs) hatten Floppycontroller, die keine HD-Laufwerke (egal, welche Bauform) ansteuern konnten. Ich kann mich jetzt nicht mehr genau daran erinnern, wann mir das erste 3.5"-HD-Laufwerk untergekommen ist, aber das muss um 1990 gewesen sein. (Mein FD1035 hingegen hat 1986 gnadenlose 280 DM gekostet, berücksichtigt man die Inflationsrate, dürfte das der Kaufkraft von etwa 300 EUR entsprechen). Konvertierungsprobleme gab es, wenn man mit einem 80-Spur-Laufwerk eine 40-Spur-Diskette beschreiben und diese mit einem echten 40-Spur-Laufwerk lesen wollte. Aber das ist eine andere Geschichte.
Rufus Τ. F. schrieb: > Konvertierungsprobleme gab es, wenn man mit einem 80-Spur-Laufwerk eine > 40-Spur-Diskette beschreiben und diese mit einem echten 40-Spur-Laufwerk > lesen wollte Ja, da waren die Köpfe unterschiedlich breit. Und dafür hat noch niemand eine Umschaltung erfunden. Georg
georg schrieb: > Und dafür hat noch niemand eine Umschaltung erfunden. Glücklicherweise braucht man die auch nicht mehr; Diskettenlaufwerke sind in der praktischen Anwendung doch recht rar geworden.
Rufus Τ. F. schrieb: > Ich kann mich jetzt nicht mehr genau daran erinnern, wann mir das erste > 3.5"-HD-Laufwerk untergekommen ist, aber das muss um 1990 gewesen sein. Mein erster 80286-PC von 1990 hatte je ein HD-Laufwerk 5.25" und 3.5". Da muss das also schon "state of the art" gewesen sein. Dass manche Leute 3.5"-Medien, die nur als DD deklariert waren, im wahrsten Sinne des Wortes "aufgebohrt" haben (weil sich anders als bei 5.25" die Magnetschicht zwischen DD und HD bei 3.5" praktisch kaum unterschied), ist 'ne andere Sache. Gemessen daran, dass die 3.5er letztendlich aber ohnehin viel fragiler als ihre größeren Kollegen waren, war das eine eher abenteuerliche Variante.
:
Bearbeitet durch Moderator
Mittlerweile bin ich im Besitz einer handvoll von Dateien, die offensichtlich die S-Parameter der Verifikationsstandards beschreiben. Es bleibt nur, diese richtig zu interpretieren und den einzelnen Standards zuzuordnen, und in ein passendes Dateiformat (wie Touchstone) zu konvertieren. Vielen Dank für die zahlreichen Hinweise und Hilfsangebote, und natürlich einen ganz besonderen Dank an Jörg für die tatkräftige Unterstützung.
Mario H. schrieb: > Ein Tape-Laufwerk habe ich ebenso wenig. Btw., was für ein Tape hast du denn? QIC-150 oder aufwärts habe ich sicher noch irgendwo in der Ecke liegen. Das können meine Erben mal wegwerfen dann. :)
Jörg W. schrieb: > Btw., was für ein Tape hast du denn? QIC-150 oder aufwärts habe ich > sicher noch irgendwo in der Ecke liegen. Keine Ahnung, was das genau für ein Teil ist. Das sieht aus wie so ein Quarter Inch Cartridge, ca. 81x60x12 mm, allerdings scheint das Band schmaler zu sein: ungefähr 4 mm. Ein Laufwerk dafür ist im HP 8510A/B Netzwerkanalysator. Auch das hat bei der letzten Werkskalibrierung 2008 zumindest einen neuen Aufkleber von Agilent bekommen.
Rufus Τ. F. schrieb: > 3.5"-DD-Laufwerke waren in PCs aber ziemlich ungebräuchlich. So etwas > gab es AFAIK nur kurze Zeit im PS/2 Model 25 und 30 Ja, sowas hab ich auch noch. Und im Amiga sind die drin. Und da gibt es sehr feine Unterschiede zwischen den Herstellern. Wenn es um Sonderformate geht. >(und die waren keine > '386, sondern nur marginal aufgemotze XTs mit einem 8086). Meines Wissens nach umgekehrt. Das waren 286AT mit auf XT kastriert.
Habe mir die Bilder mal angesehen, aber das kann ich nicht deuten. Scheint ziemlich alt zu sein. Irgendwo stand, dass durch den späteren Einbau der Floppy die Speicherkapazität vergrößert worden wäre. ;-)
Jörg W. schrieb: > Habe mir die Bilder mal angesehen, aber das kann ich nicht deuten. Aus dem HP 8510A Handbuch: "The tape drive uses the standard HP Series 98000 data cartridge (HP part number 98200A)" Also das hier: http://www.hpmuseum.net/display_item.php?hw=265
Mario H. schrieb: > Also das hier: > http://www.hpmuseum.net/display_item.php?hw=265 Zitat: "In our experience, fewer than 15 percent of these old tapes are readable." Da würde ich keine Arbeit reinstecken. Ich hatte glaube ich mal solche Bänder an einem HP-Grafik-Terminal, aber das war so etwa 80er Jahre, jedenfalls lange bevor es PCs gab. Georg
Mario H. schrieb: > Das sieht aus wie so ein Quarter Inch Cartridge, ca. 81x60x12 mm, > allerdings scheint das Band schmaler zu sein: ungefähr 4 mm. Wenn man das tatsächlich noch lesen kann, hat man sehr viel Glück. Zumindest als PC-Backup-Laufwerke waren diese Dinger kaum besser als /dev/null - man konnte sie beschreiben, aber nicht lesen. Das Format ist übrigens "Mini-QIC", die "richtigen" QIC-Bänder waren gut doppelt so groß (150x98 mm Grundfläche, und geschätzte 2cm dick). Ich hab' noch einen Wangtek-Streamer für 500-MB-Bänder herumliegen, die Bänder dafür sind allerdings mittlerweile gestorben - das Material des Transportriemens hat sich in Wohlgefallen aufgelöst. michael_ schrieb: > Und im Amiga sind die drin. Im ST ebenso. > Meines Wissens nach umgekehrt. Das waren 286AT mit auf XT kastriert. Nein, Model 25 und 30 waren 8086-Rechner. Es gab später ein Model 30/286 - das war ein AT, und zwar ein besserer, als das "Original". Mit so einer Kiste habe ich mal 'ne Zeit lang gearbeitet.
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.