Beiträge von Arnulf zu Linden

  • FreeDOS: ping von FreeDOS raus geht, ping nach FreeDOS rein geht nicht

    zweite Runde:

    Von FreeDOS aus läuft ping mal etwas länger, und während das läuft, wird ping vom anderen PC aus auf FreeDOS los gelassen. Solange ping von FreeDOS aus läuft, funktioniert auch das ping in die andere Richtung. Nach dem Ende des ping von FreeDOS aus tritt wieder das eingangs beschriebene Verhalten auf.

    Eine Recherche anhand dieses Resultats ergibt, dass auf FreeDOS ein permanent im Hintergund laufender network stack fehlt, also etwas, das bei Linux seit 'ner Ewigkeit und bei Windows seit 'ner halben Ewigkeit mit dabei ist, weshalb man da auch nicht gleich drauf kommt. Bei FreeDOS haben viele Netzwerkprogramme diesen network stack (meist WATTCP oder MTCP) gleich mit drin, weshalb die Frage ist, ob da überhaupt permanent ein network stack im Hintergrund laufen muss oder darf. Dieses Szenario dürfte auf Systeme mit sehr wenig Arbeitsspeicher abzielen.

  • FreeDOS: ping von FreeDOS raus geht, ping nach FreeDOS rein geht nicht

    Betroffen ist ein PC, auf dem Linux und FreeDOS jeweils nativ, also nix mit VM, installiert sind. Unter Linux ist der Zugriff auf das LAN vollumfänglich möglich, womit ein Hardware-Defekt ausscheidet. NIC in dem PC ist ein Intel PRO/100 82557.

    Unter FreeDOS ist ping sowohl zum gerade laufenden anderen PC (Linux) als auch zum Router (FritzBox) erfolgreich.

    Vom anderen PC aus hingegen scheitert ping auf den PC mit laufendem FreeDOS. ping schmeißt nur Destination Host Unreachable raus.

    Bevor zum ersten Mal von FreeDOS aus ein ping auf den anderen PC los gelassen wird, zeigt ip neigh show auf dem anderen PC für den PC mit laufendem FreeDOS:

    192.168.0.63 dev eth0 lladdr 00:a0:c9:4c:52:52 STALE

    Während von FreeDOS aus ein ping auf den anderen PC läuft, zeigt ip neigh show auf dem anderen PC für den PC mit laufendem FreeDOS:
    192.168.0.63 dev eth0 lladdr 00:a0:c9:4c:52:52 DELAY

    Nach dem Ende von ping von FreeDOS aus auf den anderen PC zeigt ip neigh show auf dem anderen PC für den PC mit laufendem FreeDOS:

    192.168.0.63 dev eth0 lladdr 00:a0:c9:4c:52:52 PROBE

    Und wenig später kommt, wobei es dann auch bis zum nächsten Versuch bleibt:

    192.168.0.63 dev eth0 FAILED


    Was ist da faul? Vermutlich fehlt irgendetwas in Software auf FreeDOS. Aber was?

  • Windows Vista - Der WOW der nicht now gestartet hat.

    Zitat von winfreak

    Viele hat die Oberfläche so verschreckt (aus für mich nicht nachvollziehbaren Gründen),

    Szene aus dem Büroalltag von damals:

    Auf den Blechottos unter den Schreibtischen der Kollegen lief Windows 7 64-Bit. Windows 10 gab es noch nicht.

    Ein Kollege brauchte 'n Laptop. Neu gekauft – Windows 8 64-Bit war vorinstalliert. Als der Kollege das sah, kam er zu mir (auf Arbeit damals schon und heute noch "nebenbei-Admin", kleine Klitsche halt) und sagte dazu: "Ich habe jetzt keine Zeit einen halben Computer neu zu lernen. Machen Sie mir da Windows 7 drauf." Also kam das da drauf und Windows 8 war auf Arbeit Geschichte bevor es begann. Danach ging es mit Windwos 10 64-Bit weiter gemäß "nur jede zweite Windows-Version ist brauchbar".

    Zitat von winfreak

    aus für mich nicht nachvollziehbaren Gründen

    Für mich als Smartphone-Abstinenzler und "Bedienung per Grabsch"-Hasser sind die Gründe gegen Windows 8 & 8.1 sehr wohl nachvollziehbar.

  • HP 82321 Language Processor

    Zitat von freaked

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

  • HP Vectra QS 16S

    Zitat von Arnulf zu Linden

    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.

    Der Grund dafür ist gefunden. Auf dem Vectra QS/16S Processor/Memory Board werkeln ein Chips P82C211-12 C, ein Chips P82C212B-12 und ein Chips P82C215-12. Dieser Chipsatz wurde für 286er entwickelt und kennt daher keine UMBs wie die ia32-Architektur, also ab 80386DX. Mit dem 80386SX geht dieser 286er-Chipsatz, weil der 80386SX ein Hybridprozessor ist, also intern ein 386er, aber mit der Außenwelt nur wie ein 286er verbunden.

    Es besteht derzeit allerdings keine Absicht, das installierte MS-DOS 3.30 durch FreeDOS 1.4 zu ersetzen, da die Kiste mittlerweile mit Linux ans LAN dran kommt.

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

  • HP Vectra QS 16S

    Das Linux wurde installiert. Dafür wurden lediglich Komponenten hinzugefügt, also nichts vom vorherigen Bestand entfernt oder verändert. Die vier noch freien Steckplätze (3× ISA, 1× XT) sind schließlich nicht zur Zierde da. Hinzugefügt wurden:

    • ISA-Multi-I/O-Controller Kjoken Ideplus V4: 1× IDE, 1×FDC (disabled), 2× RS232 (16450 UARTs), 1× SPP-Parallelport, 1× Gameport
    • ISA-PnP-NIC 3Com 3C509B: 10Base-2/5/T (2 & 5 disabled), set to "jumperless" (PnP disabled)
    • IDE-HDD Maxtor 90871U2 samt IDE-Kabel

    Das Linux (Slackware 9.0; Kernel 2.4.37.11) wurde von einem anderen 386er geklont und angepasst. Klonen, Kernel backen und ALSA-driver backen erfolgten aus Zeitgründen "cross" auf einem Sockel-Super-7-System (AMD K6-2+ 600; 768 MiB RAM). Linux läuft auf dem 80386SX-16 sehr gemütlich, wobei dank des Koprozessors wenigstens die "math emulation" im Kernel erspart bleibt. Die Console ist brauchbar. X wurde mit nur 8 MiB RAM und 256 KiB VRAM gar nicht erst probiert.

    Die HIL-Maus wurde durch eine RS232-Maus (Logitech Pilot Mouse) ersetzt. Dafür gibt es mehrere Gründe:

    • Mausbestand: 9× RS232 und nur 1× HIL
    • Im Vergleich zur DE-9-Steckverbindung wirkt die HIL-Steckverbindung, die einer RJ-Steckverbindung ähnelt, recht filigran und entsprechend empfindlich. Im Falle eines Ausfalls ist DE-9 zudem leichter zu ersetzen.
    • Die HIL-Maus läuft nicht gut, was vor allem am recht steifen Mauskabel (4-pol. flach statt sonst üblich rund) liegen dürfte. Den beiden Mikroschaltern unter den beiden Maustasten sind die Jahre auch schon anzumerken.
    • Unter DOS ist es wumpe, ob die HIL-Maus oder eine RS232-Maus dran hängt. CTMOUSE.EXE aus FreeDOS 1.4 lässt sich mit HPMM und RELOCATE genauso in den reserved memory abschieben wie der Treiber für die HIL-Maus.
    • Durch den Einbau des ISA-Multi-I/O-Controller sind drei RS232-Schnittstellen verfügbar. Sowohl CTMOUSE.EXE (DOS) als auch gpm (Linux) erlauben den Betrieb der RS232-Maus an COM3 mit I/O-base 0x3E8 & IRQ 5, womit COM1 & 2 mit Standard I/O & IRQ verfügbar bleiben.
    • Der HIL-Bus läuft nicht unter Linux. Die dafür nötigen Treiber liegen zwar im kernel source tree, werden von make menuconfig aber nicht angeboten und lassen sich daher auch nicht kompilieren.
    • Der zwar umfänglichen, aber nicht immer vor Übersichtlichkeit strotzenden Doku zum Vectra lässt sich entnehmen, dass die HIL-Maus nur dann zwingend benötigt wird, wenn auf dem HP 82321 Language Processor ein BASIC-Programm laufen soll, das mit Mausbedienung arbeitet.
    • Für den Betrieb der Kiste muss nicht jedesmal extra die HIL-Maus hervor gekramt werden. Statt derer kann die RS-232-Maus benutzt werden, die auch an die anderen Museumskisten dran kommt, die mit einer RS232-Maus bedient werden. Das ist zweifelsohne der mit weitem Abstand wichtigste Grund … :D

    Der aktuelle Zustand der Kiste stellt sich wie folgt da ("original" = im Lieferumfang enthalten oder zeitnah nach Lieferung hinzugefügte "Originalteile" oder Garantieaustausch damals):

    • Unlängst hinzugefügt wurden ISA-Multi-I/O-Controller Kjoken Ideplus V4, ISA-PnP-NIC 3Com 3C509B, IDE-HDD Maxtor 90871U2 samt IDE-Kabel und das 3½" 1,44 MB Diskettenlaufwerk samt Floppy-Kabel, wobei das wegen Defektes entfernte 3½" 1,44 MB Diskettenlaufwerk samt Floppy-Kabel auch nicht original war.
    • Vor langer Zeit hinzugefügt ggf. mit Entfernung ähnlicher Komponenten wurden ein 3½" 1,44 MB Diskettenlaufwerk samt Frontblende und Floppy-Kabel sowie 4× 1 MiB SIMM 70 ns (5 MiB RAM = 4× 256 KiB + 4× 1 MiB → 8 MiB RAM= 8× 1 MiB).
    • Unklar ist, ob die 4× 1 MiB SIMM, die zusammen mit den 4× 256 KiB SIMM die 5 MiB RAM ergaben, original sind. In der Originalteilliste für den Vectra QS/16S sind auch 4×1 MiB SIMM als mögliche Komponente gelistet.
    • Der Rest der Kiste dürfte original sein.

    Vectra-61.jpg

    Vectra-62.jpg

    Vectra-63.jpg

    Vectra-64.jpg

    MS-DOS 3.30 mit "Personal Assistent Manager" (PAM), der in "MS-DOS 3.30 for HP Vectra" inkludiert ist:

    Vectra-71.jpg

    Ausgabe von [DOS] mem /c. Die kryptische Zeichenkette unter "Name" stammt vom Treiber für den HP 82321 Language Processor:

    Vectra-72.jpg

    Eingabebildschirm unmitelbar nach Start des HP 82321 Language Processor:

    Vectra-73.jpg

    Ausgabe von [Linux] cat /proc/cpuinfo:

    Vectra-74.jpg

    Ausgabe von [Linux] cat /proc/ioports:

    Vectra-75.jpg

    Ausgabe von [Linux]cat /proc/interrupts :

    Vectra-76.jpg

    Ausgabe von [Linux] fdisk -l:

    Vectra-77.jpg

  • 25 Jahre XP

    Windows XP ware das letzte Windows, das größtenteils noch auf ia32 installiert wurde, und auf dem daher viel schon damals alte Software noch lief, ohne dafür extra 'ne VM aufsetzen zu müssen. Windows Vista wurde großenteils übersprungen. Zum Erscheinen von Windows 7 standen meist schon x86_64-Kisten unter 'm Schreibtisch, weshalb Windows 7 dann zumeist auch in der 64-Bit-Version installiert wurde. Damit hatte sich dann viel alte Software, die auf Windows XP 32-Bit noch lief, erledigt. VM für die alte Software? Für viele einfach zu kompliziert!

  • mem & edit; backports für MS-DOS 3.30?

    Danke. Manchmal kann die Welt so einfach sein. mem und edit aus FreeDOS 1.4 funktionieren auf MS-DOS 3.30.

    Bei mem bleibt es allerdings dabei, dass der reserved memory als komplett belegt angezeigt wird und die Treiber, die mit HPMM.SYS & RELOCATE.EXE dorthin geschoben werden, werden in der Ausgabe von mem /c gar nicht gelistet. Ansonsten zeigt mem aber deutlich mehr an als chkdsk.

    edit aus FreeDOS braucht keine qbasic.exe, und es ist das erste Programm auf der Kiste, das auch mit der HP-HIL mouse bedient werden kann, was in diesem Fall die Funktion derselben und deren Treibers zeigt.

  • GMA3150 Performance

    ntpdate zum harten Setzen der Systemzeit beim Systemstart ist auch sehr praktisch bei BIOS mit nicht behebbarem Y2K-bug, z. B. auf dem Socket-5-Mainboard Soyo SY-33A2.

    Unter Linux ist das 'n oller Hut. Hier lese ich, dass es das auch für Windows bis runter zu Windows 95 gibt. Hätte man damals durchaus gebrauchen können …

  • HP Vectra QS 16S

    Nach der Installation von MS-DOS 3.30 (HP OEM, angepasst für Vectra) ließen sich zwei Probleme lösen:

    1. Der reserved memory, an dem sich FreeDOS die Zähne ausbiss, wird von dem HP-eigenen HPMM.SYS geknackt. Mit dem zu HPMM.SYS gehörenden RELOCATE.EXE lassen sich prinzipiell Treiber und TSRs in den reserved memory abschieben, wodurch im Arbeitsspeicher < 640 KiB weniger Müll rum dümpelt. Mit KEYBOARD.SYS und \HPHIL\MOUSE.COM funktioniert das.
    2. Der HP 82321 Language Processor (aka HP Basic Language Processor, abbr.: HPBLP) lässt sich mit dem Treiber HPBLP.SYS bestiefeln und dann mit \BLP\BASIC.EXE anstarten und aus sich heraus mit der entsprechenden Tastenkombi beenden. Die Oberfläche scheint Rechner der HP9000/300-Serie nachzubilden. Mangels Manual in Kombination mit "Null Ahnung von HP Basic & HP9000-Rechner" kann ich damit erst mal nix anfangen. HPBLP.SYS reagiert allerdings allergisch auf RELOCATE.EXE und schmeißt dann nur eine Fehlermeldung statt zu laden. Somit lässt sich HPBLP.SYS nicht aus dem Arbeitsspeicher < 640 KiB abschieben.

    Das der Linux-Kernel 2.2.20-ext3 von der tomsrtbt-Diskette nur mit der Option no387 startet, obwohl ein 80387SX-16 verbaut und per DIP-Schalter eingeschaltet ist, ist ein Kernel-bug. Ein für 386 mit 387 kompilierter Kernel 2.4.33.3 startet durch – die kernel panic kommt erst, wenn der Zugriff auf die HDD mit dem root-fs scheitert, da diese HDD noch gar nicht eingebaut ist. Der Kernel 2.4.33.3 lässt sich entgegen allen Erwartungen mit loadlin 1.6f von dem fossilen MS-DOS 3.30 aus starten. Sinn des Ganzen: Zugriff auf 's LAN. Plan zur Umsetzung: IDE-HDD an IDE-Controller, der als ide1 (I/O 0x0170-0x0177 & 0x0376; IRQ 15) komplett am Mainboard-BIOS vorbei läuft und auch kein eigenes BIOS braucht, weil der direkt vom Linux-Kernel bestiefelt wird.

  • Der "Ich habe es wieder repariert" Thread

    Zitat von freaked

    :b1::b3::b1::b3::b1::b3::b1::b3::b1::b3::b1:

    so, ein ch341-programmer mit WSON-chip-adapter (ja, die nadeln, die auf eingelötete, fuzzelig kleine 5x8-mm-bios-chips drücken, zum flashen ohne auslöten),

    Es gibt also etwas für diese extra flachen SMD-BIOS-chips, auf die sich die üblichen Adapter ("Zange") nicht aufsetzen lassen, um eben ein Flash (ohne Auslöten) zu verhindern. Das könnte doch noch eine Chance sein, der Thinkstation P300 NVMe-boot beizubringen.