Beiträge von osf1g

    Dachte ich zuerst auch, aber die Tastatur- und Mausanschlüsse bei der VS2000 sind anders. Ich hatte so ein Kabel schon gegoogelt und meines ist anders.

    Es ist definitiv nicht DEC, die hatten die Kabel schön gelabelt. Auf meinem gibt es keine einzigen Hinweise, wovon und wozu das gehören könnte.

    Hallo zusammen,

    ich habe ein Video-Kabel mit Maus- und Tastaturanschluss mit meiner Vaxstation bekommen. Es ist aber kein Kabel, das dort dazu gehört (Belegung vom Videoanschluss und Maus- und Keyboard-Anschlüsse passen nicht) und ich habe so eines auch noch nie gesehen.

    Vielleicht hat jemand eine Ahnung, wozu das gehört und hat vielleicht Verwendung dafür?

    Auf der Einstiegsseite wird erwähnt, dass Systeme des Betreibers im Hecnet hängen. Vielleicht kann man darüber mehr heraus finden.

    Der Name des Betreibers müsste anhand der Nodename-Datenbank von Hecnet ein ***************

    Ich denke, auch die älteren Freeware-CDs sind deutlich jünger als VMS 5 und dessen X11-Distribution (ich schätze mal, das ist X11R4), so dass die Software dort für jüngeren VMS-X11s (X11R5) ausgelegt ist. Da würde ich schon davon ausgehen, dass die nicht unbedingt 1:1 auf das ältere VMS-Release übertragbar sind.

    Hallo,

    ich habe heute meine Vaxstation 3100 zerlegt, gesäubert und wieder zusammen gebaut. Dabei ist mir leider ein Teil übrig geblieben, das ich wohl beim zerlegen übersehen und keine Notiz für die Quelle angelegt hatte .

    Weiss vielleicht jemand, wo das hin muss? Ich vermute, das kommt unter das Systemboard als Abstandhalter. Als Grössenvergleich ein "normal" grosser USB Stick daneben.

    Ich habe auf meinem W10 laufen. Ich habe dazu eine Boot-CD gepatched. Es gibt eine Serie auf YT dazu (inklusive Links, wie man patched):


    https://www.youtube.com/watch?v=tClTcOckeGU&t=442s


    Bootcamp ist etwas tricky.


    Neuere OSX geht mit DosDude Patcher, allerdings solltest du eine Metal-Fähige Grafikkarte haben wenn du höher wie High Sierra gehst.

    Auf einem 1,1 oder 2,1 geht das auch nicht, da ist bei El Capitan Schluss. Für den DosDude Patcher ist mindestens ein 3,1 notwendig.

    Ich verwende für so was osxfuse unter macOS. Da kann ich so ziemlich alle UFS images mounten (versuche gerade, ein korruptes Solaris Disk Image zu reparieren). Die Magic-Nummern bei UFS sind etwas schwierig zu finden. Es gäbe am Ende eines Superblocks die Kennung 011954 (Geburtsdatum von Bill Joy, hex), danach könntest du suchen. Könnte aber auch von der UFS-Version abhängen, bin nicht sicher, ob das bei allen UFS-Versionen so verwendet wird.

    Der Bootblock hat auch eine Magic-Number irgendwo, fällt mir aber gerade nicht ein.

    Ein Hexdump der ersten ca. 9000 Byte könnte helfen (512 Byte Bootblock und danach 8192 Byte erster Superblock).

    Es stimmt, dass es ein paar TSR-Funktionen gab, aber die waren bei weitem nicht ausreichend, um ein brauchbares Hintergrund-Programm zu erstellen. Ich hatte auf einige inoffizielle Funktionen des int21h zurückgegriffen, damit das benutzbar war. Die waren im Standard-Werk "Undocumented DOS" beschrieben, was ich noch irgendwo rumliegen habe.

    Die Reentranz war selbstverständlich ein eigenes Thema, aber das ist ja klar.

    Aber das war nur mit undokumentierten/inoffiziellen Systemaufrufen von DOS möglich (TSR).

    undokumentiert/inoffiziell? Nein. DOS-Aufruf? Nur zum Teil. Praktisch alle TSRs hängen sich in BIOS-Interrupts ein, meistens Timer oder Tastatur. Wenn man aus dem TSR aber ins DOS wolte, musste man sicherstellen, daß niemand anderes grade keinen DOS-Aufruf macht - dazu brauchte man die DOS-Funktion 34h, um das In-DOS-Flag abzufragen. Die war aber (wenn auch kryptisch) doch durchaus dokumentiert und offiziell.

    Die Aussage, dass "praktisch alle TSRs sich in BIOS-Interrupts" hingen ist nicht korrekt. Meine TSRs hingen nahezu immer an HW-IRQs (serielle Schnittstelle, Timer, Keystroke etc.). Vor allem der Timer war geeignet für ein TSR, aber das ist kein BIOS-Interrupt. Ich denke, du verwechselst hier was.

    Die Funktionen, um ein Programm nach Beendigung im Speicher resident zu halten, war nicht von MS dokumentiert und daher inoffiziell. Kann sein, dass später diese auch mal offiziell wurden, aber zu meiner Zeit jedenfalls nicht (so bis MS-DOS 3.3). Es gab noch sehr viele weitere Funktionen, die von MS nicht in deren API gelistet wurden. Ist bei mir aber schon fast 30 Jahre her und ich bin damals dann auf Unix-Systeme umgestiegen und habe seitdem dort nichts mehr gemacht.

    Deshalb gab es ja Multitasking-Systeme, die DOS-Programme ausführen konnten.

    Ich hatte damals unter DOS Background-Programme geschrieben, die daraus ein Semi-Multitasking-System gemacht haben. Aber das war nur mit undokumentierten/inoffiziellen Systemaufrufen von DOS möglich (TSR). Um den Wiedereinstieg in unterbrochene Funktionen musste sich das Background-Programm selbst kümmern (Stack sichern, Filepointer sichern etc.). War aufwändig, aber möglich.

    Der Fehlercode deutet auf ein Problem mit dem Systemboard (oder Netzteil) hin. Wenn du schon nur Board am Netzteil getestet hast und immer noch den selben Fehler bekommst, liegt es dann daran.

    Das ROM dürfte aber ok sein und müsste bei diesem Status schon gelesen worden sein, sonst stünden die LEDs bei 1111-1111.

    Der Akkuschaden kann auch durchaus das Board schädigen, wenn die Säure über das Anschlusskabel sich bis zum Board vorarbeitet (hatte selbst erst so ein Board bekommen). Ob Netzteil oder Board das Problem ist, wäre am einfachsten mit einem funktionierenden NT zu testen, falls vorhanden oder in Reichweite.

    Das Problem bei der "Hawley"-Maus ist das Material der Roller. Zumindest bei DEC werden die porös und brechen früher oder später. Und Ersatz ist praktisch nicht aufzutreiben (und falls doch, wüsste ich gerne die Quelle).