Z80 Makine diline meraklı olan?

[Skate]

Bir tek alışmakta zorlandığım şey şu oldu.

Normalde 6502'den alışık olduğun hex kullanımı şu;
$ffff

CPC'de zar zor alıştığım hex formatı;
&ffff

Şimdi bu toolchain'de sjasmplus diye bir compiler kullanınca başıma açılan bela;
#ffff

Sharp nedir ya? CSS'de RGB color code kullanır gibi hissediyorum sürekli kendimi.

[hades]

Ben context+pasmo+specemu kullanıyorum. Context'te z80.chl dosyasını düzenledim. Z80 komutları, registerleri, flag ve conditions, pasmo komutları farklı renklerde gösteriliyor.

Geçenlerde Z80 komutları üç harfli olsa nasıl olur diye düşündüm. Mesela Ld yerine mov olacak. Halt - hlt gibi.

[Ref]

Şimdi bu toolchain'de sjasmplus diye bir compiler kullanınca başıma açılan bela;
#ffff

sjasmplus rusların sevdiği assembler. O yüzden biraz antin kuntin işler ve sanırım default olarak pentagona derliyor, switchleri spectruma ayarlamayı unutma. Pasmo her yola gelir. ister öyle kullan ister öbürü. Söylentiye göre sjasmplus pasmodan iyiymiş. Ama şu anda pasmo-sjasmplus dışında dişe dokunur ZX assembleri yok. Çok iyi z80 derleyiciler var ama bu ikisi zx spectrum dosya tipleri yaratabiliyorlar, basic headerleri falan ekleyebiliyorlar gerekirse basic bile yazabiliyorsun falan. Bunlardan hariç 7-8 tane daha derleyici var, ama isimleri bile aklımda değil, biri design design'in yazdığı o aklımda kalmış.

[Skate]

şu konuda fikri olan var mıdır?

[SAVESNA] RAM <0x4000-0x4001> will be overwritten due to 48k snapshot imperfect format.

Gerçekten de kod çalıştıktan sonra 4000/4001'i bozabiliyor. Böyle bilinen bir bug mı var snapshot formatında?

Çok da etkilemiyor, sonuçta normal binary'i yükletince düzgün çalışıyor. Sadece snapshot üzerinden çalışan sistemde bu sorun çıkıyor. Default'da NEX diye bir alternatif ile gelmişti, ben SNA'yı tercih ettim. Tekrar NEX'e mi geçsem acaba? O da şu Spectrum Next projesinin bir standardı mıdır nedir tam anlamadım gerçi.

Edit: Burada açıklanmış.
https://bitbandit.org/20161101/hacking-the-sjasmplus-z80-assembler/

[Skate]

Sonunda TAP üretmeyi de öğrendim. Biraz daha ilerleyeyim, SJAsmPlus'ı merak edenler varsa tecrübelerimi paylaşacağım.

[Ref]

şu konuda fikri olan var mıdır?

[SAVESNA] RAM <0x4000-0x4001> will be overwritten due to 48k snapshot imperfect format.

Gerçekten de kod çalıştıktan sonra 4000/4001'i bozabiliyor. Böyle bilinen bir bug mı var snapshot formatında?

evet yanlış hatırlamıyorsam SNA formatı 80'lerin kartuşlarının ürettiği bir format olduğu için biraz sorunlu. sen freeze ettiğinde son kalınan PC'yi stack'e push ediyor. Dolayısı ile SP nerdeyse oraya 2 byte'lık Program Counter bilgisi yazılıyor. herşeyi yükledikten sonra RET işletiliyor ve program kaldığı yerden devam ediyor.
Bu işlem, eğer o bölgede bir data varsa orayı bozuyor elbette. Çoğunlukla zararsız bir işlem ama zamanında bu problemi kırılmayan oyunlar yapmak için kullanan oyunlar da var. O tür oyunları çift kasetli teyple kopyalıyorlardı

[Skate]

Bunu demin yanlış başlığa göndermişim, silip tekrar buraya gönderdim, bilginize.

Şöyle bir durumla karşılaştım. Zannedersem programcıdan ziyade psikolog yardımı lazım bana. SjASMPlus kendini Assembler yerine Compiler sanmaya başladı sanırım.

