Jak probíhal vývoj pro osmibitová Atari před 45 lety?

Дата публикации: 24-08-2026 22:00:10

Vývoj aplikací pro počítače Atari s využitím cross assembleru CA65 není příliš komplikovaný. Vývoj totiž provádíme na PC se všemi jeho možnostmi. Pokusme se vrátit o 45 let zpět a použít Atari Assembler/Editor.

Основное содержимое страницы с новостью.

Většinou však byly domácí osmibitové počítače vybaveny nějakým dialektem programovacího jazyka BASIC (i když by se spíše hodilo mít k dispozici FORTH, to je však téma na delší debatu). I když se BASIC hodil na provádění různých výpočtů, jednodušších vizualizací a simulací (méně již na zpracování dat), poměrně rychle se narazilo na jeho limity. Především se jednalo o rychlost resp. pomalost samotného interpretru, obtížnou tvorbu strukturovaných programů a mnohdy i větší paměťové nároky.

Alternativou používanou profesionály byly assemblery. Dnes si ukážeme tvorbu programů v Atari Assembler/Editoru, což je sice pomalý, ovšem možná až (s ohledem na jeho velikost) překvapivě dobrý assembler. Práce v tomto assembleru je do jisté míry interaktivní a možná čtenáře tohoto článku překvapí, jak „hardcore“ vlastně celý proces vývoje byl: muselo se bojovat s omezenou kapacitou operační paměti, s pomalostí assembleru, s kryptickými chybovými kódy, ale i například s takovou „maličkostí“, jakou je malý počet znaků zobrazitelných na obrazovce.

Mnoho začínajících programátorů se muselo spokojit s takzvaným monitorem, což byl (a na některých platformách doposud je) program umožňující manipulaci s daty uloženými v operační paměti, tj. zápis dat do paměti, čtení (zobrazení) vybraného bloku, přesun bloku, vyplnění určité oblasti konstantou, vyhledávání sekvence hodnot, čtení a zápis dat na externí paměťové médium (typicky na magnetofon). Nutno dodat, že některé pokročilejší monitory byly vybaveny i takzvaným disassemblerem umožňujícím transformaci sekvence bajtů na symbolické instrukce. Mimochodem – při výpisu obsahu operační paměti se v monitorech většinou používal stejný formát, jaký najdeme u mnoha moderních programátorských hexa editorů (některé techniky již pravděpodobně dosáhly své dokonalosti a není nutné je dále vyvíjet).

Monitory, zejména jejich pokročilejší varianty vybavené disassemblerem (zpětným assemblerem), bylo možné použít i pro tvorbu programů na úrovni strojového kódu. Takový program se většinou nejprve zapsal na papír (nutně se muselo jednat o čtverečkovaný papír :-) ve formě assembleru, dále se provedl ruční překlad jednotlivých instrukcí do sekvence decimálních nebo hexadecimálních číslic a následně se tato sekvence zapsala do monitoru do určité předem vybrané oblasti operační paměti. V případě, že monitor podporoval zápis bloku paměti na externí paměťové médium (kazetový magnetofon, disketu), jednalo se o dosti primitivní, ovšem stále ještě použitelné (a v některých případech i používané) vývojové prostředí.

Na druhou stranu je programování na úrovni strojového kódu samozřejmě velmi pracné, zejména ve chvíli, kdy je nutné existující program modifikovat a tím pádem měnit cílové adresy skoků, adresy globálních proměnných atd. Mnohem civilizovanější způsob představovalo použití takzvaných assemblerů, což byly nástroje schopné překládat programy zapsané v jazyku symbolických adres/instrukcí do strojového kódu – ostatně přesně pro podobné činnosti jsou počítače zkonstruovány.

Na osmibitových domácích mikropočítačích se používaly dva typy assemblerů. Prvním typem byly assemblery interaktivní, které uživateli nabízely poměrně komfortní vývojové prostředí, v němž bylo možné zapisovat jednotlivé instrukce, spouštět programy, krokovat je, vypisovat obsahy registrů mikroprocesoru atd. Výhodou takto pojatého řešení byla nezávislost těchto assemblerů na rychlém externím paměťovém médiu. Se zástupci těchto assemblerů určených pro počítače Atari se ve stručnosti seznámíme i v dnešním článku, protože jak Atari Assembler Editor, tak i MAC/65 náleží do této kategorie.

