Beiträge von Arnulf zu Linden

Zitat von Xaar

Defekte Sektoren sind bei MFM- und RLL-Platten nicht ungewöhnlich.

Das klingt nach reichhaltigem Erfahrungsschatz. Hier ist es die allererste Kiste mit einer "pre IDE" HDD drin. Ist halt 'ne andere Welt als IDE, SCSI, SATA, NVMe.

Zitat von Xaar

Deine Platte hat auch so eine "Error Map" - mit 3 gelisteten defekten Spuren.

Jetzt weiß ich wenigstens, was die Angabe auf dem Bapperl auf der HDD soll.

Zitat von Xaar

Ansonsten ist für das BIOS-Problem besagtes "XT-IDE Universal BIOS" in Kombination mit einem IDE-Karte eine nette Lösung

Grundsätzlich schon, aber in der Praxis dann doch recht kompliziert mit EEPROM usw. …

Nach dem Abschluss der Grundreinigung gestern wurde die Kiste heute wieder zusammengebaut. Lediglich die MFM-HDD wurde erst mal im fliegenden Aufbau belassen.

Die Daten auf der MFM-HDD sind weg. Weder Linux (tomsrtbt) noch FreeDOS kommen an die MFM-HDD dran. Die Fehlermeldungen wurden bereits genannt.

BIOS zog das nun fällige low-level format ohne Fehlermeldungen durch.

Unter FreeDOS ließ sich die MFM-HDD partitionieren (1. p. P. reicht bei den !üppigen 40 MB Speicherplatz) und mit FAT16 formatieren. format c: /U zeigte nach dem Ende allerdings 42 errors found. an. Wäre das eine IDE-HDD, wäre die sofort raus geflogen und durch eine andere IDE-HDD ersetzt worden. Für diese MFM-HDD habe ich allerdings keinen Ersatz. Und das BIOS enthält eine böse Falle. Es basiert zwar auf dem BIOS Phoenix-A386SX, ist aber dahingehend kastriert, dass der Type 48 (user defined) für die HDDs nicht eingestellt werden kann. Deshalb muss die MFM-HDD erst mal drin bleiben. Ja, damals™, als die IDE-HDDs noch keine (oder nur ganz wenige) Reservesektoren hatten, gab es beim Formatieren mitunter auch ähnliche Fehlermeldungen. Diese HDDs wurden dann trotzdem weiter genutzt, bis gar nix mehr ging. Immerhin markiert DOS format diese defekten Sektoren, sodass da keine Daten drauf landen. Solange das im Betrieb nicht mehr werden, ist das in so einer Museumskiste unkritisch, wenn auch sehr unschön.

Zitat von Xaar

Würde ich nehmen, nur: wie ist der letzte Satz zu verstehen? Dass das M2V einfach die beiden Riegel nicht zusammen mag, aber sie sonst problemlos (auch auf anderen Boards) laufen?

"2 baugleiche Module": Das bedeutet, dass ich nicht geschaut habe, ob die nur baugleich sind oder auch einem Kit entstammen, sofern das überhaupt feststelbar wäre. Für dual channel auf Sockel AM2 & AM2+ reicht "baugleich" nach meiner Erfahrung immer aus.

"funktionieren gemeinsam nicht auf Asus M2V": Da war gerade ein Asus M2V im fliegenden Aufbau, als diese Riegel hier ankamen. Den einen Riegel gesteckt und memtest86+ drüber laufen lassen, alles gut, den anderen Riegel gesteckt und memtest86+ drüber laufen lassen, alles gut, den zweiten Riegel in den richtigen Slot für dual channel dazu gesteckt,

Die beiden Riegel gingen hier eh erst nach einer erfolgreichen Runde memtest86+ auf dem derzeitigen Sockel AM2+ Testsystem (AMD Phenom II X4 955; Gigabyte GA-MA770-UD3 rev. 1.0) raus, da sie nun schon 'ne Weile inna Kramkiste liegen.

Zitat von Xaar

PowerMac G5 'Late 2005' (2,0 GHz Dual-Core PowerPC 970MP):

• RAM: 2,5 GB (2x 256 MB DDR2-533 + 2x 1 GB DDR2-800@400) -> 8,5 GB (2x 256 MB DDR2-533 + 4x 1 GB DDR2-800@400 + 2x 2 GB DDR2-800@400)

Leider nur mit 400 MHz statt den 533 MHz, die der Rechner eigentlich könnte.

Was passiert denn, wenn Du nur PC-800 Riegel oder nur PC-667 Riegel steckst? Vielleicht mag die Kiste keinen Mischmasch.

2× 1 GiB DDR2 PC-533 liegen hier laut Hardware-Tabelle inna Kramkiste. Die könnten den Besitzer wechseln. In der Hardware-Tabelle steht dazu:

• 2 baugleiche Module, funktionieren gemeinsam nicht auf Asus M2V

Zitat von Xaar

Wenn der Controller die Festplatte problemlos "schluckt", dann könnte es sein, dass die Magnetisierung der Platte (langsam) den Geist aufgibt bzw. aufgegeben hat. Dann wären die Daten u. U. verloren

An so etwas dachte ich auch schon, als BIOS und Linux-Kernel 2.2.20-ext3 (von der tomsrtbt-Diskette) die zunächst klaglos erkannten, dann aber bei Zugriffsversuchen Sense war. Da die Wahrscheinlichkeit, dass das System (irgendein historisches DOS) nach Grundreinigung und Wiederzusammenbau der Kiste noch mal von der MFM-HDD startet, bei ≈ 0 liegen dürfte, muss mit dem Verlust der Daten gerechnet werden.

Zitat von Xaar

Der Floppy-/MFM-Controller könnte ein WD1003S-WA4 sein - der hat kein separates BIOS.

Zerlegung & Grundreinigung wurden gestartet. Es ist der von Dir genannte FD-/MFM-Controller. Der ist sogar in TH99 dokumentiert, womit man den Hüpfern an Bord nicht hilflos gegenüber steht. Der WD1003S-WA4 hat standardmäßig "Hard drive port address" 0x1F0…0x1F7 eingestellt. Somit scheint die Ausgabe vom Linux-Kernel

hda: non-IDE drive, CHS=820/6/17

ide0 at 0x1f0-0x1f7,0x3f6 on irq 14

kein kompletter Blödsinn zu sein.

Zitat von Xaar

Ansonsten wäre erstmal ein möglicher Weg die Nutzung einer XT-IDE-Karte mit XTIDE Universal BIOS (XUB),

So 'n Viech habe ich nicht. Und warum XT-Bus mit eigenem BIOS? Der WD1003S-WA4 hat ISA-Bus und kein eigenes BIOS. Laut dem hier (Tabelle 3.4) sollte sich mit Type 48 die Festplattengeometrie (C, H, S, WPcom, LZone) zu Fuß dem BIOS verabreichen lassen. Sollte sich die Seagate ST251-1 nicht mehr reanimieren lassen, würde ich es erst mal mit einem "dummen" ISA-IDE-Controller¹ aus der Kramkiste probieren. Die anzuschließende HDD ist dann die Qual der Wahl, also irgendeine aus dem Dunstkreis "1…2 GB; pio4, mdma2" oder eine Seagate ST3144A (130 MB; pio0, no DMA), die zeitlich von dieser Kiste nicht ganz so weit weg wäre, dafür aber recht gemütlich dreht (und wohl trotzdem die Seagate ST251-1 vermöbeln dürfte).

¹ein Multi-I/O-Controller mit 1× IDE, 1× FDC, 2× RS232, 1× Parallelport, 1× Gameport

Zitat von Xaar

Meckert denn beim POST das BIOS über die Festplatte, wenn du die Festplattengeometrie im BIOS eingestellt und gespeichert hast?

Nein.

Da kommt gar nix zur Festplattengeometrie. POST ist insgesamt sehr spartanisch im Vergleich zum üblichen POST bei ia32 (von kastrierten Fertig-PCs abgesehen).

Zitat von Xaar

TeleDisk war (bzw. ist teils noch) ein übliches Imaging-Tool

TeleDisk 2.15 ist vorhanden, ebenso gibt der hier sehr bescheidene PC-Bestand eine ia32-Kiste her, auf der nativ Windows XP läuft.

Dieses letzte Einschalten ohne neue CMOS-Stütze wurde genutzt, um die Spannungen am Netzteilstecker auf der ISA backplane zu messen, um im Notfall diesen Netzteilstecker mit einem anderen Netzteil zu verbinden. Elektrisch ist das riesige Netzteil fast ein AT-Netzteil, allerdings mit zwei +12 V-Strängen. Physisch passt ein AT- oder ATX-Netzteil rein, wobei für dessen Fixierung Bastelarbeit erforderlich werden würde.

Bei diesem Einschalten war auch ein anderes Diskettenlaufwerk angeschlossen, das, weil es funktioniert, für den Verbleib in der Kiste bestimmt ist.

Die nächsten Schritte werden erst mal Zerlegung, Grundreinigung und Herstellen einer Halterung (bestehend aus zwei CR2032-Halterungen in Reihenschaltung) für die CMOS-Stütze sein.

Zitat von Xaar

Nein, sowas habe ich nicht am Start,

Skandalös! Das hätte so einfach werden können, wenn Du das alles schon durchgeeiert hättest.

Zitat von Xaar

