Świetnie to wygląda.
Mam kilka pytań odnośnie funkcji piszącej tekst na ekranie w trybie graficznym.
Jak wiadomo systemowe generatory znaków przygotowane są dla trybów hires (1 bit na piksel). Czy:
1. Można pisać dowolny tekst używając takiego generatora (jak są interpretowane znaki w inverse video)?
2. Czy mając własny generator znaków zaprojektowany dla trybu multicolor (2 bity na piksel) można go użyć do rysowania fontów w trybie graficznym który pozwala na malowanie pikseli w kilku kolorach (np. czcionka dla trybu 12 OS rysowana w trybie 15 OS lub 7 OS)?
3. Czy można pisać tekst obrócony o 90, 180 i 270 stopni (a może 45, 135, 225 i 315)?
4. Czy tekst można pozycjonować z dokładnością do piksela czy do bajtu?
5. Czy w trybach GTIA tekst jest czytelny czy trzeba sobie skonstruować dla niego osobny generator znaków (4 bity na piksel)?

Edit: Czyli właściwie pytania 1, 2 i 5 sprowadzają się do kwestii mapowania pikseli z generatora znaków na piksele trybu graficznego :)

Czyli przepisujesz bajt z generatora do pamięci ekranu. Czyli generator ma mieć konstrukcję odpowiednią dla trybu (1bpp - singlecolor, 2bpp - multicolor, 4bpp - GTIA). W sumie to ideowo zgadza się to z tym co Atari chciało a czego nie, bo tekst w GR.12 też niespecjalnie wygląda z generatorami systemowymi :)
Skoro tiles, to może pomyśl o odbiciach w poziomie (tablica) i pionie (procedura). Twórcom BASIC-owych gier mogłoby to nieco uprzyjemnić robotę.

Edit: A pozycjonowanie co do piksela robienie sprajtów softwareowych.

Edit 2: A jeszcze z maskowaniem... Paaaanie. Tzn. z przezroczystością.

Jeśli byś się za te sprajty brał to mam następującą sugestię:

Zazwyczaj jeden z pikseli (zazwyczaj 0) traktowany jest jako kolor przezroczysty - reszta to piksele definicji sprajta. W trybach 1bpp taki sprajt jest szybko nakładany przez OR, w innych trzeba zamaskować. No ale mając np. tryb 4-kolorowy to para %00 jest zazwyczaj kolorem ramki, która często jest kolorem czarnym. Skutek jest taki, że zazwyczaj taka gra ma tło czarne. Gdybyś umożliwił przy nakładaniu sprajta wybór który kolor z definicji jest traktowany jako przezroczysty, to można byłoby wykorzystać kolor %00 jako zwykły piksel sprajta - dalej jeden sprajt miałby 3 kolory, ale jeden korzystałby z pikseli %01, %10, %11 a inny np. z %01, %10 i %00 a więc można by używać koloru ramki i mieć np. kolorowe tło (tak, jak ma Gorgh w swojej grze z motorem).
Można powiedzieć, że niczym się to nie różni od sytuacji kiedy masz dla sprajta zdefiniowany jego kształt i osobno maskę. Ale wtedy dla każdego sprajta musisz mieć i kształt i maskę. W proponowanej wyżej sytuacji masz tylko definicję sprajta, dzięki czemu zajmuje to mniej pamięci bo nie każdy sprajt musi używać pary %00.

Problem jest tylko taki, że nakładanie takiego sprajta trzeba maskować więc trzeba by mieć 256-bajtowe tablice masek. Dla trybów 1bpp potrzebujesz 2 tablice, dla 2bpp 4 tablice, dla 4bpp 16 tablic.
Można by założyć że sprajty o indeksach $00..$7F mają zawsze piksel %00 przezroczysty, a sprajty $80..$FF piksel %11 przezroczysty. Wtedy trzeba 2 tablice dla 1bpp, 2 tablice dla 2bpp i 2 tablice dla 4bpp.

Tak. To wymaga malowania dwóch sprajtów na sobie.
Nie musisz mieć tablic - możesz maskować programowo :P.

Powinno być to coś w tej podobie:
1. 1bpp:

tile1bpp:
        lda #%11111111  ;kolor przezroczysty (%1 powielony na wszystkie piksele)

        eor (zp1)       ;z piksela przezroczystego robimy %0

        nop             ;i liczymy maske

        pha             ;maskujemy piksele kloca
        and (zp1)
        sta tmp
        pla             ;maskujemy piksele ekranu
        eor #%11111111
        and (zp2)
        ora tmp         ;i scalamy
        sta (zp2)

2. 2bpp

tile2bpp:
        lda #%10101010  ;kolor przezroczysty (%10 powielony na wszystkie piksele)

        eor (zp1)       ;z piksela przezroczystego robimy %00

        pha             ;i liczymy maske
        and #%01010101
        sta tmp
        pla
        and #%10101010
        lsr
        ora tmp
        sta tmp
        asl
        ora tmp

        pha             ;maskujemy piksele kloca
        and (zp1)
        sta tmp
        pla             ;maskujemy piksele ekranu
        eor #%11111111
        and (zp2)
        ora tmp         ;i scalamy
        sta (zp2)

3. 4bpp

tile4bpp:
        lda #%00010001  ;kolor przezroczysty (%0001 powielony na wszystkie piksele)

        eor (zp1)       ;z piksela przezroczystego robimy %0000

        pha             ;i liczymy maske
        and #%00001111
        seq
        ora #%00001111
        sta tmp
        pla
        and #%11110000
        seq
        ora #%11110000
        ora tmp

        pha             ;maskujemy piksele kloca
        and (zp1)
        sta tmp
        pla             ;maskujemy piksele ekranu
        eor #%11111111
        and (zp2)
        ora tmp         ;i scalamy
        sta (zp2)

Począwszy od "maskujemy piksele kloca" kod jest identyczny. Podobny też jest kod aż do "i liczymy maske". Różny jest kod do liczenia maski stąd najfajniej mieć tę maskę stablicowaną :)

Edit: Oczywiście indeks koloru przezroczystego może być dowolny.

Edit 2: No i zp1 i zp2 możesz używać z dowolnym x czy y bo są nie używane (dlatego nie pisałem pełnego trybu adresowego).

Piękne, sterownik będzie działał po SDX ?

To je dobre.

Poproszę o testy na real atari albo z emulatorem w realnej grafice, tzn. włączone artefakty.

nie. musi byc przepisywanie danch poniewaz nie chce scrolla takiego jak jest w standardzie. chce zeby edytor mozna bylo uruchomic w okienku a wtedy scrollowac ma sie tylko zawartosc okienka.

Świetna robota, skąd można pobrać ?

Wow. Faktycznie powinieneś udać się do lekarza pierwszego kontaktu celem diagnozy :)

tez tak uwazam, ale czasem tak jest z niedostatecznie przetestowanymi urzdzeniami.