şu kadarını söyliim, anlamaya başladın ve artık doğru yola girdin diyebilirim.

iki mesajına sırayla cevap.
1) for i = 0 to 9 yerine 0 to 6 kullanman lazım. toplam 7 data var ve bu 1 to 7 ya da 0 to 6 ile ifade edilir. sonrasında "out of data error" alırsın. bu hata mesajını grafik ekranındayken göremezsin ama mesaj her halikarda çıkar ve grafiğin bir bölümünün renklerini bozar. bu nedenle öncelikle kaç adet veri varsa o kadarlık bir döngü yapman gerektiği kuralını unutma.
multicolor modeda olduğun için A harfi olması gerektiği gibi çıkmıyor. poke 53270,184 yerine poke 53270,200 yazmayı dener ya da bilgisayar zaten tek renk modunda başladığı için 20 numaralı satırı tamamen silersen (20 yazıp enter'a basman yeterli), A harfi düzgün gözükecektir. İstersen multicolor'a uygun bir A çizmeyi de deneyebilirsin.
2) Kafanın karışması normal. Çünkü bir arkaplan ve 3 karakter rengi var. Ne neyi ifade ediyor ilk bakışta anlamak güç.
Öncelikle arkaplan tüm karakterlerde ortak ve $d021 (53281) adresi ile kontrol ediliyor. poke 53281,x (x: 0-15 arası bir sayı) şeklinde arkaplan rengini değiştirebilirsin. tek renk modunda arkaplan rengi tamamen video memory yani bu koddaki "poke 1024..." bölümünden alınmaktadır. Ancak çok renkli modda 53281 adresi tüm ekran için ortak renk belirler.
Peki diğer 3 renkten ne haber? Öncelikle şunu düşünmemiz lazım. 1 byte'ın kapasitesi nedir ve commodore'da kaç renk vardır? 1 byte 0-255 arası 256 değer alabilir (2^8) ve Commdore 16 renktir (2^4). Bu durumda 1 byte kaç farklı değer tutabilir? Cevap: 2. 16*16 = 256 ya da diğer bir deyişle 2^4*2^4=2^8 olduğu için 1 byte 0-15 arası değerlerden tam olarak iki tane barındırabilir ve kapasitesi tam olarak dolar.
Bu açıklamadan sonra nibble kavramına geçmek istiyorum. 1 byte kaç bittir? 8. Peki nibble dediğimiz şey nedir? 1 byte'ın yarı kapasitesi, yani 4 bit. Tam olarak da c64 renklerinin ihtiyacı olan boyut.
Byte'ımız şu olsun
%11011001
Bu byte'ı tam ortadan ikiye ayıralım.
%1101 %1001
Bu iki parça byte'ın nibblelarıdır. Yani üst 4 bit ve alt 4 bit. Her ikisi birer rengi ifade edebilir. İşte video memory'deki bu iki parça birer renk ifade eder.
Bildiğin gibi 16'lı sayı sistemi, yani hexadecimal sayı sistemi 0-F aralığında bir basamak için 16 farklı değere sahip olur, sonrası için 2., 3. v.s. basamaklar devreye girer. 16'lı sayı sisteminin tek basamağı tam olarak bir nibble'a tekabül eder.
Örneğin biz 1024'deki video memory'e onlu sayı sistemine göre 103 yazdık. Bu hangi iki renge denk gelir ilk bakışta görmek zor. Çevirim yapmak lazım. Yani;
103 / 16 = 6 (kalan 7)
Bu bölme işleminin sonucu üst nibble'ın değerini verir. Yani 6 (mavi) rengine denk gelir. Alt nibble ise bölümden kalan sonuçtur. Ya da diğer bir hesap yöntemiyle bölümün tam sayı sonucunu bulduktan sonra;
103 - (16 * 6) = 103 - 96 = 7
şeklinde bulunabilir. Bu da alt nibble, yani 7 (sarı) rengi olduğunu gösterir. Demek ki biz 103 yazdığımızda 3 renkten 2'si mavi ve sarı oluyormuş. Peki bunu sayıya baktığımız gibi daha kolay görmemizin bir yolu yok mu? Elbette ki var, hexadecimal sistem.
103 = $67
Hex düzende 67'ye eşit. Her bir basamak tek başına bir rengi ifade ediyor bak, 6 ve 7.
Başka bir örnek.
194 = $c2
C ve 2. C'nin 10'lu sayı sisteminde karşılığı 12'dir. Bu durumda 12 ve 2, yani gri ve kırmızı.
Bu açıklamalarım geriye bir soru işareti bırakıyor. Bu 3. renk nerde? İşte renk belleği (color memory) denilen ve $d800 (55296) adresinde yer alan bu alan 3. renk için. Peki her byte'a iki renk sığıyordu, renk belleğinde bu iş nasıl oluyor. Çok basit, alt 4 bit (sağdaki 4 bit) 3. rengi ifade ediyor, soldaki 4 bit ise bir işe yaramıyor, çöp. Bu durumda renk belleğine olduğu gibi renk kodunu yazmak yeterli. Yani yeşil renk istiyorsak doğrudan 5 yazabiliriz.
%AAAABBBB = $AB
A = Kullanım dışı
B = Renk değeri
Bu durumda 5 rengini vermek için 5'in 16'nın herhangi bir katıyla toplam değerini de versek sonuç değişmez. Kısacası.
$05,$15,$25,$35,$45...
Decimal (10'lu) sayı sistemindeki karşılıkları
5,21,37,53,69 v.s. olan tüm byte değerleri alt nibbleları 5'e eşit olduğu için 3. rengi yeşil yapacaklardır.
Ve bunların hepsi Plazma'da yazıyor, bu nedenle sana çok kızıyorum.

döngünün 8191'e kadar olmasında haklısın, 7999'a kadar olması yeterli. ben kafamdan $2000'lik bloğu dolduracak şekilde yazmışım o loop'u, çünkü son 192 byte'ın bitmap ekran ya da video/color ramler açısından bir espirisi yok, birşey yazsan da sorun çıkmaz. Amacımız sadece bitmap alanı doldurmaksa 0 to 7999 doğrusu olacaktır.
Son olarak peki hangi renk hangi adresten set ediliyor dersen;
00 = arkaplan rengi $d021 (53281) tüm ekran için ortak renk, tek adres
01 = 1. renk $0400-$07e7 (1024-2047) üst nibble (sol 4 bit) %XXXX----
10 = 2. renk $0400-$07e7 (1024-2047) alt nibble (sağ 4 bit) %----XXXX
11 = 3. renk $d800-$dbe7 (55296-56295) alt nibble (sağ 4 bit) %----XXXX
En sol üstteki karakterin renklerini tek tek ayrı satırlarda set eden program örneği:
0 c0 = 0: c1 = 10: c2 = 7: c3 = 14
1 poke 53281,c0
2 poke 1024,(peek(1024) and 15) or (c1*16)
3 poke 1024,(peek(1024) and 240) or c2
4 poke 55296,c3
Buradaki peek ve or'ların sebebi bir rengi set ederken aynı bytedaki diğerini bozmamaktır. Gerçi her iki rengi de değiştireceksek kolayca iki satırı şu şekilde birleştirebiliriz.
0 c0 = 0: c1 = 10: c2 = 7: c3 = 14
1 poke 53281,c0
2 poke 1024,c1*16+c2
4 poke 55296,c3
Çok fazla kavram bir arada geçmiş olduğu için tek seferde tüm anlattıklarımı anlamayabilirsin, normaldir. Daha önce ne kadar programcılık tecrüben olursa olsun Commodore 64'de birşeyler yapmaya gelince en çok kendini geliştirmen gereken taraflar bit tabanlı işlemler, binary ve hexadecimal sayı sistemleri (2'li, 16'lı) ve benzeri konulardır. Commodore'ûn kısıtlı hafızası "ya ne uğraştırıyorsun bit işlemleriyle, 3 renk için 3 tane memory alanı kullansan, hiç bizi uğraştırmasan olmaz mıydı?" demeye müsade etmediğinden bunları öğrenmek kritik bir hal alıyor. Ama şu faydası da var. Yarın öbürgün PC'de bir network paketi ya da multimedia dosya formatlarının headerlarını parse etmen gerekirse "bu ne lan böyle, ohaa çok zormuş" demez "aaa, tam benlik" dersin.

bkz:
http://tools.ietf.org/html/rfc6184 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Herşey byte byte tutulmaz.
