Pan Tišnovský si nevzpomněl ještě na jeden způsob šíření programů. Jak se počítače dostaly do České Televize, byly programy zejména na ZX Spectrum šířeny prostřednictvím zvukového signálu přímo z vysílaného pořadu. Zpravidla na konci pořadu vyzval uvádějící diváky, aby si připravili magnetofon na nahrávání. Poté pořad skončil a během závěrečných titulků místo hudby byl vysílán právě signál, ve kterém byl uložen daný program
Atari (~600bps) a aj Commdore (~300bps) bez Turba mali mensiu prenosovu rychlost, ako Spectrum (~1500bps).
Ak by rovnaku vec vysielali do inych pocitacov, tak by to trvalo viac ako dvojnasobny cas. Naviac, Basic na ZX je priatelskejsi na vyucbu (najma prikazov a ich syntaxe), ako na inych 8-bitoch.
Ta gumová byl už docela luxus, předchozí ZX80 a ZX81 měly membránovou, ten ZX80 dokonce vcelku se základní deskou. Ale kupodivu to ani u nich nebylo tak zlé, membráně stačil velmi lehký stisk, na dnešní PC klávesnici se nadřu víc.
Kromě toho Sinclair nebyl zdaleka první kdo tohle použil, například minipočítač Wang 2200 měl na vybranou ze dvou klávesnic, alfanumerickou pro psaní textů, a basicovou, která měla pro každý příkaz speciální klávesu, a naopak texty se musely zadávat přes shift: http://home.wxs.nl/~janvdv/images/100_6734.JPG
Také to ušetřilo nějaký ten kilobajt kódu a nebylo potřeba každý příkaz extra překládat z textu do tokenu, což se samozřejmě projevilo na rychlosti, navíc už v editačním řádku fungovala detekce syntaktických chyb, které by jinak shazovaly běžící program. Tady je programátor prostě musel opravit, protože dokud to neudělal, řádek se nemohl uložit do paměti.
A on existoval nejaky BASIC ktery zdrojak tokenizoval az za behu a teprv pak hlasil syntakticke chyby?
Treba na ATARI se sice psalo po pismenech (kdekoliv na obrazovce, na rozdil od spectra) a kdyz clovek zmackl enter teda vlastne return s kursorem na logicke radce (coz mohly byt az 3 fyzicke) tak kurozor skocil pod ne a probehl preklad. Kdyz tam byla chyba tak ji to hned vypsalo.
To melo vyhodu, protoze stacilo najet kursorem nahoru na misto chyby, prepsat to a znovu odeslat.
Tokenizace se vždycky prováděla hned po odeslání řádku. Ale to neznamená, že se provede i syntaktická analýza, ta ostatně ani "není v kompetenci" scanneru; ale když ji (částečně) prováděl, byla to vcelku příjemná vlastnost. I když u těch 8bitových implementací mluvit o scanneru a parseru asi není úplně adekvátní, lexikální analýza se obvykle prováděla "fortranským" způsobem, kdy se ignorují mezery mimo řetězce, nadbytečné znaky apod. Proto např. IF1 nebyl platný název proměnné, zatímco XY1 ano, PROMENNA=10 proběhlo bez chyby, IFPR=10THEN100 pak skočilo na řádek 100, BASIC G myslím zchroustal i PR IN T"POKUS", alternace GOTO vs. GO TO a GOSUB vs. GO SUB byla taky díky tomu běžná.
Ale třeba ten BASIC na C=64 od M$, BASIC 6 a G to měly myslím zrovna tak, pokud mě paměť neklame, totéž GW BASIC na PC, tj. napíšeš řádek, ten se sice tokenizuje, ale až při běhu se syntakticky analyzuje.
Teda koukam, ze jsem ATARI BASIC nemel rad asi nepravem, kdyz to jinde bylo takhle strasny ;)
Zkousim si predstavit jakou muze mit vyhodu delat syntaktickou analyzu az za behu ale na nic nemuzu prijit. Mozna ze je ten interpret diky tomu o neco mensi, kdyz to behem analyzy rovnou provadi.
Nějaká skrytá narážka na Malý měkký? https://en.wikipedia.org/wiki/Commodore_BASIC
Poučen z jiných diskusí si nově myslím, že bychom měli usilovat o politicky korektní a pozitivně motivovanou diskusi - ten BASIC byl prostě supakůlový a měl stejné přednosti i nedostatky jako konkurence. A pokud něco fungovalo špatně, tak jen proto, že se jim v Commodoru zkratoval drátek.
Tak nasazení BASICu bylo spíše motivováno původním záměrem, přitáhnout děti (a domácí uživatele obecně) k programování. Idea domácích osmibitových (a později i některých šestnáctibitových) byla zčásti spojena s obdobnými záměry, z nichž v současnosti vychází i Raspberry Pi. Jediným jiným pokusem byl Forth u Jupiteru Ace.
Je docela zajímavé, že i ve škole nás poměrně rychle tlačili do strojáku. BASIC opravdu jen na začátek, ale pak se jel Pascal a Assembler (na AMOSu na IQ-151). Na C64 jsem v tu dobu žádný assembler ani neměl, jen monitor strojáku v Simons' BASICu, kamarád měl na Gumáku Prométhea.
Ale tenkrát zkoušel programovat kdekdo, a to často bez jakéhokoliv odborného vedení. Z tohohle pohledu byl interpretovaný BASIC hotové požehnání. I když totiž nebyl příliš rychlý, umožňoval bezpečný a snadný vývoj, dával přístup ke grafice a zvuku, programy se snadno ladily a zdrojové kódy byl schopný procházet i normální smrtelník. To se o jakémkoliv jiném jazyce říct nedalo.
Navíc byl BASIC takhle zdarma, za ostatní vývojový software se tvrdě platilo. Jen tak z legrace třeba HiSoft C bratru za £25. Vámi zmíněný Prometheus byl sice Public Domain, ale až z roku 1993, kdy už to měla osmibitová scéna pár let za sebou a ta šestnáctibitová právě končila.
No ja mam pocit ze jim to nevyslo jen o kousek, a kdyz to zjistili tak pak pridali textove chybove hlasky misto ciselnych (schvalne kdo si pamatuje co byl ERROR 6?), protoze dalsi bezna velikost ROMky je 16 KB.
Hlavne taky soucasti MS BASICu byly rutiny pro FP cisla, kdezto ATARI BASIC vyuzival cast `OS-ROM'. Tam tyhle rutiny zabiraly 2 KB z celkovych 16 KB ROM. Samozrejme ATARI BASIC pouzival i OS rutiny pro vstup/vystup znaku apod., ale to delal MS BASIC tez.
Takze by se spis melo rikat ze ATARI BASIC byl dlouhy 10 KB a kdyz byla pomoci nejakeho HW registru jeho ROMka odpojena od sbernice (a na jejich adresach pak byla RAM) tak programy v assembleru stale mohly pouzivat ty FP rutiny.
Taky MS BASIC mel promenne pro integer cisla (v ATARI BASICu bylo vsechno float). Takze myslim ze vic featur proste zabere vic kodu -- ne ze by u MS programovali pro 6502 o tolik hur.
Celkove jsem ale rad ze v ATARI MS BASIC nakonec nebyl ;)
Tak v Atari Basicu se treba docela zajimave resily zkracene verze prikazu a to tak, ze vlastne nezabraly zadnou dalsi ROM. Dtto stringy - ty mely konstantni velikost a pouzivaly stejne subrutiny jako pole, vcetne slicingu (moc pekna ficurka, ktera umoznovala spoustu triku, treba i rychle smazani bloku pameti).
Jinak MS vydal i Atari Microsoft Basic, ale melo to nejakych >24kB, coz je tedy silene moc a navic byl pomalejsi nez genialni Turbo Basic (a rychlejsi nez original Atari Basic).
No jo, na to jsem skoro zapomel. Zkracene prikazy byl dobry napad. Mohl bys trochu rozvest jak to myslis s temi stringy a slicingem? Jako ze string byl vzdy velky N bytu? To by prece bylo plytvani ne? Ja jsem ROMku BASICu nikdy necetl a navic jsem celkem rychle presel z BASICu do assembleru (prakticky hned jak jsem ziskal ATMAS-II), takze tyhle veci vlastne nevim.
Jinak Turbo BASIC byl opravdu neco (ale myslim ze zabiral 16 KB). Zajimalo by me, jestli ta jeho rychlost pramenila z nejakeho high-level triku, treba lepsi reprezentace mezikodu, nebo jestli to bylo proste jen lip napsane. Treba OS-ROM misty vypadala jako by to byl vystup kompilatoru nejakeho vyssiho jazyka. Uz tenkrat se mi podarilo lepsim naprogramovanim zrychlit napr. kresleni usecky 10*. Pokud byl ATARI BASIC napsany stejnym stylem jako OS-ROM, tak by pak zase Turbo BASIC nebyl takovy zazrak.
S tim MS BASICem to byl odhad. Mel jsem ho sice na nejake pasce ale tu uz ted asi nenajdu tak jsem podle
http://www.pagetable.com/?p=43
usoudil ze kdyz se jim to pro Ohio Scientific veslo do 8KB (bez I/O rutin) tak by to na ATARI melo byt podobne.
Jj, stringy musely být dopředu DIMenzovány. například:
DIM A$(10)
DIM B$(10)
každý z těchto DIM si z paměti vezme 20 bajtů:
2 bajty do tabulky jmen proměnných
8 bajtů do tabulky proměnných (dimenze, délka atd.)
10 bajtů pro string
Slicing, například:
DIM A$(10)
DIM B$(10)
A$="HELLO"
B$="WORLD"
A$(5)=B$
? A$
A$(2,3)="XX"
? A$
HELLOWORLD
? A$(5,8)
OWOR
Podle mě mnohem lepší než nějaké MID$, LEFT$ a RIGHT$.
OT: Ten M$ Basic se skutečně nahrával dlouho, pocitově déle než Turbo Basic, navíc skoro nic neuměl, právě v porovnání s TB, takže těžko říct, jestli to někdo reálně používal (TB byl naproti tomu využit i v některých hrách).
Nee, Atari Basic uměl:
1) skalární floaty
2) 1D pole s floaty
3) 2D pole s floaty
4) řetězce o délce 0..32768 (což je dost :-)
Takže se to řešilo různými hacky, buď superdlouhým řetězcem + polem indexů, speciálním zakončovačem (dost naivní) nebo tím, že vždycky poslední znak řetězce měl hodnotu + 128 (velmi elegantní, takto to ostatně interně dělal i BASIC v seznamu klíčových slov).
Tak takhle nejak si to pamatuju. Nevim proc ale `konstantni velikost' jsem predim cetl jako ze vsechny stringy musi mit stejnou.
Slicing jsem mozna ani nikdy nepouzil....
Asi to melo byt tahle:
A$(2,3)="XX"
? A$
HEXXOWORLD
Diky.
Jinak ten M$BAS jsem spustil asi tak 2*, nelibil se mi, tak jsem misto toho pouzival Turbo BASIC (s upravou pro Turbo 2000 ;)
Stacilo napsat zacatek prikazu a ukoncit teckou. Takze treba L. bylo LIST
Nepamatuju se uz uplne presne jak se resily kolize slov se stejnym prefixem, bylo to nejak rozhodnuto dopredu, protoze treba LOAD byl nejspis pristupny jako LO.
Jeste to melo zkratku za PRINT a totiz `?'. Takze se dalo napsat
? 1+2
3
READY
Jo bylo to podobne, ale s tim rozdilem, ze Atari Basic proste prochazel seznam klicovych slov a kdyz to nekde matchnulo aspon na jeden znak, tak se to proste povazovalo za to klicove slovo - tj. zkratky nebyly nikde ulozeny, daly se psat zkratky od jednoho pismena az do celeho nazvu prikazu/funkce/operatoru atd.
Takže to ze seznamu vzalo první slovo které pasovalo na zkratku před tečkou, a případně se dalo napsat víc písmen pro přesné rozlišení? To je určitě jednodušší než ten Commodore, tam ty zkratky sice byly jenom dvouznakové, ale člověk si ty šifry musel pamatovat, nebo věčně koukat do tabulky. Zlatý Sinclair :)
Zkusím na příkladu, řekněme že píšeš program:
10 C.1
20 CO.1
30 COL.1
40 COLO.1
50 COLOR 1
teď dáš LIST a dostaneš:
10 COLOR 1
20 COLOR 1
30 COLOR 1
40 COLOR 1
50 COLOR 1
Důvod - Atari Basic při tokenizaci našel stejné slovo ve své tabulce a uložil příslušný (vždy stejný) token. Ihned potom "zapoměl", jak přesně zněl vstup.
Za povšimutí stojí, že je to win-win situace:
1) uživatel se míň nadře při psaní kódu
2) tokenů je omezené množství (nemusí se rozeznávat, co přesně uživatel napsal)
3) čitelnost kódu na výstupu je docela dobrá, nikdo nemusí luštit, co znamená C.1 protože to nikdy neuvidí.
Naopak:
NEW
10 PR. 1
20 PRINT 1
30 ? 1
vyLISTujeme:
10 PRINT 1
20 PRINT 1
30 ? 1
Důvod: PRINT a ? je sice de facto stejný příkaz, ale má odlišné tokeny, tudíž si Atari Basic "pamatuje", co uživatel napsal :-)
Moment, ale i to nejhorsi PCcko se dokaze samo uchladit - jinak bys ho hned letel reklamovat ze? U IQ-cka to tak nabylo a po dosazeni urcite teploty proste vyskakali svabi z patic, coz me tedy nepripadne moc normalni. Ale chapu, ze s tak mizernou soucastkovou zakladnou se zadne zazraky asi nedaly cekat...
Náhodou, bylo to super. Když jsem v 90. chodil do počítačovýho kroužku, V zimě mrzlo až ruce modraly, stačilo je dát na tři minuty cca 20cm od IQčka a byly rozmražený... :D
Akorát v létě to bylo zralý na azbestovou podložku, aby se nepropálil stolem :/ Holt nic není dokonalý.