Z80'e yeterince hakim olmadığım için zaman kazanmak adına bazı durumlarda dokümantasyona bakmayıp, deneme & yanılma ile ilerlediğim oluyor. En son optimizasyon için geri dönüp, tüm kodun üzerinden geçerim, tcycleları azaltırım diyordum. Ama SjASMPlus compiler gibi davranıp, normalde CPU'da yer almayan opcode parametrelerini aşağıdaki görseldeki gibi üç opcode'a derlemek gibi saçmalıklar yapıp, bir de bunlarla ilgili warning bile vermiyor, az önce fark ettim. Bu ciddi bir sıkıntı değil benim açımdan, zaten optimizasyon noktasına geçtiğimde hiç bir zaman source code'a güvenmem, her daim binary çıktısı üzerinden kontrol ederim. Ama açıkçası şaşırttı böyle davranıyor olması. Bana "add de, de" diye bir şey yok demiyor da hl'nin değerini de ile iki kez swap ederek hallediyor işi.

Sizin kullandığınız Assemblerlarda böyle şeyler yaşadığınız oldu mu? Z80 dünyasında normal kabul edilen bir şey midir yoksa SjASMPlus biraz amacını mı aşmış?

Kontrol ettiğimde proje açıklamalarında "cross-compiler" diye de geçiyor. Bir de özellik listesinde şöyle bir madde var.

• Fake instructions as LD HL,DE (LD H,D:LD L,E) and more

Sanırım benim yaşadığım "and more" kısmına tekabül ediyor.

Edit: Adamlar daha geçen ay eklemişler bu özelliği. En azından warning verseymiş, compiler flaglerinden öyle bir şey açılabiliyor mu araştırıyorum şimdi.

31.3.2022 - 1.19.0
- added Amstrad CPC devices ("AMSTRADCPC464", "AMSTRADCPC6128") - by Oli Wilkinson
- added Amstrad CPC save snapshot and CDT (`SAVECPCSNA`, `SAVECDT`) - by Oli Wilkinson
- added `SAVE3DOS` (like SAVEBIN with +3DOS header)
- the deprecated "ok" warning suppression is removed, use "<warning-id>-ok" comment or -Wno-...
- new temporary label suffix syntax "_b" and "_f", enabling them for all expressions
- fix `--longptr` mode to keep 32b address when `DS 0` is used
- added fake instructions adc|add|sbc|sub de,bc|de|hl|sp
- dec|inc|pop|push will accept also single-comma multiarg in --syntax=a mode
- DUP/REPT will now accept also zero count (skipping the block)
- DEFL labels can be defined even as late as in last pass
- bugfixes (macros, listing, file names in errors, SLD reversepop data)

Edit 2:
--nofakes                Disable fake instructions (deprecated, use --syntax=F)

Ha şöyle...

[Ref]

Evet birçok assemblerde fake instructions özelliği var, pasmo'da olmadığı için ben hiç kullanmadım ama bazen ordan burdan kod arakladığımda bakıyorum hata alıyorum. Yani kullananlara rastladım.

Bu arada hazır girişmişken sana bir uyarı vereyim, eğer IX ve IY registerlerini kullanıyorsan "ula snow" hakkında bir araştırma yap, ekranda parazite neden olan durumlar var, emülatörünün de "ula snow" seçeneğini mutlaka aç.

Demo işlerini test için specemu dışında bir emülatör önermiyorum. Sonra yazdığın kod gerçek donanımda çalışmazsa şaşırma.

[Skate]

emülatörünün de "ula snow" seçeneğini mutlaka aç.

Ula ben de bu snow efektini nasıl yaptı diyordum, şimdi anlaşıldı.

Bu konuda iki seçenek var, snow harici genel bir "Enable ULA artifacts" seçeneği var, onu da açtım ben. Sanırım VIC'deki grey dots problemi gibi şeyler bunlar di mi?

Bkz: https://github.com/dirkwhoffmann/virtualc64/issues/395

[hades]