Das HP Computer Museum hat auch Basic-Software für diese Karte gesichert, wie mir scheint: https://hpmuseum.net/display_item.php?sw=237 (Unten in der Fußzeile unter "Download software (0.795 MB)", daneben ist auch noch etwas Dokumentation zu finden).

Den Doku-Kram vom hpmuseum.net hatte ich schon, aber diese Software noch nicht, Danke. Das ist "Archiv im Archiv". Um *.TD0 zu entpacken, wird TeleDisk benötigt. Mit der Version 2.15 funktioniert das Entpacken. Allerdings braucht es dazu 'ne olle ia32-Kiste, auf der nativ Windows XP oder älter oder DOS läuft.

Zitat von Xaar

Hast du die Platte am selben MFM-Controller in Betrieb?

Ja.

Zitat von Xaar

Die lange Karte mit dem 68000 scheint eine "82321 HP BASIC Controller Card" zu sein - siehe hier: https://hpmuseum.net/display_item.php?hw=681. Damit kann man wohl in HP Basic für die HP 9000 Series Computer geschriebene Programme ausführen. Nice

Dass die erste Antwort in diesem Fred aus der Lausitz kommt, ist keine Überraschung?

Hast Du auch sowas am Start?

Die Kiste ist definitiv dafür gedacht, "HP Basic für die HP 9000 Series Computer" drauf laufen zu lassen. Wurde damals auch gemacht. Die "HP Basic Quick Reference" ist auch noch, natürlich in Papierform (Format A6 o.ä.), vorhanden.

Zitat von Dirk

MFM könnte nen Endgegner sein. Wobei man zumindest auf IDE oder SCSI wechseln könnte.

[PC] kann sicherlich mit IDE umgehen. Ob [HP] das auch kann?

Das 3½" 1,44 MB FFD ist hin, aber mit einem "bekanntermaßen funktionierenden" 3½" 1,44 MB FDD startet die "BIOS Setup Disk" und das BIOS kann eingestellt werden. Nach dem fälligen Reboot startet die Kiste dennoch nicht von der MFM-HDD. Von der tomsrtbt-Diskette startet das System mit der erwartbaren Gemütlichkeit. Der Linux-Kernel erkennt offenbar die MFM-HDD, dmesg sagt dazu:

hda: non-IDE drive, CHS=820/6/17

ide0 at 0x1f0-0x1f7,0x3f6 on irq 14

ide0: unexpected interrupt, status=0xd5, count=1

ide0: reset: success

Die Seagate ST251-1 ist in TH99 dokumentiert. Die vom Linux-Kernel erkannten CHS-Werte stimmen mit den in TH99 dokumentierten CHS-Werten überein.

fdisk -l schmeißt nur Fehler:

hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }

hda: read_intr: status=0x40 { UncorrectableError }, CHS=0/0/1, sector=0

Im Falle einer IDE-HDD würden diese Fehler auf deren Ausfall hinweisen. Hier ist aber keine IDE-HDD am Start. Das kann also auch daran liegen, dass der Kernel doch nicht so recht warm mit der MFM-HDD wird. Dass der MFM-Controller als IDE-Controller erkannt wird, stimmt schon nachdenklich. Allerdings habe ich kein anderes System mit MFM-Controller und MFM-HDD drin und somit keine Referenz dazu.

Im BIOS Setup gibt es die Möglichkeit zur Initialisierung der MFM-HDD. Allerdings ist die datendestruktiv, und ich weiß nicht, ob auf der MFM-HDD etwas liegt, was zum Bestiefeln der "82321 HP BASIC Controller Card" benötigt wird.

FreeDOS kommt an die MFM-HDD auch nicht dran. Es erkennt zwar, das da eine ist, schmeißt aber bei jedem Zugriffsversuch nur Fehler. Das Unfassbare wird wahrscheinlicher.

Das in den nachfolgenden Bildern¹ gezeigte könnte 'n dickeres Brett zu bohren werden.

¹[PC]: 80386SX-16; 8 MiB RAM; [HP]: MC68000; ? RAM; [gemeinsam]: MFM-HDD Seagate ST251-1; 3½" 1,44 MB FDD; VGA-Grafikkarte

Der Exotenfaktor steht im Vordergrund. Ansonsten dürfte das pure Entschleunigung werden, wenn es sich reanimieren lässt.

Die Kiste stand auf Arbeit "kurz vor Tonne" auf dem Tisch mit der "zur Entsorgung" (auch durch Mitnahme durch die Mitarbeiter) freigegebenen Hardware. Bevor die Kiste auf diesen Tisch kam, wurde die erfolgreich mit der tomsrtbt-Diskette gestartet, weshalb die Kiste auch nicht direkt zum E-Schrott kam. Wegen der leeren CMOS-Stütze² ist der Zustand der MFM-HDD allerdings komplett unklar. Ein Image der für den BIOS-Zugriff notwendigen Diskette fand sich auch noch an. Hoffentlich passt das zu der Kiste.

