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