Vlákno názorů k článku Jak probíhal vývoj pro osmibitová Atari před 45 lety? od Dushino - Pamatuji si, že zmiňované "assemblery" (tak jsme ji...

Pamatuji si, že zmiňované "assemblery" (tak jsme ji říkávali) se do mého zorného pole dostaly někdy v době, kdy jsem něco slyšel o Pascalu a že ve v Pascalu nemusí číslovat řádky. Protože jsem někde získal ATMAS II https://atariwiki.org/wiki/Wiki.jsp?page=Atmas%20II a tam se řádky číslovat nemusely, zkoušel jsem v něm něco dělat. Jakmile jsem sehnal českou dokumentaci z nějakého Atari klubu, nebylo co řešit - mé opovržení číslováním řádků dosáhlo vrcholu a Basic jsem vzal na milost pouze jako Turbo Basic s příkazem RENUM. :-)
Nicméně ne všechny programy pro Atari byly psány přímo na Atari. Např. Rescue on Fractalus byl vyvíjen na sálovém počítači VAX https://en.wikipedia.org/wiki/Rescue_on_Fractalus!

Díky za doplnění. Ano, Atari a později velké herní společnosti si mohli dovolit crossplatform vývoj (to asi bylo hodně drahé). My ostatní se museli spokojit s kazeťákem popř. kazeťák+cartridge (u nás), popřípadě disketovka+car­tridge (takový sen; jak už jsem psal, tak atarácké disketovky byly naprosto nechutně drahé).

Jinak ten MAC/65 umí automatické číslování řádků. Má to svoje výhody i nevýhody (hlavně na klávesnici Atari, kde jsou šipky přes Control).

Teda, já už úplně zapomněl, že i MAC/65 čísloval řádky... Nikdy jsem s tím nezískal praxi, protože jsem jeden z těch "zdánlivě bláznivých", kdo používali monitor TM2304 a čtverečkovaný papír. Proto mi to neutkvělo v paměti. To je teda šílenost, vždyť se vždycky uváděla jako jedna z hlavních nevýhod psaní přímo do paměti potřeba přesouvat kód, když chtěl člověk "psát něco nového doprostřed" - to ale tady s ručním přečíslováváním nesmyslných čísel řádků vůbec není rychlejší!

Navíc na počítači s cca 20 řádky na obrazovce je stejně potřeba mít celý program na papíře...

Co považuju naopak za úplně úžasnou funkci je to krokování programu. Fakt to fungovalo? Pamatuje si to někdo ještě z té doby?

to krokování se dělalo klávesou OPTION a docela dobře fungovalo. Interně to (asi) bylo řešené tak, že tam DDT vkládat BRK. Takže teoreticky, kdyby program dělal třeba self modifikaci, tak to selže.... hmm to si musím vyzkoušet :-)

To jsem zvědavý :)
Já to dělal ručně - testoval jsem si takhle rutinu po rutině s návratem do monitoru.

Ještě k těm přesunům: monitor měl funkci Q - readddr.: přesun bloku s tím, že si ho disassembluje a změní argumenty JMP, JSR a LDA/STA pokud jsou absolutní a vedou do této oblasti. Pochopitelně to nevychytává všechno, např. odkazy na tyto adresy v kódu mimo přesouvanou část, ale těch bylo minimum, při rozumné organizaci kódu.

Což mi připomíná, že mi vždycky bylo z tohoto důvodu líto, že není i instrukce BNC - Branch No Condition - aby člověk mohl mít relativní skoky i bez podmínek a právě se tím nemusel zabývat. Možná jste si všimli v kódu G-driveru, že tam to na pár místech simuluji tím, že znám nastavení flagů v daném místě kódu :)

25. 8. 2026, 15:06 editováno autorem komentáře

Uplne stejne to snad delal debug.com v DOSu 8088, ne?

S tím BRK snad, ale klon 6502 použitý v Atari měl právě u tohoto příkazu nějaký problém, kdy se po realizaci instrukce BRK a ukončení její obsluhy nepokračovalo na instrukci (byte) za ní bezprostředně následujícím (BRK + 1) ale až na BRK + 2. Pamatuji, když jsem na své z Kanady importované stotřicítce nemohl nahrát Mercenary. Nejdříve krátký zavaděč a potom nějaké dlouhé bloky. V zavaděči byl test PAL/NTSC a když NTSC, tak konec. Podařilo se mi to odstranit náhradou nějaké instrukce v tom zavaděči právě dvěma BRKy, přičemž ten druhý, jak jsem později zjistil, by se nikdy nerealizoval.

zajimave, takze self-modified kod to i pri krokovani zvlada. DDT je sofistikovanejsi, nez se zda ;) A nebo to zkousim spatne:

01       .OPT OBJ
02       *=  $9000
03       LDA #0
04       STA $9005
05       INX 

