Atari BASIC
Atari BASIC linguaggio di programmazione | |
---|---|
![]() | |
Autore | Shepardson Microsystems |
Data di origine | 1979 |
Ultima versione | Revision C (1983) |
Utilizzo | uso generico |
Paradigmi | programmazione generica |
Tipizzazione | forte |
Implementazione di riferimento | |
Licenza | software commerciale |
L'Atari BASICè uninterpretedellinguaggio di programmazioneBASICsviluppato per icomputer ad 8 bitbasati sulmicroprocessoreMOS 6502commercializzati daAtari, Inc.nei primianni ottanta.L'interprete fu inizialmente distribuito su unacartucciada 8kBdiROMe successivamente venne integrato nella memoria dei modelli XL/XLE, che lo caricavano in automatico se il computer veniva avviato senza nessuna cartuccia inserita nell'apposita porta. Ilcodice sorgentedell'Atari BASIC, completo di commenti e delle specifiche di progetto, fu pubblicato in un libro nel1983.[1]
Le origini del linguaggio
[modifica|modifica wikitesto]Da console a computer
[modifica|modifica wikitesto]I sistemi che facevano parte dellafamiglia di computer Atari ad 8 bitfurono inizialmente sviluppati comeconsole giochiper sostituire l'Atari 2600.Lo sviluppo iniziò subito dopo l'inizio della commercializzazione della console, avvenuta nel1977,la cui vita utile era stata calcolata in circa 3 anni. Durante il 1977 apparvero però sul mercato i primimicrocomputerassemblati, quali ilCommodore PET,l'Apple IIed ilRadio Shack TRS-80.Ray Kassar,che nel1978aveva assunto la presidenza della società, decise che Atari avrebbe dovuto provare ad inserirsi nel mercato dei computer domestici. Ciò comportava non solo rivedere tutti i sistemi trasformandoli in computer ma anche di dotarli del software necessario al loro uso, compreso un interprete del BASIC, il linguaggio di programmazione più diffuso fra il grande pubblico.
Il Microsoft BASIC
[modifica|modifica wikitesto]Atari si rivolse quindi alla società che all'epoca produceva l'interprete più diffuso, laMicrosoft,per acquistare la licenza del suo interpreteMicrosoft 8K BASIC.La scelta della versione ad 8 kB dell'interprete fu dettata dal fatto che leROMdi allora avevano quel taglio massimo. Atari si accorse però che il valore di 8 kB presente nel nome della versione dell'interprete fornito per leCPUMOS 6502non indicava la dimensione reale del sorgente: il Microsoft BASIC era nato sull'Intel 8080ed ilportingsu 6502 aveva fatto lievitare il codice a 9 kB.
Atari si rese poi conto che doveva espandere il linguaggio per supportare meglio le caratteristiche hardware dei propri computer, come la Apple aveva fatto con il suoApplesoft BASIC.Questo passaggio incrementò la dimensione dell'interprete fino a 11 kB. A questo problema si sommava il fatto che il sorgente per 6502 del suo interprete non era documentato, cosa che rallentava il lavoro dei programmatori.
Lo sviluppo dei computer intanto proseguì e le macchine sarebbero risultate pronte per il debutto alConsumer Electronics Show(CES) del1979.La riduzione del codice dell'interprete da 11 a 8 kB stava però dando molti problemi per cui Atari decise di rivolgersi ad un altro produttore di software.
Shepardson Microsystems
[modifica|modifica wikitesto]![](https://upload.wikimedia.org/wikipedia/commons/thumb/7/7a/Basic_computing_language_for_Atari_8-bit_computers.jpg/220px-Basic_computing_language_for_Atari_8-bit_computers.jpg)
Nel mese di settembre del1978Atari contattò laShepardson Microsystems,che aveva già scritto diversi programmi per gli Apple II (che usavano lo stesso processore dei futuri computer Atari) e che era quasi al termine della scrittura di un BASIC per i computer diCromemcobasati sulbus S-100(ilCromemco 32K Structured BASIC), incaricandola di completare il suo interprete BASIC. Shepardson esaminò il lavoro fin lì svolto e concluse che sarebbe stato più semplice riscrivere da capo un interprete che potesse risiedere in 8 kB di memoria piuttosto che cercare di terminare la riduzione di quello già esistente. Atari accettò la proposta e quando le specifiche del linguaggio furono definite, nel mese di ottobre del 1978, Paul Laughton e Kathleen O'Brien si misero al lavoro sul nuovo interprete.
L'Atari BASIC
[modifica|modifica wikitesto]Il risultato fu un interprete del tutto differente, che fu denominatoAtari BASIC.Il nuovo BASIC differiva in particolar modo nella gestione dellestringhe di caratteri:mentre il Microsoft BASIC ne consentiva la modifica, permettendo di incrementare o decrementare le loro dimensioni, l'Atari BASIC le considerava come costanti, non più modificabili.
Il contratto stipulato con Atari specificava la consegna entro il 6 aprile1979dell'interprete funzionante (ed anche di un gestore di file, che in seguito sarebbe stato noto come DOS 1.0). Per coprirsi le spalle Atari decise però di continuare a lavorare sulla riduzione del Microsoft BASIC in modo da averne una prima versione in tempo utile per il CES del 1979, mostrarlo alla fiera e poi passare all'Atari BASIC non appena questo fosse stato completato. Ma i bonus sui tempi di consegna fecero terminare a Shepardson il lavoro prima del tempo per cui Atari decise di portare al CES l'Atari BASIC, visto che era stato completato prima della conversione del Microsoft BASIC.
Versioni
[modifica|modifica wikitesto]I programmatori di Shepardson avevano lasciato nella prima versione dell'interprete alcuni problemi, e si erano prefissati di sistemarli in un secondo tempo. Ma Atari aveva già messo in fabbricazione le ROM dell'Atari BASIC e la tecnologia dell'epoca non permetteva cambi di programma. L'Atari BASIC fu perciò prodotto con deibugnoti e fu in seguito indicato comeRevision A.
- Revision A– Prima versione della cartuccia dell'Atari BASIC (8 kB di ROM). Questa versione conteneva un bug nellafunzioneche copiava la memoria: in determinate circostanze, la cancellazione delle righe del codice portava a un blocco della macchina noto come "2-line lockup".[2]
- Revision B– Corretta la maggior parte dei bug della Revision A. Durante la correzione del bug "2-line bug" i programmatori reintrodussero lo stesso errore in una funzione più comune, con il risultato che il numero di blocchi aumentò considerevolmente.[2]Questa versione fu preinstallata all'interno dei modelli 600XL e nei primi 800XLs e non fu mai distribuita sotto forma di cartuccia.
- Revision C– Eliminava i problemi di gestione della memoria della precedente Revision B. Preinstallata negli 800XLs più recenti, negli 800XLF, negli XEGS e in tutti i computer XE. La versione su cartuccia fu prodotta in piccola serie.
Un programmatore poteva sapere la versione dell'interprete in uso esaminando una precisa locazione di memoria. Il comandoPRINT PEEK(43234)
inserito al READY della macchina restituiva162
per la Revision A,96
per la Revision B e234
per la Revision C.
Caratteristiche del linguaggio
[modifica|modifica wikitesto]Editor del programma
[modifica|modifica wikitesto]L'Atari BASIC usava uneditora righe, come molti BASIC del tempo. A differenza di altri, però, esso analizzava immediatamente la riga immessa alla ricerca di errori di sintassi. Se veniveva inserito un comando sbagliato, l'editor riproponeva la riga che lo conteneva mostrando il punto in cui aveva individuato l'errore.
Quando l'interprete non stava eseguendo un programma, era nella cosiddetta "modalità immediata". Le righe inserite che iniziavano con un numero venivano considerate come righe del sorgente e memorizzate, mentre le righe che iniziavano direttamente con un comando venivano analizzate ed eseguite immediatamente.
Quando il programmatore digitava il comandoRUN
l'interprete eseguiva il programma presente in memoria. Al comando si poteva passare anche un numero di riga, ad esempioRUN 2000
,per iniziare l'esecuzione del codice da un determinato punto. Se la riga esisteva, l'esecuzione partiva da quella indicata, altrimenti dalla prima riga presente dopo quella specificata.
A differenza di altri interpreti, l'Atari BASIC permetteva di eseguire tutti i comandi sia durante l'esecuzione del sorgente che in modalità immediata. Ad esempio,LIST
,che mostrava il listato sorgente presente in memoria se inserito in modalità immediata, funzionava anche se richiamato dall'interno del programma stesso. Questo modo di interpretare i comandi era utile nel caso si fosse voluto scrivere del codice auto-modificante.
Ogni riga del programma (le "righe logiche" ) potevano occupare fino a 3 righe dello schermo (le "righe fisiche" ) da 40 caratteri ciascuna, per un totale di 120 caratteri. Il cursore poteva essere mosso liberamente all'interno di queste righe, a differenza degli editor di altri BASIC dove per andare "su" in una riga di programma bisognava per forza scorrere a sinistra finché il cursore non arrivava al bordo e proseguiva dalla fine della riga precedente dello schermo (la stessa cosa per scorrere "giù" ). Il cursore poteva essere mosso liberamente all'interno dello schermo, e se usciva da un lato ricompariva dall'altro.
L'insieme di caratteri
[modifica|modifica wikitesto]L'Atari usava un insieme di caratteri leggermente modificato rispetto alla tabellaASCII,denominataATASCII.I primi 128 caratteri corrispondevano per la maggior parte a quelli ASCII, con l'eccezione che tutti i caratteri erano stampabili, anche quelli con i codici da 0 a 31, che nella tabella ASCII non lo erano perché corrispondenti a "codici di controllo" che eseguivano operazioni particolari come ad esempio il ritorno a capo. I caratteri dal 128 al 255 erano la visualizzazione inversa dei primi caratteri da 0 a 127.
L'interprete accettava per i nomi delle variabili i caratteri maiuscoli (65-90) ed i caratteri numerici (48-57), con il nome che doveva iniziare con una lettera. I nomi delle stringhe di testo dovevano terminare con il simbolo del dollaro,$
.
L'insieme di caratteri conteneva anche i caratteri minuscoli ed alcuni caratteri grafici anche se poi la maggior parte dei linguaggi che furono resi disponibili per quei computer, compreso l'Atari BASIC, non riconoscevano i comandi scritti in lettere non maiuscole.
Nelle ROM della Revision C dell'interprete fu inserito un insieme di caratteri alternativo che comprendeva anche le lettere accentate, pensato per l'uso inEuropa.
Dato che l'insieme di caratteri era copiato in una determinata zona della memoria RAM da cui l'interprete leggeva i dati per i caratteri da stampare a video, l'utente poteva modificare tale insieme semplicemente copiando la propria mappa di caratteri sopra a quella originale (la modifica valeva solo fino allo spegnimento della macchina).
Il tokenizzatore
[modifica|modifica wikitesto]Come molti interpreti dell'epoca, anche l'Atari BASIC utilizzava untokenizzatoreche si occupava della conversione dei comandi contenuti nelle righe fisiche dalla forma estesa in cui li inseriva l'utente ad una più stringata dettatoken,che permetteva un risparmio della memoria utilizzata per contenere il programma.
Il risultato elaborato dal tokenizzatore veniva poi memorizzato in aree di memoria differenti a seconda del tipo di dato sotto forma di unpuntatorea 2 byte: i nomi delle variabili erano memorizzati in un'area dettavariable name tablementre i loro valori in un'altra zona dettavariable value table,e così via per gli altri oggetti. Una variabile non necessitava che il suo nome fosse tutte le volte che compariva nel codice memorizzato per esteso: bastava inserire il puntatore all'area di memoria appropriata. Il cambio di nome era parimenti semplice dato che bastava modificare i valori contenuti nell'area dove era memorizzato il nome per avere la modifica a livello globale.
Nel Microsoft BASIC c'erano poche forme abbreviate dei comandi, come?
perPRINT
e'
perREM
.L'Atari BASIC permetteva invece di abbreviare tutte le parole riservate semplicemente scrivendo una o più lettere della parola e poi inserendo un punto: ad esempio,L.
,LI.
eLIS.
potevano essere tutte forme brevi e valide diLIST
.Per espandere la forma abbreviata, il tokenizzatore cercava nel suo elenco di parole chiave e poi effettuava la sostituzione con la prima occorrenza trovata. L'elenco era ordinato in modo da porre in alto le abbreviazioni più corte per i comandi più comuni, così da aiutare il programmatore durante la scrittura del proprio codice: per questo motivo ".", che corrispondeva alla forma breve diREM
,era al primo posto. Questo accelerava anche il processo di analisi lessicale dato che avere le forme contratte dei comandi più comuni in cima all'elenco permetteva al tokenizzatore di risparmiarsi tutte le volte la scansione dell'intera lista. Quando il programma veniva stampato a video, il tokenizzatore riconvertiva le forme abbreviate in comandi estesi.
Altri interpreti dell'epoca avevano comandi composti da più parole separati da uno spazio, ad esempioGO TO
). L'Atari BASIC non adottava questa sintassi anche se aveva 2 eccezioni alla regola nei comandi per l'accesso alle periferiche esterne:OPEN #
ePRINT #
.
Le istruzioni di saltoGOTO
eGOSUB
permettevano l'uso di variabili al posto del numero di riga esplicitato.
Gestione delle stringhe
[modifica|modifica wikitesto]L'Atari BASIC gestiva le stringhe in maniera completamente diversa rispetto ai BASIC stile Microsoft. In questi ultimi le stringhe potevano essere di lunghezza variabile e permettevano diverse operazioni mentre l'Altair BASIC usava l'approccio delFortran,ossia le stringhe eranoarraydi caratteri la cui massima dimensione era indicata con il comandoDIM
,anche se poi la sua dimensione poteva variare durante l'esecuzione del programma tra questo valore e 0. Data una stringa, per accedere al suo intero contenuto bastava usare il nome stesso della stringa, ad esempioA$
;se invece si voleva accedere solo ad una sua parte bastava indicare tra parentesi i caratteri di inizio e fine, ad esempioA$(4,6)
prelevava i caratteri 4, 5 e 6.
Nonostante questo modo di gestione delle stringhe fosse molto elegante, comportava però dei problemi quando si dovevano portare sull'Atari BASIC programmi scritti per altri interpreti dato che non solo si dovevano considerare le istruzioniLEFT$
,RIGHT$
e simili usate dai BASIC in stile Microsoft ma anche il fatto che la dimensione di una stringa in Atari BASIC era stabilita a priori.
Input/Output
[modifica|modifica wikitesto]L'Atari BASIC supportava l'accesso al CIO (Central Input/Output), che nelsistema operativodei computer Atari si occupava dell'accesso alle periferiche diinput/output,con le parole chiaveOPEN #, CLOSE #, PRINT #, INPUT #, GET #, PUT #, NOTE #, POINT #
eXIO #
,seguiti dal numero del canale che si intendeva utilizzare. I canali che il CIO offriva erano 8, numerati da 0 a 7 ma alcuni non erano disponibili all'utente perché riservati dal sistema: il canale 0 rappresentava l'editor stesso; il canale 6 era usato per accedere allo schermo in modalità grafica; il canale 7 era utilizzato per stampare e accedere al registratore a cassette mediante i comandiLPRINT, SAVE, LOAD, CSAVE, CLOAD
.
Grafica
[modifica|modifica wikitesto]![](https://upload.wikimedia.org/wikipedia/commons/thumb/8/84/Atari-gr2-sl.png/220px-Atari-gr2-sl.png)
I computer Atari ad 8 bit avevano un sofisticato sistema di gestione della grafica dovuto all'uso di appositi chip, l'ANTICed ilCTIA:ciò perché originariamente i computer erano stati progettati per essere console giochi. Grazie ai 2 chip il sistema offriva diverse modalità grafiche ed era presente anche il supporto aglisprite.
Purtroppo l'Atari BASIC non metteva a disposizione comandi per gestire direttamente gli sprite ma ciò era comunque fattibile mediante l'uso diPEEK e POKEcon cui leggere e scrivere direttamente nei registri del CTIA. Il risultato non era però dei migliori perché il chip grafico supportava lo scorrimento orizzontale degli sprite ma non quello verticale per cui usando l'Atari BASIC, che era molto lento nello spostamento di blocchi di dati in memoria, nel caso di scorrimenti verticali si ottenevano prestazioni scarse. Per gestire questo problema i programmatori ricorrevano ad un paio di trucchi: usavano piccole funzioni scritte direttamente inlinguaggio macchinaoppure memorizzavano i dati degli sprite in stringhe e poi usavano le funzioni di copia delle stringhe, che erano funzioni in linguaggio macchina e quindi eseguite molto velocemente.
I comandi per gestire la grafica erano:COLOR
,SETCOLOR
,CLEAR
,PLOT
,DRAWTO
,LOCATE
eGRAPHICS
.Mancava un comandoFILL
per riempire una determinata area con un colore, strana mancanza dato che il sistema operativo aveva una funzione per eseguire questa operazione.
Prestazioni
[modifica|modifica wikitesto]Se paragonato ad altri interpreti preinstallati su computer similari dell'epoca, l'Atari BASIC risultava estremamente lento, specialmente se si considera che il MOS 6502 operava ad una frequenza quasi doppia rispetto agli altri sistemi. La maggior parte di questi problemi di lentezza derivava da diversi motivi che traevano origine dalla natura stessa del codice e del sistema.
Il primo motivo era che l'Atari BASIC poteva usare variabili al posto dei numeri di riga nelle istruzioni di saltoGOTO
eGOSUB
,e ciò comportava un aggravio di calcoli nella funzione di ricerca del numero di riga. Inoltre l'interprete non generava un errore nel caso la riga indicata non esistesse ma l'esecuzione proseguiva alla riga immediatamente successiva. Questo comportamento veniva adottato per implementare il comportamento diNEXT
nel cicloFOR
...NEXT
,rallentandone l'esecuzione.
Il secondo motivo risiedeva nel fatto che l'Atari BASIC non gestiva nativamente i numeri interi: tutti i numeri, anche i numeri di riga, erano numeri in virgola mobile per cui un'operazione con numeri interi vedeva eseguita continuamente la conversione da intero a virgola mobile e viceversa. Questo perché l'Atari BASIC si appoggiava alle funzioni di gestione dei numeri in virgola mobile predefinite all'interno del sistema operativo del computer, che oltretutto usavano la notazioneBCDper la memorizzazione dei numeri per via del fatto che la CPU supportava nativamente tale formato.
Col tempo diversi produttori misero in commercio interpreti BASIC alternativi con prestazioni da 3 a 5 volte superiori rispetto a quelle dell'Atari BASIC. Anche la stessa Atari rilasciò il BASIC che aveva iniziato a sviluppare sulla base del Microsoft BASIC, l'Atari Microsoft BASIC,che aveva prestazioni superiori ma che non era compatibile con l'Atari BASIC.
Note
[modifica|modifica wikitesto]- ^Bill Wilkinson,The Atari BASIC Source Book,Compute! Books, 1983,ISBN0-942386-15-9.
- ^ab(EN)Atari BASIC Bugs(JPG), inCompute!,n. 74, Greensboro, Compute! Publications, luglio 1986, p. 16,ISSN0194-357X .
Bibliografia
[modifica|modifica wikitesto]- Atari 400-800 - Manuale di riferimento del linguaggio Basic per l'elaboratore personale Atari,Atari, 1982.
- Atari BASIC - Manuale d'uso,Atari, 1983.
- Bill Carris,Basic Atari,Gruppo Editoriale Jackson, 1985.
- Gary Ryan, Cliff McConnell,Altri giochi per il vostro Atari,Gremese Editore, 1985,ISBN88-7605-153-8.
- Bill Wilkinson,The Atari BASIC Source Book,COMPUTE! Books, 1983,ISBN0-942386-15-9.URL consultato il 5 agosto 2012(archiviato dall'url originaleil 26 luglio 2012).
- Bill Wilkinson,Inside Atari DOS,COMPUTE! Books, 1982,ISBN0-942386-02-7.URL consultato il 5 agosto 2012.
- Chris Crawford et al.,10: ATARI BASIC,inDe Re Atari,1982.URL consultato il 5 agosto 2012.
- Bob Albrecht, LeRoy Finkel, Jerald R. Brown,Atari Basic - A Self-Teaching Guide,Wiley Microcomputer Guides, 1979.URL consultato il 5 agosto 2012.
- Bob Albrecht, LeRoy Finkel, Jerald R. Brown,Atari Basic - XL Edition,1985.URL consultato il 5 agosto 2012.
Voci correlate
[modifica|modifica wikitesto]Collegamenti esterni
[modifica|modifica wikitesto]- XFormer, un emulatore Atari per MS-DOS e Windows,suemulators.
- De Re Atari,un manuale sui computer Atari