Gute Frage... da das Datenblatt von dem Ali M5818 in der Digitalen Müllhalde nicht aufzutreiben ist, ist die Frage schwer zu beantworten.
Beiträge von Norbert-97801
-
-
Ich würde mal davon ausgehen, das es bei dem Chip ähnlich ist, wenn er "Austausch-Kompatibel" ist.
-
Pin 21 soll laut Datenblatt einen internen Pull-Up haben, wenn es ein DS12887A oder ein DS12C887A ist und sollte extern keinen weitern Pullup bekommen. und auch nicht mit GND verbunden werden - ausser du musst das RAM löschen...
Seite 10 im PDF:
https://www.analog.com/media/en/technical-documentation/data-sheets/DS12885-DS12C887A.pdf
-
Das Problem dürfte eher darin zu suchen sein, das der DS1287 mit Uhr/Cotrolregister (14 Byte) "nur" 64 Byte hat und der DS12887+ hat 128Byte inclusive 14 Byte für die Uhr/Controlregister. Ich vermute, das das Speicher-Mapping zwischen den beiden nicht kompatibel ist...
-
So ein ähnliches Thema hatten wir schon mal... der ATMega2560 mit 16MHz dürfte dafür zu langsam sein...
-
Gute Arbeit... fehlt nur noch Y/Z...
hast du einen Schaltplan? und würdest du die Firmware "freigeben"? -
Commodore hebt dafür extra mit einem Spannungsteiler am ground des 7805 das Niveau um 0,2V an.
Der Spannungsteiler bei den C64-Netzteilen, die ich bisher in der Hand hatte, bestannd immer aus einem 1KOhm-Widerstand zwischen GND-Pin des 7805 und Netzteil-GND...
-
Bei manchen Modellen kann man allerdings die Firmware austauschen. Da ist ein ATmega644 oder so drin und es gibt eine freie Firmware dafür irgendwo im Netz. (wenn ich mich recht entsinne)
Die Firmware gibt es Microcontroller.net. Ich habe mir dort auch die Schaltpläne gezogen und das Teil selber aufgebaut - mit einem ATMega644. Als Stromversorgung verwende ich ein LiIon-Akku von einem SIEMENS S4 Handy, der übrig geblieben war... funktioniert gut.
-
And another question:
What is the brown wire? I can't find it in the documents and where does it have to be connected?
Maybe it is the final solution?
looks like an trace repair...
-
- 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.
-
Dann war es ein SINIX-L...
-
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.
-
Haben die blauen 7-Segment-Anzeigen eine gemeinsame Kathode?
-
Deswegen sollten wir mal telefonieren...
-
Das freut mich, das die Maschine wieder bootet... hast du selbst neu installiert oder ist das noch das Original-System auf der Platte?
-
Ich denke, da wirst du Pech haben. Die VcFe 23.0 ist doch verschoben worden: https://www.vcfe.org/D/
-
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?
-
Ja, stimmt... aber du sgtest auch, das du die Platinen auf einen nicht-roten Hintergrund nochmal ablichten wolltest... :
(Das mache ich nach Ostern dann noch mal anders - der Hintergrund ist bääh :))
Aber die Oster-Zeit ist ja erst mit Pfingsten vorüber...
-
Auch von mir alles gute und ich wüsche erfolgreiches gelingen in Anbetracht des riesigen Berges Arbeit, das da auf dich und deine Familie wartet... Ich hoffe, das es nicht so schlimm ist, wie es sich anhört...
-
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...
-
Wie dumm kann man nur sein, und die Waren, die man verschickt nicht Polstern? 20€ habe für alles bezahlt.
forum.classic-computing.de/index.php?attachment/193405/forum.classic-computing.de/index.php?attachment/193406/forum.classic-computing.de/index.php?attachment/193407/forum.classic-computing.de/index.php?attachment/193408/
Die Bilder sind leider nicht zu sehen...
-
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...
-
Frohes Fest,
euer van Gogh
Solange du dir dein Ohr nicht abschneidest, ist alles gut...
-
Machst du mir noch ein paar Platinen-Photos von dem Reiser-Board und von dem Mainboard?
-
Die Entstörkondensatoren in meinen beiden RM200-Netzteilen sind unauffällig und OK... ich denke, der muss nicht getauscht werden.
-
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.
-
Funktioniert die Degaus-Schaltung von dem Monitor noch? Derartige Farbfehler können von einer zu stark magnetisierten Bildröhre stammen...
-
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...