Hello, Guest the thread was viewed609 times and contains 16 replies

last post from HypnoToad at the

c16 zu dunkle Farbe 0 (Hintergrund)

    Hallo,


    mein c16 zeigt die Farbe 0 zu dunkel an, also wenn ich


    "color 0,2,7: color 1,2,7:color 4,2,7" eingebe müsste ja der Bildschirm komplett weiß sein (Rand, Hintergrund und Schrift) und mann dürfte die Schrift nicht lesen können.


    Aber bei mir ist nur der Rahmen weiß und die Schrift. Während der Hintergrund dunkler ist, also grau. Die Schrift kann man lesen.


    Die Farbe ist identisch mit einem Farbwert dunkler. Es gibt noch mehr Farbstufen, aus der Liste vom 0-7, die übersprungen werden und dunkler bleiben.


    Ich vermute, dass es ein Problem mit dem Rechner ist, habe leider keinen CRT mehr, womit ich das vergleichen kann. Oder könnte es auch ein Problem mit dem ODV sein und dem HDMI Bildschirm, den ich benutze? Das Bild ist auch so alles andere als gut.


    Ist das Problem bekannt?

    Quote from kadi

    Die Farbe ist identisch mit einem Farbwert dunkler. Es gibt noch mehr Farbstufen, aus der Liste vom 0-7, die übersprungen werden und dunkler bleiben.

    Wenn das die Umschreibung dafür ist, daß die Helligkeiten 0, 1, 2, 3, 4, 5, 6, 7 beim Hintergrundregister als 0, 0, 2, 2, 4, 4 und 6, 6 interpretiert werden, dann hängt also im Hintergrundregister Bit 0 (Wert: 1) fest auf 0. Das soll natürlich nicht so sein, und ist auch leider kein gutes Zeichen.


    Prinzipiell gibt es zwar noch die Möglichkeit, daß der Helligkeitswert auf dem Weg zum Hintergrundregister verfälscht wird, das ist aber sehr unwahrscheinlich. Was passiert, wenn Du anstelle von COLOR 0,2,7 den Befehl POKE65301,113 eingibst?


    Quote from root42

    Hast du mal im Emulator (yape, vice) getestet?

    Mit Emulation hat das nichts zu tun. Auf funktionierender Hardware hat die Hintergrundfarbe genauso 8 verschiedene Helligkeiten wie jede andere Farbquelle auch, und die gängigen Emulatoren kriegen das genauso hin.

    Hi

    Quote from Mike

    Wenn das die Umschreibung dafür ist, daß die Helligkeiten 0, 1, 2, 3, 4, 5, 6, 7 beim Hintergrundregister als 0, 0, 2, 2, 4, 4 und 6, 6 interpretiert werden, dann hängt also im Hintergrundregister Bit 0 (Wert: 1) fest auf 0.

    Hab das noch einmal untersucht und es ist wie 0 1 0 1 4 5 4 5.


    und ja es springt heller und dunkler von 0-7...


    Der Poke ist auch dunkel.

    Sieht aber von der Reihenfolge auch so aus als sei da ein Bit kaputt und immer aus 0, halt das Bit1 mit Wert 2.


    Bedeutet das das da möglicherweise der RAM defekt ist? Oder ein Chip wie der Ted?


    Habe gestern viele Programme laufen lassen, mir kam das System ansonsten stabil vor.


    Die Rams sind schon gesockelt, da ich vor 40 jahren mal auf satte 64K aufgerüstet habe.

    Quote from kadi

    Sieht aber von der Reihenfolge auch so aus als sei da ein Bit kaputt und immer aus 0, halt das Bit1 mit Wert 2.

    Quote from kadi

    Der Poke ist auch dunkel.

    Dann kann man einen Übertragungsfehler (z.B. eine defekte RAM-Zelle als Zwischenspeicherwert für die COLOR-Parameter, wie gesagt, von vornherein ziemlich unwahrscheinlich) zum TED-Register ausschließen.


    Das Bit 1 der Luminanz wird im Bit 5 des Registerwerts übertragen. Da andere Funktionen augenscheinlich nicht beeinträchtigt sind, kann eine fehlerhafte Datenbusverbindung ebenfalls nicht die Ursache sein. Denn dann ließe sich z.B. der Cursor nicht mehr an allen Stellen positionieren.


    An einem C64 hatte ich mal einen ähnlichen Fehler, hier konnten in eins der Farbregister auch nur noch 8 verschiedene Farben ge-POKE-d werden, da hing dann auch ein Bit ständig auf 0. Das ist dann in beiden Fällen ein teildefekter Videochip, und ich kann dir nur die Daumen drücken, daß es dabei bleibt.

    Quote from kadi

    Danke für Eure Hilfe, mein Problem ist geklärt. TED Tausch = Problem Tausch. Also ist was am TED kaputt. Werde nach Ersatz suchen.

    Nur mal rein aus Neugierde: ist es ein 7360 oder 8360? Wobei 7360 ja extrem selten anzutreffen sind, Und ist es einer aus der Originalbestückung von 1984 oder mit anderen Datumscode?

    > Dieser C= 16 lief aber letzes mal auch noch...


    Die eingebaute Selbstzerstörung funktioniert leider auch bei unbenutzten Chips und Raumtemperatur. Und schuld hat tragischerweise ausgerechnet ein ungeeigneter 'passivation layer', das ist (grob vereinfacht) der Schutzlack, der eigentlich als letzte Schicht den Halbleiterchip vor dem Wegrosten durch Umwelteinflüsse schützen soll. Commodore wußte auch, daß da irgendwas nicht stimmt, aber die C16-Chips konnte man nicht einfach in der vorherigen, stabilen Prozeß fertigen. Anders als beim C64, der war noch in NMOS entwickelt worden, sodaß man die Umstellung auf HMOS verschieben konnte- bis auf die PLA, die wurde ursprünglich teuer zugekauft, und die Eigenbau-HMOS-PLA sind genauso notorische 'Gammler' wie die 264er-Chips. Erst ein Jahr später, beim C128, hatte man das Problem gelöst.

    • New
    Quote from cbm-warrior

    Nur mal rein aus Neugierde: ist es ein 7360 oder 8360? Wobei 7360 ja extrem selten anzutreffen sind, Und ist es einer aus der Originalbestückung von 1984 oder mit anderen Datumscode?

    Drauf steht das mos logo und 8360R2 und 5084

    Er ist aus meinem c16, den ich Anfang '86 bei ALDI erstanden habe.


    Was bedeutet 5084 ist das das Datum?