Daha önce farklı ekran silme rutinleri karaladığımı yazmıştım. Bu mesajda yine farklı bir ekran silme rutinini adım adım açıklamaya çalışacağım. İlk olarak Spectrum'un[ garip ekran adreslemesinden bahsedelim. Spectrum'un ekran belleği $4000-$57FF arasında yer alır ve 6144 byte uzunluğundadır. Ancak bu adresler lineer değildir. Yani "ben $4000'den başlayıp $57FF'e kadar her şeyi rahatça ekrana basarım" diyemiyoruz. Ekran 3 bloktan oluşur. Her blok kendi içinde 8 text satırı ve her text satırı da 8 pixel satırı olarak düzenlenmiştir. Yani bir ekran bloku 64 pixel satırından oluşur. Bir blok 2048 byte uzunluğundadır.
Bir pixel satırı 32 byte uzunluğundadır. İlk pixel satırı -ekranın en üstündeki- $4000-$401F arasındadır. Lineer olmayan ekran yapısı nedeniyle bir alttaki pixel satırı $4020 yerine $4100 adresinden başlar ve 8 pixel satırının son adresi $4700'dir. Başka bir deyişle bir karakter satırını oluşturan 8 pixel satırının adresleri arasında 256 byte fark vardır. Bir sonraki karakter satırının ilk pixel satır adresi ise $4020'dir. Bunu da şöyle ifade edelim. Karakter satırlarının aralarındaki adres farkı 32'dir.

0. karakter satırı
0. pixel satırı: $4000
1. pixel satırı: $4100
...
...
7. pixel satırı: $4700

1. karakter satırı
0. pixel satırı: $4020
1. pixel satırı: $4120
...
...
7. pixel satırı: $4720
...
...
7. karakter satırı
0. pixel satırı: $40e0
1. pixel satırı: $41e0
...
...
7. pixel satırı: $47e0

Bu ön bilgiden sonra silme rutinimizi tasarlamaya başlayabiliriz. Silme rutinimiz ekranı iki karakter genişliğinde kolonlar halinde yukarıdan aşağıya pixel satırlarını silecek. Rutinin çalışma adresi $8000 olsun. İlk olarak ekranı $FF ile doldurarak silme işleminin istediğimiz gibi olup olmadığını kontrol etmiş olacağız.

ld hl,$4000
        ld de,$4001
        ld bc,6143
        ld (hl),$ff
        ldir

araya biraz gecikme koyalım

        ld b,30
wait    halt
        djnz wait

Artık işleme başlayabiliriz. Ekranı temizlemek demek ekranın ilgili adresine 0 yazmak demektir. Bunun için xor a ile aküyü sıfırlayıp daha sonra ilgili adrese aküdeki değeri yazacağız. Ekran adresimizi tanımlayalım.

        xor a           ; aküyü sıfırla
        ld ix,$4000     ; ekran başlangıç adresi
        ld (ix+0),a     ; iki karakter genişliği şartımız olduğu için
        ld (ix+1),a     ; bir sonraki kolonu da siliyoruz

Şimdi bir alttaki pixel satırını silmemiz gerekiyor. Bunun için ix registerinde $4100 olması lazım. Yani bir önceki değerin 256 fazlası olmalı. Kısa bir özet geçeyim. Z80 her ne kadar 8 bitlik işlemci ve registerleri de buna bağlı olarak 8 bitlik olsa da registerler çift olarak kullanılabilir ve bu sayede 16 bitlik işlemler yapılabilir. Ayrıca Z80'in IX ve IY registerleri ise gerçek 16 bitlik registerlerdir. İşin güzel tarafı bu iki register ayrı ayrı low ve high registerlermiş gibi komutlara sahiptir. Ancak bu komutlar Z80'in standart komut listesinde yer almaz ve undocumented command olarak tanımlanmıştır.
Bu kısa bilgiden sonra LD IX,$4000 komutunu LD IXH,$40 - LD IXL,$00 olarak düşünebiliriz. Yapmamız gereken IXH kısmının $41 olması. Bunun için ise INC IXH komutunu kullanıyoruz. Eğer bu işlemi bir döngü içinde 8 kez yaparsak bir karakter satırını oluşturan 8 pixel satırını temizlemiş oluruz. Bunun için temizleme kısmında bir sayaç tanımlamamız gerekir. Bunun için de b registerini kullanacağız.
Sayacın başlangıç değeri 8 olmalı ki istediğimiz sayıda pixel satırını temizlemiş olalım. Daha sonra sayacı 1 azaltıp sayaç 0 olana kadar işlemleri tekrarlamalıyız. Bunun için ise sayaç olarak B registerini ve sadece B registerine özel DJNZ komutunu kullanacağız. Programın yeni hali şu şekilde olacaktır.


        xor a           ; aküyü sıfırla
        ld ix,$4000     ; ekran başlangıç adresi
loop00  ld b,8
        ld (ix+0),a     ; iki karakter genişliği şartımız olduğu için
        ld (ix+1),a     ; bir sonraki kolonu da siliyoruz
        inc ixh         ; ix=ix+256
        djnz loop00

