Názory k článku Programování pro osmibitová Atari: volání instrukcí procesoru MOS 6502

Krátké doplnění (v článku plně nezaznělo) k tomuto kódu:

.proc hex_digit
        cmp #$0a                ; test na hodnotu 0-9 nebo 10-15
        bcc skip_add            ; je to hodnota 0-9
        adc #6                  ; pricist sedmicku (6+carry) 

to přičtení šestky je správně, protože bude nastaven příznak C (carry). To víme jistě, protože jinak by se neprovedl skok. Takže nemá smysl carry nulovat přes CLC a přičíst sedmičku; takto je možné kód o bajt a dva cykly zkrátit.

ještě by bylo dobré uvést, že 6502 nastavuje příznaky u většiny instrukcí, takže se vlastně vyhneme CMP (ta se moc nepoužívá) a TST. Na druhou stranu to někdy štve, že se příznaky "zničí" i třeba při načítání operandu.

jj pravda, příště to zkusím rozebrat. A taky rozdíl v BCD aritmetice. V tomto ohledu je MOS 6502 asi unikátní.

A taky hezké bylo, že drtivá většina instrukcí byla 1 takt, s immediate operandem 2 takty.
Jó, to byly války se Spektristy, jestli je 1/2 takty na 1.79MHz lepší než 4/7 na Zilogu na už si nepamatuju 4MHz?

já po letech uzavřel se známýma Spektristama věčné příměří (zdravím Petyho), takže už se k tomu, že 1/2 na 1,79MHz je lepší (v kontextu toho, co to všechno dělá, tak je) nemůžu oficiálně vyjadřovat :-)

A neni to prast jak uhod?

1.79*2=3.58

Vlastne oba majit ty frekvence presnejsi a jsou sladene, aby se to synchronizovalo s paprskem televize.

6502 ma 2+ clocks na instrukci
Z80 ma 4+ clocks na instrukci

A oba to tak maji nastavene kvuli rychlosti cteni nebo zapisu do tehdejsi RAM.

Z80 ma jen jemnejsi skalovani.

inc a          ...4 T-states
ret nz         ...5 T-states (11 kdyz skace)
inc bc         ...6 T-states
add a,(hl)     ...7 T-states
rrc b          ...8 T-states
?
ld (hl), num   ...10 T-states
inc (hl)       ...11 T-states
jr adr         ...12 T-states
djnz adr       ...13 T-states (7 pri ukonceni)
ld ix, num     ...14 T-states
set 0,(hl)     ...15 T-states
ld hl, (adr)   ...16 T-states
call adr       ...17 T-states
?
ld a, (ix+num) ...19 T-states
ld ix, (adr)   ...20 T-states
ldir           ...21 T-states (16 pri ukonceni)
?
set 0,(ix+num) ...23 T-states

Na adresach pod 32768 si nahodne prictete obcas nejake zpozdeni u ZX, protoze ULA zrovna cte co ma kreslit.

Zrovna v tomhle se od sebe ty CPU nelisi a jeden jede 100 km/h a druhy 62.14 mph.

10. 3. 2026, 15:22 editováno autorem komentáře

6502 totiz cte z pameti vzdycky 2x, i pro jednobajtove instrukce. Proto ty 2 cykly, vlastne nezavisle na tom, jestli ma instrukce (immediate) operand nebo ne. A v kazdem cyklu se do pameti pristupuje jen 1/2 casu, takze zbytek si muze obsadit ANTIC, DMA, ...

Omlouvam se u toho djnz je to jako u relativniho skoku, jen o 1 T-state pomalejsi. Takze pri ukonceni je to 8 ne 7.

Z80 na Spectru měl 3.5MHz

SHARP MZ821 měl CPU na 3.547MHz = 1/5 frekvence GDG 17.73MHz.
17.73 byl 4-násobek frekvence barvonosné PALu.

Ač odkojen 6510, musím uznat, že z programátorského i výkonnostního hlediska vyhrává Z80. To samozřejmě nic nemění na věci, že nejlepší osmibiťák byl Commodore 64. MOS vsadil na cenu a výrobci lepších osmibiťáků za peníze ušetřené na CPU mu pořídili k ruce pomocníky - nepotřebujete nadupané CPU, když se spousta práce může udělat jinde. 6502 je ale krásná ukázka, jak se inženýrsky zhostit výzvy "za málo peněz co nejvíc muziky."

P.S. - u nás panovala rivalita mezi commodoristy a ataristy. Spectristy jsme svorně považovali za druhou ligu a nikdo jsme je neřešil. Ani oni sami neprotestovali, jen tiše záviděli. Gumák byl jenom nouzovka.

Ve druhe lize Spectristi a hlavne Sharpisti, jelikoz meli nekompatibilni processor, si k tomu pak pripojovali ramdisky a floppy a provozovali na tom ruzne divne negraficke veci jako CP/M :-)

:-) Taky provozovali Turbo Pascal a jiné obskurnosti

tehdy měli jednu tuzemskou bombu - Hlípu. Tu jsem záviděl

Dodnes nechapu jak jsem byl schopny si k Sharpu udelat funkcni ramdisk :) Ale CP/M bylo super.

