Beiträge von Norbert-97801

    - bissi C auf ner R5000 programmieren :)

    Das wird etwas kompliziert, denn es wird mit dem GCC "nur" 32-Bittig funktionieren und leider ist der GCC-SINIX-Support auch schon abgekündigt vom GCC-Team.


    Der CDS++ von Fujitsu-SIEMENS benötigt leider einen Lizenz-Key, der mir bisher noch nicht über den Weg gelaufen ist. als man CDS++ bei Fujitsu-SIEMENS noch kaufen konnte, sollte die Lizenz ca. 16.000,-- € kosten. Aber es muss sie gegebn haben, da ich eine Installations-CD dazu habe.

    . Das wären 500 bps?

    das solltest du nach mal nachprüfen: die Tastatur sollte eine Datenrate von 600Bit/s haben, wenn die Tastatur ohne einen Takt Daten liefert (Asynchrone Schnittstelle). Dann sollte die Tastatur die Belegung auf dem 5poligen Dioden-Stecker haben, wie das Bild mit der Pinbelegung, das fritzeflink auch schon gepostet hat... Passt also. :)

    Vorher waren das Systeme mit 486er und SINIX-H wenn ich mich richtig entsinne.

    Da muss ich dir leider widersprechen: SINIX-H ist die SINIX-Version ist für die MX300 mit NSC-Prozessor - Das ist die Version SINIX 5.20 bis SINIX 5.24.


    Wenn es SINIX-H war, dann waren die dazugehörigen Rechner MX300 mit NSC-CPUs der 32k-Reihe wie dem NSC32332 und dem NSC32532 und haben den Intel Multibus I.


    Für Intel-Kompatible PCs gab es SINIX-D und SINIX-K (SINIX ODT, eine SCO-Variante). Eine weitere Variante, SINIX-V, für Beatle-Kassen-Systeme, die auch PC-Kompatibel waren, aber als Kassen-System mit Spezial-Anschlüssen für POS-Displays und Kassen-Schubladen ausgestattet waren (sind?)...

    Und dann gab es noch SINIX-Z für PCs, das bei der Entwicklung von SINIX-L für die MX300i (mit Intel-Prozessor) mit entstanden ist...

    Ich vermute mal, das der Tausch der Treiber-Bausteine nichts bringen wird. Die blauen LEDs haben, wie du ja selber geschrieben hast, einen UF von 3,3V, die roten und grünen LEDs 2,3V bzw. 2,5V. Damit dürfte die Schaltschwelle für den Darlington-Transistor ca. 0,8V bis 1V höher liegen. Wie viel V hat der H-Pegel, wenn der Treiber die LED ansteuert?


    Im Moment sieht es ja so aus, das R5 0 Ohm hat. Damit sieht der Spannungspfad der Treiber-Schaltung wie folgt aus: +5V --> R5 (0 Ohm) --> RL (10 Ohm) --> [1234]C (75491) ---> [1234]E (75491) ---> blaue LED (A) / blaue LED (K) ---> [123456]Y (75492) ---> GND


    Die Rechnung habe ich mal vereinfacht: Den Spannungsabfall (wenige mV) an RL habe ich außer acht gelassen, den VCE der beiden Treiberstufen: je 0,7V angenommen, die blaue LED hat ~ 3,3V macht in summe 4,7V. Ich gehe davon aus, das der High-Pegel von den Eingängen [1234]A (75491) in diesem Fall jenseits der +5V liegt, denn der 75491 ist ja der "High site" NPN-Treiber. Die Clamping-Diode am Eingang wird die Eingangs-Spannung von A auf VSS + 0,7V(max.) begrenzen.


    Das dürfte der Grund sein, warum die blauen LEDs nicht leuchten.


    Den VSS von dem 75491 zu erhöhen, könnte das Problem zum Teil lösen, aber die 100 Ohm-Pullup's an den Eingängen müssen auf VSS-Pegel der High-Site-Treiber liegen. Das könnte dazu führen, das die Ausgänge der 8255 überlastet werden, weil der Strom zu groß wird, bzw. die Spannung dem 8255 nicht bekommen wird, da er an den I/O-Pins "nur" max. VCC (also 5V) verkraftet...


    Die Schaltung zwischen den I/O-Pins und den High-Site-Treibern müsste ggf. auch noch mal angepasst werden.

    Auf dem 2. Bild sieht es so aus, als ob du (oder der Vorbesitzer) "." und "," ( ">" und "<") vertauscht hättest...


    Ist in dem Terminal ein Drucker für Bildschiremabzüge etc. drin?

    Okay! Mir waren tatsächlich nur die wesentlichen Änderungen, dass die DNS Anfrage über einen verschlüsselten Kommunikationskanal läuft und die Metdadaten reduziert werden, um so die Pakete klein zu halten, bekannt.

    Das mag zwar sein, das eventuell die Metadaten veringert werden, aber nur dann, wenn die HTTPS-Verbindung für den DNS im hintergrund dauerhaft offen gehalten wird. Selbst dann kannst du immer noch Datum und Uhrzeit festhalten, wann eine Abfrage lief. Also nicht wirklich "Datenspaarsamer".


    Nichts dest troz halte ich persönlich DNS Over HTTPS für ein "Schwachins-Konstrukt" weil die HTTPS-DNS-Resolver-Pflege neben dem normalen DNS-Resolvern dann zusätzlich im Browser mit gemacht werden muss - und sei es auch nur, das dieser Resolver abgeschaltet wird - Welcher "Normal-Anwender" wird das auf anhieb können? Ganz zu schweigen davon, das die Abfragen wahrscheinlich dann alle primär bei Google, Facebook & Co. landen werden - von wegen "Privacy" und für Endanwender "einfach" zu pflegende Systeme...

    Apropo Privacy:
    Es Ist aber auch eine Frage der Abfrage-Reihenfolge. Wenn ich intern auch URLs wie wwwdev01.nnrz.de (die Domäne nnrz.de gehört mir, deswegen das URL-Beispiel) im Browser verwende, dann würde der Browser die Anfrage zuerst in die große, weite Welt schicken, um dann festzustellen, das dieser Name nicht extern verwendet wird, und nur der interne DNS die Antwort kennt. So wissen die externen HTTPS-DNS-Betreiber, wie es bei mir intern teilweise aussieht. Ich habe zwar nichts zu verbergen, aber ich möchte doch selber entscheiden, wem ich was erzähle... ;) ... so viel zum Thema Privacy bzüglich DNS over HTTPS.


    Das wird in der Zukunft sogar noch lustiger.


    Google hat Ende 2023 einen neuen Record-Typ für DNS vorgeschlagen, den HTTPS Record. Darin können u.a. Vorgaben hinterlegt werden, welche HTTP Version genutzt werden darf und es können Backup- Webserver aufgeführt werden. Das geht mit Prioritäten ähnlich den MX Records für Mailexchanger. Diese Einträge wertet auch der Browser aus, der Resolver des Betriebssystems ist außen vor.

    Lustig - jetzt wollen die die RZ-Load-Balancer-Funktionen in den DNS / Client-Webbrowser verlagern. So können Google & Co ihre gewinne weiter maximieren... ;) ... weil teure zusatz Hard-/Software eingespaart werden kann...

    Ich habe doch geschrieben das ich einen Takt habe . An pin 6 liegen 2Mhz an . Ich bin nur verwundert wie unsauber das Rechteck Signal ist .

    Die Steuerung läuft aber trotzdem nicht . Könnte der Processor einen Schaden haben .

    Wenn ich dich richtig verstanden habe, ist das Signal am 74LS04 (20MHz) vorhanden. Wenn du an der CPU dann 2MHz hast, und der Signalverlauf "unter aller Sau" ist, würde ich mir den in der nähe beheimateten Teiler ansehen. Ich würde dann vermuten, das der dann einen an der Waffel hat...

    Stimmt. Es muss ein stärkeres Magnetfeld in der nähe sein, wenn das Bild sich nach dem Degaußing so verfärbt. Ich würde sogar mal vermuten, das die Störquelle unter dem Monitor zu suchen sein müsste, da das Bild sich an der Unterkante gleichmäßig verzerrt.

    Während meiner Schulzeit haben wir einen defekten Farbfernseher in Röhren/Transistor-Technik während des Physik-Unterrichts repariert (Mitte der 80'er). Der Lehrer hat da auch Grundlagen (Ohmsches Gesetz, Funktion von Transistor/Röhre, etc.) angesprochen, ebenso die Gefahren der Hochspannung. Es gab auch "Wahlpflicht-Fächer" zum Thema Elektronik, in denen die Lehrer (meiner Meinung nach) nicht einfach "herum gelabert" haben. Ich weiß nicht, wie das heute ist, aber ich hatte während meiner Schulzeit engagierte Lehrer, die es auch geschafft haben die Neugier bei solchen Themen zu wecken... ;) ... daraufhin habe ich ja meine Lehre bei SIEMENS gemacht... :)

    inidraki , ich habe einen kleinen Vorschlag zur Güte: wenn du schon Emojis verwenden möchtest, und nicht auf sie verzichten magst: eventuell ist es dir ja möglich, die in dem Forum angebotenen, grafischen Versionen zu verwenden, damit wir hier kein Lexikon "ASCII-Emoji - Deutsch" verwenden müssen. Die von dir verwendeten "ASCII-Emojis" sind zimlich anstrenged zu übersetzten / Interpretieren. :)



    Viele Grüße

    ::pc:: :wegmuss:

    Welche CF-Karten hast du verwendet? Eventuell beherrschen sie die CHS Adressierung nicht mehr. Ich habe hier auch welche, die nur noch LBA können und deswegen in meinen SIEMENS PCD-4T oder älter nicht funktionieren. Die BIOSe können die HDs nur mit CHS ansprechen. Eventuell macht das XT-CF-BIOS was ähnliches...

    Dass der OP das Phänomen in gleich zwei 8032-SK hat, was natürlich ein Serienproblem ausschliesst ( ;) ) und das Problem auftaucht/verschwindet, wenn man den Rechner aufklappt/zuklappt, lässt in meinem persönlichen Tipp den Spielstand Wackelkontakt : Elkos zugunsten Wackelkontakt driften.

    Das hat der OP ja noch nicht geschrieben, ob mit dem vermutet defekten EPROMs der Fehler mitwandert...

    Ich denke, da sind ein paar Elkos in der Bildschirm-Elektronik "grenzwertig" unterwegs, die bei Erwärmung z.B. in ihrer Kapazität anfangen zu driften. Das Problem, das auch (eine) Kalte Lötstelle(n) für Probleme sorgen können ist ja auch noch nicht aus der Welt. Hatte CBM_Ba letztens nicht ein ähnliches Problem mit einem CBM-Monitor oder jemand anderes?


    PS: in meiner SIEMENS 8160 habe ich ein ähnliches Wärme-Problem, da die Vektor-Zeichen zwischendurch immer mal wieder nach links weg kippen und das Bild unleserlich wird... ich tippe da auf Elkos in den X- und Y-Verstärker-Baugruppen.

    Ich finde auch, das man die Wünsche des Spenders berücksichtigen sollte muss. Ich habe auch schon Festplatten bekommen, die vergessen wurden zu löschen. Da das Boot-System-Platten aus einer RM400-E60 waren, hätte ich liebend gern auf den Platten nach Software-Lizenzen geschaut. Das aber habe ich mir schweren Herzens verkniffen und die Festplatten unter Linux mit dd gelöscht, bevor sie wieder in die RM400 reinkamen.


    Eine Wiederherstellung der Daten sehe ich auch eher kritisch, zumal der abgebende Mensch ja, meiner Meinung nach, seinen willen schon deutlich gemacht hat, auch wenn er das nicht nach den BSI-Empfehlungen gemacht hat... ;)



    PS: bevor die Frage kommt, woher ich wusste, das der abgebende die Platten gelöst haben wollte: ich hatte ihn gefragt, ob die Festplatten gelöscht sind... :)