İlk karakter satırnı oluşturan 8 pixel satırını temizledik. Artık bir sonraki karakterine geçebiliriz. Ancak bir sorun var. İkinci karakter satırının ilk pixel adresi $4020. İlk aklımıza gelen ix registerine $4020 vererek temizleme kısmını tekrar yazmak. Fikir güzel ama 24 ekran satırı için aynı işlemi yapmak gereksiz yere hafıza kullanmak demektir. Ne yapabiliriz? Temizleme rutinini ortak olarak kullanıp bir CALL komutuyla çağırmak. İlk çözüme göre önemli miktarda hafızadan tasarruf edebiliriz. Başka bir çözüm deneyebiliriz. Biraz matematik yapacağız.
İlk karakter satırı temizlendiğinde IX registerindeki değer artık $4800 olmuştur. Bizim istediğimiz IX'in $4020 olması. Yapmamız gereken $4800'den $4020 elde etmek. Bunun için iki yol var. İlk olarak $4800'den $07E0 çıkartabiliriz. Ben çıkartma işlemi yerine daha büyük bir sayı ile toplayıp aynı sonucu elde ediyorum. Sebebi ise IX komutu için çıkartma komutunun olmaması.
Bu toplama işlemini DE registerini kullanarak yapıyoruz.
8 karakter satırımız olduğu için aynı işlemi 8 kez yapmamız  ve bir sayaç kullanmamız lazım. Elimizdeki 8 bit registerlerden A ve B registerlerini kullandık. Yeni sayaç olarak C registerini kullanacağız. Sayaç değeri 8 olacak ve B registerinden önce kullanmak zorundayız. Daha sonra sayacı 1 azaltıp 0 olup olmadığına bakmalıyız. 0 ise işimiz bitmiş demektir. Sayaç her azaltılıp döngüye girildiğinde bir sonraki karakter satırında işlem yapan sayaç çalışmaya başlar. Bu arada HALT komutunu kullanarak hızımızı bira düşüreceğiz. Yoksa 1 sn'de ekran temizlenecektir.

        halt
        ld de,$f820
        add ix,de
        dec c
        jr nz,loop01

Kodun başına LD C,8 satırını ekleyeceğiz. Kod aşağıdaki hale gelecek.

        xor a           ; aküyü sıfırla
        ld ix,$4000     ; ekran başlangıç adresi
        ld c,8          ; karakter satır sayacı
loop01  ld b,8          ; pixel satır sayacı
loop00  ld (ix+0),a     ; iki karakter genişliği şartımız olduğu için
        ld (ix+1),a     ; bir sonraki kolonu da siliyoruz
        inc ixh         ; ix=ix+256
        djnz loop00     ; pixel sayacını 1 azalt, 0 değilse işlemleri tekrarla
        halt            ; biraz bekle
        ld de,$f820     ; Bir sonraki karakter satırını
        add ix,de       ; hesapla
        dec c           ; karakter satır sayacını 1 azalt
        jr nz,loop01    ; 0 değilse işlemleri tekrarla


Buraya kadar olan kısımda bir ekran blokunu temizlemiş olduk. Artık bir sonraki ekran blokuna geçebiliriz. Ekran bloklarının adres farkı 2048'dir. IX registerine baktımızda $4100 olduğunu görürüz. Bu sayıya $0700 ekleyerek bir sonraki blok adresini elde ederiz. Ekran 3 bloktan oluştuğu için blok sayacı tanımlıyoruz ve başlangıç değeri 3 olmalı. Yeni blok adresini elde ettikten sonra sayacı azaltıp işlemleri tekrarlayacağız.
Kodun yeni hali.

        xor a           ; aküyü sıfırla
        ld ix,$4000     ; ekran başlangıç adresi
        ld l,3          ; blok sayacı
loop02  ld c,8          ; karakter satır sayacı
loop01  ld b,8          ; pixel satır sayacı
loop00  ld (ix+0),a     ; iki karakter genişliği şartımız olduğu için
        ld (ix+1),a     ; bir sonraki kolonu da siliyoruz
        inc ixh         ; ix=ix+256
        djnz loop00     ; pixel sayacını 1 azalt, 0 değilse işlemleri tekrarla

        halt            ; biraz bekle
        ld de,$f820     ; Bir sonraki karakter satır
        add ix,de       ; adresini hesapla
        dec c           ; karakter satır sayacını 1 azalt
        jr nz,loop01    ; 0 değilse işlemleri tekrarla

        ld de,$0700     ; bir sonraki blok
        add ix,de       ; adresini hesapla
        dec l           ; blok sayacını 1 azalt
        jr nz,loop02    ; 0 değilse işlemleri tekrarla


