Posts by Arnulf zu Linden

AMD Phenom II X4 955 Black Edition HDZ955FBK4DGI:

knoppix (vom USB-Stick) friert beim Start ein. POST bleibt manchmal hängen oder löst reboot aus. memtest86+ mit bekanntermaßen funktionierenden Speicherriegeln löst reboot aus oder schmeißt unexpected interrupt by CPU*, wobei * = {0; 1; 2; 3} und bleibt dann hängen. Auf dem selben Brett mit den selben Speicherriegeln und einem AMD Phenom II X4 945 drauf läuft das selbe memtest86+ fehlerfrei durch. Muss wohl 'n "switch to death" gewesen sein, denn bis vorgestern lief der AMD Phenom II X4 955 Black Edition noch fehlerfrei auf dem Brett. Hier wurde der auch nie übertaktet, aber dessen Vorgeschichte (Gebrauchtkauf für 'n schmalen Taler inna Bucht) kenne ich nicht. Der hat es noch nicht mal bis zur Volljährigkeit geschafft.

Abzugeben sind folgende nvidia-Grafikkarten:

PCIe x16:

• 1 Stk. GeForce GT 520 (2 GiB DDR3; HDMI, DVI, VGA); Lüfter fehlt
• 1 Stk. GeForce 9400GT (512 MiB DDR2; DVI, VGA, S-Video)
• 7 Stk. GeForce 9300GE (256 MiB DDR2; 2× DVI)
• 1 Stk. GeForce 7300GS (256 MiB DDR2; DVI, VGA, S-Video)
• 1 Stk. GeForce 6200 (128 MiB DDR; DVI, VGA, S-Video)

AGP 8×:

• 1 Stk. GeForce MX440-8X (64 MiB DDR; VGA, S-Video, Composite Video)

Preis: großzügig aufgerundeter Versand (Hermes), will nix dran verdienen, aber auch nicht auf Kosten (Paketband usw.) sitzen bleiben.

Mit Ausnahme der GeForce GT 520 sind die Grafikkarten lüfterlos. Abhängig von der Luftzirkulation im Gehäuse kann es ohne Lüfter aber recht warm werden, weshalb da u. U. ein 40 mm oder 50 mm Miefquirl drauf sollte. WLP sollte erneuert werden. Volle Leistung unter Windows & Linux entfalten die GPUs nur mit den proprietären nvidia-Treibern. Mit den WDM-Treibern (Windows) und nouveau (Linux) lässt sich der Desktop anzeigen, aber mehr auch nicht.

Ach ja, einige PCI-NICs mit RTL8139 Chip sind auch noch abzugeben.

Quote from Xaar

Wenn ich mir die Date-Codes auf den ganzen Karten so anschaue, scheint der Rechner Ende 1989 gefertigt worden zu sein

Auf Sachen achtet der Mann …

Quote from Xaar

mit einer Ausnahme: Das System Board. Die EPROMs haben 'ne 1990er Datumsangabe drauf, die verlöteten Chips sind von 1991 bzw. Anfang 1992. Eventuell ist das Board schonmal getauscht worden.

So ein früher Austausch des Vectra QS/16S System Interface Board ist durchaus möglich und würde in die für viele Produkte geltende Ausfallverteilung (Badewannenkurve) passen. Viel erstaunlicher finde ich, dass sich die MFM-HDD solange hält. Was hier an IDE-HDDs bereits den letzten Gang angetreten hat …

FreeDOS 1.4 ist installiert.

Leider macht loadhigh bzw. lh nicht das, was es soll. Die Treiber müllen weiterhin allesamt den Speicher < 640 KiB voll. MOUSE ist der Originaltreiber für die HP HIL Mouse, alles andere kommt von FreeDOS.

Ausgabe von

DEVICE=C:\FREEDOS\BIN\JEMMEX.EXE NOEMS X=TEST I=TEST NOVME NOINVLPG /V

Ausgaben von mem /c /p

Ich vermute das Problem bei

Upper        0K     0K   0K

Reserved   388K   388K   0K

