@toscanii: http://www.atari.org.pl/tape_preservation_project
Poza tym na głównej stronie portalu AtariArea znajduje się sekcja "Artykuły" i "FAQ". Możesz tam znaleźć różne rzeczy.

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).

Pomysł jest bardzo fajny.  A do sterowania w zasadzie wystarczą trzy rejestry:

$D500 WR: DATA
b7..b0 - A8..A1

$D501 WR: CTRL
b7 - /RESET
b6 - /SBYRESET
b5 - ROMDISABLE (opcjonalnie)
b4..b0 - n/c

$D501 RD: STAT
b7 - /LRQ
b6 - SBY
b5..b0 - n/c

kiedy ROMDISABLE=0 i SE=1 (/ALD jest spięty jakoś z R/W z Atari).

Jeśli lista alofonów jest podobna do SC-01A (http://www.atari.org.pl/forum/viewtopic.php?id=11736) i do tej używanej przez S.A.M. to może nawet udałoby się to spiąć z istniejącym oprogramowaniem?

Pytanie: co jest w zewnętrznym ROM-ie? Czy po prostu blokowany jest wewnętrzny i SP0256 wykonuje wtedy program z zewnętrznego? Są te ROM-y SPR128 gdzieś dostępne (chip i zawartość)? Jeśli jest gdzieś zawartość to może wsadzić do urządzenia jakiś RAM zapisywany z poziomu Atari i udostępnić jeszcze ROMDISABLE w rejestrze sterującym żeby można było użyć innych wsadów (albo zrobić sobie własne)?

Na wiki do Amstrada trochę o tym chipie jest: http://www.cpcwiki.eu/index.php/SP0256_Allophones

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.

Ś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 :)

Można przemapować dowolne urządzenie SIO na napęd Dx: za pomocą polecenia MAP np.:

MAP 1 SIO N:

Od tej pory SDX pod DN: będzie widział dysk 1 SIO.

Edit: Mnie się to przydaje przy pracy z HDD, bo na A: ciągle mam HDD (który normalnie przykrywa mi urządzenie SIO), a na N: mam pierwsze urządzenie SIO.

Edit 2: Widzę że jest jeszcze SWAP do zamiany miejscami napędów. Ale nie używałem :)

Zmieńmy trochę tablice:

masktab:
:64     .byte [1 << [# & %111]] ^ $FF
pixeltab:
:64     .byte [1 << [# & %111]]

Przeoczyłem jakoś Twój post.

S: nie znam, K: też - bufory klawiatury które widziałem wpinają się w przerwania VBLKD oraz VKEYBD OS-a.

Tak. Przepraszam - pisałem na szybko. Poniżej działająca:

;YX-U2
iifp:
  stx FR0
  sty FR0+1
  cpy #$80
  php
  bcc @+
  txa
  eor #$ff   ;abs(a)
  adc #0
  sta FR0
  tya
  eor #$ff
  adc #0
  sta FR0+1
@ jsr IFP
  asl FR0  ;korekcja znaku
  plp
  ror FR0
  rts

To zamienia Ci liczbę U2 na FP.
Wcześniej zrobiłem uzupełnienie do 1 zamiast do 2 przy abs.

Dodawanie i odejmowanie? Wydawało mi się że wystarczy potraktować liczbę jako U2 i wtedy zwyczajnie:

lda a
clc
adc b
sta c
lda a+1
adc b+1
sta c+1

b15 składników i wyniku wskazuje znak (i N w rejestrze flag). V mówi o przepełnieniu zakresu U2. OCB z bibliotekami?
Mnożenie U2 jest bardziej skomplikowane, ale OIDP na codebase64 są procedury korygujące znak.

Sama procedura może rezydować w dowolnym miejscu pamięci, tylko słowo adr powinno być ulokowane na ZPG.

A czy to nie wygląda na ubitą linię LUM1 (logiczna 1 albo 0)? Może ta bramka odwracająca (4050 pin 11 i 12 ze schematu) padła? Albo się rozlutowało :>