²6,0 V Lithium, an der Gehäuseform erkennbar 2× 3,0 V Lithium in Reihenschaltung, also für 'n ersten Schuss durch 2× CR2032 in Reihenschaltung ersetzbar, und wenn das CMOS nicht zu sehr dran nuckelt, auch als Dauerlösung.

privat:

Meist gar nicht, weil es in der Regel ausgeschaltet, damit bei Bedarf Saft auf 'm Akku ist, in einer Plastiktüte im Kleinkrambeutel liegt. Den Erreichbarkeitswahn mache ich nicht mit!

Wenn ausnahmsweise mal Erreichbarkeit erforderlich ist, ertönt irgendein unangenehmer mitgelieferter Telefonklingelton, der auch gegen Hintergrundlärm einigermaßen durchkommt, und dazu vibriert es auch.

dienstlich:

Dienst-Handy? Wat 'n dat? Ham wa nich, gibts nich, is nich da.

Zitat von Smaecks

das hat dann die soundblaster audigy 2 zs platinum pro

Der IEEE1394a-Anschluss auf diesen Karten entspricht nicht der Spezifikation. Der liefert keine 1,5 A, und auch bei der Spannung gibt es Einschränkungen. Da stieß ich damals drauf, weil eine 2½"-HDD in einem externen Gehäuse mit IEEE1394a-Anschluss nicht dran lief, am IEEE1394a-Anschluss des Mainboards hingegen schon.

Henry Purcell: O Solitude

Zitat von Blue

Ah, sehr gut. Hatte damals ein haufen Spaß mit dem Schrottcontroller (nicht.)

Diese ganzen Bugfix und Tipps dafür, sind im Endeffekt vergebene Mühe, am Ende stirbt es trotzdem weg.

Der CMD640 ist soweit mir bekannt der schrottigste IDE-Controller überhaupt, gefolgt vom RZ1000, beide gerne auf Sockel-4-Brettern verbaut. Der Linux-Kernel hatte den CMD640 zwar irgendwann im Griff, aber bot dafür nur 'ne Performance einer Schlaftablette. In der vorhandenen Sockel-4-Kiste werkelt so ein Ding (PCI-Version). Die IDE-HDD (mdma2, pio4) läuft am CMD640 nur mit pio3 – und wird daher nur genutzt, um den Kernel zu laden, der dann einen PCI-SCSI-Controller bestiefelt. Da hängt zwar auch nur 'ne HDD (FAST-20 WIDE SCSI 20 MB/s) dran, aber das sind gegenüber einer IDE-HDD am CMD640 trotzdem Welten …

Zitat von Playitlouder

Kostet neu grade über 600€.

Danke Sam Altman und co.

… wobei "neu" u. U. auch schon nur noch für "unbenutzt, in OVP" stehen kann, da Micron die Marke Crucial einstellt oder bereits eingestellt hat.

Wann platzt endlich die KI-Blase, damit Hardware wieder bezahlbar & verfügbar wird?

Dell Latitude E5550: Crucial CT500MX500SSD1 → Crucial CT2000MX500SSD1

Spender war eine Sockel-AM3+-Kiste, in der diese enorme Speicherkapazität absehbar nicht mehr gebraucht werden wird. Da kam stattdessen die CT500MX500SSD1 rein.

Der Laptop ist zwar auch nicht gerade im Dauereinsatz, aber da drin bieten 2 TB vs. 500 GB einfach mehr Speicherplatz, falls der doch noch mal in längeren Einsatz kommen sollte.

Zitat von Xaar

Ich hab' dafür früher "AWIcons" verwendet, was ich auch in einer Version von 2002 noch hier habe - das bekomme ich aber in einer VM mit Windows 2000, XP oder 2003 nicht installiert,

Dann lass AWIcons doch auf nativer ia32-Hardware laufen. Vielleicht hast Du einen der Zeit entsprechenden PC mit Windows 2000, XP oder 2003 einsatzbereit.

Zitat von Xaar

Wenn, dann muss das schon lizenzrechtlich sauber sein - das ist nicht für 'n Bastelprojekt zuhause gedacht. […]

Ich suche da für die Arbeit nach einer Lösung für ein deutlich älteres Rechnersystem, dessen 16-Bit-Software aber nicht mehr auf einem 64-Bit-Betriebssystem lauffähig ist. Eine VM-Lösung wäre auch denkbar, hat aber lizenztechnisch auch seine Hürden.

Ist diese 16-Bit-Software für DOS oder braucht die schon Windows, und falls ja welche Version(en)?

Was spricht gegen Linux 64-Bit als OS und darauf 'ne VM, in der die 16-Bit-Software läuft? Lizenzrechtlich sollte das sauber lösbar sein.

¹ggf. reicht sogar wine