Poznámka: ovšem, jak uvidíme dále, lze tyto assemblery použít i v dávkovém režimu (viz praktickou část článku).

Druhý typ assemblerů je používán dodnes – jedná se vlastně o běžné překladače, kterým se na vstupu předloží zdrojový kód (v případě osmibitových počítačů Atari uložený na kazetě či disketě) a po překladu se výsledný nativní kód taktéž uloží na paměťové médium (odkud ho lze spustit). Tyto assemblery byly mnohdy vybaveny více či méně dokonalým systémem maker (odtud název macroassembler). Příkladem takového assembleru pro Atari jsou všechny moderní crossassemblery, včetně CA65, který v tomto seriálu hojně používáme.

Jedním z nejstarších vývojových nástrojů pro osmibitové mikropočítače Atari je Atari Assembler Editor, jehož vznik se datuje do let 1979 až 1980. Tento nástroj byl používán i pro vývoj samotného operačního systému počítačů Atari. Jak však tento nástroj vůbec vznikl, když ještě vlastně počítače Atari nebyly dokončené? První (zjednodušené) verze byly ručně děrovány na děrnou pásku, která byla použita pro naprogramování čipu EPROM. Ten byl vložen do prototypu Atari a následně otestován. Jednalo se tak o jednu z forem bootstrapingu, kterým jsme ze zabývali v článku Můžeme věřit překladačům? Projekty řešící schéma „důvěřivé důvěry“. Výsledná podoba Atari Assembler Editoru byla dodávána na standardní cartridge o kapacitě osmi kilobajtů (ovšem ve skutečnosti se do značné míry využívaly subrutiny z operačního systému a používané i Atari BASICem).

Atari Assembler Editor se skládal ze tří částí: editoru, assembleru a debuggeru (což však byl ve skutečnosti pouze monitor – viz předchozí text). Všechny tři části byly dostupné z cartridge a bylo možné se mezi nimi přepínat. Zdrojový kód zapisovaný v editoru byl překládán dvouprůchodovým překladačem a mohl být v operační paměti uložen souběžně se zdrojovým kódem, což ovšem znamenalo omezení maximálního objemu zdrojového kódu. Zajímavé a typické pro interaktivní assemblery je, že řádky zdrojového kódu byly číslovány, podobně jako v BASICu. K dispozici však byly i poměrně pokročilé operace pro vyhledání návěští atd.

Debugger (spíše monitor) umožňoval zobrazení obsahu operační paměti, zobrazení obsahu registrů mikroprocesoru, modifikaci paměti, zobrazení disassemblované části paměti, krokování programu atd. – ovšem ne tak kvalitně, jako tomu bylo u dále popsaného assembleru MAC/65.

Další programátorský nástroj, s nímž se prozatím alespoň ve stručnosti seznámíme, se jmenuje MAC/65. Jedná se o assembler a současně i o debugger, jehož ovládání je odvozeno od výše zmíněného Atari Assembler Editoru; ve skutečnosti je však MAC/65 prakticky po všech stránkách lepší (až na poněkud vyšší cenu). Za vývojem MAC/65 stála společnost Optimized Systems Software (OSS). MAC/65 byl dodáván na specializované cartridgi s kapacitou 16kB, což je dvojnásobná kapacita, než jakou počítače Atari podporují (konektor měl pouze třináct adresních pinů). Z tohoto důvodu bylo oněch 16kB rozděleno do dvojice paměťových bank, z nichž každá měla kapacitu osmi kilobajtů a mezi kterými se provádělo automatické přepínání (taková cartridge se někdy nazývala „supercartridge“ a existovalo jich více typů, které se lišily způsobem přepínání paměťových bank).

Předností assembleru MAC/65 byl mnohem rychlejší překlad v porovnání s Atari Assembler Editorem. Taktéž byla k dispozici lepší forma debuggeru dostupná pod příkazem DDT (což je velmi příhodné označení).