(myslenka je asi jasna: namisto INX se zapise instrukce BRK. A DDT to umozni krokovat...tj nevrati tam INX ale ponecha BRK)

"atarácké disketovky byly naprosto nechutně drahé"

ona ta disketovka v ty dobe stala zhruba totez, co to atarko (nove cca 10kKc, rekneme rok 85, ovsem cena zalezela na znamostech/kurzu bonu/pristupku k zapadnim menam ...) a navic byla prakticky nesehnatelna, uplne stejne jako diskety do ni. Nadto kapacita oturbeny kazety byla vyrazne lepsi.

V nejmodernejsi variante mela totiz ta disketovka 180kB jedno nebo 360kB oboustrana. Na jednu stranu prumerne oturbene 90min kazety se dalo naladovat +- 10MB. I uplne bez turba byla kapacita takovy pasky neco kolem 3MB na jednu stranu. Takze se bavime zhruba o pomeru 1:20 ale taky klidne 1:200+ ... a samozrejme i tohle byl jeden z tech duvodu, proc ty disketovky nikdo nijak zvlast neresil.

Maximalne v dobach PC si nadsenci vyrobili redukci na standardni PC disketu. A v dobach soucasnych ... mel sem v ruce cardridge, uvnitr bylo pico. Po startu z toho najela miniappka se seznamem "disket" (tech tam bylo asi tak mililon ...) a po "zasunuti" diskety se s tim uz dalo presne stejne jako s tou disketovkou fungovat.

Je to tak. Jen dodám, že my jsme tehdy byli velmi specifický "trh": pravděpodobně v dobách rozmachu 8bit Atari na Západě nikdy běžný uživatel neměl tolik SW jako my tady. Zaprvé my jsme k tomu přišli později, takže ho bylo celkově mnohem víc, a zadruhé tam bylo zvykem za věci platit. Takže u nás ten poměr počet dostupných disket na počet vlastněného SW byl řádově jiný...

Typicky se tak na disketu dával SW, který s ní pak aktivně pracoval: buď hry, které si dohrávaly své další části (International Karate byl z diskety bohatší než z kazety, myslím) nebo uživatelské programy jako textový editor Čapek (počeštěný SpeedScript), TurboBasic apod.

Nebo samozřejmě hra/-y, které byly zrovna v kursu a hrály se mockrát za den :D

Je to tak, některé verze her pro kazetu byly osekané, např. takový Jumpman měl variantu Jumpman Junior, která byla pro kazety a byla osekaná o úrovně. Ale technicky šlo i průběžně donahrávat z kazety, ja vím, že jsme takhle s bráchou hráli Gauntlet. Ale spíš se tomu tvůrci vyhýbali, už jen co si pamatuji, tak často nahrávání nové úrovně z kazety toho Gauntletu končilo zásekem hry, takže to byl pro nás i konec hry.

Jinak Německo, Československo a Polsko mělo opravdu velké zastoupení vlastníků, nadšenců a programátorů. Ale pojem "legální SW" tu asi znal málokdo. Minimálně na malém městě, natož aby u nás byla oficiální prodejna. Však hry se buď získávaly kopírováním od známých, nebo byla hromada inzerátů v Annonci a podobných, kde na vyžádání poslal inzerent seznam, člověk si zaškrtal, co chce, poslal to zpátky, a došla mu na dobírku kazeta s vybraným SW.

Těch 10 MB na kazetě je opravdu plus minus. 90 minut x 60 sekund x 3600 bitů za sekundu děleno 8 vychází na 2 430 000 bajtů, tedy kolem 2 MB.

No právě - v Pascalu se řádky skutečně číslovat nemusely Nebo spíš - pro účely překladače - přímo v kódu, ani nemohly. Ale chtělo už to mít na tom prostředí k dispozici nějaký slušný celobrázkový editor, kde by se ta vkládání a přesuny řádku daly provádět přímo při psaní kódu.
Což byl často problém i později, Jak si nemnozí vzpomenou, tak ještě v MS DOSu byl standardně přibalen edlin - řádkový editor. Který při listingu na obrazovku sám zobrazoval pořadová čísla řádků v souboru.
A právě skrze ta zobrazená pořadová čísla řádků pak programátor interními příkazy prováděl editaci souboru.
Změn řádek č. 25 na, zruš řádek 50, nebo "vlož za řádek 99 nový - a při příštím listingu se ta aktuální pořadová čísla řádků sama aktualizovala..

Dalším příkladem byl cross-assembler CAMAC, běžící na minipočítači Data General. Minipočítač přišel v roce 1981 na $100,000 (přibližně $360,000 v roce 2026). To se mohlo vyplatit bohaté společnosti s mnoha vývojáři.

Ale myslím, že tehdejší hodně nadupané IBM PC (ne AT, ne XT) s 384 KB RAM by nějaký ten cross-assembler zvládlo. Byť jen pro jednoho uživatele.