Posts by hans

    Ja, auch und auch als EPS4. Allen Printserven ist zueigen, dass sich die seriellen Ports nicht als Terminalports eignen.

    aber für serielle Plotter und Drucker?

    Genau, dafür sind sie gedacht. Die Firmware ist praktisch identisch zu den Terminalservern, ist aber für die seriellen Schnittstellen eben eingeschränkt.

    Und da dann die IP-Adresse des Routers eintragen.

    jetzt, mit gestartetem DECNET (gestartet vor UCX) sehe ich bei UCX SHOW INTERFACES die MAC Adresse AA-00-04-00-1E-5C


    Beim Starten der Maschine / Bei TEST 50 aus dem Chevron sehe ich "ID 08-00-2B-0C-30-B4"


    Das ist also die besagte Änderung der Mac Adresse durch den Start von UCX?

    Genau. Jetzt könntest Du auf einer Linux-Maschine, die auch am Hub hängt, mit sudo tcpdump ether host AA-00-04-00-1E-5C or ether host 08-00-2B-0C-30-B4 alle Pakete zeigen, die von und an die VAX unter ihrer Hardware- oder DECNET-Mac-Adresse gesendet werden.

    Hast Du UCX nach DECNET gestartet? Ich glaube, das ist notwendig, da DECNET die Mac-Adresse des Ethernet-Interface ändert und das - wenn ich mich richtig erinnere - dann das UCX verwirrt.


    Dann würde ich mit tcpdump oder Wireshark von einem anderen Rechner auf dem Hub gucken, ob die Pakete von der VAX auf dem Ethernet ankommen. Dazu brauchst Du die Mac-Adresse der VAX (https://powerdog.com/addrconv.cgi), und dann sudo tcpdump -i <interface> ether host <macaddresse>. Wenn Du dann von der VAX aus pingst, müsstest Du ARP- und/oder ICMP-Pakete von der VAX und ggf. auch die Antworten sehen.

    "Global Sections" sind separat identifizierte und von mehreren Prozessen gleichzeitig in den Adressraum gemappte Speicherbereiche. Für jede dieser Sections wird ein paar dutzend Bytes Hauptspeicher reserviert, eine Überprovisionierung hat keine wesentlichen Nachteile. "Global Pages" sind die eigentlichen Speicherseiten, die für "Global Sections" bereitgehalten werden. Jede Page hat 512 Bytes, 1662 freie Global Sections sind entsprechend etwa 830 KB ungenutzter Speicher, der nicht für andere Zwecke benutzt werden kann.


    Genau genommen "benötigt" man von beidem keine Reserven und kann sie so einstellen, dass es genau für die Software passt, die man betreiben möchte. Wenn man dann doch irgendwann ein neues Programm starten will, welches GPTFULL meldet, muss man eben wieder mit AUTOGEN ans Werk gehen.

    Nicht raten, sondern nachsehen:

    Code
    $ write sys$output f$getsyi("free_gblsects")
    179
    $ write sys$output f$getsyi("free_gblpages")
    6572

    Damit weisst Du dann, wie viel von den konfigurierten Sections und Pages verballert sind und kannst entsprechend den richtigen Wert für MODPARAMS.DAT ermitteln. Etwas größer schadet nicht, aber Deine Maschine ist nicht groß und der Speicher, der durch GBLSECTS und GBLPAGES zur Seite gelegt wird, kann nicht anderweitig verwendet werden.

    Danke hans. Das probier ich mal. Die Schuhschachtel hat 6MB RAM. Läuft auf sowas überhaupt UCX?

    Müsste, 6 MB ist ja nicht wenig für eine VAX. Aber Du musst beim Parameter-Tuning halt etwas präziser vorgehen. Schau halt erstmal, wie FREE_GBLSECTIONS und FREE_GBLPAGES aussieht und dann schau ihm Handbuch nach, wie viele Pages / Sections UCX braucht, damit Du das einigermassen genau einstellen kannst.

    In Deinem MODPARAMS.DAT steht ja nicht, dass GBLPAGES vergrößert werden soll. NPAGEDYN und NPAGEVIR helfen bei GPTFULL nicht.


    Auf meiner VAX (128MB RAM) habe ich

    Code
    min_gblpages=45000
    min_gblsections=500

    ... aber das wird für die Schuhschachtel zu üppig sein. Jedenfalls: GBLPAGES und GBLSECTIONS sind die Parameter, die Du tunen musst.

    Asynchrone serielle Schnittstellen verwenden immer ein Startbit, welches den Anfang eines Datenbytes anzeigt, und ein oder zwei Stopp-Bits, die das Ende markieren. Das Startbit ist high, das/die Stopbits sind low, so dass am Anfang eines Zeichens immer ein low-zu-high-Übergang zu finden ist. Das niedrigwertigste Bit wird im Allgemeinen zuerst übertragen (LSB first). Das 8N1 (8 Datenbits, keine Parität, 1 Stopbit) hat dementsprechend 10 Bits pro Zeichen.

    Ich kann jetzt aber kein ethisches Problem darin sehen, dass ich gerne einen möglichst guten Preis bekommen möchte

    Das ist ja Dein gutes Recht, aber wenn Du etwas versteigern möchtest, dann ist der Marktplatz des Forums nicht der richtige Platz. Stell das Teil doch auf eBay, wenn es Dir ums Geld geht.

    Grundsätzlich ja, aber meist ist eher das Problem, die 'richtige' Stelle zu finden.

    Klar, zuerst mal sucht man halt nach der Fehlermeldung, wenn es denn eine gibt. Ansonsten wird es in diesem Fall wird es ja vermutlich so sein, dass die Software eigene Diskettenroutinen mitbringt, die direkt mit dem FDC reden - Ich würde zunächst nach den entsprechenden Hardware-Adressen suchen.


    Ich sag nicht, dass es leicht ist, aber mit Ghidra macht das jedenfalls einigermassen Spaß.


    Die Atari-Skripte sehen jedenfalls cool aus!

    Für's Auslesen ist der genaue Chiptyp nachrangig. Beim AM29F400 handelt es sich einen einfachen parallelen Flash-Baustein, den man mit dem richtigen Adapter auch als 2716 auslesen kann - Ein Mäuseklavier für die oberen Adressleitungen und die Konfiguration der Organisation (8/16 Bit) vorausgesetzt :)


    Ich würde das Ding auf eine TSSOP-48-Breakout-Platine löten und dann frei als 27c4001 oder einen anderen unterstützten 512k x 8-Typ auf einem Präzisionssockel verdrahten und dann auslesen (ID Check ausschalten).

    Na am "einfachsten" wird es doch sein, mit Ghidra den Kopierschutz zu entfernen. Ghidra ist ein interaktiver Disassembler, und wenn man das Executable-Format kennt, kann man sich eigentlich relativ einfach durch solche Dinge durchpuzzlen. Ich habe das mal mit einem Firmware-Update für den Lantronix EPS-16 Terminalserver gemacht, Details kann man hier nachlesen: https://netzhansa.com/lantronix-lat-master-password/


    Hat Spaß gemacht, kann ich empfehlen :)

    Ich plane, Besuchern eine Art Führung durch Retrostar und TELEBAHN zu geben. Da wäre es dann ganz cool, wenn auf einigen der Rechner noch jemand anderes eingelogged wäre. Ich werde aber auch wieder Zugänge zum Netz bereitstellen, so dass Besucher auf eigene Faust herumgucken können. Letztes Mal wurde diese Möglichkeit fast gar nicht genutzt, aber vielleicht kann man durch die Führung und vielleicht bessere Online-Doku ja mehr Interesse wecken.


    Eine Vereins-Bridge gibt es mWn nicht, aber es gibt den losen Plan, im Oldenburger Computermuseum einen Zugang einzurichten. Vielleicht schaffe ich das im Sommer.

    Wenn es nur um nette Formatierung geht, dann hilft Digital Standard Runoff, das ist bei VMS immer dabei (HELP RUNOFF). Ansonsten ist das DEC-Produkt zur Textverarbeitung WPS-PLUS:


    Irgendwie isses ja doof, wenn man unterschiedliche Programme je nach verwendeter Terminalemulation starten muss. Da ich ja ohnehin mal herausfinden wollte, wie man in unter RSTS/E aus BASIC heraus mit dem Betriebssystem interagiert, habe ich mal ins Handbuch geschaut. Man muss dazu wissen, dass nur der Kernel von RSTS/E in Assembler geschrieben ist. Die Utilities sind in BASIC programmiert, daher gehen auch die Programmierbeispiele in der Dokumentation alle davon aus, das man BASIC benutzt.


    Um den Terminaltypen herauszufinden, muss man die Systemroutine "Set Terminal Characteristics" aufrufen. Das geht mit der BASIC-Funktion SYS(), die einen String als Parameter erhält, in dem der Systemaufruf byteweise enkodiert ist. SYS() liefert einen String zurück, der das Ergebnis des Aufrufs enthält. Sowie ums Encoding als auch ums Decoding darf man sich dann in BASIC selber kümmern. Das sieht dann so aus:

    Code
    2220 def fnGetTerminalType%()
    2225 dim returned%(30)
    2230 change sys(chr$(6%)+chr$(16%)+chr$(0%)+chr$(255%)+chr$(0%)) to returned%
    2235 if returned%(11%) = 128% then goto 2255 ! Hardcopy
    2240 change sys(chr$(6%)+chr$(16%)+chr$(1%)+chr$(255%)+chr$(0%)) to returned%
    2245 if returned%(5) = 3% then fnGetTerminalType% = 1 : goto 2260 ! VT52
    2250 if returned%(25) and 1% then fnGetTerminalType% = 2 : goto 2260 ! ANSI
    2255 fnTerminalType% = 0
    2260 fnend

    Interessant ist CHANGE - Damit kann man einen String byteweise in ein Integer-Array konvertieren, damit man etwas bequemer darauf zugreifen kann. Zur Ermittlung der Emulation sind zwei SYS()-Aufrufe notwendig, denn man muss erstmal ausschließen, dass es sich um ein Hardcopy-Terminal handelt, bevor man zwischen VT52 (expliziter Typ) und VT100/VT200/VT300 (ANSI) unterscheidet.


    Ich finde das ganz goldig, und in BASIC kann man auch gut herumprobieren. Ist natürlich Spaghetti :tüdeldü:


    Die Doku zu RSTS/E V10.0 ist auf Bitsavers: https://bitsavers.org/pdf/dec/pdp11/rsts_e/V10/