V praktické části dnešního článku si nejprve ukážeme několik způsobů, jakými lze využít původní Atari Assembler/Editor pro vývoj aplikací. Využívat budu původní verzi tohoto nástroje, která byla dodávána v cartridge. To znamenalo, že samotné načtení assembleru bylo prakticky okamžité – postačilo počítač zapnout ve stavu, kdy v něm byla cartridge nainstalována. Tudíž bylo možné realizovat vývoj i v případě, že jediným záznamovým zařízením byl kazetový magnetofon (to ovšem znamenalo omezení velikosti vyvíjeného programu a samozřejmě také nepříjemná zdržení při čtení a zápisu jak zdrojového kódu programu, tak i výsledného binárního spustitelného souboru).

Ovšem i samotný Atari Assembler/Editor měl mnohá omezení. Zejména standardní kapacity cartridge dosahovaly maximálně osmi kilobajtů (bylo k dispozici jen třináct adresových vodičů) – a přesně tuto velikost má i cartridge s assemblerem. Velmi stručná hlášení assembleru i stručnosti příkazů plynou mj. i z těchto omezení. S dalšími omezeními a nedostatky tohoto assembleru se postupně seznámíme v dalších kapitolách.

V tomto režimu se očekává zápis příkazů nebo programových řádků. Podobně jako v BASICu se řádek začínající celým číslem považuje za programový řádek, který je uložen do paměti (zpracovávat se bude ve správném pořadí). Ostatní řádky jsou chápány jako příkazy, které se ihned vykonají.

To znamená, že pokud vynecháme návěští, musí být mezi číslem řádku a instrukcí zapsány minimálně dvě mezery (nebo více mezer). Kromě instrukcí lze zapisovat i několik typů pseudoinstrukcí a deklarací. Jednou z nich je i určení adresy, od které budou ukládány další překládané řádky. Náš program je velmi krátký a vejde se celý do šesté stránky paměti, tj. bude ukládán od adresy $0600 (šestá stránka je volná i v BASICu i v prostředí assembleru). Zkusme tedy zapsat následující program (pozor na dvojité mezery):

Poznámka: pokud uděláte chybu, stačí řádek napsat znovu.

Zdrojový kód si můžete kdykoli zobrazit se správným pořadím řádků pomocí příkazu LIST (tedy jako v BASICu).

Nic nám ovšem nebrání v zápisu programu včetně komentářů. Ty se od operandů oddělují mezerou nebo mezerami:

Po zápisu zdrojového kódu programu do paměti je nutné provést jeho překlad. Pro tento účel slouží příkaz ASM, který sice akceptuje několik parametrů, ovšem jedná se o parametry nepovinné. V případě, že zadáme pouze příkaz:

provede se postupné načítání programových řádků z operační paměti a výsledek překladu je taktéž uložen do operační paměti (v našem případě od adresy $0600, tedy na šestou stránku paměti). A současně s druhou fází překladu se na obrazovku (resp. přesněji řečeno na zařízení E: vypisuje takzvaný listing), v němž je možné zkontrolovat adresy atd. Listing má pevně daný formát se sloupcem s absolutní adresou, dále se sloupcem s výpisem obsahu paměti, pravé sloupce pak obsahují opis zdrojového kódu:

Po provedení příkazu ASM se assembler vrátí zpět do režimu EDIT.

Pochopitelně ovšem mohou být ve fázi překladu nalezeny různé chyby. Assembler je v tomto případě poměrně strohý a vypíše pouze kód chyby, jehož význam je nutné dohledat v manuálu (ten je ovšem praktický – začíná právě seznamem možných chyb s jejich popisem):

Poznámka: jiné assemblery se snaží chyby hledat již při zápisu jednotlivých programových řádků, což je pochopitelně praktičtější.

Spuštění programu je nutné provést v režimu debuggeru, do kterého se přepneme příkazem:

V tomto režimu jsou očekávány odlišné příkazy, než v režimu editoru. Jedním novým příkazem je příkaz pro skok (goto) na určitou adresu, která je zapsána za jméno příkazu G:

Samotný zdrojový kód je možné uložit na libovolné zařízení, které umožňuje zápis. K tomu se příkaz LIST, který může mít následující podobu:

Zařízení se ovšem používají i v příkazu ASM. Příkladem je uložení listingu do souboru či tisk na zařízení P:

Poznámka: čárka zapsaná v předchozím příkazu na zdánlivě nesmyslné pozici, je ve skutečnosti nutnou součástí příkazu. Vynechali jsme totiž jméno souboru se zdrojovým kódem.

Již z předchozí poznámky do jisté míry vyplývá, že assembler dokáže pracovat dávkovým způsobem, tedy tak, jak jsme zvyklí dnes. Vstupní zdrojový text může být načítán ze zvoleného zařízení (souboru), postupně překládán a listing produkovaný assemblerem bude uložen do jiného zařízení či souboru:

Ostatně samotný listing si můžeme nechat zobrazit operačním systémem. Jen je zapotřebí korektně pracovat se znaky pro konec řádku:

Nejvíce komplikovaná varianta příkazu ASM obsahuje jména tří zařízení a popř. i tři jména souborů. Formát je následující:

Můžeme například načítat zdrojový soubor z diskety, listing provádět na tiskárnu (zařízení P:) a výsledný binární soubor ukládat na kazetu ve standardním formátu (bloky 600Bd, zařízení C:):

Vzhledem k tomu, že ukázkové screenshoty vytvářím v emulátoru a nikoli na reálném Atari, mohu využít zařízení H:

Poznámka: no není CIO nádherné? Autorům původního Atari Assembler/Editoru se určitě ani nesnilo o tom, že by byl tento nástroj používán společně s SSD!

Zastavme se na chvíli u souboru PRG1.OBJ, který vznikl jako výsledek činnosti assembleru (a vlastně i linkeru – pokud tedy použijeme moderní terminologii). Tento soubor má délku dvanácti bajtů a jeho obsah si můžeme zobrazit například nástrojem od (octal dump), nebo je možné využít jakéhokoli dobového nebo moderního hexa editoru. Pro jednoduchost ovšem zůstaňme u nástroje od:

Tento soubor je možné přímo spustit v emulátoru osmibitových mikropočítačů Atari. Na rozdíl od moderních formátů spustitelných souborů (ELF atd.) má PRG.OBJ interně velmi jednoduchou strukturu. Skládá se (obecně) z jednotlivých segmentů, přičemž na začátku je u spustitelných souborů umístěn speciální segment nazvaný EXEHDR. Každý segment je uložen následovně:

Náš soubor PRG1.OBJ obsahuje jen jediný segment. Jeho obsah lze tedy dekódovat následujícím způsobem:

Poznámka: život Ataristy nebyl jednoduchý, zejména proto, že se nedostávalo kvalitních informačních zdrojů. Ovšem na druhou stranu byla většina technologií, na kterých tyto stroje vznikly, vlastně velmi snadno pochopitelná.

Při zápisu a překladu programu, který se skládá ze čtyř programových řádků a pouhých tří instrukcí, pochopitelně nedokážeme posoudit, do jaké míry je Atari Assembler/Editor reálně použitelný ani jak je rychlý (nebo naopak pomalý). Proto se pokusíme o naprogramování poněkud delší aplikace. Bude se jednat o přepis příkladu, se kterým jsme se seznámili při popisu konfigurace grafického čipu GTIA. Program zobrazí pětici hráčů (players), přesněji řečeno čtyři hráče doplněné o čtveřici střel, ze kterých byl složen pátý hráč. Uživatel následně může s využitím joysticku horizontálně pohybovat prvním hráčem. Aby byl pohyb dostatečně pomalý (a viditelný pro člověka), je synchronizován s hodinami počítače.

Zdrojový kód bude mít délku cca 130 řádků, tedy zhruba pět obrazovek. Je to již dlouhý program? Záleží na úhlu pohledu. Překlad takového programu totiž Atari Assembler/Editoru trvá neuvěřitelných 24 sekund a překlad s výpisem (listingem) dokonce 33 sekund. Rychlost překladu tedy dosahuje necelých šesti zdrojových řádků za sekundu.

Poznámka: nakonec je z mého pohledu největší překážkou malý počet znaků na řádku. A dobré je vypnout si zvuky kláves :-)

