Názory k článku Programování pro osmibitová Atari: blokové výplně a přesuny dat, grafický subsystém

Ked vidim XE dizajn, hned mam zvyseny tep :) Nadhera.
A ten "riscovy" 6502 kod...

Náhodou to, že je tak málo registrů, je na Atari zábava. Konečně je programování v assembleru o něčem jiném, než napodobovat překladače (protože většina překladačů pro 6502 je hodně špatná, celkem logicky - není to RISC :-). Mě to vlastně přijde docela elegantní.

Nie je to sice risc, ale instrukciami to dohana :)
Rad som sa s tym kedysi babral a je to super na ucenie.

Zdarec vespollek, jeste vyrazne rychlejsi je idelane v ZP mit kousek kodu ala

...
lda addr16,y
sta addr16,y
iny
bne
inc ^^
....

jsou to 2 cykly na 1 byte, co je docela hodne :)

Pokud neni ZP tak se prodluzuje nastaveni adres a take vnejsi cyklus bude stat o 2 cykly navic.

P.

jj to je jeste lepsi reseni. Adresu tam cpes prepisem kodu ze?

Tak tak.... Prakticky je to totozne jako lda/sta lda/sta ldy #0 lda () sta () - jen misto 'lda ()' uz volas jsr $00xx. Dokonce i to inc zp+1 je defacto identicke, jen self-mod. V realu pak nekdy ZP funguje jak 'overlay' :)

Pri slozitejsich realtime efektech to ani jinak nejde (kazdej cykl je znat, tady je jedna z mala vyhod ataraka, ze se da, kdyz neni grafika, z procaku dostat vicero cyklu na radek, u nas je to vicemene fixni, kom badlajny). Jinak prakticky pocet cyklu u nas a u vas je az na chlup stejnej - chlup pro vas :)

Velice casto se nicmene musi vygenerovat lda/sta (nejdelsi co jsem generoval mel asi 12K v kuse). Z podstaty obvykle jsou adresy nemenenne, pripadne se meni v ramci X/Y registru.

P.

hmm sekvence LDA/STA, nebylo takto náhodou řešené video Bad Apple? Že aby se to ustíhalo, tak to byly přímé zápisy do VRAM a přepínaly se stránky... Musím dohledat.

Produkci ataraka moc neznam takze netusim, ale obecne je to bezne vsude, kde by pojidaci knedliku umreli hlady. Jednou jsem delal intro pro znamej diskmag a udelal jsem tam sachovnici a protoze jsem byl linej a je to kratke (konkretne $6447-$7e10), udelal jsem to makrama v asm co mam (moc to zabalit nejde :). Relanej kod teda vypada:

; roll the cheese
txt_roll            .rep font_size_y :y
                    .rep 8 :ycnt
                    .rep txt_scroll_size+1 :x

                    lda font+(y*(txt_scroll_size+1)+(txt_scroll_size-x))*8+ycnt
                    eor txt_eor_x+(txt_scroll_size-x)
                    eor txt_eor_y+y*8+ycnt
                    rol
                    sta font+(y*(txt_scroll_size+1)+(txt_scroll_size-x))*8+ycnt
                    .if ycnt & 1
                    sta font+$0400+(txt_scroll_size-x)*8+7-(ycnt+8*y)/2
                    .endif

                    .endrep
                    .endrep
                    .endrep

                    rts

to druhe dole je polovicni 'odraz'. txt_eor_x/y (btw. bufery v ZP, taktez moc a moc cyklu doma) paj ridi samotnej efekt. Zobrazeni je fontem (256 vlastnich znaku, hec :)

Efekt je vetsi textovej skrol, prez kterej jezdi po sinuvoce sachovnice, co to 'eoruje' (4 barvy). Pod tim se pak lehce vlni odraz jako 'na hladine'. A za tim je pak dalsi vetsi sachovnice, co to doplnuje (dalsi barvy). Par radku - ale vyapda to docela pekne :)

Zapisy do 2 VRAM narazi na problem toho, ze potrebujes mit kod 2x (lda() sta() je vykonove no go), coz je nekdy nerealny. Casteji se to resi syncrhonizaci s paprskem, kdy je 1VRAM a clovek bezi pred/za (podle toho jak na to chces koukat, ze...). U nas je to jeste komplikovanejsi v tom, ze poslednich 8 bajtu VRAM jsou 'adresy' sprajtu. Tim roste pocet 'sta' a cyklu. Pokud nejde sync, je lepsi rozdelit obrazovku na 2 VRAM a delat to napul, protoze vlk se nazere a cykly zustanou v koze (je to buferovane, nemusis byt akuratne sync, ale zaroven zeres 1 pamet a obetovat 2x0.5 VRAM je lepsi nez velke kB kodu). A CRAM (to neznate...) u nas je fixni a nelze nikam posunout, takze syncu se vyhnout nelze. A za 1 frame nelze presunout '2 VRAM' a jeste mit nejakej vykon na neco dalsiho, takze se to pak resi omezenim barev - treba 1x CRAM na 4 znaky, takze ma clovek lda/sta/sta/sta (to je usetrenych lda...). Nicmene pak jsou potreba taktez 2 'move' rutiny (suda/licha). Ale do 64K se toho vleze hafo... :)

No nic, uz prestanu placat blbosti.

P.

Měl jsem v paměti, že Atari 800XL/XE, 65/130XE měly procesor MOC 6502C ne 6502A, jak se píše v článku. Zdroje z Internetu to potvrzují...
C varianta měla totiž HALT vývod, A ne.

26. 3. 2026, 04:04 editováno autorem komentáře

XL a XE měly procesor 65C02 a ne 6502C - to je rozdíl (Custom CMOS vs. NMOS)

Mám dojem, že tady někomu ušla pointa mého sdělení.

A mimochodem, 65C02 (CMOS verzi s opravami) mělo Apple IIc a IIe a Atari Lynx (to mělo verzi 65SC02), nikoli XL/XE.

27. 3. 2026, 23:49 editováno autorem komentáře

No v Atarku se pouzival cip oznacovany SALLY, ktery se (nevim proc) nekdy znacil i 6502C, ale "prave" cecko to neni. Musim to v clanku nejak opravit, diky za upozorneni. Ty cipy nejsou zamenitelne - frekvencne a instrukcne jo, vetsinu vyvodu maji stejnou, ale chybi HALT.

Sally je kódové označení pro 6502C. To C = Custom (customizovaná 6502), které jsi navrhli sami v Atari. Tak uplně nevím, co má znamenat to "pravé céčko to není", jiné Céčko než to od Atari neexistuje, kódové označení Sally, modelové 6502C.

Omlouvám, existovala i 6502C, která nebyla C = Custom, ale čip, který zvládal 4 MHz v řadě bez písmene, pak A, B a C. Jak se tu myslel jsem na Atari, tak jsem si to neuvědomil.

jj chtěl jsem to napsat, ale nestihl.