Buraya kadar olan kısımda ekranın soldan iki kolonunu yukarıdan aşağıya doğru pixel pixel sildik. Şimdi bu işlemi tüm kolonlar için yapmak gerekiyor. Specrum ekranı 32 kolondan oluştuğu ve biz de iki kolon kullanarak işlem yaptığımız için kolon sayacımızı 16 olarak tanımlıyoruz. IX registerine bakıp iki sonraki kolon için işlemlerimizi yapıp ve gerekli komutları ekleyip silme rutinimizi bitiriyoruz.


        org $8000

        ld hl,$4000
        ld de,$4001
        ld bc,6143
        ld (hl),$ff
        ldir
        ld b,30
wait    halt
        djnz wait

cls     xor a           ; aküyü sıfırla
        ld ix,$4000     ; ekran başlangıç adresi
        ld h,16         ; kolon sayacı
loop03  ld l,3          ; blok sayacı
loop02  ld c,8          ; karakter satır sayacı
loop01  ld b,8          ; pixel satır sayacı
loop00  ld (ix+0),a     ; iki karakter genişliği şartımız olduğu için
        ld (ix+1),a     ; bir sonraki kolonu da siliyoruz
        inc ixh         ; ix=ix+256
        djnz loop00     ; pixel sayacını 1 azalt, 0 değilse işlemleri tekrarla

        halt            ; biraz bekle
        ld de,$f820     ; Bir sonraki karakter satır
        add ix,de       ; adresini hesapla
        dec c           ; karakter satır sayacını 1 azalt
        jr nz,loop01    ; 0 değilse işlemleri tekrarla

        ld de,$0700     ; bir sonraki blok
        add ix,de       ; adresini hesapla
        dec l           ; blok sayacını 1 azalt
        jr nz,loop02    ; 0 değilse işlemleri tekrarla

        ld de,$e802     ; iki sonraki kolon
        add ix,de       ; adresini hesapla
        dec h           ; kolon sayacını 1 azalt
        jr nz,loop03    ; 0 değilse işlemleri tekrarla

        ret             ; mutlu son

        end $8000


Not: Eğer HALT komutunu DJNZ komutundan önce kullanırsanız ekran silme işlemi daha yavaş olur.

[Skate]

Bu arada herkes sürekli ZX Spectrum'un video memory layout'u için çok garip, kötü falan diyor. Halbuki bence çok çok iyi. Üç nedeni var.

1) Zaten satır başlarını tablodan okuyabiliyoruz. Bu durumda istediği kadar saçma bir adreslemeye sahip olsun, hatta hafızanın dört bir yanına serpiştirilmiş olsun, bizi etkilemiyor.
2) Satır başından sonrası yana doğru sıralı gidiyor ki bu ne demek? Polygon rutinlerinin son derece hızlı olabilmesi demek. Henüz en hızlı yöntem hangisi diye incelemedim ancak stack bölgesi olarak polygonun yatay çizgisinin başını işaret edecek olursak sanırım push push push şeklinde çizim yapabiliriz.
3) Ekranın üç bölgeye ayrılmış olması da o kadar kötü bir şey değil. Logo alanı, diğer grafik öğeleri buna göre tasarlanıp, efekt çizim alanı için kendi içinde tutarlı bir alan belirlenebilir. Dediğim gibi tablo kullanıldığında bunun da bir önemi kalmıyor ancak ben video memory layout'u beğendim. Saçma gibi gözüken ama aslında Commodore 64'ünküne tercih edeceğim biçimde.

Tabii dez avantajı yok değil. Yukarıdan aşağı XOR fill yapmak gerektiğinde kodun tamamen unrolled yazılması gerekir. Yine de @Ref'den de duymuştum bu lafı, @hades de şimdi benzerini söylemiş. O "garip adresleme" aslında o kadar da garip ya da dez avantajlı sayılmaz. Sağa doğru ilerledikçe sıralı gitmesi çoğu durumda yeterli.

[ssg]

CPC'de zar zor alıştığım hex formatı;
&ffff

BASIC'te evet ama assembly'sinde (MAXAM, GENA3 vs) yine "#" kullanılıyordu. GW-BASIC'in de hex syntax'i "&H"tir mesela. Sanırım BASIC'likle alakalı.

