Hello, Guest the thread was called1.5k times and contains 77 replays

last post from Mac Bacon at the

C128 mit Grafikmüll

  • Das Color RAM hat also keinen zufälligen Inhalt, sondern von Haus aus $FF ... weil jetzt - ohne /WE - wird es sicher nicht mehr beschrieben.

    Ich meine mich zu erinnern, dass wir hier im Forum tatsächlich schon einmal einen Fall hatten, wo ein funktionierendes SRAM als Einschaltzustand keinen zufälligen Inhalt, sondern ein reguläres Muster hatte. Ob das $0 oder $f war oder byteweise wechselte, weiß ich nicht mehr.

    In diesem Fall wurden aber vier Chips getestet - sind die etwa alle vom gleichen Hersteller/Typ?


    Wenn alle vier Chips tatsächlich $f als Einschaltzustand haben, ist jetzt natürlich wieder die Hypothese "/WE geht niemals low" möglich...

  • Im C64-Modus scheinen ja die Farben (lt. Fotos) zu stimmen.

    Nein, auch dort passen sie offenbar nicht:

    Beim Start des C64 ist die Schriftfarbe cyan statt hellblau, beim 128er ist es mittelgrau statt grün.

    die Schriftfarbe kann im 128er sowie 64er Modus nicht verändert werden

  • So, mal schnell mein 128-Testboard angeschlossen. Ich habe bunte @ beim Einschalten, WZEW. Weil ich zu faul war, den nicht gesockelten 74LS74 auszulöten habe ich ihm mal schnell Pin 9 durchgekniffen. Ergebnis: Normale Funktion, nur bunte Zeichen, ebenfalls WZEW.

    Wahnsinn, dass Du Dir die Mühe für weiteren Erkenntnisgewinn hier gemacht hast. Vielen Dank.



    Hast du mit dem Durchgangsprüfer eine Verbindung vom PLA (U11) Pin 45 auf das Color-RAM, Pin 18 und 20?

    Sind überhaupt Pin 18 und 20 des Color-RAMs verbunden?


    Durchgang geprüft und okay für alle genannten Verbindungen.

  • Wahnsinn, dass Du Dir die Mühe für weiteren Erkenntnisgewinn hier gemacht hast. Vielen Dank.

    Kein Thema, für irgendwas habe ich meine Testboards ja. :-D

    Was haben denn die @ beim EInschalten für eine Farbe?

    Könntest du das noch bitte herausfinden?

  • Ich habe noch einen Test gemacht mit der Wizard Of Wor Cartridge.

    Man sieht dort sehr schön, dass das hellgrau statt der bunten Farben angezeigt wird.

    Allerdings wie es scheint nicht immer, zumindest sind die Wände der Level blau.

    Ich hab allerdings auch noch nicht geprüft, wie diese generiert werden.

    Angehängt habe ich noch Screenshots aus dem Emulator zum Vergleich.



    Und hier der Emu zum Vergleich:


  • Nein, sorry, ich meinte was anderes:


    Beim Einschalten des C128 kommt sofort ein Bild (schneller als z. B. beim C64) . Der Schirm ist normalerweise mit "@" gefüllt, diese haben - da das Color-RAM noch nicht initialisiert wurde - alle möglichen Farben. Wie ist das bei dir?

  • Hmmm ... alles grau ...


    Bringt uns nicht wirkich weiter. Zwei Möglichkeiten:

    • Das Auslesen des ColorRAMs ist generell nicht möglich.
    • Das Color-RAM ist beim Power-Up mit $FF gefüllt und lässt sich nicht beschreiben.

    Die wahrscheinlichere Variante ist die erste.


    Hast du ein Oszi?

  • Zwei Möglichkeiten:

    Das Auslesen des ColorRAMs ist generell nicht möglich.
    Das Color-RAM ist beim Power-Up mit $FF gefüllt und lässt sich nicht beschreiben.

    Die wahrscheinlichere Variante ist die erste.

    Ich bin inzwischen auf die zweite Variante umgeschwenkt. Post #61 habt Ihr gesehen?

    Ein ähnlicher Fall lag hier vor.

    Interessant wäre auch noch dieser Test, vielleicht ist die zweite Hälfte ja mit $0 gefüllt.

  • Mac Bacon


    Es muss aber noch was anderes kaputt sein:

    Dieses Verhalten ist definitiv nicht normal. Hast du irgendeinen Schimmer, was das auslösen könnte? Ich denke da z. B. an einen anderen Baustein, der zeitgleich mit dem Color-RAM selektiert wird.

  • Dieses Verhalten ist definitiv nicht normal. Hast du irgendeinen Schimmer, was das auslösen könnte? Ich denke da z. B. an einen anderen Baustein, der zeitgleich mit dem Color-RAM selektiert wird.

    Nein, keine Ahnung. Insbesondere das "eine Zeile höher" ist sehr seltsam, denn ein Versatz von 40 lässt sich kaum mit einfachen Bitfehlern o.ä. erklären.

    Das Cursorblinken wird erreicht, indem beim Screencode Bit 7 invertiert wird, und im Color-RAM temporär die Farbe ersetzt wird. Falls /WE für das Color-RAM nicht korrekt erzeugt wird, würden schlimmstenfalls (kommt auf /OE an) sowohl SRAM als auch CPU den Datenbus treiben - ich wüsste aber auch nicht, wie das diese Symptome auslösen könnte.

    Falls beide Gatterchips, die zur Erzeugung von /WE nötig sind, bereits getauscht wurden, kommt man da wohl nur mit einem Oszi weiter - oder man testet die fraglichen Chips (SRAM, VIC, 4066, 2 x LSdingsbums) in einem anderen Rechner.

  • Tritt das nur beim READY. nach der Einschaltmeldung auf? Fahr doch mal ein paar Zellen runter mit dem Cursor! Was passiert dann?


    @MacBacon

    An welchen ZP-Adresse steht die aktuelle Cursorposition? Wird als Zeile/Spalte gespeichert, nehme ich an?

    Das Cursorblinken wird erreicht, indem beim Screencode Bit 7 invertiert wird, und im Color-RAM temporär die Farbe ersetzt wird

    Wenn das zufällig so übereinstimmt, dass ZP-Adresse = Adresse des Zeichens im Color-RAM, das geändert werden soll würde es den Zusammenhang mit dem Cursorblinken eventuell erklären.

  • An welchen ZP-Adresse steht die aktuelle Cursorposition? Wird als Zeile/Spalte gespeichert, nehme ich an?

    $e0/e1 zeigt auf den Anfang der Zeile im Screen, $e2/e3 zeigt auf den Anfang der Zeile im Color-RAM, $ec enthält den Offset (letzterer wird in Y geladen und der Zugriff dann via lda/sta (Zeiger),y gemacht).

    Wenn das zufällig so übereinstimmt, dass ZP-Adresse = Adresse des Zeichens im Color-RAM, das geändert werden soll würde es den Zusammenhang mit dem Cursorblinken eventuell erklären.

    Das erklärt aber kein "schnelles Blinken" - solange der Cursor sich nicht ändert, finden da keine Schreibzugriffe statt.

    Das Ergebnis:

    Danke, die andere Hälfte steht also auch komplett auf $f.

  • $e0/e1 zeigt auf den Anfang der Zeile im Screen, $e2/e3 zeigt auf den Anfang der Zeile im Color-RAM, $ec enthält den Offset (letzterer wird in Y geladen und der Zugriff dann via lda/sta (Zeiger),y gemacht).

    $F1 "unechte Bildschirmzeile" macht was? [EDIT] (Beim C64) [/EDIT]

    Das "R" vom "READY." der Einschaltmeldung steht auf Position 241 im Screen-RAM.

  • $F1 [...] macht was?

    Das "R" vom "READY." der Einschaltmeldung steht auf Position 241 im Screen-RAM.

    Nullbasiert ist es Offset 240. Bei $f0 wird das zuletzt über den Bildschirmtreiber ausgegebene Zeichen gepuffert, das wird für ESC-Sequenzen gebraucht und hat mit dem Cursorblinken nichts zu tun.