Vorstellung es65

    Hallo, ich wollte einen kuriosen "Server" aus den 80er Jahren vorstellen. Ich habe leider keine Informationen zu dem Gerät, bin aber dabei ihn komplett zu dokumentieren. Im stardot forum habe ich einen Thread gestarted (Stardot Forum) und dort gibt es jemanden der eine emulation versuchen möchte. Ich selber habe bereits einiges an Arbeit und Recherche in das Projekt gesteckt. Es gibt einen bitbucket Account wo alle Dokumente inkl. Schaltpläne und ROM Inhalte sowie disassembly liegen (Bitbucket).

    Was super wäre wenn jemand mit wirklich guten 6502 assembler Kenntnissen den code ansehen könnte. Ist zwar nicht mein erstes Projekt, jedoch ist es das umfangreichste.

    Hier noch ein Video vom Start und einloggen von vier Benutzern (entschuldigung für die mittelmäßige Qualität) - es65 Startup

    lg. robert

    Hallo Robert!


    Ich würde da eigentlich ganz gerne mal reinschauen. Aber warum stellst Du die Informationen auf Web-Seiten, die mit Datenkraken und -schnüfflern verseucht sind? Bitbucket ist nichts für mich. Youtube ist 'ne Zumutung. Wenn die seit Juni aufgezwungene Werbung gekommen wäre, hätte ich nicht mal das Filmchen angeschaut. So kam hier immerhin keine. Eigene Domain mit Web-Space? Dort bezahle ich als Interessent nicht mit meinen Daten und dem Sicherheitsrisiko von durch Cloudflare und anderen untergeschobenen oder abgeschnorchelten Daten.


    Wg. 6502-Code: selbstmodifizierender Code war damals normal, wenn es um Geschwindigkeit geht. Dem 6502 fehlen Register und/oder Adressierungsarten. Dafür war er schnell :) Ich schreibe ganz gerne Code, bei dem Zieladressen "angepaßt" werden, vorzugsweise bei IO-Aktionen.


    Indizierte Sprünge sind doch ok. Wie will man sonst einen Zustandsautomaten "kostengünstig" schreiben?


    Gruß, Ralf

    Ok :) Schick mal den ROM-Inhalt sowie eine "Addressmap" soweit bekannt. Ich scheuche das durch meinen Disassembler. Du kannst das hier über "Konversation" schicken.

    Zitat von RalfK

    Hallo Robert!


    Youtube ist 'ne Zumutung. Wenn die seit Juni aufgezwungene Werbung gekommen wäre, hätte ich nicht mal das Filmchen angeschaut.

    Gruß, Ralf

    Einfach nen guten Werbeblocker verwenden- ich habe noch nie in Youtube Werbung gesehen. ;)

    Bin allgemein komplett werbefrei unterwegs.


    Ok, back to topic. :)

    Erster Blick auf den Schaltplan: die Speicher (RAM und EPROM) haben durchgängig nur 2kB pro Chip. Dann ist das wirklich alt :) Bemerkenswert sind die Leitungstreiber der Seriellanschlüsse: kein V.28, sondern über Optokoppler mit dahintergeschalteten Treibern mit TTL-Pegel! Hast Du eine Vorstellung, wo dieses Gerät damals eingesetzt wurde? Medizintechnik, Leittechnik/Stromversorger, oder so?


    Aus der Darstellung der Adreßbelegung: interpretiere ich das so, daß das Multitasking in diesem Rechner daraus bestand, daß lediglich die CPU und der größere Teil vom ROM-Code in einfacher Ausfertigung vorhanden war, aber alles andere für die 4 User separat? 4* IO, 4* RAM.

    Jeder User hat 32k zur Verfügung sowie eine serielle Schnittstelle (außer dem Terminal) und I/O (LEDs und Schalter) und kann auf bis zu vier Floppy LW und einen Drucker zugreifen.


    Ich habe mit den ROMs gerade ein paar Schwierigkeiten: die sind jeweils als Images der einzelnen Chips vorhanden. Aber ich sehe noch keine Regel, wie ich die zu einem Image zusammensetzen soll, damit das eine durchgehende Code-Datei ergibt. Im TGM_hi sehe ich die beiden Vektoren für Reset und IRQ auf $8000 zeigen, und ich weiß, daß zwischen $8000 und $FC00 (dem Start dieses ganz oben liegenden ROMs) viele "kleinere" sind.

    Man kann ja auch mal direkt an der Quelle fragen - ich meine, wenn es vorn schon draufsteht ... HTLuVA St.Pölten ist ja nun nicht völlig aus der Welt. Die sprechen das sogar "germanisch" oder sowas in der Art - es gibt also noch nichtmal eine Sprachbarriere.


    Hier magst Du evtl. mal reinhören - der Mann im Video kann Dir sicher auch die passenden Adressen geben und ist wohl auch jemand, der mit Interessierten Leuten gerne mal einen Plausch über das es-65 hält. Außerdem scheint er ja ganz nett zu sein. Man müßte halt dann noch rausbekommen, wer der Herr Ertel (?) oder Hertel (?) war. "1980: Dipl.-Ing. Gerhard Ertl übernimmt die Leitung der Abteilung" läßt darauf schließen, daß man mit dem Namen auf einem Server mit Abschlußarbeiten auch was zum Thema finden kann - und darüber auch potentiell neue Ansprechpartner.


    Und evtl. gibt es ja sogar noch Dokumentation etc. da vor Ort in St.Pölten ...


    https://www.youtube.com/watch?v=VegHB5kYBxU&t=335s

    Prof.Schmid über seinen Einstieg in die Elektronikbastlerei mit Computern


    https://ti.tuwien.ac.at/ecs

    da ist er jetzt, wenn er nicht bei YT ist



    Quelle

    https://www.htlstp.ac.at/abtei…und-technische-informatik

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

    Nach etwas mehr Einblick in den Code: es stehen auffällig zu viele ungültige Opcodes für einen 6502 drin. Es sind allerdings auch keine für den CMOS-Befehlssatz. Wenn die übliche EPROM-Vergeßlichkeit bereits zugeschlagen haben sollte, würde das Gerät allerdings nicht vernünftig funktionieren. Es ist merkwürdig ...

    Ja, das ist komisch aber der code funktioniert. Siehe das folgende Beispiel:

    In der funktion CopyTextBuffer ist einiges komisch jedoch funktioniert die Funktion. Danach kommt noch diese Funktion:


    Bin selber etwas verwirrt. Illegale opcodes vielleicht (Ist ein 6502 NMOS).

    lg.

    Diese brk sind ein deutlicher Hinweis. Das ist Opcode $00, und der ist im NMOS-Befehlssatz definiert und immer dort vorhanden. Es könnte sich um einen Hinweis auf selbstmodifizierenden Code handeln, aber dazu muß dieser Code im RAM stehen. Hier im EPROM nicht ...


    Wg. den vielen ".byte": die wenigsten sind im CMOS-Befehlssatz vorhanden, d.h. es könnte sich wirklich um nicht dokumentierte Befehle handeln. Diese sind allerdings extrem herstellerspezifisch. Daher natürlich die Frage: welcher Hersteller lieferte die CPU für dieses Gerät? Ein ganz harter Gegentest wäre die CPU zu tauschen.


    Eine Idee zu den brk: es gibt in diesem Gerät eine ungewöhnliche IRQ-Mechanik mit mehr Vektoren, als das ein 6502 beherrscht. Zudem stehen die Vektoren im EPROM und die beiden Vektoren für IRQ und Reset sind dieselben. Der Code, der nach dem Reset-Vektor ausgeführt wird, ist tatsächlich die Initialisierung von CPU und Hardware, aber sicher kein IRQ-Service-Code. Gibt's in diesem Bereich ein RAM im Hintergrund, das unter gewissen Randbedingungen benutzt wird, und in dem modifizierter Code aus dem EPROM rüberkopiert wurde?


    Welches ROM hast Du im Bereich $Axxx eingeblendet? Ich habe es hier mit dem P0 probiert, das einen anderen Inhalt enthält.

    $Axxx ist banked ROM da wird alles eingeblendet wann die CPU es will oder braucht. Der User hat keinen Einfluss darauf. In P3 ist z.Bsp. der Assembler drinnen. Sobald man den started wird ROM umgeblendet. In P2 ist die commandline drinnen und auch der Editor (zumindest der start). Die Vektoren für IRQ und RESET sind nicht dieselben!


    Dann steckt in dem 2716 auf Position U11, das im oben gezeigten Schaltungsteil der Generierung der IRQ-"Vektoren" in seiner Adreßlage umgeschaltet wird, der Code aus der Datei TGM_hi.bin?


    Soweit habe ich das verstanden: 8 IRQs und 8 Vektoren zwischen $FFE0 und $FFEF. Sehr trickreich :) Das bedeutet auch, daß bei brk der IRQ-Vektor ohne Hardware-Modifikation genommen wird, und der ist zufällig derselbe wie Reset. D.h. ein brk bedeutet Neustart.

    Guten Abend

    robert_99

    Anhand dem Aufdruck Ing. E Steiner 1130 Wien welcher auf einer Einsteckkarten links unten könnte ich mir folgendes mit viel Phantasie vorstellen, hat zwar mit der Technik selbst nichts zu tun, aber ggf. kann man da ja auch anfragen


    Der Server war eine Auftragsarbeit, gefertigt von Ing E Steiner aus Wien, war ggf auch eine Firma


    nach mehreren Suchanfragen käme ein Ing Ernst Steiner am Nächsten in Frage, welcher 1989 zusätzlich eine Personal Dienst Leistung / Zweig gegründet hat,


    https://www.steiner-hitech.at/ueber-uns/unsere-geschichte/

    Weißt Du, welchen Wert die CPU mit den Befehlen LDA $FFFA liest? Der Befehl kommt zwei Mal vor.

    $FFFA ist der NMI Vector. Der wird umgebogen auf $FFF0 oder $FFF2 oder $FFF4 oder $FFF6 je nach Stellung der Bits PB0 vom 6522 oder MOVE_NMI von U7 welcher wiederum auf 0xF8D0-0xF8DF gemappt ist. Daher ein (dummy) schreiben auf $F8D2 löscht das Bit und ein schreiben auf $F8DA Setzt das Bit.

    Ist alles recht ausgefuchst. Meine Hochachtung an den der sich das ausgedacht hat.

    Übrigens Danke für alle Vorschläge zur Informationsfindung. Ich habe bereits mit drei Personen Kontakt gehabt welche in der Entwicklung involviert waren. Inklusive Hr. Steiner. Leider gibt es keine Unterlagen mehr. Die ursprüngliche Firma wurde verkauft inkl. aller Unterlagen. Die Personen die an die Hard- und Softwareentwicklung beteiligt waren wissen auch nichts mehr. Einer ist gestorben.

    lg. Robert

    Zitat von robert_99

    $FFFA ist der NMI Vector. Der wird umgebogen auf $FFF0 oder $FFF2 oder $FFF4 oder $FFF6 je nach Stellung der Bits PB0 vom 6522 oder MOVE_NMI von U7 welcher wiederum auf 0xF8D0-0xF8DF gemappt ist.

    Ok, ich war da einem falschen Gedanken aufgesessen. Das Lesen vom EPROM-Inhalt ist wirklich nur abhängig von der Adresse. Dann nehme ich den Ablauf vom brk zurück.


    brk müßte demzufolge wie IRQ0 und IRQ7 bei $899C landen, und dieser Code wird mir zu unverständlich, weil da noch diverse Nebenwirkungen drinstecken können, die in Hardware gegossen sind.


    Ich fühle bei diesem System-Design allerdings weniger Hochachtung vor der (unnötigen) Komplexität. Denn die (von mir vermutete) Funktion hätte man um 1980 herum auf anderen Wegen ebenso erreichen können. Neben den vielen Hardware-Tricks fielen mir in der Software noch die undurchsichtigen Stack-Aktionen auf. Es werden Werte aus dem Stack gelesen (lda $010N,x), damit gerechnet und auch Werte wieder zurückgeschrieben (sta $010Nxx). Und diesen Stack gibt es vier Mal parallel. Gruseliges Software-Design, IMHO.

    Zitat von RalfK

    Es werden Werte aus dem Stack gelesen (lda $010N,x), damit gerechnet und auch Werte wieder zurückgeschrieben (sta $010Nxx). Und diesen Stack gibt es vier Mal parallel.


    Klingt doch eigentlich sinnvoll, wenn da 4 User dran sind.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

    Zitat von ThoralfAsmussen
    Zitat von RalfK

    Es werden Werte aus dem Stack gelesen (lda $010N,x), damit gerechnet und auch Werte wieder zurückgeschrieben (sta $010Nxx). Und diesen Stack gibt es vier Mal parallel.


    Klingt doch eigentlich sinnvoll, wenn da 4 User dran sind.

    Das scheint unabhängig voneinander zu sein. Ich gehe davon aus, daß jeder Nutzer eine der unteren RAM-Bänke exklusiv nutzt, auch wenn ich die Umschaltmechanik nicht erforscht habe.


    Die Rechenoperationen auf dem Stack sind aus einer ganz anderen Rubrik. Das ist einfach nur ziemlich undurchsichtig. Da braucht der Entwickler während seiner Beschäftigung mit dem Code eine Skizze, was wo gerade auf dem eigenen Stack abgelegt ist. Für ein Entwicklerteam ist das zu undurchsichtig, und wartbar eher auch nicht.

    Sodele, mir hat die Sache mit dem BRK keine Ruhe gelassen :) Das sieht mir momentan aus wie ein etwas spezieller Unterprogrammaufruf. Der landet wie IRQ0 und IRQ7 bei $899C. Dort wird erstmal am VIA-Chip von der MUC-Karte an den Ausgängen PB6 und PB7 "gebastelt", d.h. die werden beide auf '0' gesetzt. Du hast im Schaltplan allerdings keine Verbindung beschrieben. Im Anschluß wird festgestellt, daß die IRQ-Quelle "nur" ein BRK ist, es wird nochmal an diesen Port-Bits gebastelt und der IRQ-Service vorbildlich verlassen.


    D.h. ein BRK-Befehl bewirkt etwas an vermutlich zwei Port-Bits auf der MUC-Karte. Somit hat der eine Funktion und kehrt wieder an die Stelle zurück, wo er herkam. Ist das eine Bankumschaltung?

    Wenn was nicht im Schaltplan ist dann ist es wahrscheinlich nicht angeschlossen / bestückt. Die Hardware kann noch mehr als bei meinem Modell bestückt ist (siehe Fotos). Soweit ich das erkennen kann ist PB7 direkt auf CA1 verbunden (mit Jumper) und gibt ein 50Hz Rechtecksignal aus (gemessen), PB6 ist nicht verbunden.

    Zitat von robert_99

    Soweit ich das erkennen kann ist PB7 direkt auf CA1 verbunden (mit Jumper) und gibt ein 50Hz Rechtecksignal aus (gemessen), PB6 ist nicht verbunden.

    Dann ist es relativ sinnlos, was die Software an dieser Stelle macht. Die 50Hz kommen aus dem freilaufendem Timer 1 vom 6522, nur darf man dem nicht so einfach am Port-Pin reinpfuschen, IMHO. Hm, schon wieder was Merkwürdiges ...

    CA1 ist immer ein Eingang und kann unter anderem einen Interrupt auslösen.

    Der Timer hat PB7 als Ausgang im Square Wave Modus.

    Das macht doch Sinn!