Hallo Besucher, der Thread wurde 4k mal aufgerufen und enthält 25 Antworten

letzter Beitrag von sauhund am

Fehler im C64-Wiki?

  • Hatte der Autor bestimmt aus dem Großen Grafikbuch von Data Becker abgeschrieben


    Ne, da steht es nämlich richtig drin ;)


    @Cold Sewers: Das mag richtig sein, was sein 64* beim Bildschirmspeicher erklärt. Aber ich finde das ziemlich verwirrend. Sollte zumindestens erläutert werden. Von mir aus kanns geändert werden, ich finde es für Leute, die mal kurz nachschlagen nicht sinnvoll.

  • hehehe, wo colt recht hat, hat er recht, aber schön, dass wir drüber gesprochen haben. *rollback*


    wenn es beim Grafikbuch so steht, ist es falsch.


    Das Buch hatte ich mal mit Evil.Joe auf dem Schoß vor 5 Jahren oder so bei meinen ersten ASM Versuchen und wir haben es so, wie dort die Bits gezählt werden, genau nicht hingekriegt, $D018 richtig zu schalten :D

  • Ich weiß, wie man Bits nummeriert. Es ist einfach eine Sache des Herangehens.
    Wenn ich weiß, dass ich nur 3 von 8 Bits zu berücksichtigen habe, dann tue ich so, als ob es halt die ersten Bits sind. Dann haut es aber nicht mit dem im Wiki angegeben Faktor hin.
    Die andere Möglichkeit ist, wie wohl hier bevorzugt, die davorliegenden Bits auf 1 zu setzen. Dann ist natürlich der Faktor im Wiki richtig.


    Genau aus dem Grund wollte ich nicht einfach was im Wiki ändern, sondern das lieber im Forum abklären lassen.

  • Nee, das versteht doch kein Normalmensch. Da steht zwar 'was von einer Multiplikation (*) dahinter -"1024*Bit 'irgendwas' "- aber da weiß doch keiner, was das Bit dahinter bedeuten soll bzw. gar welchen Wert es hat oder mind. haben sollte (2), um auf den da gerade richtigen/kompatiblen Wert zu kommen. Ein Bit hat wortwörtlich doch eh nur Wert 0 oder 1, und dann steht da 'was von 0 bis 3 aufeinmal.. ;).
    Ich hab's allg. auch noch nie mit diesen abstrakten und scheinbar wortwörtlich genommen auch noch falschen/unlogischen Bit-Darstellungen in einigen Lehrbüchern gehabt. Ich und viele andere brauchen da eher direkt die genauen Adressen und Register + am besten Dezimalwerte(oder meinetwegen Hexadezimal) damit das, ohne beim Lesen parallel oder vorher noch drei Rechnungen anstellen und die Denkweise vorher noch auf 'unlogisch' stellen zu müssen, fluppt ;).


    Naja ok, wenn dann da stehen würde: "1024*Bit Nr. 0..8 bzw. 0..3 gesetzt in einem Byte(8 Bit)-"Strang", wäre es doch auch vom Lesen her für mich wieder logisch aber dann sieht's ja noch länger aus ;).
    --
    Also lange Rede kurzer Sinn: Es gibt 'so ne' und 'so ne' Leute. Ich z.B. brauche es einfach praktikabler -das ist das Wort- und vermeintlich natürlicher (also nicht so computerbrainish immer) damit das mit meiner Art harmoniert, alles andere ist zu trocken für mich. Und auch wenn man es verstehen kann, sympatisch werden diese Bit-Schreibweisen auf mich niemals/in keiner Millisekunde wirken. Es wird sich immer elend trocken anfühlen.

  • Ich werde demnächst einfach mal eine Tabelle reinstellen (wenn ich die denn mal finde).


    Man kann das aber irgendwann auch leicht auswendig lernen, high nibble für Screen in $0400/1024er Schritten low nibble für Charset in $0800 bzw. $0400er "Doppelschritten"


    Einfach mal mal folgendes in BASIC eingeben, dann sollte es klar sein:

    Code
    1. POKE53272,20


    --> nix passiert, Änderung von 22 auf 23 ist genauso Banane :)

  • bit1-3 * 0x800 oder bit 0-3*0x400 waere richtig.
    Aber letzteres ist echt mal ne recht doofe Darstellung meiner Meinung nach :)


    Das hier sollte auch gehen :)

    Code
    1. lda #(3-bitmap/$4000)
    2. sta $dd00
    3. lda #((colmap-bitmap/$4000*$4000)/$4000)/$400)*16+8
    4. sta $d018
  • Ich und viele andere brauchen da eher direkt die genauen Adressen und Register + am besten Dezimalwerte(oder meinetwegen Hexadezimal) damit das, ohne beim Lesen parallel oder vorher noch drei Rechnungen anstellen und die Denkweise vorher noch auf 'unlogisch' stellen zu müssen, fluppt .


    überhaupt sollte man derartiges immer in einer art dokumentieren das es jene welche sowieso nie eine zeile programmieren selbiges besser verstehen. unter programmierern allgemein bekannte und angewandte konventionen sind da wirklich nur noch fehl am platze.

    Code
    1. lda #(3-bitmap/$4000)


    schönes beispiel dafür dass man wirklich immer klammern sollte - versuch das mal im TASS (der rechnet stumpf von links nach rechts...) :)

  • Ich werde demnächst einfach mal eine Tabelle reinstellen (wenn ich die denn mal finde).


    Etwa die Tabelle die ich Dir damals zukommen ließ ? Damit kann ich notfalls aushelfen ;)


  • an der stelle btw mal ein tip.... wer das mit den bits verstanden hat sollte sich die tabelle mal derartig erweitern das ALLE bitkombinationen da stehen ... und dann mal überlegen was man daraus ableiten, bzw mit code wie

    Code
    1. lda #<wert>
    2. sta $dd00
    3. sta $d018


    anstellen kann, und warum genau das geht....

  • ja mactron, genau DIE Tabelle meinte ich, da habe ich jahrelang draufgestarrt, bis ich sie nicht mehr brauchte :)


    Noch ne Bankswitching-Tabelle (bits ------xx von $dd00) dazu, bisschen Info zu $d011 und $d016 und man hat eigentlich imho alles, was man für Darstellen der meisten Grafikmodi braucht