c16 zu dunkle Farbe 0 (Hintergrund)

Kann ich vielleicht heute Abend mal an meinen Geräten testen. Hast du mal im Emulator (yape, vice) getestet?

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.

Jo, da ist wohl was im Argen. Auf meinem Plus/4 geht das ohne Probleme.

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.

Wenn noch ein anderer Rechner der 264er Familie vorhanden ist, setz mal den TED in einen anderen Rechner und beobachte, ob das Problem dann mit umzieht.

Schade drum! Ich würde ihn aber auf jeden Fall aufheben, er funktioniert ja noch zu einem großen Teil. Kann man dann zum Testen von anderen Boards verwenden.

Sehe ich das richtig, dass es noch keinen fertigen DropInErsatz für den TED gibt?

Quote from HypnoToad

Sehe ich das richtig, dass es noch keinen fertigen DropInErsatz für den TED gibt?

Nein, es gibt den ThED, der ist aber noch nicht released.

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.

Das ist die Produktionswoche. KW50 in 1984