HP 82321 Language Processor

  • Hier staubte schon lange ein HP 82321 Language Processor (aka HP Basic Language Processor, abbr.: BLP) ungenutzt vor sich hin. Dieser BLP wurde damals einem 286er Vectra entnommen, nachdem dieser Rechner über 'n Deister gegangen war. Mit dem HP Vectra QS/16S steht nun ein zum Testen dieses bis dato hier ungenutzten BLP geeignetes System zur Verfügung. Dieser BLP funktioniert, und das nach sooo langer Zeit. :) Er ist wie der im HP Vectra QS/16S verbaute BLP recht üppig mit 2 MiB RAM ausgestattet.

    BLP mit abgenommener Speichererweiterungskarte, nach der Grundreinigung, mit Einstellung I/O-base 0x250 & IRQ 7:

    HPBLP.jpg


    Und hier beginnt der sportlichere Teil: Dieser BLP sollte in einem deutlich neueren System unter FreeDOS 1.4 laufen.

    Als System wurde wegen der vollen Baulänge des BLP eine Kiste mit ATX-Brett drin ausgewählt. Die Wahl fiel auf dieses System:

    • AMD K6-III 450
    • Asus P5A (Ali Aladdin V rev. G)
    • 768 MiB RAM
    • nvidia GeForce FX5200 (AGP 2×/4×/8× @ 2×)
    • Intel PRO/100 82557 (100Base-TX NIC; PCI)
    • Fortemedia FM801 (Sound; PCI)
    • Ali ? (USB 2.0; PCI)
    • Promise Ultra100TX2 (Dual-IDE; PCI)
    • [Rest hierfür egal]

    Für diese Kiste sprachen zwei Dinge:

    • Das Fehlen von ISA- oder XT-Bus-Steckkarten erleichterte das Freischaufeln von Ressourcen (I/O, IRQ) für den BLP. Die BIOS-Einstellung IRQ 5 Used By ISA : Yes genügt, um die AGP-Grafikkarte und die PCI-Karten von der Nutzung des IRQ 5 abzuhalten. Die Abwesenheit einer ISA- oder XT-Bus-Soundkarte oder MIDI-Karte sorgt dafür, dass I/O-base 0x330 frei bleibt. Der BLP-Treiber sucht standardmäßig nach BLP mit den Einstellungen I/O-base,IRQ = {0x250,7; 0x280,9; 0x330,5}. IRQ 7 ist vom ECP-Parallelport belegt. IRQ 9 ist u. a. von ACPI belegt und daher ein ganz schlechter Plan. Bleiben der IRQ 5 und somit die Einstellung des BLP auf 0x330,5.
    • [Linux] /cat/proc/ioports gibt u. a. aus: 03c0-03df : vga+ Das könnte ein Grund sein, warum der BLP das erwartete Bild über die AGP-Grafikkarte ausgibt. Bei den vorhandenen Pentium III-Kisten, die noch ISA-Bus-Steckplätze an Bord haben, gibt /cat/proc/ioports keinen I/O-Adressbereich für VGA+ aus, weshalb keine Kiste davon genommen wurde. Bei den beiden vorhandenen Kisten mit AMD K6-2+ 600 drin gibt /cat/proc/ioports einen I/O-Adressbereich für VGA+ aus, aber beide Kisten haben AT-Bretter drin, auf denen der Prozessorkühler dem Einbau von ISA- oder XT-Bus-Karten voller Länge im Weg ist.

    IRQ 9 in Verbindung mit einer XT-Bus-Karte ist etwas irreführend, denn der XT-Bus kennt nur die IRQ 0…7 und hat somit keinen Kontakt für den IRQ 9, sondern nur einen für den IRQ 2, der in AT-Systemen aber mit dem IRQ 9 verbandelt ist.

    Auf der Kiste wurde FreeDOS 1.4 installiert als dual-boot mit der bereits installierten Slackware 13.0.

    Dass der Installer für den BLP-Treiber unter FreeDOS nicht läuft, war bekannt. Stattdessen wurde das von diesem Installer auf dem HP Vectra QS/16S angelegte Verzeichnis auf die HDD in der o. g. Kiste kopiert und in die FDCONFIG.SYS unterhalb des Eintrags für JEMMEX.EXE eingetragen:

    DEVICEHIGH=C:\BLP\HPBLP.SYS

    Das funktioniert. HPBLP.SYS landet mit der Hilfe von JEMMEX.EXE komplett im UMB, und trotzdem lässt sich BASIC auf dem BLP genauso wie auf dem HP Vectra QS/16S starten. Der Test mit einem BASIC-Vierzeiler lief erfolgreich.

    Bleibt die Frage nach dem tieferen Sinn des Ganzen: Wer programmiert heute noch in Rocky Mountain BASIC (HP BASIC dialect)? Und wer hat privat ein Gerät zum Anschluss an die IEEE488-Schnittstelle? ;)

    Ein Traum wäre natürlich, auf die IEEE488-Schnittstelle auf dem BLP direkt von Linux aus zugreifen zu können, aber das wird wohl ein Traum bleiben …

  • Interessant. Irgendwo mal gelesen, dass diese Dinger ein Ding war, hatte nicht Microsoft sogar als erste Hardware sowas rausgebracht. Weiß nur nicht mehr für welche Hardware mit welcher Hardware. Als Cross Kompiling noch kein Ding war. Wobei, vielleicht kommt es ja wieder. Hatte jetzt gehört das man für die M-Macs nur noch auf selbiger Hardware coden kann.


  • ich nehme mal an, die karte war dazu da, dass ein sie unterstütztendes programm den basic code schneller ablaufen lies, oder nur kompillieren?

    gabs da in der x86 welt überhaupt jemals bedarf für sowas? nicht mal ibm basic oder qbasic waren jetzt wirklich weit genutzt und verbreitet, eher noch qbasic, weils halt gratis dabei war.

  • ich nehme mal an, die karte war dazu da, dass ein sie unterstütztendes programm den basic code schneller ablaufen lies

    Einmal angestartet bildet die Karte einen "Computer im Computer". Der MC68000 ist eine für damalige Verhältnisse vollwertige CPU, eigener Arbeitsspeicher ist auch drauf. Der DOS-Treiber reicht an die Karte COM1 und LPT1 sowie FDC und HDD (mit entsprechender Config der HDD) durch und auch Grafik (hier VGA).

  • Naja, die GPIB Schnittstelle lässt mich vermuten, dass das für Messaufgaben, evtl. in einem automatisiertem Umfeld verwendet wurde. Also der vermutlich zeitkritische Teil, die Kommunikation mit den Messgeräten/evtl. irgend ein Handling läuft auf der Karte direkt, und der x86 Chip im Computer kümmert sich um eine Visualisierung oder Auswertung.

    Der kann dann auch mal ein paar Sekunden mit Diagramme-Zeichnen etc. aufgehalten sein (Heute: Browsing History zu MS hochladen), ohne dass die Fertigungslinie stehen bleibt weil die Messung nicht durchgeführt wird. :oO:

    🍎 MacBook Air (Mac17,3) - Apple M5 - 32 GB LPDDR5X - 1 TB NVMe - WQHD IPS 13,6" - macOS27
    Awow China Tablet - Intel N95 - 12 GB LPDDR5 - 256 GB NVMe - WXGA 10,1" - Win11

  • Ich glaube war echt nen Mangel an Cross Compilern. Habe jetzt die Microsoft Karte ergoogelt, war ihr erstes Hardware Projekt, quasi nen Z80 für Apple II:

    The Microsoft SoftCard for the Apple II: Getting two processors to share the same memory - The Old New Thing
    Reportedly Microsoft's first hardware product.
    devblogs.microsoft.com

    Glaube war auch alles kurzlebig, und machte nur sinn, weil ein zweiter Rechner entweder zu teuer war. Insbesondere, wenn der zweite richtung mainframe blinkte.


Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!