HP Vectra QS 16S

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.

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.

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

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

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

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

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

Zitat von 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:

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

Zitat von 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 …

Zitat von 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?