Hallo an die "alten" Hasen hier im Forum die mit Röhren-TVs noch was anfangen können :-) Ich bin leidenschaftlicher Retro-Elektronik-Sammler und stehe vor der Herausforderung das ich von meinem "nativen" NTSC-VHS-Rekorder auch gern mal "natives" NTSC auf der Röhre sehen möchte. NTSC-Fernsehgeräte sind hierzulande praktisch nicht zu bekommen, ein Transport aus USA/Japan eher unerschwinglich und da wäre meine, vielleicht etwas naive Frage: Was bestimmt in einem Farb-Röhren-TV, welcher nur als reiner Monitor dient (also nur S-Video Eingang, kein Tuner-Betrieb) ob dieser PAL oder NTSC darstellt? Habe auch schon überlegt ob man hierzulande ein Gerät bekommt (wegen Transport und Röhre) und die Elektronikplatine aus USA/Japan. Aber das ist ähnlich schwierig, finde ich. Was unterscheidet diese Geräte und ist es möglich einen Umbau in Betracht zu ziehen? Hier als Beispiel das TV-Gerät welches ich aktuell für PAL verwende mal als Schaltplan beigefügt. Ich denke der Y/C Filter am S-Video Eingang müsste angepasst werden und dann natürlich das Timing-Thema. Hier frage ich mich wie groß der Hersteller die Unterschiede in der Elektronik machen musste? Völlig eigenes Board oder nur ein paar spezielle, in der Produktion leicht auszuwechselnde Komponenten? (Quarz, IC, Jumper, ...) Aktuell nutze ich einen "Grundig ST70-780 text" um PAL-Aufnahmen anzuschauen. Dieser ist laut Datenblatt nur PAL-Tauglich. Es gibt aber auch einen "Grundig ST70-780 FR/TOP" (was auch immer diese Buchstaben hinten bedeuten mögen) und dieser kann auch NTSC. Habe von beiden mal das Service-Manual angefügt, vielleicht erkennt man dort ja Unterschiede die man ggf. nachrüsten/umrüsten könnte. Ich habe bereits an TVs gearbeitet, mir ist die Problematik mit Hochspannung, etc. geläufig, so ganz unbedarft bin ich da nicht. Aber ich bin kein gelernter R/F-Techniker.
:
Verschoben durch Admin
Ohne das Service-Manual genauer betrachtet zu haben, laut Seite 3 des Manuals scheint es sich um ein Multinormgerät für PAL/Secam/NTSC zu handeln.
Die Farbträgerfrequenz ist unterschiedlich: https://dewiki.de/Lexikon/PAL_(Fernsehnorm)#Wahl_der_NTSC-Farbtr%C3%A4gerfrequenz Auch der Tonabstand ist anders. Gruss
Rainer D. schrieb: > Ohne das Service-Manual genauer betrachtet zu haben, laut Seite 3 des > Manuals scheint es sich um ein Multinormgerät für PAL/Secam/NTSC zu > handeln. Sorry, mein Beitrag war nicht perfekt. Ich habe nicht den FR/TOP sondern nur den "text". Habe das oben im Beitrag korrigiert. Die "Prozessorplatte" scheint bei beiden gleich zu sein (Seite 46, bzw. 42). In beiden Modellen kommt der Multi-Norm Filter TDA8843/44 bzw. TDA8375 (alternativbestückungen) zum Einsatz. Im Schaltplan vom "text" ist sogar der 3,58 MHz Quarz eingezeichnet, allerdings mit dem Zusatz "Multi". Müsste mal nachsehen ob der auf meiner Platine auch drauf ist...
:
Bearbeitet durch User
Olli Z. schrieb: > Sorry, mein Beitrag war nicht perfekt. Ich habe nicht den FR/TOP sondern > nur den "text". Habe das oben im Beitrag korrigiert. Es scheint fertige Wandler zu geben. Hab mich aber auch noch nicht damit befasst. https://www.google.com/search?client=firefox-b-d&q=ntsc+pal+wandler https://www.amazon.de/Unbekannt-VD002-Bidirektionaler-PAL-NTSC-Converter/dp/B0089OGNXW
Die Angaben: "PAL/SECAM/NTSC 4,43MHz B/G, I (Mono), L/L" auf Seite 1-3 verstehe ich auch nicht, da 4,43 MHz für NTSC völlig unüblich ist. Die Farbträgerfrequenz bei NTSC ist nämlich 3,58 MHz. NTSC mit 4,43 MHz habe ich jedenfalls nie erlebt. Ob man NTSC durch einfachen Tausch des Quarzes auswerten kann, würde ich bezweifeln. Was man sonst noch alle machen müsste, kann man nur durch umfangreiches Studium der Service-Unterlagen herausfinden. Sollte man in den Unterlagen aber einen Quarz von 3,58 MHz entdecken, hat man wahrscheinlich Glück und die Angabe auf Seite 1-3 war einfach ungenau und die NTSC-Decodierung erfolgt mit den korrekten 3,58 MHz. Dann muss man nur herausfinden, wie die Normenumschaltung bei diesem Gerät erfolgt (automatisch oder über eine / welche ? Schaltspannung. Wenn ich mehr Zeit als jetzt habe und bis dahin die Antwort noch nicht erfolgt ist, kann ich ja mal nachforschen.
Üblicherweise sind Decoder eigene Baugruppen und die lassen sich normalerweise austauschen, wenn sie von den Anschlüssen her kompatibel sind. Wir standen ja in der DDR vor dem gleichen Problem, da unsere Geräte Anfangs nur SECAM konnten und somit Westfernsehen in Farbe nicht möglich war. Wer dei entsprechenden Connections hatte hat sich dann einen PAL-Decoder schicken lassen, der dann sogar in unseren Geräten funktioniert hat. Ob man die Karten nur austauschen mußte oder ob da noch mehr zu tun war kann ich nicht sagen.
Zeno schrieb: > Wir standen ja in der DDR vor dem gleichen Problem, da unsere > Geräte Anfangs nur SECAM konnten und somit Westfernsehen in Farbe nicht > möglich war. Wer dei entsprechenden Connections hatte hat sich dann > einen PAL-Decoder schicken lassen, der dann sogar in unseren Geräten > funktioniert hat. Was für ein Wunder... Das lag einfach daran, dass (nahezu) dieselben Geräte (Color20, Color22) unter anderen Labels und Typenbezeichnungen auch im Westen vertickt wurden. Dort hätten sie natürlich keine Chance, wenn sie nicht auch PAL gekonnt hätten. Also gab es eine Ausstattungsvariante mit PAL-Decoder. In der Ost-Version war der schlicht nicht bestückt. > Ob man die Karten nur austauschen mußte oder ob da > noch mehr zu tun war kann ich nicht sagen. Sie mussten nicht ausgetauscht werden, sondern der PAL-Decoder wurde einfach zusätzlich eingebaut. Zusätzlich musste der in der Ost-Version mit "Farbe/SW" beschriftete Schalter zum "SECAM/PAL"-Schalter umgerüstet werden. Der hatte genug freie Kontakte dafür (auch wieder: kein Wunder...).
Olli Z. schrieb: > Müsste mal nachsehen ob der auf meiner Platine auch drauf ist... Jaja, das wäre natürlich zuviel verlangt. Daher auch der Konjunktiv "müsste". Das kann niemand von Dir verlangen, dass Du da einfach selber nachsiehst. Nicht, dass Du Dich noch überarbeitest. Du Armer! Noch schlimmer wäre es, die info-Taste auf der Fernbedienung drücken zu müssen. Wo die jetzt gerade rumgeistert, die doofe Fernbedienung? Am End' noch die Fernbedienung in die Hand nehmen müssen?!? Puuuh, vielleicht irgendwann mal nächstes Jahr... Mit der i-Taste könnte "man" (Du selbstverständlich nicht, Gott bewahre!) den "Dialogcenter" aufrufen und "Tint" verstellen... oder es eben besser gleich sein lassen. Die drohende Überanstrengung so zwischen den Feiertagen. Was "da" passieren kann, nicht auszudenken!
Günni schrieb: > NTSC mit 4,43 MHz habe > ich jedenfalls nie erlebt. https://en.wikipedia.org/wiki/NTSC#NTSC_4.43
Angehängte Dateien:
-
ic34015_tv-processor.png
110 KB -
tda4665_64_s_delay.jpg
190 KB -
SDA_5256C.jpg
140 KB -
processor_matrix.png
27 KB
Günni schrieb: > Sollte man in den Unterlagen aber einen Quarz von 3,58 MHz entdecken, > hat man wahrscheinlich Glück und die Angabe auf Seite 1-3 war einfach Das habe ich und zwar im "CUC 2030" ("text") Manual auf Seite 44. Der gelb hinterlegte 3,58 MHz Quarz sowie der Kondensator fehlten auf meinem Board. Ich habe nicht wirklich damit gerechnet das es sooo einfach ist, aber natürlich habe ich beides nachgelötet, aber leider ohne Änderung. Der Hinweistext "Multi" könnte durchaus auf Multi-Norm hindeuten... > Dann muss man nur herausfinden, wie die Normenumschaltung bei diesem > Gerät erfolgt (automatisch oder über eine / welche ? Schaltspannung. Dafür gibt es im Service-Dialog eine Einstellung. "auto", "PAL", "NTSC", "SECAM", pro Kanal wählbar. Die hatte ich schon vorher entdeckt aber ohne den Quarz kann das natürlich schon grundsätzlich nicht funktionieren. Aber auch nach der Nachrüstung ändert sich nichts durch das umschalten. Meine kleine Hoffnung war, das anscheinend wenigstens die Firmware im Gerät Multinorm kann. So weit ist der Hersteller dann wohl auch nicht gegangen für jede Norm eine angepasste Firmware herzustellen. Aber es gibt noch zwei weitere Komponenten deren Betrachtung lohnt: 1.) Die 64µs Verzögerungsleitung, im "CUC 2030" mit einem TDA4665 realisiert (siehe Bild). Hier müsste für NTSC doch eher eine 52µs Variante zum Einsatz kommen? Der oberhalb vom TDA freie Platz auf der kleinen Senkrechtplatine (IC35400) ist für einen TDA8395 gedacht, ein SECAM-Decoder. 2.) Der Zentralprozessor (siehe Bild), der ein schon markantes "PAL" auf dem Gehäuse trägt... im Datenblatt ist mein Modell also ein 29305-119.37 und hat damit den "SDA5256CG001" von Siemens und dieser kann wohl nur die NORM "INL", was auch immer das bedeutet? "International"? Ich vermute das die NORM "FR" vielleicht France und damit SECAM bedeutet und "NIC" dann NTSC"? Womöglich stehen die Buchstaben aber auch für Ausstattungslinien (2te Scart-Buchse, PIP-Board, Dolby-Surround, etc.
:
Bearbeitet durch User
"NIC" steht für NICAM, eine früher in skandinavischen Ländern benutzte Tonnorm.
Die Firmware steht im EPROM 27C512, wovon es einige Nachbesserungen gab. Bei einem Grossteil der Serie wurde der NTSC-Farbträger-Quarz 3,579.. MHz nicht bestückt.
Nichtverzweifelter schrieb: > "NIC" steht für NICAM, eine früher in skandinavischen Ländern benutzte Tonnorm. Interessant. Mein Gerät "ST70-780 TEXT" ist laut Gerätelabel und Datenblatt ein "CUC 2030" und das kann nur PAL. Dann gab es da noch den "ST70-780 NIC/TOP", ein "CUC 2030N" der den von Dir genannten Zusatz "Nicam" bei den unterstützten Normen trägt. Und dann ist da noch der "ST70-780 FR/TOP", welcher ein "CUC 2030 F" ist. "TOP" steht dabei wohl für das TOP-Teletext-System. Dieses Modell kann neben PAL auch NTSC. Der Schaltplan vom 2030 F ist praktisch identisch mit meinem Modell. In den Plänen sind die Varianten mit entsprechenden Labeln versehen, z.b. (FR). Neben dem unbestückten Quarz/Kondensator (den ich selektiert habe um die im Plan geforderten 2% Toleranz einzuhalten) finde ich keine weiteren Bauteile die mit (MULTI) bezeichnet sind. Auch komisch das ich den im Schaltplan als Q34044 bezeichneten Quarz nicht in der Teileliste vom CUC 2030 FR finde, obwohl dieses Gerät ja NTSC können soll.
:
Bearbeitet durch User
Angehängte Dateien:
Nichtverzweifelter schrieb: > Die Firmware steht im EPROM 27C512, wovon es einige Nachbesserungen gab. In dem CUC 2030 gibt es das wohl nicht, das ist nur vorhanden wenn eine Prozessorplatine drauf ist. Bei meinem Modell "TEXT" und dem "FR" ist nur ein X24C08 I2C EEPROM dran (siehe Bild). > Bei einem Grossteil der Serie wurde der NTSC-Farbträger-Quarz 3,579.. > MHz nicht bestückt. Sicher hat man die zwei Bauteile für vermutlich 0,10€ pro Gerät eingespart. Aber entweder ist die Firmware im Eeprom vom FR anders oder es fehlt noch irgendwo ein "Jumper" (0 Ohm Widerstand), wie der mit (FR) gekennzeichnete...
Hallo Olli, leider hat ein fachkundiger Moderator Deinen Röhrenfernseher-Thread in die Rubrik "Smart Home" verschoben. Zu Deinen Fragen: Ja, die 64 Mikrosekunden Verzögerungsleitung wird mit dem genannten IC realisiert, für NTSC erübrigt sich selbige prinzipbedingt. Die Addition "zwischengespeicherte Zeile" mit "nachfolgender Zeile" findet gar nicht statt. Im 24C04 oder 08 steht keine Firmware, sie ist im Bedienteilprozessor mit drin. Dein SM ist die früheste Ausgabe, siehe Standbyverbrauch: " noch nicht bekannt". TOP bezieht sich auf den Textdecoder:"Table of Pages".
Der TDA8843 ist ein PAL Dekoder, während der TDA8844 eben ein PAL/NTSC Dekoder ist. Nur der TDA8844 oder w.w. (wahlweise) der TDA8375 sind Multinorm Chips und akzeptieren auch den 3,58 MHz Quarz. Davon unabhängig können beide Varianten noch den SECAM Dekoder einschleifen. Die Frage ist, ob Grundig verschiedene Software für die Geräte ausliefert oder ob die Firmware sich auf die jeweilige Bestückung alleine einstellt. So wie es im Moment aussieht, muss man den SDA5256C-G101 haben, der in die Multinorm Apparate eingebaut wurde. Der vorhandene SDA5256C-G001 ist anscheinend für die PAL/Secam Dinger ohne NTSC.
Hast du keinen Zugriff auf einen Amiga Monitor o.ä. Oder einen Multisync- MNonitor?
Als Vorversuch könntest du mal das Composite-NTSC am Video-In der Scartbuchse einspeisen, um zu checken, ob er Framerate und Zeile noch synchronisiert kriegt. Wenn das funktioniert, kannst du dir immer einen externen NTSC auf RGB Dekoder bauen und den am Scart einspeisen. Sowas kann man z.B. mit TDA3566 lösen und ein wenig Synchronkram.
Hallo, c-hater schrieb: > Das lag einfach daran, dass (nahezu) dieselben Geräte (Color20, Color22) > unter anderen Labels und Typenbezeichnungen auch im Westen vertickt > wurden. Dort hätten sie natürlich keine Chance, wenn sie nicht auch PAL > gekonnt hätten. Also gab es eine Ausstattungsvariante mit PAL-Decoder. > In der Ost-Version war der schlicht nicht bestückt. Blödsinn. Color20/22 hatten nie PAL-Decoder, erst der Chromat hatte einen diskreten PAL-Decoder. Beliebt zum Nachrüsten war ein Grundig-PAL-Decoder Modul, das lief mit wenig Aufwand in jedem Secam-TV. Einfach, weil eben das FBAS-Signal vorn reingnung und hinten die Differenzsignale R-Y und B-Y rauskamen. Da die Grün Dematrizierung bei PAL und Secam im Pronzip identisch ist, nraucht man nur noch den passenden H- und V-Syncronimpuls im jeweiligen Gerät zu beschaffen. Ich habe die Dinger mehrfach eingebaut, meist aber in Radugs-TV oder auch in ein russisches Farb-TV-Koffergrät, Typ da weiß ich nicht mehr. Später gab es dann den MCA-Decoder, PAL/Secam-Kombi, der ließ sich wegen seiner größe in Fremdgeräte meist nicht einbauen. Prinzipiell ist es kein unlösbares Problem in seinen Grundig einen NTSC-Decoder nachzurüsten, Problem wird sein, einen aufzutreiben... Gruß aus Berlin Michael
@Oli-Z Gibt es in den TV's, im Menue Servicebereiche, wo Du nicht hinkommst? - Weil Pincode geschützt.
c-hater schrieb: > Zeno schrieb: > >> Wir standen ja in der DDR vor dem gleichen Problem, da unsere >> Geräte Anfangs nur SECAM konnten und somit Westfernsehen in Farbe nicht >> möglich war. Wer dei entsprechenden Connections hatte hat sich dann >> einen PAL-Decoder schicken lassen, der dann sogar in unseren Geräten >> funktioniert hat. > > Was für ein Wunder... > > Das lag einfach daran, dass (nahezu) dieselben Geräte (Color20, Color22) > unter anderen Labels und Typenbezeichnungen auch im Westen vertickt > wurden. Dort hätten sie natürlich keine Chance, wenn sie nicht auch PAL > gekonnt hätten. Also gab es eine Ausstattungsvariante mit PAL-Decoder. > In der Ost-Version war der schlicht nicht bestückt. Das ist Blödsinn. Die Geräte waren nicht "vorbereitet, daß sie PAL konnten", und "nur nicht mit einem PAL- Dekoder bestückt". ALLE Farbfernseher, DDR,- Geräte, ud sogar die mordsschweren Kisten aus der Taiga ("Raduga", "Rubin") konnten jedoch mit PAL- Dekodern erweitert werden, es gab "wildverdrahtete" Einbauten, aber auch professionell anmutende mit Subplatinen, auf die "West"- Dekoder aufgesteckt wurden. Üblicherweise blieben die SECAM- Dekoder drin, es wurde meist via Relais umgeschaltet.
Günni schrieb: > Die Angaben: "PAL/SECAM/NTSC 4,43MHz B/G, I (Mono), L/L" auf Seite 1-3 > verstehe ich auch nicht, da 4,43 MHz für NTSC völlig unüblich ist. NTSC B/G war in Europa sogar ausgesprochen üblich, denn das wurde von fast allen NTSC-abspielfähigen VHS-Recordern beim Abspielen echter NTSC-Kassetten geliefert. Damit kamen die meisten besseren Fernseher dieser Zeit klar. Mein Favorit ist immer noch Sony Trinitron. IIRC akzeptierte meiner damals auch NTSC-M. Ich hatte mal spasseshalber sämtliche Videonormen meines Philips PM5418 durchprobiert. Überall kam ein stabiles Bild, und fast immer auch farbig.
Soul E. schrieb: > Mein Favorit ist immer noch Sony Trinitron. Aber nur, solange er nicht kaputt ging. Wenn du da die Rückwand aufgemacht hast, bist du erschlagen worden von Kabelsalat, wild montierten Platinen und einer unglaublichen Anzahl von Bauteilen. Ein Glück sind sie nicht oft kaputtgegangen :-) Und das Bild war wirklich gut. Allerdings haben dann auch andere Hersteller später von der alten Delta Röhre Abstand genommen und sind auf Streifentriplets gewechselt. Toshiba hatte dann irgendwas mit 'Q' Technologie, wimre und Panasonic hatte da auch was, dessen Name mir nicht mehr einfällt (GAOO?).
:
Bearbeitet durch User
Moin, Also "kurz nach der Zeit, als Kyrenius Landpfleger in Syrien war", hab' ich mal aus Spass an der Freud' einen alten Grundig Supercolor versucht auf NTSC umzuruesten. Damals gabs noch auf UHF den "AFN Superstation", fuer die amerikanischen Soldaten. Standardmaessig hatte ich eine Glotze mit'm 4.5MHz Keramikfilter und extra Schwingkreis um den TBA120 fuer die Ton-ZF; damit ging Superstation dann wenigstens in SW mit Ton. An einer anderen Glotze hab' ich dann mal den Farbteil etwas mishandelt, um NTSC auch in Bunt zu kriegen. iirc war das: PAL-Quarz durch NTSC-Quarz ersetzen; Oszillatorschwingkreis anpassen; Farbabschalter permanent deaktivieren; Farbverstaerker "neu abgleichen" (d.h. auf Maximum bei 3.58MHz einstellen) - Farben geniessen... Naja, sah' schon sehr bunt aus, auch ein kleines RC Glied irgendwo in der Phasenregelung (weil ja I und Q etwas anders in der Weltgeschichte liegen als U und V) hat's nicht wirklich rausgerissen... z.b. Bill Cosby hatte einen seeehr violetten Teint. War aber eben alles in Glotzen, die weit vor Multinormfaehigkeit waren. Und bei den damaligen Grundigs waren die Ton-ZF und Farbgedoens auf extra Modulen, die konnte man dann wenn man mit Basteln durch war, wieder rausschmeissen und durch andere "Original"Module von der naechsten Sperrmuellabfuhr ersetzen ;-) Gruss WK
c-hater schrieb: > In der Ost-Version war der schlicht nicht bestückt. Und beispielsweise beim Raduga war auch einfach der PAL-Dekoder nicht bestückt? ;-(
Nichtverzweifelter schrieb: > leider hat ein fachkundiger Moderator Deinen > Röhrenfernseher-Thread in die Rubrik "Smart Home" > verschoben. Das wurde wohl wieder berichtigt :-) > Ja, die 64 Mikrosekunden Verzögerungsleitung > wird mit dem genannten IC realisiert, für NTSC > erübrigt sich selbige prinzipbedingt. Die Addition > "zwischengespeicherte Zeile" mit "nachfolgender > Zeile" findet gar nicht statt. Ah, war das wegen der Phasenverschiebung beim PAL notwendig? > Im 24C04 oder 08 steht keine Firmware, sie ist im > Bedienteilprozessor mit drin. Jab, denn die Firmware selbst steckt im ROM des Chips. Und das kleine EEPROM ist nur für die Einstellwerte. Steht auch im SM beschrieben wie man diese neu initialisiert wenn man das EEPROM tauschen musste. Mein Fehler, hätte ich durch genaueres lesen selbst raus bekommen. > Dein SM ist die früheste Ausgabe, siehe > Standbyverbrauch: " noch nicht bekannt". Sicher. Es gibt da so zahlreiche das es echt schwer ist die richtigen rauszufinden. Man muss erstmal durch alle Kürzel und Varianten/Markennamen durchblicken. Dann bauen die teilweise aufeinander auf (Supplementals). Diese Geräte der CUC 2030 Serie, die scheinbar fast baugleich sind können ECHTES NTSC auf der AV-Buchse (3,58 MHz) und haben daher wohl sicherlich den richtigen Chip mit der richtigen Firmware drin: ST 63-701 NIC/TOP (CUC 2030 N) ST 63-706 NIC/TOP (CUC 2030 N) ST 63-712 NIC/TOP (CUC 2030 N) ST 70-701 NIC/TOP (CUC 2030 N) ST 70-706 NIC/TOP (CUC 2030 N) ST 70-712 NIC/TOP (CUC 2030 N) ST 70-712/5 NIC/TOP (CUC 2030 N) Dann gibt es noch eine ganze Reihe mit Pseudo-NTSC auf 4,43 MHz, die mir aber nichts nützen würden. Ich hab schon gesucht aber maximal findet man den 70-712 in Polen (haben die NTSC??) auf alten Archiwum.pl Seiten, also längst verköhert. > TOP bezieht sich auf den > Textdecoder:"Table of Pages". TOP oder TEXT spielt für mich keine Rolle, ebenso wenig der Tuner, das brauche ich nicht. Mir reicht AV.
Angehängte Dateien:
-
27-12-_2021_14-45-31.png
28 KB
Matthias S. schrieb: > Der TDA8843 ist ein PAL Dekoder, während der TDA8844 eben ein PAL/NTSC > Dekoder ist. Nur der TDA8844 oder w.w. (wahlweise) der TDA8375 sind > Multinorm Chips und akzeptieren auch den 3,58 MHz Quarz. Davon > unabhängig können beide Varianten noch den SECAM Dekoder einschleifen. Wenn ich das Datenblatt richtig gelesen habe kann auch der TDA843 NTSC. Der 8844 kann zusätzlich noch SECAM. Und der TDA8375 kann auch alles. Also ist in meinem ST70-780 TEXT auf jeden Fall ein Multinorm fähiger Farbdekoder drin. > Die Frage ist, ob Grundig verschiedene Software für die Geräte > ausliefert oder ob die Firmware sich auf die jeweilige Bestückung > alleine einstellt. Das ist eine sehr gute Frage aber ich fürchte das die Antwort wohl NEIN lautet, die FW, bzw. das ROM ist fest auf bestimmten Chips der SDA5256 Serie einprogrammiert und dafür ist dann wohl auch der Zusatz hinten mit G101. Nur die mit separater CPU-Platine haben ein separates EPROM. Schade... so einen SDA bekommt man praktisch nicht zu kaufen, da müsste man ein altes Gerät ausschlachten und dazu müsste man genau wissen wo die Multinorm-fähigen Mikrocontroller drin sind. > So wie es im Moment aussieht, muss man den SDA5256C-G101 haben, der in > die Multinorm Apparate eingebaut wurde. Der vorhandene SDA5256C-G001 ist > anscheinend für die PAL/Secam Dinger ohne NTSC. Richtig :-/
michael_ schrieb: > Hast du keinen Zugriff auf einen Amiga Monitor o.ä. > Oder einen Multisync- MNonitor? Nein, leider nicht.
Matthias S. schrieb: > Als Vorversuch könntest du mal das Composite-NTSC am Video-In der > Scartbuchse einspeisen, um zu checken, ob er Framerate und Zeile noch > synchronisiert kriegt. Das habe ich schon getan. Sowohl mit dem Rekorder-Ausgang als auch mit meinem Fluke Testbild-Generator. Er kann das Bild stabil darstellen, nur die Farbe stimmt nicht und es sieht aus als habe das Bild ein feines "Schachbrettmuster" überlagert. > Wenn das funktioniert, kannst du dir immer einen externen NTSC auf RGB > Dekoder bauen und den am Scart einspeisen. Sowas kann man z.B. mit > TDA3566 lösen und ein wenig Synchronkram. Ok, klingt interessant, darauf würde ich zurückkommen. Es gibt ja auch (wurde oben schon genannt) fertige Wandler zu kaufen, um die 20-30€. Aber hier schwingt natürlich die Bastlerehre mit und die nervige Stimme im Kopf die sagt "das muss doch irgendwie gehen" (siehe meine Thread zum Mischpult, etc.). Ich bin da recht verbissen ;-)
Etwas zu den "ach so unterschiedlichen Prozessoren". Hier hat man den sowieso nötigen Bedienteilprozessor mit dem Videotextdecoder vereinigt. Die wesentlichen Unterschiede sind: Grösse des RAMs für eine oder 8 VT-Seiten. Zeichensatz = Charakter Generator für West- oder Osteuropa (kyrilische Schrift). Tatsächlich finden sich im Netz reichlich Bilder vom SDA.... "OIRT" (ehemaliger Ostblock), statt "PAL" , oder auch der Zusatz TDA88.. Bei "Falschbestückung", was soll denn gross passieren? Nichts Schlimmes. Der Videotext liefert "Zeichensalat", na und? Ich glaube also nicht daran, dass wegen "der falschen Firmware" die entsprechende TV-Norm NICHT anwählbar sein soll. Den Hinweis mit den möglicherweise "nicht erreichbaren Menüpunkten" mal beachten, wer weiß ... PIN 7390 steht ja im Manual, auch die 8500. Hotelmodus aktiviert? Trotzdem mal aktivieren, dann deaktivieren. Vielleicht lässt sich ja dann die Norm zwangsweise wählen (siehe dazu SM) Gib bitte mal Rückmeldung, wie sich die Kiste benimmt bei der Normwahl.
Olli Z. schrieb: > Nichtverzweifelter schrieb: >> Ja, die 64 Mikrosekunden Verzögerungsleitung >> wird mit dem genannten IC realisiert, für NTSC >> erübrigt sich selbige prinzipbedingt. Die Addition >> "zwischengespeicherte Zeile" mit "nachfolgender >> Zeile" findet gar nicht statt. > Ah, war das wegen der Phasenverschiebung beim PAL notwendig? ne das war um aus böser farbverfälschender Phase eine Amplitudenänderung zu machen, denn Amplitudenänderung ist weniger schlimm und auffällig als grüne Gesichter! https://www.elektroniktutor.de/geraetetechnik/pal_ffs.html Bild https://www.elektroniktutor.de/geraetetechnik/te_pict/palburst.png
:
Bearbeitet durch User
Vielleicht ist es viel einfacher. Wenn du mal es an eine neuere Flachglotze anschließt. Am AV oder Scart. Bei meinem 8 Jahre alten Medion steht TV-System: PAL, SECAM, B/G, D/K, I, L/L' Das sollte dann im letzten Erdwinkel funktionieren.
Olli Z. schrieb: > Ah, war das wegen der Phasenverschiebung beim PAL notwendig? Jein. Die Addition "zwischengespeicherte Zeile" mit "nachfolgender Zeile" ist nicht "notwendig", sondern der Clou und damit die ganz entscheidende Verbesserung von PAL gegenüber NTSC. Durch diesen Trick hoben sich Phasenverschiebungen zwischen U und V gegenseitig auf und damit die Farbfehler, die NTSC eigen waren. Weißt Du denn nicht, wofür die Abkürzung NTSC steht? "Never the same color" bedeutet das nämlich! :) Damit die Amis nicht dauerhaft grüne und blaue Gesichter auf ihrer Glotze hatten, mussten sie die Phase manuell mit einem "Tint-Regler" nachstellen. Und zwar durchaus häufig. Deutsche mit ihrem PAL-System mussten es dank Prof. Bruch nicht tun. Beschäftige Dich mal mit den Grundlagen des analogen Farbfernsehens!
Nichtverzweifelter schrieb: > Etwas zu den "ach so unterschiedlichen Prozessoren". :-) > Tatsächlich finden sich im Netz reichlich Bilder vom SDA.... "OIRT" > (ehemaliger Ostblock), statt "PAL" , oder auch der Zusatz TDA88.. Echt? Ich finde da nicht so viel... nur zwei: https://tectronelectronics.eu/images/detailed/38/830515855600%20--%20000%20(13236).jpg https://skylots.org/6567567053/SDA5256C--G101 > Bei "Falschbestückung", was soll denn gross passieren? Nichts Schlimmes. Das würde ich sofort tun, wenn ich einen entsprechenden Chip zur Hand hätte (bekäme). > Der Videotext liefert "Zeichensalat", na und? Ich glaube also nicht Videotext ist mir total wurscht :-) > daran, dass wegen "der falschen Firmware" die entsprechende TV-Norm > NICHT anwählbar sein soll. Naja, ich habe im Service-Menü die Möglichkeit die Farbnorm auszuwählen "auto", "PAL", "NTSC", "SECAM". Das macht nur keinen Unterschied, daher glaube ich das es einfach nichts bewirkt weil der Chip(ROM) fest auf PAL eingestellt ist und dem TDA gar keine entsprechende Anweisung gibt? > Den Hinweis mit den möglicherweise "nicht erreichbaren Menüpunkten" mal > beachten, wer weiß ... ? Ich erreiche nur das Service-Menü mit der 8500. Andere Codes funktionieren nicht. Und in diesem Service-Menü finde ich nichts zur Farbe/Norm. In einem anderen Manual habe ich gelesen das man das NVRAM initialisieren und den NTSC 3,6 Menüpunkt bei nicht bestücktem Quarz deaktivieren soll. Diesen habe ich aber nicht. > PIN 7390 steht ja im Manual, auch die 8500. Bei mir klappt nur die 8500. Im Handbuch steht was von 7038 aber auch der bewirkt nichts. Ich denke der ist für die Kindersicherung oder sowas... > Hotelmodus aktiviert? Trotzdem mal aktivieren, dann deaktivieren. > Vielleicht lässt sich ja dann die Norm zwangsweise wählen (siehe dazu Hab ich gemacht, hat nichts bewirkt. Ebenso das zurücksetzen des NVRAM. > Gib bitte mal Rückmeldung, wie sich die Kiste benimmt bei der Normwahl. Nach wie vor das es echtes NTSC (egal ob vom Rekorder oder vom Bildgenerator) nur S/W anzeigen und irgendwie grobkörnig (Schachbrettmuster anstelle Flächen). Was ich aber entdeckt habe ist, das man den AV1 (SCART) auf S-VIDEO umstellen kann. In der Tat umgeht er dann den Y/C-Splitter im TDA und speist ihm direkt Chroma und Luma ein. Evtl. bringt das einen Erfolg. Muss mir morgen dazu mal einen Adapter bauen, weil meine Scart-Dinger alle nur Composite-Video haben.
Rainer Z. schrieb: > Jein. Die Addition "zwischengespeicherte Zeile" mit "nachfolgender > Zeile" ist nicht "notwendig", sondern der Clou und damit die ganz > entscheidende Verbesserung von PAL gegenüber NTSC. Durch diesen Trick Danke für die Auffrischung, jetzt wo Du es sagst fällt es mir wieder ein darüber gelesen zu haben. > Beschäftige Dich mal mit den Grundlagen des analogen Farbfernsehens! Das tue ich bereits seit geraumer Zeit, aber es lesen ist das eine und verstehen und hängen bleiben das andere. Ist doch ne Menge was es da zu lernen gibt... und, auch wenn es sicher gut gemeint ist, lesen allein bringt einem nicht immer die Erkenntnis die man benötigt. Nicht ohne Grund fragte ich hier nach "alten Hasen", also Leute mit Erfahrung die nicht was neu gelesenes falsch interpretieren und damit falsche Schlüsse ziehen, sondern es einfach aus der Erfahrung und Praxis wissen. Ich denke genau dafür sind Foren da...
Wenn überhaupt, muss der 3,58Mhz auf jeden Fall bestückt werden, sonst klappt die Umschalterei auf NTSC sowieso nicht. Allerdings bin ich mir nicht sicher, ob das alles so sinnvoll ist, denn wenns immer noch an der Firmware hängt, ist das fast unlösbar (Krieg mal Chips für die Grotte). Bau dir doch einen externen Multidekoder mit RGB/Sync Ausgang, dann ist das universeller und ein interessantes Projekt, das du mit jedem SCART Fernseher verwenden kannst, der auf NTSC (RS-170 Timing) synchronisiert. Heute kann man sowas auch mit dem MC steuern und timen.
Quarz und Kondensator sind längst nachbestückt, Rückmeldung darüber nebst Foto s.o.
Hallo Olli, deinen TV kannst Du nich so einfach auf NTSC umbauen,dazu benötigst Du auch die Software aus dem Multinorm Gerät um den TDA88x per I2C auf NTSC umzuschalten. Wegen Patent und Lizenzgebühren hatten die "normalen" TV Geräte nur die TV Normen für Europa, maximal noch SECAM Ost im Standard. Evtl. kannst Du ein Telefunken TV aus 1985- 2000 finden, ich glaube ab dem ICC5 Chassis konnten die alle zumindest NTSC mit 4,3 Mhz. Gruß, Elmar
Elmar A. schrieb: > ich glaube ab > dem ICC5 Chassis konnten die alle zumindest NTSC mit 4,3 Mhz Gerade das will er ja nicht. Originales amerikanisches NTSC ist gefragt, da der TE da schon einiges an Equipment dafür rumstehen hat. Man könnte evtl. auch einen I²C Bemopser in die Datenleitungen einschleifen?
:
Bearbeitet durch User
Matthias S. schrieb: > michael_ schrieb: >> TV-System: PAL, SECAM, B/G, D/K, I, L/L' > > Nö, da ist doch gar kein NTSC dabei... Geht trotzdem. Hätte mich auch gewundert. Mit SCART RGB probiert. Bei SAT-Empfänger und DVD-Player den Ausgang auf NTSC umgeschalten, geht.
@michael, RGB ist kein NTSC oder PAL mehr, mit dem RGB Signal kann man direkt ( nach Verstärkung ) die Bildröhre ansteuern. @Matthias S. den I2C Bus mit anderen Signalen füttern könnte theoretisch funktionieren wird aber in einer Neukonstruktion des TV enden, fürchte ich.... Am einfachtsen ist wohl ein Normenwandler gibt es ab 20 Euro, den kann man ja bestellen und wenn der nix taugt wieder zurücksenden. Falls ein moderner Flach TV bereitsteht kann man mit dem probieren, kommt hier ein Bild dann den Videoausgang vom Flach TV wieder mit dem Grundig verbinden, evtl. macht der Flach TV einen Normenwandlung, funktioniert mit den Philips 55xx Geräten. Gruß, Elmar
Elmar A. schrieb: > @michael, RGB ist kein NTSC oder PAL mehr, mit dem RGB Signal kann man > direkt ( nach Verstärkung ) die Bildröhre ansteuern. Hä? Befasse dich mal damit. Übrigens, beim SAT-Empfänger wird es direkt als NTSC3,58 angegeben.
@michael, das RGB Signal steht am Ausgang des PAL, SECAM, NTSC, etc. Dekoder an und kann dann vereinfacht gesagt direkt auf die Videoendstufen des TV gegeben werden. Wenn Du die NTSC Fähigkeit deines TV testen willst würde ich den SAT Receiver auf Ausgang FBAS und NTSC schalten, die RGB Pins im Scartstecker trennen und dann testen. Wenn das RGB Signal immer aus dem Receiver kommt schaltet dein TV wahrscheinlich immer automatisch auf RGB um, bei den Dreamboxen liegt immer das RGB Signal am Ausgang an, daher die Pins im Scartstecker trennen. Gruß, Elmar
Hi, Olli Z. schrieb: >> daran, dass wegen "der falschen Firmware" die entsprechende TV-Norm >> NICHT anwählbar sein soll. > Naja, ich habe im Service-Menü die Möglichkeit die Farbnorm auszuwählen > "auto", "PAL", "NTSC", "SECAM". Das macht nur keinen Unterschied, daher > glaube ich das es einfach nichts bewirkt weil der Chip(ROM) fest auf PAL > eingestellt ist und dem TDA gar keine entsprechende Anweisung gibt? Da wäre es doch mal eine Idee sich einen der Lowest-Cost Logicanalyzer (~10Eur) zu besorgen und einfach mal nachzuschauen wie der TDA konfiguriert wird. Und falls es wirklich nur (noch) an der Parametrierung des TDA scheitern sollte weil die verwendete Firmware diesen partout nicht auf NTSC einstellen will, dann wäre es doch naheliegend diese Parametrierung mit einem kleinen µC selber vorzunehmen. Einen I2C Bitstream auszugeben ist nun wirklich kein Problem. Ebensowenig wie die Datenleitungen zum TDA aufzutrennen und einen µC da so einzuschleifen das dieser normalerweise alle Signale einfach nur durchleitet, bei Bedarf aber auf Knopfdruck eben sein eigenes Konfig-Telegramm an den TDA sendet. (Wohlgemerkt: Natürlich nur wenn das Ziel ist wirklich NATIVES NTSC auf genau DIESEM TV zu schauen. GEht es nur darum natives NTSC auf irgendeinem Fernseher zu sehen, dann ist es wahrscheinlich einfacher sich ein entsrechendes Gerät neu (Flachbild) oder gebraucht (Röhre) als Multinormgerät zuzulegen- geht es nur daraum irgendwie NTSC auf diesen TV zu bekommen ist ein Wandler das mittel der Wahl. Wenn auch mit Qualitätsverlust bei den "bezahlbaren" Geräten - Oder man geht gleich über RGB) Elmar A. schrieb: > Wegen Patent und Lizenzgebühren hatten die "normalen" TV Geräte nur die > TV Normen für Europa, maximal noch SECAM Ost im Standard. Bis in die 70er (NTSC/SECAM) bzw. 80er Jahre kann man davon ausgehen das Patentgebühren tatsächlich mit eine Rolle gespielt haben. Aber spätestens ab 1983 war das völlig irrelevant, da dann selbst für das als letztes Patentierte PAL die 20 Jahre Schutzfrist abgelaufen sind. Rainer Z. schrieb: > Olli Z. schrieb: >> Ah, war das wegen der Phasenverschiebung beim PAL notwendig? > > Jein. Die Addition "zwischengespeicherte Zeile" mit "nachfolgender > Zeile" ist nicht "notwendig", sondern der Clou und damit die ganz > entscheidende Verbesserung von PAL gegenüber NTSC. Durch diesen Trick > hoben sich Phasenverschiebungen zwischen U und V gegenseitig auf und > damit die Farbfehler, die NTSC eigen waren. Wobei es aber sogar eine PAL(Empfänger)Variante gab die ganz ohne Verzögerungsglied auskam. Bei diesem "Schmalspur-Pal" wurde einfach nur die Farbinformation der ungeraden Zeilen ausgewertet und genau so für die geraden zeilen mitverwendet (oder war es umgekehrt?) Der Grund warum einige HErsteller diese Variante verwendet haben liegt darin das beim PAL PAtent die Schutzwürdigkeit gerade aus der abwechselnden Übertragung (bzw. deren Auswertung) von Invertierter und nichtinvertierter Farbinformation unter verwendung eines Verzögerungelementes bestand und durch verzicht auf diese Elemente (Verzögerungselement und auswertung der invertierten Farbinformation) keine durch das Patent erlangten Schutzrechte betroffen waren, für die so gebauten Geräte damit keine Lizenzgebühren fällig wurden. Der (große) Nachteil dieser Lösung liegt natürlich darin das somit der große Vorteil des PAL Systems, die gegenseitige Aufhebung der Phasenverschiebung, gerade nicht mehr gegeben war und somit dieselbe Anfälligkeit wie bei NTSC vorhanden war. Inklusive derselben Notwendigkeit für einen Farbregler wie bei NTSC. Wobei mir aber kein Gerät für den Mitteleuropäischen Markt bekannt ist das so gearbeitet hat. Will es nicht ausschließen das es solche Geräte auch hier zu kaufen gab, vermute aber das ist eher auf den absoluten Lowest Cost Markt in teilen von Asien und vieleicht Südamerika beschränkt geblieben wo viele Käufer sehr lange selbst auf einfachste Geräte sparen mussten. Gruß Carsten P.S.: Die Nutzung einer Verzögerungsleitung zur Farbübertragung wurde bereits mit dem SECAM Verfahren patentiert. Daher war bei (vollwertigen) PAL für die Verwendung des Verzögerungsgliedes Abgaben an die SECAM-Erfinder nötig. (Wenn natürlich auch weit weniger als bei nutzung des kpl. Secam-Verfahrens)
Carsten S. schrieb: > Der (große) Nachteil dieser Lösung liegt natürlich darin das somit der > große Vorteil des PAL Systems, die gegenseitige Aufhebung der > Phasenverschiebung, gerade nicht mehr gegeben war und somit dieselbe > Anfälligkeit wie bei NTSC vorhanden war. Carsten und seine Romanseiten :-P PAL I wurde m.W. nie in Geräten verwendet, hatte aber den gleichen Vorteil wie immer bei PAL. Nur fand die Mischung der beiden Phasenlagen in den aufeinanderfolgenden Bildzeilen im Auge des Betrachters statt. Aber selbst der simpelste PAL Fernseher kam bei uns schon mit Glasverzögerungsleitung auf den Markt, so das PAL I nie eine Rolle gespielt hat. PAL III war das erfolgreiche Verfahren. Was es mit PAL II auf sich hatte, kann ich nicht sagen. michael_ schrieb: > Mit SCART RGB probiert. Wenn ich ein Composite Video schon auf RGB dekodiert habe, spielt die Norm des Composite natürlich keine Rolle mehr, das hat der Dekoder dann schon gemacht. Dann muss der Monitor/TV nur noch mit den Rasterfrequenzen klarkommen (60Hz/15750Hz).
Carsten S. schrieb: > Der Grund warum einige HErsteller diese Variante verwendet haben liegt > darin das beim PAL PAtent die Schutzwürdigkeit gerade aus der > abwechselnden Übertragung (bzw. deren Auswertung) von Invertierter und > nichtinvertierter Farbinformation unter verwendung eines > Verzögerungelementes bestand Korrekt! Aber warum so? Wer es mit den Patenten für PAL genau wissen will: https://www.spiegel.de/kultur/legende-gehaekelt-a-a29dc5a4-0002-0001-0000-000045849789 Die Welt will betrogen werden.
Matthias S. schrieb: > Wenn überhaupt, muss der 3,58Mhz auf jeden Fall bestückt werden, sonst klappt die Umschalterei auf NTSC sowieso nicht. Vollkommen logisch und wenn Du oben liest war es das erste was ich gemacht hatte. Quarz und Kondensator nachgerüstet.
Elmar A. schrieb: > Wegen Patent und Lizenzgebühren hatten die "normalen" TV Geräte nur Ja, stimmt, daran hatte ich garnicht mehr gedacht. Also sind es nicht bloß die paar Cent für die Bauteile. Die wurden absichtlich weggelassen damit man belegen konnte das das Gerät nicht für den NTSC Empfang geeignet ist. Das macht Sinn, von diesem Standpunkt betrachtet. > dem ICC5 Chassis konnten die alle zumindest NTSC mit 4,3 Mhz. An Pseudo-NTSC habe ich kein Interesse. Wenn schon, denn schon..
Elmar A. schrieb im Beitrag #6923232
> Falls ein moderner Flach TV bereitsteht kann man mit dem probieren,
Sowas möchte ich ebenfalls nicht. Mir geht es gerade um den Charme der
Röhrengeräte. Und, die Flachbildler kommen mit teils schlechten
Aufnahmen vom Rekorder aus dem Sync. Nä, möchte ich nitt :-)
michael_ schrieb: > Mit SCART RGB probiert. > Bei SAT-Empfänger und DVD-Player den Ausgang auf NTSC umgeschalten sorry wenn du RGB schrei ist da lange kein PAL,Secam, NTSC dabei sondern eben nur RGB! Den Unterschied sollte man schon kennen wer hier mitdiskutieren möchte
Wie oft denn noch? Lizenzgebühren für in den frühen 80ern ausgelaufene Patente? Das Chassis stammt aus der Zeit ab1997.
Matthias S. schrieb: > Der TDA8843 ist ein PAL Dekoder, während der TDA8844 eben ein PAL/NTSC > Dekoder ist. Das ist nicht richtig, beide können Beides. Siehe Philips-Datenblatt!
Joachim B. schrieb: > michael_ schrieb: >> Mit SCART RGB probiert. >> Bei SAT-Empfänger und DVD-Player den Ausgang auf NTSC umgeschalten > > sorry wenn du RGB schrei ist da lange kein PAL,Secam, NTSC dabei sondern > eben nur RGB! > > Den Unterschied sollte man schon kennen wer hier mitdiskutieren möchte Junge! Das sind die zwei Modi, welche man über SCART übertragen kann. RGB und Analog. Und dieses RGB hat wenig mit dem RGB zu tun, was man an eine Bildröhre anlegt. Es braucht schließlich noch die Synchronisation. Und wer das praktisch nicht kennt, was aus SAT-Empfängern, Videorecordern oder DVD-Playern rauskommt, der tut mir nur Leid. Und es geht natürlich auch über den AV-Eingang des TV. Selbst mit einem 3m 3mm Audiokabel :-) Bild war gut, hatte gerade nichts anderes. Olli Z. schrieb: > Elmar A. schrieb im Beitrag #6923232 >> Falls ein moderner Flach TV bereitsteht kann man mit dem probieren, > Sowas möchte ich ebenfalls nicht. Mir geht es gerade um den Charme der > Röhrengeräte. Und, die Flachbildler kommen mit teils schlechten > Aufnahmen vom Rekorder aus dem Sync. Nä, möchte ich nitt :-) Fröhliches Basteln und nachbestücken!
Nichtverzweifelter schrieb: > Das ist nicht richtig, beide können Beides. Jaja, ich habs schon vor einer Weile mitgekriegt. Aber warum baut Grunzig nur in die Multinorms den 8844 bzw. den TDA8375 ein? michael_ schrieb: > Es braucht schließlich noch die Synchronisation. Die kommt immer über den Video In des Scart, auch im RGB Betrieb. Da kommt dann ein BB Signal aus der Quelle.
:
Bearbeitet durch User
michael_ schrieb: > Junge! > Das sind die zwei Modi, welche man über SCART übertragen kann. > RGB und Analog. du outest dich oder du kannst nicht schreiben! Seit wann unterscheidet man RGB und analog? Wolltest du zart andeuten das RGB digital ist? vorhanden oder nicht? Du hast NULL Ahnung von PAL BAS FBAS
Joachim B. schrieb: > Seit wann unterscheidet man RGB und analog? > Wolltest du zart andeuten das RGB digital ist? vorhanden oder nicht? > > Du hast NULL Ahnung von PAL BAS FBAS Weil es SCART-Kabel gibt, welche nicht voll bestückt sind. Und die können kein RGB. Gut, analog verorte ich als den AV-Eingang über Koax.. Schau dir doch mal die SCART-Belegung an.
"Koax" gibts nur an der Antennbuchse, hahaaaaa! Nun streitet Euch doch nicht. Den 3,579.. Quarz nochmal gegen einen anderen tauschen (Serienresonanz). Für den 12pF einen Trimmkondensator 5-30pF nehmen. nur der 44er kann SECAM. Originaldatenblatt runterladen, dort gibts Tabellen von 40 bis '46.
Nichtverzweifelter schrieb: > "Koax" gibts nur an der Antennbuchse, hahaaaaa! > > Nun streitet Euch doch nicht. Doch! Gibt es nicht nur an der Anennenbuchse.
michael_ schrieb: > Gut, analog verorte ich als den AV-Eingang über Koax.. Pfeifer sie faseln Unsinn (tm) In deinen letzten Postings stimmt ja nichts, oder wie man früher in der Sesamstraße sang, "eins von diesen Dingen passt nicht zu den Anderen"
Geschirmte Kabel gibt es auch an der Scartbuchse. "Koax" heisst es aber wirklich nur an der Antennenbuchse.
Joachim B. schrieb: > michael_ schrieb: >> Gut, analog verorte ich als den AV-Eingang über Koax.. > > Pfeifer sie faseln Unsinn (tm) > In deinen letzten Postings stimmt ja nichts, oder wie man früher in der > Sesamstraße sang, "eins von diesen Dingen passt nicht zu den Anderen" Du willst doch nur stänkern. Fazit: An einen Flachbild-TV kann man NTSC darstellen. Über SCART RGB oder den AV-Eingang. Wenn der TO das als eklig emfindet, dann soll er seine Lösung bitte selbst suchen.
Der TO hat aber einen ganz bestimmten Röhren-TV, darauf könnten wir uns beschränken. Steht auch so im Titel.
michael_ schrieb: > Du willst doch nur stänkern. nö nur verwahre ich mich gegen absoluten fernsehtechnischen Unsinn. Du schmeißt hier mit TV Fachbegriffen rum als wenn du was wüsstest, leider ist dein Wissen nicht belastbar, also lass es doch!
Beitrag #6924030 wurde von einem Moderator gelöscht.
michael_ schrieb: > An einen Flachbild-TV kann man NTSC darstellen. > Über SCART RGB oder den AV-Eingang. Über SCART RGB ist es kein NTSC mehr, weil bereits decodiert. Der Grundig hat zwar einen RGB-Eingang über die SCART-Buchse, aber ich habe keinen Videorecorder kennengelernt, welcher RGB-Signal ausgibt. Das soll nicht heißen, dass es keine gäbe, ich selber kenne nur keine. Somit dürfte der Hinweis auf den RGB-Eingang am Fernseher dem TO nicht weiterbringen.
Carsten S. schrieb: > Da wäre es doch mal eine Idee sich einen der Lowest-Cost Logicanalyzer > (~10Eur) zu besorgen und einfach mal nachzuschauen wie der TDA > konfiguriert wird. Einen LA habe ich, nachgeschaut habe ich noch nicht, das werde ich wohl mal tun, nur um Gewissheit zu haben. Ich muss auch noch den Metallkäfig runterlöten um zu sehen welcher TDA Farbdekoder bei mir tatsächlich bestückt ist von den 3 möglichen. Aber das Protokoll zu "entschlüsseln" wird eine Herausforderung, denn da muss man auch erstmal durchblicken. Vor allem aber fehlt mir der Vergleich zu einem Gerät welches NTSC ansteuert. Ich suche also etwas was nicht da ist, das wird schon tricky... > (Wohlgemerkt: Natürlich nur wenn das Ziel ist wirklich NATIVES NTSC > auf genau DIESEM TV zu schauen. GEht es nur darum natives NTSC auf Ja, genau darum geht es mir, das haben einige die hier mitdiskutieren vielleicht aus den Augen verloren mit ihren teils guten Ideen und Ratschlägen. Es geht um die Herausforderung aus dem eigentlich nur PAL-fähigen Gerät ein PAL/NTSC Gerät zu machen. > Qualitätsverlust bei den "bezahlbaren" Geräten - Oder man geht gleich > über RGB) Ich habe NTSC auf S-Video bzw. Composite-Video, kein RGB und würde jetzt auch nichts dazwischen schalten wollen. U.a. auch um alte Spielekonsolen aus USA dort betreiben zu können. > Bis in die 70er (NTSC/SECAM) bzw. 80er Jahre kann man davon ausgehen > das Patentgebühren tatsächlich mit eine Rolle gespielt haben. > Aber spätestens ab 1983 war das völlig irrelevant, da dann selbst für > das als letztes Patentierte PAL die 20 Jahre Schutzfrist abgelaufen > sind. Also doch nur sparen an ein paar Cent für Bauteile? Hm, die Auto-Industrie machts vor ;-) Schade, klang irgendwie einleuchtend das mit den Lizenzgebühren...
Also nochmal als Zwischenüberschrift: Bitte keine Hinweise auf Normwandlung außerhalb vom Gerät. Mir geht es hier in diesem Post um die Möglichkeit meinen vorhandenen ST70-780 TEXT so umzurüsten das er nativ NTSC über AV kann, nicht mehr, nicht weniger. Wer das für Schwachsinn oder unmöglich hält möge bitte nicht mitdiskutieren.
michael_ schrieb: > Das sind die zwei Modi, welche man über SCART übertragen kann. > RGB und Analog. Nenn es RGB und FBAS oder RGB und CVBS. Analog sind sie beide. > Und dieses RGB hat wenig mit dem RGB zu tun, was man an eine Bildröhre > anlegt. Doch, das hat es. PAL und NTSC sind Modulationsverfahren für das Farbart-Signal. Dies wird in modulierter Form dem Helligkeitssignal BAS/VBS hinzugefügt, und das ergibt dann das FBAS / CVBS. Gelber Cinchstecker oder der Video-Pin am SCART. Oder auf HF aufmoduliert an der Antenne. RGB ist das demodulierte Nutzsignal, sozusagen die Helligkeit pro Grundfarbe. Die geht direkt auf die Kathode der Bildröhre bzw auf das Pixel des LCD. Um an RGB zu kommen, muss man das PAL- oder NTSC-Signal auspacken ("demodulieren"). Danach ist das kein PAL oder NTSC mehr, sondern ausgepackte Nutzdaten. Du könntest sogar NTSC demodulieren und das daraus gewonnene RGB-Signal dann wieder als PAL modulieren. So arbeiten professionelle Normenwandler. Oft wird dabei auch die Zeilen- und Bildfrequenz geändert, aber darum geht es hier (noch) nicht. > Es braucht schließlich noch die Synchronisation. Die braucht man auch. Bei FBAS/CVBS ist sie im Signal enthalten und unterscheidet sich nur durch den Spannungspegel. Bei RGB wird sie meist getrennt zugeführt. Bei Computern und in der professionellen Videotechnik als H-Sync und V-Sync zur Zeilen- und Bildsynchronisation, beim SCART oft in Form des ohnehin vorhandenen FBAS/CVBS-Signales. D.h. dort ist noch ein zweites Mal die komplette Bildinformation vorhanden, man benutzt davon aber nur die Synchronsignale.
Soul E. schrieb: > michael_ schrieb: >> Es braucht schließlich noch die Synchronisation. > > Die braucht man auch. Bei FBAS/CVBS ist sie im Signal enthalten und > unterscheidet sich nur durch den Spannungspegel. Bei RGB wird sie meist > getrennt zugeführt. Bei Computern und in der professionellen > Videotechnik als H-Sync und V-Sync zur Zeilen- und Bildsynchronisation, > beim SCART oft in Form des ohnehin vorhandenen FBAS/CVBS-Signales. D.h. > dort ist noch ein zweites Mal die komplette Bildinformation vorhanden, > man benutzt davon aber nur die Synchronsignale. Es gibt auch noch „Sync on Green“. Da sind die dann wie beim BAS im Grünsignal enthalten.
Olli Z. schrieb: > Aber das Protokoll zu "entschlüsseln" wird eine Herausforderung, denn da > muss man auch erstmal durchblicken. I²C ist allerdings insofern unproblematisch, als das alles bekannt ist. Du hast Start und Stop, die Adresse des TDA884x und auch das Service Menü. Ein I²C Injektor wäre übrigens eine Möglichkeit, ohne Firmware Rumgewurschtel was zu erreichen. Allerdings weiss ich aus den alten Tagen, das auf dem I²C Bus der Geräte ganz schön was los ist, da viele Befehle rücksichtslos wiederholt werden - immer und immer wieder. Zum Glück wird so gut wie immer 100kHz benutzt und nicht die neumodischen 400kHz.
Dirk B. schrieb: > Es gibt auch noch „Sync on Green“. > Da sind die dann wie beim BAS im Grünsignal enthalten. Und es gibt auch Composite Sync. Da sind H-Sync und V-Sync in einem Signal kombiniert. Aber wir wollen unseren Pucki = Schlaumaier = michael_ mit seinem technischen Halbwissen ja nicht noch weiter verwirren.
Hi, Olli Z. schrieb: > Aber das Protokoll zu "entschlüsseln" wird eine Herausforderung, denn da > muss man auch erstmal durchblicken. Vor allem aber fehlt mir der > Vergleich zu einem Gerät welches NTSC ansteuert. Ich suche also etwas > was nicht da ist, das wird schon tricky... Naja, entschlüsseln ist ja gar nicht nötig. Du hast ja selbst das Datenblatt zum TDA hier hochgeladen. Und da steht doch das gesamte Protokoll (Registeradressen und Bitbedeutung) schon drin. Viele Einstellungen ergeben sich dabei durch die HArdware des Gerätes. Daher sind die einfach nur 1-1 zu übernehmen. Tatsächlich relevant für die Frage ob NTSC oder Pal sind dabei nur eine handvoll Bits. Und nur diese musst du verändern... Im Einfachsten Fall reicht es vielleicht schon die meisten davon auf "Auto-Erkennung" zu setzen. ICh würde z.B. als erstes versuchen damit anzufangen im Register Control0 die Bits XA und XB auf 1 zu setzen (Parametrierung das beides Quarze, also 4,43 MHz und 3,56 MHz, bestückt sind), in Control1 dann die Bits FORF&FORS sowie CM0, CM1, CM2 alle auf 0 (Auto erkennung Bildwechselfrequenz mit Vorzug 60Hz sowie Auto erkennung Farbmodus) dann noch im Register Vertical Amplitude das Bit LBM auf 0 und im REgister White Point B das Bit MAT auf 0. Dann mal schauen was passiert... DAvon abhängig dann weiter verfeinern. Gruß Carsten
Carsten S. schrieb: > beides > Quarze, > also 4,43 MHz und 3,56 MHz, 3,56? vertippt? ich kenne 3,58 Andere 3,579 passt wiki 3,57954545 MHz für den Farbträger bei der NTSC-Farbmodulation
:
Bearbeitet durch User
Und regelmässig wird es der Bedienteil-VT-Prozessor zurücksetzen, auf "seine" Werte.
Nichtverzweifelter schrieb: > Und regelmässig wird es der Bedienteil-VT-Prozessor zurücksetzen, auf > "seine" Werte. Die sollte das neu eingefügte I2C Gateway ja unterdrücken und nicht durchreichrn.
Hi, Joachim B. schrieb: > 3,56? vertippt? JAIN... So ähnlich - eher Gedankenlosigkeit. Bin gerade nebenbei am Aufräumen meines "Spiel"zimmers und hatte noch ein paar Minuten vorher ein paar 5,6MHz Quarze in der Hand (Ersatzteile für ganz alte FuG, kommen jetzt in den Keller...) Da hat sich wohl das 56 kurzzeitig festgesetzt ;-) Gruß Carsten
:
Bearbeitet durch User
Es bringt ja nichts, sich gross Gedanken zu machen über die Umprogrammierung von Registern in ... möglicherweise ... gar nicht vorhandenen ICs. Der olli muss unter die Abschirmhaube gucken. Es kann sich nämlich auch die Ersatzplatine drunter verstecken. Siehe Service Manual. Die kann dann definitiv nur PAL und MESECAM.
Nichtverzweifelter schrieb: > Der olli muss unter die Abschirmhaube gucken. Es kann sich nämlich auch > die Ersatzplatine drunter verstecken. Siehe Service Manual. > > Die kann dann definitiv nur PAL und MESECAM. Leider nicht, da ist schon der SDA 5256C drauf und eben nicht diese HuPa, die man auf manchen SM Titelseiten sieht. Diese haben nämlich ein externes EPROM für die Firmware.
Geht nicht um den Prozessor-VT-Decoder SDA5256 Du-sollen-gucken-ob-TDA8843-oda-Andere-verbaut-sein-huga-huga! Das-sein-ZF-Verstärker-Demodulator-Farbdecoder-Videomatrix-PAL/NTSC-und- so-weiter. Olli Z. schrieb: > Ich muss auch noch den Metallkäfig runterlöten um zu sehen welcher TDA > Farbdekoder bei mir tatsächlich bestückt ist Du-das-machen-hugahuga. Du-haben-selba-geschrieben. Ich-denken-Du-längst-gemacht-huga?
und wenn der TDA88xx gefunden wurde und kein TDA8840 eingebaut ist das Oszillosokop an Pin33 vom TDA88xx, dort wird die Frequenz vom gewählten Quarz wieder ausgegeben. "The frequency of the active X-tal is fed to the Fsc output (pin 33) and can be used to tune an external comb filter (e.g. the SAA 4961)." TDA8840 kann nur PAl. Gruß, Elmar
Elmar A. schrieb: > TDA8840 kann nur PAl. Grunzig selber behauptet, das in diese Chassis nur der TDA8843 oder der TDA8844 bzw. der TDA8375 eingebaut wird. Wie kommst du auf den TDA8840? NB: Ist schon schade, das der I²C Bus nicht einfach hinten auf der Scartbuchse liegt. Philips hat das oft gemacht. So konnte ich z.B. den VR2340 V2000 Recorder komplett vom Apple aus steuern.
:
Bearbeitet durch User
keine Ahnung welcher TDA da drin ist, mi dem TDA8840 würde nur PAL funktionieren, also nachsehen was verbaut ist, das sich der vorhandene Aufbau vom Servicemanual unterscheidet ist nicht ungewöhnlich. Wenn man im Servicemode NTSC auswählen kann sollte die Firmware das Umschalten unterstützen, zum prüfen am Pin33 nachsehen welcher Quarz gewählt wurde, wenn ein kompatibler TDA88xx eingebaut ist. Gruß, Elmar
Habe heute den S-Video Eingang vom TV getestet, den hatte ich letztens entdeckt das er auf dem SCART AV1 (hinten) anliegt (Pin 15 für Chroma und Pin 20 für Luma). Im Dialog-Menü kann man AV1 auf "VHS" und "SVHS" umstellen. Beim anlegen einer PAL-Farbquelle hat das auch funktioniert. Habe es heute mal mit dem NTSC-Rekorder getestet, das klappte leider nicht. War mir fast klar, denn der Farbdekoder wird ja nicht in den NTSC-Betrieb geschaltet, Quarz hin, Quarz her. Das ist also in der Tat ein Softwareproblem :-/
Auf den 8840 kommt er, weil er das Sammeldatenblatt des IC-Herstellers Philips gelesen hat. Die noch höheren Nummern als im Chassis können dann nur NTSC.
Elmar A. schrieb: > keine Ahnung welcher TDA da drin ist, mi dem TDA8840 würde nur PAL > funktionieren, also nachsehen was verbaut ist, das sich der vorhandene Das hatten wir ja weiter oben schon geklärt. Im ST70-780 wurden nur Multinorm Dekoder verbaut. > Aufbau vom Servicemanual unterscheidet ist nicht ungewöhnlich. Das wäre natürlich möglich... Theorie und Praxis. Ich schraube das Teil also nochmal auf und sehe nach. > Wenn man im Servicemode NTSC auswählen kann sollte die Firmware das > Umschalten unterstützen, zum prüfen am Pin33 nachsehen welcher Quarz Nur das die Dialoge gleich sind heißt nicht zwingend das es auch etwas bewirkt. Möglicherweise ist das von externer Beschaltung (Jumper) abhängig oder es werden die Befehle einfach nicht gesendet. Alles möglich. Ich werde auch mal einen Sniff vom I2C Bus anfertigen um mal zu sehen was der Zentralprozessor mit dem Farbdekoder so alles "ausschnapselt" ;-)
Matthias S. schrieb: > NB: Ist schon schade, das der I²C Bus nicht einfach hinten auf der > Scartbuchse liegt. Philips hat das oft gemacht. So konnte ich z.B. den Ich werde mir da definitiv was einbauen denn wer weiss wie oft ich das Teil noch auf und zuschrauben muss...
Was ist denn nun unter der Haube? Big block oder doch nur small block? 😉
Nichtverzweifelter schrieb: > Du-sollen-gucken-ob-TDA8843-oda-Andere-verbaut-sein-huga-huga! Jaja, hab schon kapiert, mach ich ja auch :-)
wenn der TDA88xx freigelegt ist dann "am Pin33 nachsehen welcher Quarz gewählt wurde". Welchen "nativen NTSC" Recorder verwendest Du ? Und in welchem NTSC sind deine Kasetten aufgezeichnet ? Hast Du evtl. einen Testbildgenerator der NTSC ausgeben kann ? Wenn nicht dann den Rekorder auch mal an einem modernen Flachbild TV anschliessen und nachsehen was rauskommt. Die Firmware in der CPU ist für alle möglichen Optionen identisch, nur die Chassisnummer muss passen, die CPUs sind maskenprogrammiert, da hat man nicht verschiedene Versionen produzieren lassen. Gruß, Elmar
Abschliessend: Unter der Abschirmhaube kann sich eine Ersatzplatine befinden, die den - damals zeitweise nicht lieferbaren - TDA88.. ersetzt. Die Platine bildet pinkompatibel eine Mindestschaltung nach, die aufgrund der zugeführten 4,433MHz nur PAL und MESECAM kann. Kein NTSC. Die Diagnose von Olli, es handele sich um ein Softwareproblem, ist solange verfrüht, bis er nachgesehen hat, was unter der Abschirmhaube wirklich sitzt, ein TDA8843, 44 , die Ers.-Pl. etc. Bei schlechtem Empfang via Zimmerantenne Ende der Neunziger würde man auch keinen "... die Farbsysteme durchprobierenden Empfänger" haben wollen. Aussetzende Farbe aufgrund eines nicht weit genug nachziehbaren Quarzes waren bei Farbfernsehern verschiedener Generationen gar nicht so selten. Zwingend ist systembedingt, dass der 4.433619MHz Generator im TV aufs Hertz genau auf den FHT-Burst einrastet. Phasenstarr sogar. Pro Zeile. Guten Rutsch Euch allen.
Elmar A. schrieb: > wenn der TDA88xx freigelegt ist dann "am Pin33 nachsehen welcher Quarz > gewählt wurde". Werde heute Abend mal wieder dran rum basteln, Platine raus, hauben runter und nachsehen/nachmessen. > Welchen "nativen NTSC" Recorder verwendest Du ? Einen Panasonic AG 7300 NTSC. > Und in welchem NTSC sind deine Kasetten aufgezeichnet ? Amerikanische NTSC M > Hast Du evtl. einen Testbildgenerator der NTSC ausgeben kann ? Ja, habe neb Flukr Generator mit PAL und NTSC Lizenz. Einzig muss ich noch lernen wir die einzelnen Bildmuster anzuwenden sind, da ist ja jedes für einen bestimmen Einstellzweck gedacht. > Wenn nicht dann den Rekorder auch mal an einem modernen Flachbild TV > anschliessen und nachsehen was rauskommt. Hab ich schon, der kann das darstellen, bekommt aber durch die teils alteb Aufnahmeb ubd schlechte Qualität ständig dropped-frame Aussetzer, eine Röhre reagiert da ganz anders. > Die Firmware in der CPU ist für alle möglichen Optionen identisch, nur > die Chassisnummer muss passen, die CPUs sind maskenprogrammiert, da hat > man nicht verschiedene Versionen produzieren lassen. Das war auch meine Hoffnung, denn bei den Geräteb mit separatem Eprom wäre ein Firmwaretausch einfacher für den Hersteller. Daher glaubr ich das es womöglich noch externe ID Beschaltung gibt wie Jumper (0 Ohn Widerstände) oder sowas... Dieses "FR" würde mich nich interessieren, was das bedeutet.
Olli Z. schrieb: > Einzig muss ich > noch lernen wir die einzelnen Bildmuster anzuwenden sind, da ist ja > jedes für einen bestimmen Einstellzweck gedacht. Gitter für Konvergenz, Kreis für Bildlage, Linearität -> Kreis&Gitter, Streifenmuster für obere Grenzfrequenz Video, Unbuntfelder (nur für PAL? Farbdifferenz) https://de.wikipedia.org/wiki/Testbild Was meinst du denn noch? kenne NTSC Testbilder nicht.
:
Bearbeitet durch User
Joachim B. schrieb: > Was meinst du denn noch? kenne NTSC Testbilder nicht. https://web.archive.org/web/20160204073016/http://www.pembers.freeserve.co.uk/Test-Cards/Test-Card-Technical.html#TCD-TCE Weiter unten werden auch die NTSC-Farbbalken erklärt. Für das Auge sieht alles gleich aus, aber die Amplituden der Chrominanz- und Luminanzanteile sind unterschiedlich.
Angehängte Dateien:
-
fluke_54100.jpg
130 KB
Joachim B. schrieb: > Gitter für Konvergenz, Kreis für Bildlage, Linearität -> Kreis&Gitter, > Streifenmuster für obere Grenzfrequenz Video, Unbuntfelder (nur für PAL? > Farbdifferenz) > https://de.wikipedia.org/wiki/Testbild > Was meinst du denn noch? kenne NTSC Testbilder nicht. Also, ich habe hier den Fluke 54100 und es wäre anmaßend übertrieben von mir zu behaupten ich könnte das Teil bedienen. Ja, ich bekomme ihn von NTSC auf PAL und diverse Muster eingestellt, aber ich habe noch keine Ahnung was man womit macht. Z.b. würde ich gern das zurückgesetzt NVM wieder richtig einstellen, Bildgeometrie. Mit welchem Muster mache ich das damit das Bild optimal in der Röhre "steht" nicht zuviel abgeschnitten wird und alles möglichst grade erscheint? Ich mache gern mal ein paar "Screenshots" von dem was die einzelnen Knöpfe so erzeugen. Dahinter verbirgt sich bei längerem drücken meist noch ein Untermenü mit zig weiteren Variationen des Musters.
Nichtverzweifelter schrieb: > Unter der Abschirmhaube kann sich eine Ersatzplatine befinden, die den - Nein, tut es nicht :-) > Aussetzende Farbe aufgrund eines nicht weit genug nachziehbaren Quarzes > waren bei Farbfernsehern verschiedener Generationen gar nicht so selten. Das sollte ich mit meinem Dana auch mal nachmessen, ggf. den 18pF durch einen Trimmko ersetzen? Aber erstmal lege ich mir den I2C nach draussen um mir mit dem LA den Datenstrom mal anzusehen und ob der µC dem Farbdekoder beim Menüwechsel von "PAL" auf "NTSC" oder "auto" überhaupt irgendwas in die Richtung sendet. Sehr schade das ich nicht die µC Variante mit externem EPROM habe, da könnte man mal die Software mit IDA Pro analysieren und schauen was die so macht..
:
Bearbeitet durch User
...die Du natürlich "spielend" disassemblierst?!? Woher hast Du eigentlich den Quarz genommen und welche Frequenz steht auf dessen Gehäuse? (Im Foto nicht zu lesen)
Hi, Olli Z. schrieb: > Soo, decap und Geheimnis gelüftet: "es ist ein TDA8375" Sieht doch gut aus. Jetzt noch der I2C LOG und man kann schon deutlich mehr sehen... Vielleicht passen ja tatsächlich nur die beiden BITs XA und XB nicht die angeben welche(r) Quarz(e) bestückt sind und der Rest steht schon passend bzw. wird bei Einstellung NTSC im Menü passend eingestellt. ICh hoffe das dein LA Protokollanalyse kann. Ansonsten halt einen der 10Euro Dinger nehmen und mit Sigrok nachsehen... Einzeln Bits Zählen bräuchte man zum Glück bei solchen Preisen selbst als Hobbyist mit etwas Sparzwang ja nicht mehr. Nichtverzweifelter schrieb: > Na klar: > 27C512 EPROM, das sind dann mal eben 64KB in Assembler. Nichtverzweifelter schrieb: > ...die Du natürlich "spielend" disassemblierst?!? Naja, zumindest hätte man, mit dem richtigen Werkzeug, bei einem externen (E)EPROM die Möglichkeit herauszufinden an genau welcher Stelle im Programm der sich gerade ganz genau befindet wenn er bestimmte Dinge macht. (Wie I2C Ausgabe an den TDA, Umschaltung PAL/NTSC usw.) Es ist also gar nicht nötig "alles" zu Dissamblieren (bzw. im NAchgang Sinnvoll zwischen Programm und CODE zu trennen und den Programmablauf(plan) herauszuarbeiten) Es reicht sich von der gefundenen Stelle vorzuarbeiten. Gruß Carsten
Nichtverzweifelter schrieb: > ...die Du natürlich "spielend" disassemblierst?!? Das sollte kein großes Problem darstellen. Wie Carsten schon schrieb geht man da systematisch vor. Hätte ich die Firmware als Dump... vielleicht gibt es aber auch eine Möglichkeit das ROM extern auszulesen? Bekäme man Schreibzugriff aufs RAM könnte man vielleicht "von außen" einen kleinen Trojaner einschleusen der das ROM ausliest und Byteweise über einen (Seriellen) IO-Port ausgibt. Aber sicher haben die Hersteller einen Schutz implementiert. Der fängt mit dem Watchdog an, den es zu deaktivieren gälte... Aber, Disassembling fängt immer mit dem sammeln von Informationen an. Hier haben wir das Glück ein Datenblatt zu besitzen vom SDA5256 und das besagt das der Chip eine 8 bit C500-CPU hat welche 8051 kompatibel ist. Damit hat man schon die erste Aufgabe einen Disassembler dafür zu suchen. Dann geht man von den Ports aus rückwärts und schaut wie diese verwendet werden, sprich man sucht die IO-Subfunktionen, wie z.B. für I2C. Die findet man über die meist memory-mapped IO bezogenen Adressen. Darüber findet man dann die Initialisierungsroutine und auch die Sende- und Empfangsroutinen, wie in der Regel mit Puffern arbeiten, ggf. auch mit Ringpuffern und über Interrupts/Timer gesteuert werden. Mit etwas Glück hat der Code eine statische Serverloop die alles schön nacheinander ausführt. Ansonsten muss man schauen auf welche RAM-Bereiche die Sendefunktion zurückgreift und die Stellen/Funktionen finden die diese Bereiche manipulieren (Read=Empfangs, Write=Senderoutinen). Usw. usw. das geht schon. Ist Arbeit, keine Frage und nicht "mal eben so" und auch nicht "spielend", aber machbar. Auch diese Weise habe ich schon Interna von Fahrzeugmodulen "enträtselt" und die sind deutlich komplexer aufgebaut ;-) Über den Schaltplan wissen wir: - Der SDA ist am Port P0.1 und SCL am P0.2 des Prozessors verbunden. Über das Datenblatt wissen wir: – One 8-bit I/O port with open drain output and optional I2C-Bus emulation (auf dem Datenblatt-Blockschaltbild ist nicht von einem I2C-Controller zu sehen, also vermute ich das es rein per Software gemacht wird und das die genannte "Emulation" hier halt darin besteht das es Open-Drain Ports sind die I2C benötigt) - Der Chip hat nach außen hin 3 8-Bit IO/ports (P0, P1, P3) und einen 4 Bit (P2) - Der Port P0 wird über die IO-Adresse 0x80 angesprochen. Es sind also die Bits 1 und 2 dieses Datenwortes interessant für I2C.
Nichtverzweifelter schrieb: > Woher hast Du eigentlich den Quarz genommen und welche Frequenz steht > auf dessen Gehäuse? (Im Foto nicht zu lesen) Ich habe für meine NTSC-Basteileien so div. Quarze gekauft u.a. den den ich auch dort reingelötet habe einen HC18 mit der Resonanzfrequenz "3,579545 MHZ"
Ist das nicht zu kompliziert? Wenn man sich rein auf den I²C Bus beschränkt, weiss man doch schon 90% dessen, was man zum Umbau benötigt. Dann kann man den Bus zum TDA8375 auftrennen und einen I2C Bemopser konstruieren, der alles, was zum Chip geht durchreicht bis auf die Normumschaltung. Soweit ich die Grunzig Kiste im Schaltplan angeguckt habe, hat die auch mehrere I2C Busse, so daß die Chance eines vollgestopften Bus nicht so hoch ist wie bei Kisten mit nur einem. Am besten mach das mal mit dem LA erstmal und dann sieht man weiter. Aus eigener Erfahrung weiss ich jedenfalls, das die Analyse eines 27512 EPROM mit MCS51 Software kein Zuckerschlecken ist. Mein altes E-Auto hat das im Carcontroller (80C535) und das einzige, was man da recht bequem erkennt, sind die ASCII Strings. Ansonsten muss man sich mit DIS51 oder ähnlichem Werkzeug tagelang da durchquälen - und dann übersteigt der Aufwand schnell den Nutzen.
:
Bearbeitet durch User
Hier dann mein erstes Dump vom I2C (Hinweis: an dem ja auch andere Komponenten hängen als nur der Farbdekoder!) vom Einschaltmoment des Fernsehers (die ersten Sekunden). Das logicdata-File ist vom Salae LA. Der I2C scheint vom CLK her nur mit 50kHz betrieben zu werden. Laut Datenblatt vom TDA8375 (Seite 20 ff.) sollte der Dekoder auf der I2C-Adresse 0x8A (read) und 0x8B (write) kommunizieren. Ein Lesezugriff gibt immer 3 Bytes (Status-Bytes) zurück (siehe "OUTPUT ADDRESS"). Dazu finde ich zunächst folgendes im Dump:
1 | Time [s], Analyzer Name, Decoded Protocol Result |
2 | 3.810255687500000,I2C,Setup Read to [0x8B] + ACK |
3 | 3.810445625000000,I2C,0xD0 + ACK |
4 | 3.810588375000000,I2C,0xC4 + ACK |
5 | 3.810731125000000,I2C,0xC7 + NAK |
Im ersten Byte Bit 7 (POR) soll so lange gelesen werden bis dieses 0 ist. Das ist nach diesem, zweite Lesezugriff der Fall (0x50):
1 | 3.810914812500000,I2C,Setup Read to [0x8B] + ACK |
2 | 3.811104812500000,I2C,0x50 + ACK |
3 | 3.811247500000000,I2C,0xC4 + ACK |
4 | 3.811390250000000,I2C,0xC7 + NAK |
Alsdann schreibt der Master (µC) die ersten Registerwerte
1 | 3.811571625000000,I2C,Setup Write to [0x8A] + ACK |
2 | 3.811766937500000,I2C,0x20 + NAK |
3 | 3.811961562500000,I2C,0x00 + NAK |
Im Datenblatt steht "Auto-increment mode available for subaddresses." was wohl bedeutet das der erste Schreibzugriff in das Register mit der Subadresse 0x00 geht, der zweite nach 0x01, usw. Demnach würde hier das "Control 0" Register mit dem Wert 0x20 (0b0010 0000) und "Control 1" mit 0x00 gesetzt.
:
Bearbeitet durch User
Olli Z. schrieb: Der erste INIT-Versuch vom µC für den TDA8375 wird von ihm mit NAK abgelehnt. Was auch immer die Software da versucht, geht erstmal nicht: >
1 | > 3.811571625000000,I2C,Setup Write to [0x8A] + ACK |
2 | > 3.811766937500000,I2C,0x20 + NAK |
3 | > 3.811961562500000,I2C,0x00 + NAK |
4 | > |
Aber dann hats die Firmware kapiert und macht es richtig:
1 | 3.821523875000000,I2C,Setup Write to [0x8A] + ACK |
2 | 3.821719187500000,I2C,0x00 + ACK |
3 | 3.821914875000000,I2C,0x02 + ACK |
4 | 3.822111812500000,I2C,0xD0 + ACK |
5 | 3.822308812500000,I2C,0x20 + ACK |
6 | 3.822505750000000,I2C,0xA4 + ACK |
7 | 3.822702750000000,I2C,0x36 + ACK |
8 | 3.822901062500000,I2C,0x13 + ACK |
9 | 3.823098687500000,I2C,0x12 + ACK |
10 | 3.823295687500000,I2C,0x1C + ACK |
11 | 3.823494000000000,I2C,0x9A + ACK |
12 | 3.823691625000000,I2C,0x25 + ACK |
13 | 3.823889937500000,I2C,0xCA + ACK |
14 | 3.824087562500000,I2C,0x67 + ACK |
15 | 3.824286562500000,I2C,0x2A + ACK |
16 | 3.824484187500000,I2C,0x26 + ACK |
17 | 3.824681875000000,I2C,0x22 + ACK |
18 | 3.824878812500000,I2C,0x05 + ACK |
19 | 3.825075812500000,I2C,0x20 + ACK |
20 | 3.825272125000000,I2C,0x28 + ACK |
21 | 3.825469062500000,I2C,0x30 + ACK |
22 | 3.825666062500000,I2C,0x15 + ACK |
23 | 3.825864375000000,I2C,0x80 + ACK |
24 | 3.826060000000000,I2C,0x16 + ACK |
25 | 3.826257625000000,I2C,0x19 + ACK |
26 | 3.826455312500000,I2C,0x20 + ACK |
Jetzt geht es darum zu verstehen was das im Chip bewirkt...
So, ich denke ich weiss nun was da läuft. Das erste Byte welches der Farbdekoder vom µC bekommt ist die Start-Subadresse (hier 0x00). Danach folgen nur noch Datenbytes. Das erste Byte mit dem Wert 0x02 geht somit in das Register an Subadresse 0x00. Nun erfolgt der Auto-Increment und das nächste Byte (0xD0) geht somit an Adresse 0x01, usw. Das beduetet das diese Folge:
1 | 3.821523875000000,I2C,Setup Write to [0x8A] + ACK |
2 | 3.821719187500000,I2C,0x00 + ACK |
3 | 3.821914875000000,I2C,0x02 + ACK |
4 | 3.822111812500000,I2C,0xD0 + ACK |
"Control 0" mit dem Wert 0x02 und "Control 1" mit dem Wert 0xD0 beschreibt, was wiederrum heißt: setze XA und XB auf 0b10 und das bedeutet laut Table 14 "one 4.4 MHz crystal (pin 35)" :-( Also ganz klar, hier wird "falsch" initialisiert. Dies ändert sich auch nicht im laufenden Betrieb beim umschalten der Norm am aktuellen Kanal über das Service-Menü. Da wird dann einzig und allen der Wert "CM0-CM2" (Dekoder-Mode) geändert und zwar von diesen Werten analog zur Anzeige im Dialog: 0b000 => "not forced, own intelligence, two crystals" 0b101 => "forced crystal pin 35 (PAL)" 0b110 => "forced crystal pin 35 (NTSC)" 0b111 => "forced crystal pin 35 (SECAM)" Die "own intelligence, two crystals" wird halt durch die Angabe das nur ein Quarz an Pin 35 vorhanden ist, "kastriert". Also ist nun völlig klar wie der Hase läuft. Die Frage ist dann, was veranlasst die Firmware dazu nur einen Quarz zu initialisieren? Wenn es wirklich so ist das das "PAL" auf dem Gehäuse des Chips nur Blendwerk ist und die Firmware bei allen Geräten gleich ist, dann müsste es eine Hardware-Kodierung geben auf die die Software reagiert. Z.B. liest die Firmware ja die Status-Bytes vom Farbdekoder ein. Darin enthalten ist auch eine Chip-ID des Dekoders. Die Firmware weiss also das es sich um einen 8375 handelt. Möglicherweise(!) hat den Grundig nur dann bestückt wenn es sich um ein Single-Norm Gerät handelte und bei Multinorm den 8844/8845 genommen? Andere Möglichkeit wäre das es noch irgendwo einen Jumper gibt der das festlegt und/oder es damit abhängig von anderen Ausstattungsmerkmalen war? Die Alternative wäre nun eine "Chip-In-The-Middle" Hardware zu bauen, die in den I2C-Bus zwischen Farbdekoder und µC einzuschleifen und zu veranlassen die Quarzbestückung anders zu senden (0b11). Das würde ich nun mal angehen...
Olli Z. schrieb: > Die Frage ist dann, was > veranlasst die Firmware dazu nur einen Quarz zu initialisieren? Wenn es > wirklich so ist das das "PAL" auf dem Gehäuse des Chips nur Blendwerk > ist und die Firmware bei allen Geräten gleich ist, dann müsste es eine > Hardware-Kodierung geben auf die die Software reagiert. Max Grundig, der alte Knauser, hätte nie auch nur einen Pfennig für die Beschriftung des MC ausgegeben, wenn es nicht nötig gewesen wäre. Deswegen vermute ich stark, das die Aufschrift 'PAL' auch wirklich PAL-only meint (evtl. mit SECAM Huckepack). Man sieht ja auch, das die Firmware die Existenz eines 2. Farbträger Quarzes erstmal kategorisch ausschliesst.
:
Bearbeitet durch User
Matthias S. schrieb: > Max Grundig, der alte Knauser, hätte nie auch nur einen Pfennig für die > Beschriftung des MC ausgegeben, wenn es nicht nötig gewesen wäre. Der gute Max verstarb aber schon etwa 1985, dieses Chassis stammt von 1997 und später. 😄🤩😉
Mal eben nachgeschaut: Er verstarb im Jahr 1989 und hatte da bereits nichts mehr mit seiner ehemaligen Firma zu schaffen.
Tja, die Frage ließe sich nur mit Zugriff auf die Firmware selbst klären..
Oder auch mit einem Blick auf die Geschichte. Wiedervereinigung 1990. Der kalte Krieg ist zu Ende. Die ehemaligen Besatzungsmächte ziehen sich aus Deutschland mehr und mehr zurück. Die USA legt Standort für Standort still. Die einzigen NTSC-Standorte in D "überhaupt". Mit dem allgemeinen Preisverfall der Fernsehgeräte ist ein echter Export nach USA für den Hersteller nicht wirtschaftlich. Ein Weitbereichsnetzteil (90 bis 240Volt) hat das Chassis auch nicht. Eine Mitnahme durch heimkehrende Soldatenfamilien ist auch deswegen unwahrscheinlich. So "teuer" sind TVs bald nicht mehr, dass sich dies gelohnt hätte. Zur Währungsumstellung 2001 kostete ein "Standard"-70cm-Röhrenfernseher im Kaufhaus noch 600DM (Aldi, etc.), dann rund 400 Euro. Wegen vereinzelter Nachfragen gab es eine interne Servicemitteilung an den Fachhandel sowie Vertragswerkstätten, dass bei einem Grossteil der Serie der 3,579..MHz Quarz gar nicht bestückt ist.
Angehängte Dateien:
-
fr_jumper.png
38 KB
Nette Geschichten, aber hart an der Grenze zur Verschwörungstheorie, findet ihr nicht? Ich habe ja durch den Dump bewiesen das die Steuerung alles so macht als wäre es ein Multi-Norm Gerät und auch die Menüpunkte im OSD sind verfügbar. Einzig das eine INIT-Byte ist anders. Und es soll für Grundig wirtschaftlich gewesen sein 4 verschiedene ROM-Masken hergestellt zu haben die sich möglicherweise nur in einem einzigen INIT-Byte für den Farbdekoder unterschieden haben? Das kann ich auch nicht recht glauben. Für eine Beschriftung ist nur eine Siebdruckschablone nötig, die kostet nichts im Vergleich zu einer ROM-Maske. Ich denke immer noch das es extern ein Bauteil (Jumper oder ID über I2C) gibt um der Firmware mitzuteilen ob ein zweiter Quarz da ist oder nicht. Der Dekoder selbst hat wohl keine Funktion um das festzustellen? Mir sticht ja immer noch dieser "Jumper" (0 Ohm SMD-Widerstand) CR81010 in der Nase... Jetzt muss ich erstmal einen I2C-Filter bauen um dem Dekoder die "richtige" INIT-Sequenz zu geben und zu prüfen ob das wirklich ausreicht oder da doch noch mehr zu tun wäre. Würde mal versuchen das mit einem Arduino Nano oder STM32 Bluepill hin zu bekommen.
:
Bearbeitet durch User
Die übrigen Portbits kannst Du über einen "Angstwiderstand" von etwa 1 bis 2 Kiloohm einzeln nacheinanderauf hi oder low legen.
So, mal ein paar Versuche mit einem I2C-Sender gemacht, einfach nur mal parallel mit drauf auf den Bus und mal Master gespielt, aber leider noch ohne den gewünschten Erfolg. Folgender Versuchsaufbau: - Arduino Nano mit USB am PC - Programmiert mit I2C-Master Lib von "Rambo" (passt ja vom Bauzeitraum des Fernsehers ;-) https://github.com/rambo/I2C und einer modifizierten Version des "i2crepl" aus den examples der Lib. - Anschluß an I2C Bus vom Fernseher mit SDA/SCL (und GND), jeweils mit einem 100 Ohm in Reihe. - Ebenfalls parallel dazu meinen LA geklemmt, damit ich mitlesen kann was auf dem Bus passiert. Folgendes habe ich noch beim sniffen beobachtet. Der Prozessor des FS sendet jede Sekunde zweimal im Abstand von 5ms eine Programmierung an den Farbdekoder. Warum zweimal? Keine Ahnung! :-) Die beiden Pakete scheinen gleich zu sein, auch wenn sich der Inhalt der insgesamt 24 Bytes an ein zwei Stellen mal leicht ändert, auch wenn man nichts am FS umstellt. Mein erster Versuch war einfach nur die Bytefolge 0x00, 0x03 (oder 0x00, 0x43) an 0x8A zu senden. 0x8A ist die Write-Adresse (wenn man I2Cwrite() der Lib verwendet muss man die um ein Bit nach rechts schieben, also 0x45, weil die High-Level Funktion das Read/Write Bit selbst steuert). Beides führte zu keiner wirklich sinnvollen Reaktion. Zur Info: mit dem ersten Byte gibt man die Subadresse an (hier 0x00) und dann folgen die Datenbytes, wobei der Dekoder dann intern die Subadresse automatisch inkrementiert. Im ersten Byte steht an Bit-Position D1+D0 die Nutzung der Quarze, welche ja mit 0b10 initialisiert wird und ich da dann eine 0b11 schreibe, damit der Farbdekoder weiss das er zwei Quarze hat und diese auch nutzen kann. Dann habe ich eines der Pakete (24 Bytes) genommen und sende das, mit nur leicht abgewandeltem ersten Byte. Da "zuckt" das Bild, aber mehr auch nicht. Keine erkennbare Farbe, alles weiterhin S/W mit der NTSC-Quelle (Videorekorder oder Bildgenerator). Was ich noch merkwürdig finde ist, das der Prozessor 24 Bytes sendet, der Farbdekoder aber nur 0x16 (22) Subadressen/Register hat. Im Datenblatt steht nicht was passiert wenn der Auto-Inkrement "oben" angekommen ist, ob ein Überlauf stattfindet. Wieder Raum für Spekulationen. Ich befürchte das ich den Bus durch zwei Master etwas aus dem Sync bringe. Gut möglich das sich SCL meines Arduino und SCL vom Prozessor mischen, oder SDA und das ergibt Matsche. Auch sendet die I2C entweder mit 100 oder 400 kHz, der interne Prozessor jedoch nur mit 50 kHz. Ich denke zwar das das nichts ausmacht, denn verstehen wird das der Farbdekoder, aber mit einem kleinen Patch in der Lib könnte man das ändern. Ich muss also mit zwei I2C Bussen arbeiten, was aber gar nicht so trivial ist, zumindest mit dem Arduino Nano und den hab ich halt grad mal zur Verfügung. Der hat kein natives I2C, sondern nur TWI und davon auch nur einen. Eine Software-I2C habe ich noch nicht gefunden. Die meisten Lösungen gehen darauf mehrere Slaves zu haben, ggf. Slaves mit gleicher HW-Adresse und dafür dann ein logisches Oder mit separat gespeistem SCL zu bauen. Das nutzt mir hier aber nichts, da ich einmal Master und einmal Slave simulieren muss und da brauche ich zwei unabhängige I2C Busse.
Olli Z. schrieb: > Ich muss also mit zwei I2C Bussen arbeiten Du kannst mit nem Analogschalter 74HC4052 einfach zwischen 2 Mastern umschalten.
Olli Z. schrieb: > Auch sendet die I2C entweder mit 100 oder 400 kHz, der interne Prozessor > jedoch nur mit 50 kHz du solltest dich für eine I2C Frequenz entscheiden und deutlicher schreiben: Olli Z. schrieb: > Auch sendet die I2C welche? Du hast es im Kopf, aber das sehen wir nicht! Klar kann ich spekulieren das du die von Arduino meinst, ich kann aber auch ganz falsch liegen! Also bitte immer mit Kontext posten www, wer wie was mit Subjekt Prädikat und Objekt.
Meine beiden Grundig Multinorm Röhren-TV habe ich noch behalten. Die hatte ich vor allem um französische Sender aus dem Elsaß zu sehen, einen amerikanischen Soldatensender gab es auch im nächsten Vorort. Aber dessen miserable Bildqualität und das Programmangebot haben mich davon abgehalten dort öfters reinzuschauen. Normunterschiede: frz. TV: gleiche Bild/Zeilenfrequenz, aber inverse Modulation, auf einem PAL-TV kam nur ein durchlaufendes negatives s/w-Bild. Farbe SECAM, FM-moduliert statt QAM, auch Verzögerung um eine Zeile aber nur halbe vertikale Farbauflösung gegenüber PAL. Die Franzosen hatten mal noch eine andere Norm aber die war damals (Mitte der 80er) schon Geschichte. amer.TV: 60 Hz Bild, Zeile 15675 (?) statt 15625 Hz 525 Zeilen statt 625. Farbe NTSC, dazu auf der Fernbedienung ein zusätzlicher Einsteller für Hue (Farbton) von violetter bis zu grüner Hautfarbe. Ton-ZF 4,5 statt 5,5 MHz
:
Bearbeitet durch User
Olli Z. schrieb: > Der hat kein natives I2C, sondern nur TWI Das ist das gleiche, wurde nur aus Copyrightgründen TWI genannt. > Eine Software-I2C habe ich noch nicht gefunden. Peter Fleurys I²C Lib funktioniert mit Hardware TWI oder Software Bitbanging auf allen AVR, die mir bisher untergekommen sind: http://www.peterfleury.ep(i)zy.com/avr-software.html#libs Nimm die Klammern aus dem Link, sind wg. eines Spamfilters hier im Forum. > Der Prozessor des FS sendet jede Sekunde zweimal im Abstand von 5ms eine > Programmierung an den Farbdekoder. Warum zweimal? Keine Ahnung! Ja, das habe ich oben schon mal erwähnt. Die Jungs stopfen den Bus voll. Es spricht aber nicht viel dagegen, die Programmierung des TDA8375 selber zu machen und ihn vom Grundig Bus komplett abzuhängen. Oder eben mit einem Mux umschalten - siehe den CD4052/4053.
:
Bearbeitet durch User
Joachim B. schrieb: Und ich dachte schon meine Texte sind zu lang, zu ausführlich ;-) >> Auch sendet die I2C entweder mit 100 oder 400 kHz, der interne Prozessor >> jedoch nur mit 50 kHz > du solltest dich für eine I2C Frequenz entscheiden und deutlicher > schreiben: Also, der "Standard" bei I2C ist normalerweise 100 kHz für SCL oder (I2C-fast) 400 kHz. Zumindest die 100 kHz können alle Bauteile mit I2C Bus vertragen. Die im Fernseher verwendete SCL liegt aber laut meinen LA-Messungen (siehe die logic-files weiter oben) bei ca. 50 kHz. D.H. der SDA5256 (Prozessor) des Fernsehers verwendet nur so viel. Die Slave-Bausteine können das sicher gut wegstecken wenn ich diese von meiner Arduino-I2C mit 100 kHz beschicke, aber wenn ich dem SDA5256 vom Fernseher als simulierter Farbdekoder eine Antwort schicken muss, weil ich mich mit Arduino zwischen Farbdekoder-I2C und Fernseher-I2C Bus klemme, dann sollte ich das wohl besser auch mit 50 kHz tun. Das war meine Aussage dahinter.
Hi, Olli Z. schrieb: > aber wenn ich dem SDA5256 vom Fernseher als > simulierter Farbdekoder eine Antwort schicken muss, weil ich mich mit > Arduino zwischen Farbdekoder-I2C und Fernseher-I2C Bus klemme, dann > sollte ich das wohl besser auch mit 50 kHz tun. Bei der Antwort simuliert du doch den Slave... Da gibt der Master den Takt vor und generiert genau die Geschwindigkeit die ER möchte. Bei einer vernünftig implementierten I2C Routine also "Null Problemo" Gruß Carsten
Achja: Der Erste Versuch den ich machen würde wäre was passiert überhaupt wenn du den Bus zwischen Prozessor und TDA nach der Initialisierung! auftrennst. Geht dann der TV in einen Fehlermodus oder läuft es normal weiter? Falls es normal weiter läuft sollte ein "Zwischenglied" zwar weiterhin das Endziel sein, aber für deine Tests ob es überhaupt geht könntest du den TDA dann einfach selbst bespielen ohne das der µC des TV dazwischensendet. Was meinst du mit "Du hast im Moment nur einen "Arduino Nano" zur Verfügung? Meinst du damit tatsächlich die STÜCKZAHL EINS? ODer das du gerade nur Nanos als schnell und einfach einzusetzende Bausteine da hast? Also mehrere Module, aber halt alles nur Nano? Falls zweiteres könntest du eine "Gateway mit Bitmanipulation bei Bedarf" Lösung auch mit ZWEI Nanos realisieren die du Back-TO-Back über eine ASYNC (RS232) Verbindung koppelst. (Für deine ZWecke reicht ja sogar vom TV-µC Modul TX zum TDA seitigen Modul. RX ist gar nicht zwingend nötig weil du die Aufgaben ja notfalls kpl. selbst generieren kannst. Eine vereinfachte zwischenlösung davon wäre ein Modul das einfach nur alle an den TDA gerichteten Telegegramme ACK(t) und das du nach Auftrennen des Busses dann TV Seitig einhängst falls der TV sonst in den Fehlermodus geht. (ISt erst mal weniger komplex zu Programmieren da du noch nicht die "zusammenarbeit" der Module realisieren musst und kann dann später in eine echte (intelligente) Brücke erweitert werden wenn als wie gewünscht klappt.) Gruß Carsten
Carsten Sch. schrieb: > Der Erste Versuch den ich machen würde wäre was passiert überhaupt wenn > du den Bus zwischen Prozessor und TDA nach der Initialisierung! Das hatte ich bereits am Anfang versucht, weil ich dachte ich könnte so "in aller Ruhe" den Dekoder umprogrammieren. Geht aber nicht weil der TV-Prozessor jede Sekunde vom Farbdekoder die Status-Register ausliest (besonders das POR Flag) und wenn das nicht kommt oder nicht den erwarteten Wert (low) hat, dann geht der TV nach kurzer Zeit aus. > Was meinst du mit "Du hast im Moment nur einen "Arduino Nano" zur > Verfügung? Ich meine das ich hier einen ganzen Stall voll Prozessoren und Elektronik habe, aber leider keinen Arduino Mega, welcher wohl über zwei native I2C Busse verfügt. Darüber hinaus habe ich noch andere Mini-Boards aber da müsste ich mich erst wieder reinarbeiten und ich wollte jetzt eigentlich kein Unterprojekt aufmachen ;-) Erstmal muss "nur" bewiesen werden ob man über die Umprogrammierung des Farbdekoders NTSC darstellen kann oder ob das noch von weiteren, bislang nicht erkannten Teilen der Software abhängig ist. > ODer das du gerade nur Nanos als schnell und einfach einzusetzende > Bausteine da hast? Also mehrere Module, aber halt alles nur Nano? Ja, und nen Uno aber das ist ja praktisch derselbe Atmega. > Falls zweiteres könntest du eine "Gateway mit Bitmanipulation bei > Bedarf" Lösung auch mit ZWEI Nanos realisieren die du Back-TO-Back über > eine ASYNC (RS232) Verbindung koppelst. (Für deine ZWecke reicht ja > sogar vom TV-µC Modul TX zum TDA seitigen Modul. RX ist gar nicht > zwingend nötig weil du die Aufgaben ja notfalls kpl. selbst generieren > kannst. Und wie man sieht fängt es an komplex zu werden. Das anfangs hier gesagte "... schalte doch einfach einen kleinen Mikroprozessor dazwischen der den Farbdekoder programmiert..." ist halt nicht sooo trivial wie es zunächst aussieht :-) Ich schaue mir gerade die Lib von Peter Fleury an um per Bit-Bang einen zweiten Bus zu bauen. Das sollte wohl am einfachsten sein, bevor ich anfange mit Multiplexing oder externen Bausteinen. Ich werde berichten!
Der ATmega328PB hat 2 * I2C. Gibt es als Board Wattuino Pro Mini PB zu kaufen.
Olli Z. schrieb: > "... schalte doch einfach einen kleinen Mikroprozessor > dazwischen der den Farbdekoder programmiert..." ist halt nicht sooo > trivial wie es zunächst aussieht :-) Kommt drauf an, was man mit kleinem uC meint ;-). Es gibt genügend kleine die mehrere I²C Busse haben und auch schnell genug bedienen könnten. Aber genau dein Hinweis mit, TV fragt zyklisch den Baustein ab, war vorher wohl kaum jemanden so bewußt hier. Es wird dir auch nicht viel nützen den TDA8xxx selbst umzuprogrammieren wenn die TV SW diesen dann wieder zyklisch anders beschreibt. Oder kannst du den I²C zum TDA8xxx im Betrieb auftrennen und die TV SW stört das nicht? Wenn ja, dann kannst nach dem starten des TVs den I²C zum TDA8xxx mit Analogschalter umschalten auf deinen Master. Der sollte am besten auch mit den 50kHz laufen und die gleichen Pull-Ups verwenden. Ansonsten wenn die TV SW auch im Betrieb einen fehlenden TDA8xxx erkennt und abschaltet, dann könntest nach dem starten den TV Master auf einen 2. solchen TDA umschalten und den eigentlichen TDA8xxx auf deinen Master.
Olli Z. schrieb: > Und ich dachte schon meine Texte sind zu lang, zu ausführlich ;-) nicht in wesentlichen Teilen! Olli Z. schrieb: > Also, der "Standard" bei I2C ist normalerweise 100 kHz für SCL oder > (I2C-fast) 400 kHz. bekannt! aber nicht: Olli Z. schrieb: > Die im Fernseher verwendete SCL liegt aber laut meinen LA-Messungen > (siehe die logic-files weiter oben) bei ca. 50 kHz. die Info fehlte! woher sollen wir wissen welche I2C du meinst wenn es 2 Master gibt den TV und dein µC? Du solltest zumindest im TV die Leiterbahn mal auftrennen, dazu benutzten wir Belzer Schaber* (tm) wenn es mit einseitig Bauteil ablöten nicht geht! *Belzer Schaber ist nun verkauft und wohl https://www.distrelec.de/de/dreikantschaber-bahco-3525-hb/p/18067588 klar kann man auch Cutter oder Teppichmesser nehmen, aber die Gefahr das die Klinge bricht, man abrutscht und das halbe Chassis trennt ist viel größer. Der 3-kant Schaber ist viel besser zu halten und punktgenau zu führen
:
Bearbeitet durch User
michael_ schrieb: > Hast du keinen Zugriff auf einen Amiga Monitor o.ä. > Oder einen Multisync- Monitor? Also, der 1084 war wohl kein Multinorm Monitor, die Geräte in den USA konnten NTSC und die europäischen PAL. Was ging, war, dass er sich bei RGB Speisung auf wahlweiße 50 bzw. 60 Hz syncronisierte. Das gleiche gilt für die Mutisync (bekannt z.B. NEC 3D), die konnten RGB und gingen bis 15 KHz Zeilenfrequenz (600x200 Pixel, z.B. Amiga) runter, konten aber auch VGA. Die Mutisync hatten aber keinen Composite Eingang.
hast Du mal dein Oszi,: "am Pin33 nachsehen welcher Quarz gewählt wurde" gemacht ? Auch mal nachsehen ob Dein NTSC Quarz überhaupt schwingt, der müsste immer eingeschaltet sein. Der TDA läuft wahrscheinlich immer mit "own intelligence", die Umstellung auf NTSC wird dann wahrscheinlich zum Ablenkprozessor gesendet um die Horizontal/Vertikal-Frequenz anzupassen. Du könntest ja auch den PAL und NTSC Quarz tauschen und nachsehen ob dann NTSC funktioniert. Das Datenblat wird wahrscheinlich nicht alle "Geheimnisse" zum I2C verraten. Gruß, Elmar
Olli Z. schrieb: > Ich schaue mir gerade die Lib von Peter Fleury an um per Bit-Bang einen > zweiten Bus zu bauen. Das sollte wohl am einfachsten sein, bevor ich > anfange mit Multiplexing oder externen Bausteinen. Es könnte auch reichen, einen Tiny als 'Dummy' am Grundig Bus zu betreiben, der so tut, als wäre er ein TDA8375. (Müsste ja nur das Status Register simulieren und immer ACK, solange er angesprochen wird). Dann bist du völlig frei, den wirklichen TDA zu manipulieren.
Mehrere Gründe, warum das "Alles nicht so einfach ist..." Die sog. Schutzschaltung. Beim Betrieb der Farbbildröhre müssen Grenzwerte zuverlässig eingehalten werden, der mittlere Strahlstrom sowie die Hochspannung. Bereits beim Auftreten des sog. Ersten Fehlers dürfen die Grenzwerte nicht überschritten werden, da die abgegebene Röntgenstrahlung sonst überproportional ansteigt. Pin 50 Signalname U Schutz.
Nichtverzweifelter schrieb: > Die sog. Schutzschaltung. Beim Betrieb der Farbbildröhre müssen > Grenzwerte zuverlässig eingehalten werden, der mittlere Strahlstrom > sowie die Hochspannung. Das wird aber nicht über den Bus geregelt. Es redet ja niemand davon, den Chip aus dem TV zu reissen, sondern nur den I2C Bus zu manipulieren.
Ein weiterer Grund, warum "Das alles nicht so einfach ist": Die Koinzidenzstufe. Seit etwa ab 1980/81 vorgeschrieben. So ein (beliebiges) Fernsehgerät konnte immer weitere Frequenzbänder empfangen. Den damals so genannten "Unteren Sonderkanalbereich", den "Oberen S...", dann noch den "Erweiterten Sonderkanalbereich", letztlich dann: Durchgehend von 45 bis 800MHz, grob gerundet. Die Folge: "Polizeifunk", "nicht öffentlichere beweglicher Landfunk" , "Flugfunk" wären problemlos mitzuhören gewesen. Das wollte der Gilb nicht, das "Fermelde Technische Zentralamt" auch nicht. Folglich mussten die TV-Gerätehersteller ihre Schaltungen um jene Koinzidenzstufe erweitern, eine Auswertung auf H-Synchronsignale im empfangenen "Sendersignal". Logik: Ist es kein Fernsehsignal, so hat der Tonkanal stummgeschaltet zu bleiben. Auch das erledigt der TDA.
Weiterer Grund: Sendeschluss, Energiesparen. Kam auch schon Anfang der 80er Jahre, später machte das jeder beliebige Röhren-TV. Ist der Zeilenablenkgenerator nicht synchronisiert, "meldet" er das, der Bedienteilprozessor zählt meistens so um die 5 Minuten, geht dann in "Standby". Bei einer Busblockade wahrscheinlich schneller (Eigenüberwachung).
Also, ich habe ja den SDA/SCL Bus kurz vor dem Farbdekoder (TDA) aufgetrennt und je eine Stichleitung rausgelegt die vom TV-Microcontroller kommt und eine die zum TDA geht. An die uC-I2C Leitung habe ich dann das I2C (hust - Wire) Interface eine Arduino (Nano) verbunden und mittels Wire.h Bibliothek eine Slave-Simulation zusammengestellt. Ich empfange darüber problemlos die Daten vom uC die an den TDA gerichtet sind. Sowohl die Read-Requests (auslesen der Statusregister) auf 0x8B, als auch die Write-Requests (zum beschreiben der Register auf 0x8A). Habe mir das anfangs einfach auf eine serielle Console ausgeben lassen. Zuständig sind zwei Serviceroutinen im Code. Alles nach "Lehrbuch" ;-) Nun wollte ich die Master-Simulation in Richtung TDA mit einer Big-Bang Library machen. Dabei habe ich zunächst einfach versucht dem TDA die Leseanfrage vom uC weiterzuleiten. Leider reagiert dieser nicht wie erwartet. Mit dem LA erkenne ich das der Leserequest auf Byte 0x8B rausgeht aber dann ein NAK erfolgt, weil der Slave nicht darauf reagiert. Es ist fast so als wäre die elektrische Verbindung gestört, oder das Kabel abgezogen. Natürlich habe ich schon alles mögliche probiert (Signale tauschen, Pegel prüfen, Takt runtersetzen bis auf 10kHz, alles überprüfen, andere Bitbang lib testen), alles erfolglos. Wo könnte der Fehler stecken? Verbinde ich die beiden Stichleitungen, läuft der TV und ich kann auch mit dem LA sniffen.
Olli Z. schrieb: > Wo könnte der Fehler stecken? in Prosa statt Schaltbild Woher sollen wir erkennen das du 1. richtig verkabelt hast? 2. alle relevanten GND verbunden sind? uvam.
Angehängte Dateien:
-
IMG_2367.jpg
470 KB -
tda8375_i2c_bus.png
150 KB
Schaltbild... naja. GND ist dran, klar und vertauscht habe ich zigmal nachgeprüft.
1 | #include <Wire.h> |
2 | #include <BitBang_I2C.h> |
3 | |
4 | BBI2C bbi2c; |
5 | |
6 | void setup() |
7 | {
|
8 | // Slave simulation |
9 | Wire.begin(0x45); |
10 | Wire.onReceive(receive_event); |
11 | Wire.onRequest(request_event); |
12 | |
13 | // Master simulation |
14 | memset(&bbi2c, 0, sizeof(bbi2c)); |
15 | bbi2c.bWire = 0; // use bit-bang |
16 | bbi2c.iSDA = 2; // Port "D2" (green) |
17 | bbi2c.iSCL = 3; // Port "D3" (blue) |
18 | I2CInit(&bbi2c, 50000L); // 50 kHz clock |
19 | } |
20 | |
21 | /** |
22 | * Data is send from Master to Slave (us) |
23 | */ |
24 | void receive_event(int num_received_bytes) |
25 | {
|
26 | byte buffer[32]; |
27 | byte data; |
28 | int i = 0; |
29 | |
30 | while(Wire.available()) |
31 | {
|
32 | data = Wire.read(); |
33 | buffer[i++] = data; |
34 | } |
35 | I2CWrite(&bbi2c, 0x45, buffer, num_received_bytes); |
36 | } |
37 | |
38 | /** |
39 | * Data is requested by Master from Slave (us) |
40 | */ |
41 | void request_event(void) |
42 | {
|
43 | byte buffer[32]; |
44 | |
45 | I2CRead(&bbi2c, 0x45, buffer, 3); |
46 | for (int i=0; i <= 2; i++) |
47 | {
|
48 | Wire.write(buffer[i]); |
49 | } |
50 | } |
51 | |
52 | void loop() {
|
53 | delay(10); |
54 | } |
:
Bearbeitet durch User
Olli Z. schrieb: > Wo könnte der Fehler stecken? Verbinde ich die beiden Stichleitungen, > läuft der TV und ich kann auch mit dem LA sniffen. Frage, da mir das peinlicherweise auch schon mal zu einer ZEit passiert ist als es schon lange nicht mehr hätte passieren dürfen und ich dann bestimmt eine Stunde gesuncht und geflucht habe bis mir mein dummer Fehler aufgefallen ist (Manchmal gibt es halt so Tage...) Der I2C Bus braucht ja Pull-Up Widerstände. Wenn du die Leitung auftrennst musst du also für eines der beiden Segmente neue Widerstände anbringen. Also: An die (neuen) Pull-Up Widerstände für das Stück zwischen Arduino und TDA hast du gedacht ? Gruß Carsten
:
Bearbeitet durch User
Olli Z. schrieb: > GND ist dran was denkst du wie oft ich das hörte und gelesen hatte? und dann war es doch anders! wenn du doch alles richtig gemacht hättest würde es funktionieren! Es funktioniert aber nicht! Wie sollen wir Fehler finden wenn du nichts von dem zeigst was du gemacht hast?
:
Bearbeitet durch User
Olli Z. schrieb: > Mit dem LA erkenne ich das der Leserequest auf Byte 0x8B > rausgeht aber dann ein NAK erfolgt, weil der Slave nicht darauf > reagiert. Es kann sein, das du die drei Statusregister im Umschnurzel-MC vorhalten musst, weil sonst die Ablaufsteuerung ungeduldig wird. Also immer mal wieder vom TDA8375 lesen und auf Anfrage dem Kontroll-MC präsentieren.
Es ist wohl so das die BitBangI2c Library für Arduino (BB2IC) nicht richtig funktioniert. Ich habe den TDA gestern mal mit Wire angesprochen und da reagiert er erwartungsgemäß. Im LA-Snap von BitBang sehe ich ein falsches Timing, die Datenbits und die Taktflanke ändern sich nahezu gleichzeitig, da sollte aber eine Phasenverschiebung drin sein. Habe dann eine andere Library verwendet (gibt ja genug davon, stöhn) die "Arduino_SoftWareI"C" (https://github.com/Seeed-Studio/Arduino_Software_I2C/) und damit lieft auch der Bit-Bang Kontakt zum TDA sofort problemlos. Auch der LA-Snap sah nun gut aus. Es war also kein falsch gepinntes Signal oder sowas sondern die BitBang_I2C (https://github.com/bitbank2/BitBang_I2C) hat für mich einfach nicht funktioniert. Dann habe ich meine "Man-In-The-Middle" Software darauf umgeschrieben aber so einfach ist es auch nicht... Problem 1) Timing Der TV-uC erwartet als I2C-Master das wenn er Daten von einem Slave requested, also dessen Adresse auf den Bus legt, das dieser sofort ein ACK gibt und gemäß dem vom Master vorgegebenen Takt die Daten sendet. Wenn ich in meiner Behandlungsroutine jedoch in diesem Moment erst den TDA befrage um sein Ergebnis zu relayen, dauert das zu lange und der Master gibt irgendwie auf (so meine Theorie). Also habe ich das so gemacht das ich immer das letzte vom TDA empfangene Paket sofort zum TV-uC sende und danach dann die eigentliche Statusinfo vom TDA lade und für die nächste Abfrage speichere. Ich beginne dabei mit der Sequenz 0xD0, 0xC4, 0xC7 (da ist POR noch HIGH), die sollte unverfänglich sein. Bei der direkten Kommunikation von TV-uC zu TDA sieht die Initialsequenz so aus:
1 | 3.810255687500000,I2C,Setup Read to [0x8B] + ACK |
2 | 3.810445625000000,I2C,0xD0 + ACK <--- POR (D7) != 0 (wait for POR) |
3 | 3.810588375000000,I2C,0xC4 + ACK |
4 | 3.810731125000000,I2C,0xC7 + NAK |
5 | ... |
6 | 3.810914812500000,I2C,Setup Read to [0x8B] + ACK |
7 | 3.811104812500000,I2C,0x50 + ACK <--- POR (D7) == 0 (OK!) |
8 | 3.811247500000000,I2C,0xC4 + ACK |
9 | 3.811390250000000,I2C,0xC7 + NAK |
Solange ich dem TV-uC die mit 0xD0 beginnende Antwort sende, dreht dieser in einer Endlosschleife, solange bis POR null ist. Aber - auch das hat nicht geklappt, sprich der Fernseher springt nicht an. Hier habe ich im LA am I2C zum TV-uC gesehen das anstatt der erwarteten Bytes die Antwort immer 0x00, 0x00, 0x00 war. Eine Debug-Ausgabe vom Arduino zeigte aber das dieser die richtigen Werte vom TDA empfängt. Dennoch akzeptiert der TV diese Antwort irgendwie... Ich vermute im Moment das sich der TV-uC zunächst nur auf das POR-Bit konzentriert und das ist ja auch mit der Null-Antwort aus seiner Sicht korrekt. Problem 2) Fehlendes NAK bei falscher Abfrage Der TV-uC macht nach obiger Feststellung zunächst einen Schreibversuch auf den TDA, welcher aber ungültig ist, da der TDA mit NAK antwortet. Im direkt verbundenen Zustand sieht das so aus:
1 | 3.811571625000000,I2C,Setup Write to [0x8A] + ACK |
2 | 3.811766937500000,I2C,0x20 + NAK |
3 | 3.811961562500000,I2C,0x00 + NAK |
In meinem Code weiss ich nicht wie ich ein NAK erzeugen sollte, wenn ich die o.g. Daten erhalten würde? Aktuell sieht mein Code so aus:
1 | // |
2 | // grundig_i2c_test1 |
3 | // |
4 | |
5 | #include <Wire.h> |
6 | #include "SoftwareI2C.h" |
7 | |
8 | SoftwareI2C softwarei2c; |
9 | uint8_t reqBuffer[3] = { 0xD0, 0xC4, 0xC7 }; // intial sequence
|
10 | |
11 | void setup() |
12 | {
|
13 | // Slave simulation |
14 | Wire.begin(0x45); |
15 | Wire.onReceive(receive_event); |
16 | Wire.onRequest(request_event); |
17 | |
18 | // Master simulation |
19 | softwarei2c.begin(2, 3); // sda, scl |
20 | // SDA = Port "D2" (green) wh-vt |
21 | // SCL = Port "D3" (blue) bu-gy |
22 | |
23 | Serial.begin(115200); |
24 | Serial.println("Grundig I2C Man-In-The-Middle NTSC-Coder: AT YOUR SERVICE!");
|
25 | } |
26 | |
27 | /** |
28 | * Intercept data send from TV (Master) to TDA (Slave) |
29 | */ |
30 | void receive_event(int num_received_bytes) |
31 | {
|
32 | uint8_t buffer[32]; |
33 | uint8_t data; |
34 | int i = 0; |
35 | |
36 | // read message into buffer |
37 | while(Wire.available()) |
38 | {
|
39 | data = Wire.read(); |
40 | buffer[i++] = data; |
41 | |
42 | // detect "bad write" (0x20, 0x00) to be answered by NAK |
43 | if (i == 2 && buffer[0] == 0x20 && buffer[1] == 0x00) {
|
44 | return; // SOS! I don't know what to do here to send NAK! |
45 | } |
46 | } |
47 | |
48 | // relay received message to TDA |
49 | softwarei2c.beginTransmission(0x45); |
50 | softwarei2c.write(num_received_bytes, buffer); |
51 | softwarei2c.endTransmission(); |
52 | |
53 | /* |
54 | // DEBUG OUT |
55 | Serial.print("TV -> ARDU:");
|
56 | for (i=0; i < num_received_bytes; i++) |
57 | {
|
58 | Serial.print(" ");
|
59 | Serial.print(buffer[i] < 16 ? "0" : ""); |
60 | Serial.print(buffer[i], HEX); |
61 | } |
62 | Serial.println(); |
63 | */ |
64 | } |
65 | |
66 | /** |
67 | * Data is requested by Master from Slave (us) |
68 | */ |
69 | void request_event(void) |
70 | {
|
71 | int i; |
72 | |
73 | // send last received answer from TDA to TV |
74 | Wire.write(reqBuffer, 3); |
75 | |
76 | // get real status from TDA into buffer |
77 | softwarei2c.requestFrom(0x45, 3); |
78 | i = 0; |
79 | while(softwarei2c.available()) |
80 | {
|
81 | reqBuffer[i] = softwarei2c.read(); |
82 | i++; |
83 | } |
84 | |
85 | /* DEBUG OUT |
86 | Serial.print("TV request status from TDA:");
|
87 | for (i=0; i <= 2; i++) |
88 | {
|
89 | Serial.print(" ");
|
90 | Serial.print(buffer[i] < 16 ? "0" : ""); |
91 | Serial.print(buffer[i], HEX); |
92 | } |
93 | Serial.println(); |
94 | */ |
95 | } |
96 | |
97 | void loop() {
|
98 | delay(100); // no idea ist this is for any good... |
99 | } |
Angehängte Dateien:
-
first_sim_answer.png
26 KB -
la_byte_detail.png
34 KB
Hier mal ein LA-Screenshot vom I2C-Bus der vom TV-uC kommt. Diesen bediene ich mit der Wire Library, also Hardwarenah. Was auch immer das für ein Gezappel auf der SDA Leitung da vor dem Read-Request ist, die nachfolgende Leseanforderung an 0x8B sieht ja ok aus. Die Pause die dann folgt ist der Verarbeitungszeit im Arduino geschuldet. Wenn ich TV-uC und TDA direkt verbinde liegt dazwischen keine Leerlaufzeit, klar. Das nach der Bytesequenz 0xD0, 0xC4, 0xC7 folgenge NAK ist wohl normal(?). Beim zweiten Bild (la_byte_detail.png) sieht man wie der TV-uC das "Setup read to" Byte schön sauber aufbaut. Die Flankenwechsel von SDA und SCL sind ordentlich phasenverschoben, wie aus dem Lehrbuch (bis zum roten Strich). Sobald dann aber der Arduino mit Wire-Lib(!) nun zu sendenden Datenbits auflegt sieht es so aus als wäre der zu langsam, sprich die 1-Bits gehen quasi gleichzeitig mit der steigenden Flanke vom SCL hoch (rot umrahmt). Das kann zu Fehlinterpretationen führen. Merkwürdigerweise legt der I2C-Master im TV-uC dann auch plötzlich einen schnelleren SCL Takt an. Die Pulse sind deutlich kürzer. Wären sie so lang wie beim senden des Request-Bytes, wäre das Timing vom Arduino vermutlich ok.
Thread beobachten
Seitenaufteilung abschalten
.jpg){kind=link}
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.