Gibt es da noch 'ne Chance oder ist das in Stein gemeißelt, womit die Kiste bzgl. Speicherverwaltung genauso bescheiden wie ein 286er daher käme. Schlägt hier ggf. der 80386SX zu?

Quote from Arnulf zu Linden

format c: /U zeigte nach dem Ende allerdings 42 errors found. an.

Das dürfte laut TH99 genau auf Kante liegen. TH99 enthält ein Manual von Seagate zu dieser HDD. Darin Findet sich unter Features --> Media defect:

Quote from Total Hardware 99

ST251/ST252 Media Defect Specification
There will be no more than forty-two (42) defects total per drive.
Cylinders 0,1 and 2 are defect free.

Nachfolgend Fotos von den Platinen nach der Grundreinigung:

Vectra QS/16S System Interface Board:

Vectra QS/16S Processor/Memory Board & 8× 1 MiB SIMM:

Die Kiste wurde irgendwann mal von 5 MiB RAM auf die maximal möglichen 8 MiB RAM aufgerüstet. Die vier Riegel mit den vergoldeten Kontakten sind nicht original. Ob die vier Riegel mit den verzinnten Kontakten original sind, ist nicht mehr nachvollziehbar. An Bord ist neben dem Intel 80386SX-16 auch ein Koprozessor Intel 80387SX. syschk 2.45 zeigt den auch an inkl. des von dem belegten IRQ13. Laut HP Company PC Service Handbook Volume 2 war der Koprozessor allerdings unsinnigerweise per DIP-switch deaktiviert. Wieso zeigt syschk 2.45 den trotzdem an? Also Deckel auf, DIP-switch umgelegt. Für syschk 2.45 spielt das keine Geige. Eigentlich sollte jetzt aber auch der Linux Kernel 2.2.20-ext3 auf der tomsrtbt-Diskette den Koprozessor erkennen … Pustekuchen.

Der Kernel 2.2.20-ext3 bleibt bei Checking 386/387 coupling... hängen.

Gibt es ein DOS tool, mit dem sich feststellen lässt, ob der Koprozessor funktioniert? Es sollte idealerweise so klein sein, dass es komplett von Diskette laufen kann.

CHKCOP22 macht das und meint, dass der Koprozessor funktioniert.

Bleibt zu hoffen, dass unter DOS die Funktionen, insbesonders die zur Speicherverwaltung, die ab 80386DX und höher laufen, auch genauso auf dem 80386SX laufen.

ST-506 Four-Function Controller Board:

Es gab auch schon Multi-I/O-Controller mit IDE an Bord für diese Kisten. Hier geht Exotenfaktor vor Geschwindigkeit, weshalb der drin bleibt, solange die Seagate ST251-1 ihren Dienst tut.

HP VGA Board:

Die Grafikkarte ist "VGA as less as possible". Die Karte ist für die Bestückung mit 512 KiB VRAM vorgesehen, wovon aber die Hälfte fehlt. Auf der anderen Seite ist es wenigstens VGA und nicht irgend ein damals noch verbreiteter Wildwuchs, was den Monitoranschluss sowohl mechanisch als auch elektrisch stark vereinfacht.

HP 82321 Language Processor:

Der HP 82321 Language Processor ist mit 2 MiB RAM recht üppig ausgestattet (Standard: 1 MiB; Sparbrötchen: 0,5 MiB; Maximum: 4 MiB)

Abgesehen vom Arbeitsspeicher oder mindestens einer Hälfte davon (s. o.) und dem samt Kabel ersetzten Diskettenlaufwerk, wobei die entfernten Komponenten auch schon nicht mehr original waren, dürfte die Kiste noch im Originalzustand sein. Weil die Daten von der MFM-HDD nicht wiederherstellbar waren, kann über das ursprünglich installierte DOS nur gemutmaßt werden. Auf der Diskette, die für den Zugriff auf das BIOS benötigt wird, finden sich u. a. die Dateien IBMBIO.COM und IBMDOS.COM, was irgendwie nach IBM PC-DOS aussieht.

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

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

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

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

Quote from 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

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

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

Quote from 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

Quote from 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).

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

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

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

Quote from Xaar

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

Ja.

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

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

Quote from 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

Quote from 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 …

Quote from 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?