[Ref]

Bu arada herkes sürekli ZX Spectrum'un video memory layout'u için çok garip, kötü falan diyor. Halbuki bence çok çok iyi. Üç nedeni var.

1) Zaten satır başlarını tablodan okuyabiliyoruz. Bu durumda istediği kadar saçma bir adreslemeye sahip olsun, hatta hafızanın dört bir yanına serpiştirilmiş olsun, bizi etkilemiyor.
2) Satır başından sonrası yana doğru sıralı gidiyor ki bu ne demek? Polygon rutinlerinin son derece hızlı olabilmesi demek. Henüz en hızlı yöntem hangisi diye incelemedim ancak stack bölgesi olarak polygonun yatay çizgisinin başını işaret edecek olursak sanırım push push push şeklinde çizim yapabiliriz.
3) Ekranın üç bölgeye ayrılmış olması da o kadar kötü bir şey değil. Logo alanı, diğer grafik öğeleri buna göre tasarlanıp, efekt çizim alanı için kendi içinde tutarlı bir alan belirlenebilir. Dediğim gibi tablo kullanıldığında bunun da bir önemi kalmıyor ancak ben video memory layout'u beğendim. Saçma gibi gözüken ama aslında Commodore 64'ünküne tercih edeceğim biçimde.

Tabii dez avantajı yok değil. Yukarıdan aşağı XOR fill yapmak gerektiğinde kodun tamamen unrolled yazılması gerekir. Yine de @Ref'den de duymuştum bu lafı, @hades de şimdi benzerini söylemiş. O "garip adresleme" aslında o kadar da garip ya da dez avantajlı sayılmaz. Sağa doğru ilerledikçe sıralı gitmesi çoğu durumda yeterli.

16 bitlik HL registerine göre ayarlamışlar, inc h yapınca bir satır aşağı iniyorsun, inc l yapınca bir sütun yana gidiyorsun. o şikayetler genelde sprite basmakla ilgili, özellikle ekranı 3 parçası arasında geçiş yapacaksan sıkıntı oluyor, dediğin gibi onu da tablo ile hallediyorsun. Sonuçta o layout spectrumun özelliklerinden biri, oric'inki biraz saçma gelir bana ama o da oric'e özgü bir görüntü üretiyor, appleii'nin yeşilli pembeli görüntüsü bir ayrı görsel. Sonuçta o dönemin bütün bilgisayarları kendine has bir görsel üretiyor sadece o layout'un ekranda temsili yüzünden.

Ama birkaç şikayetimiz var layoutla ilgili, ama dediğin gibi, o kadar da kötü değil.


@hades kodun tamamı varsa ekleyebilir misin? parça parça anlatmışsın ama bir arada da bitmiş hali gibi bir asm dosyası kolay denemek için iyi oluyor.

[Skate]

Bitmap converter'ımı da yazdım, sorunsuz çalışıyor. Ancak şöyle bir durumla karşılaştım emülatörde. Gerçek cihaz olmadan deneyemiyorum da. Hatırlıyorum @hades'in 256 bytelarından birinde de border koyu tonlarda çıkmıştı, @hades 7DX Party'de bana emülatörden bir ayar yaptırmıştı. Sanırım benzer bir durumla karşı karşıyayım.

Şimdilik sadece 8 açık renk tonunu kullandım. Visual Studio Code içindeki plugin olarak gelen emülatör'de düzgün görünüyor renkler. Ama ZX Spin'de saçmalıyor biraz. Aşağıda ikisini de attachlıyorum. Bu durumu bana açıklayabilir misiniz? Yani gerçek cihazda nasıl görünüyor, ZX Spin neden böyle bir şey yapıyor? Başta init etmeyi unuttuğum bir şeyler mi var? Ben sadece 4000 ve 5800'e transfer ediyorum datayı, başka bir şey yaptığım yok an itibariyle.

Edit: Renkleri düzelten ayarı bulup, onu da ekledim mesaja. Ancak işte sorum gerçek 48k/128k cihazlarda ne oluyor? Bu ayar gerçek cihazda hangi durumda ortaya çıkıyor? Hakim değilim konuya.

[Skate]

Bitmap converter scriptimi şuradan yayınladım. Henüz sadece 8 açık renk palete göre çıktı verebiliyor. Daha geliştireceğim, geliştirdikçe buraya push ederim.

https://github.com/c64skate/zx-spectrum-bitmap-converter