letzter Beitrag von sauhund am
Fehler im C64-Wiki?
- domspitze
- Erledigt
-
-
Da hast Du Recht. Hatte der Autor bestimmt aus dem Großen Grafikbuch von Data Becker abgeschrieben
Danke, ist korrigiert.
-
An sich war das aber vorher schon richtig so, sofern man der üblichen Konvention folgend das niederwertigste Bit als Bit #0 benummert. Da Bits 3-1 die Zeichensatzauswahl tätigen ist da durch die Bitwertigkeit schon eine Mutiplikation mit 2 gegeben
-
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
-
Vielleicht sollte man einfach "in soundsoviel KByte-Schritten" als Erklärung reinscheiben, aber ich mach das nicht, ich hab Angst vor den Grammarians
-
Kann das jemand mit Wiki-Zugang ändern.
Da kann übrigens *jeder* etwas reinschreiben/korrigieren. Man muss nicht mal angemeldet sein...
-
ich finde es für Leute, die mal kurz nachschlagen nicht sinnvoll.
Also da ein, zwei Zeilen darunter die Bedeutung von Bit 0 erklärt wird, sollte das eigentlich auch beim "kurz nachschlagen" deutlich genug sein. Ich hab auch noch nirgends eine andere Nummerierung als 7654|3210 gesehen. -
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.
-
Ist doch allet tuti
Wie gesagt, Vorsicht mit diesem Buch
-
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. -
Ach, ich sollte einfach öfters in den Programmers Reference Guide reinschauen. Der ist zwar auf Englisch, aber es ist so einfach beschrieben.
-
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:
--> nix passiert, Änderung von 22 auf 23 ist genauso Banane -
Es wird sich immer elend trocken anfühlen.
ich kenn da eine loesung ...Bourbon whiskey
ne mal im ernst probiers mal in assembler - da wirds eigentlich schnell klar. -
EDIT:
*lol* vergesst es, grad festgestellt, dass ich das auch völlig anders sehe
Bei Charset muss man natürlich *$0800 rechnen. Bei Screen *$0400.EDIT2:
jedenfalls rechne ich immer so, wie hier in der Tabelle:
http://codebase64.org/doku.php…ganizing#character_memory
D.h. nur die signifikanten Bits. Sprich bei Charset nehme ich Bit 321 als ein Wert, bei Screen das Highbyte als einen Wert. -
-
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.
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 aushelfenCode- $D018-table by mactron
- VIC bank-configuration by $D018:
- screen char bitmap
- $0x = screen @ $0000 $x0-$x1 = char @ $0000 $x0-$x7 = bitmap @ $0000
- $1x = screen @ $0400
- $2x = screen @ $0800 $x2-$x3 = char @ $0800
- $3x = screen @ $0C00
- $4x = screen @ $1000 $x4-$x5 = char @ $1000
- $5x = screen @ $1400
- $6x = screen @ $1800 $x6-$x7 = char @ $1800
- $7x = screen @ $1C00
- $8x = screen @ $2000 $x8-$x9 = char @ $2000 $x8-$xF = bitmap @ $2000
- $9x = screen @ $2400
- $ax = screen @ $2800 $xa-$xb = char @ $2800
- $bx = screen @ $2C00
- $cx = screen @ $3000 $xc-$xd = char @ $3000
- $dx = screen @ $3400
- $ex = screen @ $3800 $xe-$xf = char @ $3800
- $fx = screen @ $3C00
- Example:
- ldy #$1e ; screen at $0400 / char at 3800 on Bank 0 ( #$15 = default after power on)
- sty $d018
-
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
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