Posts by Mac Bacon

    Falls dies überhaupt möglich ist so bekomme ich beim Starten von Anwendungen im c128 Modus nur einen Bildschirm voller Zeichen (Bild3).

    Welche Anwendungen sind das und wie startest Du die?

    Du weißt, dass der 128er einen zweiten Videochip (VDC) mit separatem Ausgang hat und die meisten 128er-Anwendungen nur mit diesem sinnvoll benutzbar sind? Dein Screenshot deutet zwar auf andere Probleme hin, aber die Sache mit den zwei Videoausgängen wird von "neuen" 128er-Besitzern erschreckend oft ignoriert. ;)

    Im C64 Modus lassen sich Spiele starten weisen aber auch Fehlfarben auf.

    Die beste Bildqualität erhält man, wenn man Luma und Chroma separat zum Monitor führt. An der Videobuchse des C64/128 liegt neben Luma und Chroma aber auch noch ein kombiniertes Signal an. Nimmt man dieses statt Chroma, entstehen Farbfehler wie oben.

    Miss das Kabel durch, oder - falls das Kabel noch einen weiteren, derzeit unbenutzten Cinch-Stecker hat - probier diesen als Chroma. Verlass Dich nicht auf die Steckerfarben, sowas wie "gelber Stecker in gelbe Buchse, roter Stecker in rote Buchse" funktioniert hier nicht.


    Mach bitte auch ein Foto von dem Kabel und/oder Signalkonverter, mit dem der TFT angeschlossen ist.

    Wäre es denkbar, dass die Seriennummern mehr oder weniger per Zufallsgenerator ermittelt wurden und es bei Commodore dann einfach entsprechende Listen gab, in denen man bei Bedarf nachsehen konnte?

    Nein, da könnten ja Dubletten entstehen. Irgendein System haben Seriennummern immer. Es kann natürlich sein, dass unterschiedliche Produktionsstandorte unterschiedliche Systeme benutzen, das kommt dem Sammler dann natürlich komplett chaotisch vor.

    VIC ist defekt.

    Wie sollte der VIC ein Problem beim Adressieren des Char-ROMs haben, wenn er keines beim Adressieren des Screen-RAMs hat?

    Ok, es sollen schon Pferde vor Apotheken gekotzt haben, aber dass der VIC hier der Übeltäter ist, scheint mir äußerst unwahrscheinlich.


    EDIT:

    Adressleitung A3 kommt nicht korrekt zum Char-ROM.

    Der entsprechende Pin am Char-ROM sieht auch extrem mitgenommen aus. Der ist wohl schon abgebrochen und wurde notdürftig geflickt?

    Das Diagramm in Post #2 ist ziemlich irreführend. Hier mal ein korrektes (und verständliches) Diagramm für die Pixelverteilung in Mode 0:

    Das ist doch nur vertikal gespiegelt. Post #2 beschreibt das Mapping von Pixeln zum Byte, Du beschreibst das Mapping vom Byte zu Pixeln.

    Und verständlich ist keins der beiden Diagramme, denn bei beiden fehlt die Beschriftung. :P

    Siehe hier.

    (Schriftliches über die Farbspeicherungsinterna)

    Kann einer der Hardwaremenschen erklären, warum die Bits so durcheinander gewürfelt sind? Ich hab versucht, da eine Kostenersparnis bzw. Verringerung der Hardwarekomplexität hinein zu interpretieren, aber mir fällt rein gar nichts ein.

    Wenn ich ganz naiv davon ausgehe, dass das aus dem RAM gelesene Byte in ein Schieberegister kopiert und der Inhalt dann im Pixeltakt weitergeschoben wird, könnte man im 1/2/4-bpp-Modus jeweils mit den oberen 1/2/4 Bits des Registers die Palettenregister adressieren und fertig ist die Laube. In der Permutation der Bits kann ich keinen Sinn entdecken.

    Die Farbspeicherung aus dem Diagramm in Post #2 verstehe ich noch nicht so recht, gibt's da auch was Schriftliches zum Nachlesen?

    Siehe hier. In den Mehrfarbmodi werden die Informationen für ein bestimmtes Pixel nicht in "nebeneinanderliegenden" Bits gespeichert, sondern sind über das ganze Byte verteilt, und im 4bpp-Modus ist nicht mal die Reihenfolge der Bit-Wertigkeiten einheitlich.

    Ich würde da einfach eine 256 Byte große Konvertierungstabelle benutzen...

    Nein, eher nicht.

    Der Meinung bin und bleibe ich sehr wohl.

    Mein Beitrag bezog sich auf das, was ich zitiert hatte (und was Du in Deiner Antwort weggelassen hast): Nämlich dass man von "viele geschachtelte Klammern" auf "man muss häufiger zwischenspeichern" rückschließen könne - und das stimmt nun mal nicht.

    Welche Art der Auswertung Du in Deinem Programm bevorzugst und ob das irgendwie kürzer oder schneller oder lesbarer geht, ist dafür völlig unerheblich.

    Allein die vielen geschachtelten Klammerpaare lassen erahnen, dass man häufiger zwischenspeichern muss.

    Nein, eher nicht. Ein Ausdruck wie A + (B * (C + (D * (E + (F * (G + (H * I))))))) mag kompliziert aussehen, lässt sich aber - wenn man von innen nach außen rechnet - auf Assembler-Ebene ganz leicht sequenziell verarbeiten.


    Deine Beispiele im Vergleich:

    (WO AND WU) OR (WR AND WL) OR (WL AND WO AND RU) OR (WO AND WR AND LU) OR (WR AND WU AND LO) OR (WU AND WL AND RO)

    Hier berechnet man die ersten fünf Klammerausdrücke und speichert die fünf Ergebnisse ab. Dann berechnet man den sechsten Klammerausdruck und fährt direkt fort, indem man die fünf zuvor gespeicherten Ergebnisse aufODERt.


    Jetzt die optimierte Variante (der aktuelle Rechen- und Speicherschritt ist unterstrichen):

    (WU AND WL AND RO) OR (WO AND ((WR AND LU) OR WU OR (WL AND RU))) OR (WR AND (WL OR (WU AND LO)))

    Schritt 1:

    (WU AND WL AND RO) OR (WO AND ((WR AND LU) OR WU OR (WL AND RU))) OR (WR AND (WL OR (WU AND LO)))


    Schritt 2:


    (WU AND WL AND RO) OR (WO AND (TEMP1 OR WU OR (WL AND RU))) OR (WR AND (WL OR (WU AND LO)))


    Schritt 3:


    TEMP2 OR (WO AND (TEMP1 OR WU OR (WL AND RU))) OR (WR AND (WL OR (WU AND LO)))


    Nach dem Speichern von nur drei Zwischenergebnissen liegt die Formel dann bereits in dieser Form vor:

    TEMP2 OR TEMP3 OR (WR AND (WL OR (WU AND LO)))

    Die kann man jetzt von innen nach außen in einem Rutsch ausrechnen.

    Kann man hier erkennen was kaputt ist, und wie man es behebt?

    Der Bildschirminhalt wiederholt sich nach 64 Zeichen -> A6 kommt nicht richtig vom VIC zum RAM.

    Der Bildschirminhalt wiederholt sich nach 128 Zeichen -> A7 kommt nicht richtig vom VIC zum RAM.

    Die zweite der vier Kopien scheint "richtig" positioniert zu sein, d.h. A6 ist immer high und A7 immer low.


    Es werden falsche Zeichen angezeigt, z.B. "KIK(N*" statt "SIC V2" -> entweder liest der VIC falsche Screencodes aus dem RAM (dann wäre Datenbit D3 immer high und D4 immer low) oder er adressiert das Char-ROM falsch (dann wäre Adressbit A6 immer high und A7 immer low). Ich tippe auf die zweite Möglichkeit, da sie gleich beide Probleme erklärt.


    Da RAM und Char-ROM unterschiedlich angesprochen werden (gemultiplexte Adressen etc.), würde ich das Problem eher auf VIC-Seite suchen, also beim Chip selbst, dem Sockel, Leiterbahnen, usw.


    Aber ich frage mich gerade, wie der RAM-Inhalt stabil bleiben kann, wenn der VIC auf A6 und A7 immer nur konstante Pegel sendet. Das reicht doch nicht für den Refresh? Vielleicht erzeugen die CPU-Zugriffe genügend "Abwechslung"?