Nejprve si ukažme, jak vypadá původní zdrojový kód příkladu, který budeme přepisovat. V něm je zobrazeno pět spritů (pátý hráč je tvořen čtyřmi střelami) a s využitím joysticku je možné horizontálně pohybovat prvním hráčem:

V prvním kroku do syntaxe Assembler/Editoru přepíšeme definici konstant, které představují adresy registrů čipů ANTIC a GTIA, adresy stínových registrů, kódy barev atd. Mnoho těchto konstant je dostupných při použití CA65 (po provedení .include „atari.inc“), ovšem tento luxus v Assembler/Editoru pochopitelně nemáme. Povšimněte si, že se při výpočtu konstant mohou použít i jednoduché výrazy. V názvech konstant nesmí být podtržítka, takže výsledek zrovna neoplývá čitelností:

Dále přepíšeme původní hlavní proceduru, která nastaví pozice a barvy všech hráčů, nakonfiguruje spojení střel do pátého hráče, povolí DMA, priority hráčů vůči pozadí atd. Vzhledem k tomu, že PMBASE (bitmapy hráčů) nejsou nastaveny, budou sice hráči (po překladu a spuštění) zobrazeni, ovšem prozatím s (pseudo)náhodnými tvary:

Konečně se dostáváme k zajímavější části – k programové smyčce sloužící pro nastavení bitmap (tedy tvarů) všech pěti hráčů. Výsledek by měl vypadat takto:

Povšimněte si, jak se mohou zapisovat kratší návěští (na stejný řádek, jako instrukce). Na řádku 5000 je navíc uvedena definice bitmapy, resp. její části:

Konečně se dostáváme k hlavní programové smyčce, ve které se čte náklon joysticku a podle něj se mění horizontální pozice prvního hráče. Navíc je posun synchronizován s hodinami počítače:

Zde používáme jak krátká návěští (LOOP), tak delší návěští zapsaná na samostatném řádku (WAITWSYNC):

Úplný zdrojový kód demonstračního příkladu se sprity, který byl přepsán do formátu plně kompatibilního s Atari Assembler/Editorem, vypadá následovně. Pro jednoduchost jsem vše psal velkými písmeny, aby se zachovaly dobové zvyky:

Podívejme se pro úplnost ještě na listing, který byl vygenerován následujícím příkazem:

Všechny demonstrační příklady, s nimiž jsme se v předchozích článcích i v článku dnešním seznámili a které jsou určeny pro překlad s využitím assembleru ca65, jsou dostupné, jak je zvykem, na GitHubu. V tabulce níže jsou uvedeny odkazy na jednotlivé zdrojové kódy příkladů psané v assembleru i „listingy“ vygenerované samotným assemblerem, ze kterých je patrné, jakým způsobem se jednotlivé příklady přeložily do výsledného XEX souboru:

Схожие новости

#	Наименование новости	Тональность	Информативность	Дата публикации
1	The meaning of numbers	0	15.1	21-08-2026
2	Maxell и Disk Union возродили культовые черно‑красные кассеты UD‑60U из 1970‑х	0	10.99	25-08-2026
3	Мой опыт онбординга разраба с амнезией	0	8.24	03-08-2026
4	Как сделать игру для ZX Spectrum в 2026 (и зачем)	0	8.57	05-08-2026
5	Отладка исходного кода Asterisk	0	2.5	05-09-2025
6	Новый процессор IBM для мейнфреймов умеет выполнять код IBM Z и Arm одновременно и без эмуляции	0	7.66	25-08-2026
7	Kakehashi: запуск macOS бинарников на Linux ARM. Часть 1: рабочий 7zip, curl и успехи с Apple Git	0	9.18	01-08-2026
8	Podepisování PDF přes eObčanku na macOS	0	12.2	04-08-2026
9	Claude Code erhält Zugriff auf iPhone-Simulator	0	12	24-07-2026
10	Le développement augmenté, un avis politiquement correct, mais bon...	0	5	31-07-2025

Классификация: . Схожих патентов: 0. Схожих новостей: 10. Тональность: 0. Информативность: 12.9. Источник: www.root.cz.