A taky z nedostatku her predelavat hry ze Spektra. Legrace byla, ze na rozdil od Spekta se na Sharpu se muselo prepinalo mezi RAM a video RAM, a nebyla vyjimka, ze na Spektru kod pristupujici do VRAM byl na problemovych adresach, takze se musel presunout mimo rozsah mapovani VRAM. Plus uplne odlisna organizace VRAM. Chutovka byla, kde jsem predelaval vektorovy Elite. Vrcholem bylo, ze v CR byl nejaky clovek co od nas tyto predelavky kupoval a normalne prodaval. Na autorske prava se moc nehralo. Ostatne kopirovani her v ramci Svazarmu bylo taky normalni.

http://visual6502.org/

Tento článok mi pripomenul že už tento piatok bude na Slovensku 8bit demo párty Forever
https://forever.zeroteam.sk/

Ach to je nostalgie. Pred mnoha lety jsem v Atari asembleru napsal graficky editor s podporou mysi a pluginu pro podporu ruznych tiskaren. Nejhorsi je ze uz nic z toho nemam :( Mozna by v prazskem Atari klubu jeste meli binarky, ale zdrojaky jsou uz pryc :(

Já k tomu udělal světelné pero. Na hrotu byl fotorezistor a jak se stiskl mikrospínač, tak zleva jel bílý pruh a jak 'narazil' na snímač, tak jel další pruh shora. Psal jsem to ve 'strojáku' a zapojené to bylo do gameportu. Byl jsem na to tenkrát dost hrd :-D

To se tak někdo měl, když měl assembler. První "strojáky" jsme psali v Basicu pomocí "DATA" a decimálních hodnot instrukcí, dodnes si pamatuji, snad dobře, že LDA bylo 165 ;-)
Další fáze byl vlastní, v Basicu napsaný, primitivní assembler, než se nám podařilo někde zkopírovat assembler MAC65. A pak už to byla jedna báseň. :-)

Na 8mibitech to bylo hodne o tom, ze resit nejaky asm = zabirat si vzacny misto v ramce. Takze bylo dost efektivni to psat v tech kodech rovnou do pameti a pak to stacilo jen spustit.

Navic atari/c64 mely pekne vyvedenou sbernici, do ktere se dal strcit plosnak s epromkou, pouzivalo se to treba jako loader turbozavadece. Do 2kB za par zbrdli v libovolny prodejne tesly se toho veslo ... jo a mazat se to dalo "horskym sluncem" ;D.

Pripadne se teda daly primo v podobe ty kardridge koupit gamesy, ale to specielne u nas byla nejspis extremni vzacnost.

Když to bylo větší, tak se to rozdělovalo na více částí. Pak se to teprve spojovalo. MAC65 zase tak moc nežral. Ale je jasný, že na 64 kB RAM bylo všechno hodně.

Přemýšlím už pár dní, jak sepsat svůj dojem z článku... Je v něm totiž všechno správně a ještě má nejlepší popis té problematiky registrů vs. nulté stránky, co jsem kde viděl. Za to obzvlášť dík! Hned je vidět, že to je záměr architektury systému a ne jenom seškrtání počtu registrů.

Stejně mám ale v hlavě pořád pocit, že tomu "něco" chybí, aby čtenář ze světa Z80/Intel nasál tu atmosféru. (Jako já jsem takhle hledal opačně článek o ZX Spectru, abych to po letech pochopil líp.) Myslím, že to mám: přidal bych dva speciální díly seriálu s obrázky o architektuře.

První ATARI XL/XE jako celku, jak je organizovaná RAM/ROM/cartridge a proč (jak už tu někdo vzpomínal), a jak spolupracují 6502, ANTIC (jako paralelně běžící procesor s vlastní instrukční sadou), GTIA, POKEY. A jaké to mělo ve stručnosti důsledky: grafické možnosti s různým rozlišením na každém řádku, šetření RAM, scrolling...

V dalším díle druhý obrázek o vnitřní architektuře 6502, jak se dekódují instrukce a následně provádějí. Tenhle obrázek je těžké sehnat ve srozumitelné podobě. Někde jsem jeden dobrý měl, ale netuším, jestli ho najdu. Z tohoto obrázku totiž vyplyne, co bylo na této architektuře CPU tak geniální, proč to všechno šlo tak rychle, že zvládal totéž co Z80 na dvojnásobné frekvenci. A taky na druhou stranu, že ta optimalizace byla tak moc svázaná s tehdejšími podmínkami, že je klidně možné, že to byl jeden z důvodů, proč se v tomto směru nepokračovalo v architekturách CPU dál.

Díky za feedback. Určitě bude jeden celý díl jen o grafice, ale určitě nestihnu všechno, takže spíš dva díly (jeden bitmapové režimy, druhý textové - ty jsou důležitější a někam nacpat sprity :-). Hmm popsat, jak se koprocesory dělí o sběrnici a RAM - musím si to refreshovat, jako zhruba vím, jak to funguje, ale chtělo by to prozkoumat víc do hloubky. Budu rád za jakékoli materiály!