Atari BASIC

Atari BASIC linguaggio di programmazione
L'editor dell'Atari BASIC
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
Modifica dati su Wikidata · Manuale

L'Atari BASIC è un interprete del linguaggio di programmazione BASIC sviluppato per i computer ad 8 bit basati sul microprocessore MOS 6502 commercializzati da Atari, Inc. nei primi anni ottanta. L'interprete fu inizialmente distribuito su una cartuccia da 8 kB di ROM e 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. Il codice sorgente dell'Atari BASIC, completo di commenti e delle specifiche di progetto, fu pubblicato in un libro nel 1983.^[1]

I sistemi che facevano parte della famiglia di computer Atari ad 8 bit furono inizialmente sviluppati come console giochi per sostituire l'Atari 2600. Lo sviluppo iniziò subito dopo l'inizio della commercializzazione della console, avvenuta nel 1977, la cui vita utile era stata calcolata in circa 3 anni. Durante il 1977 apparvero però sul mercato i primi microcomputer assemblati, quali il Commodore PET, l'Apple II ed il Radio Shack TRS-80. Ray Kassar, che nel 1978 aveva 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.

Lo stesso argomento in dettaglio: Atari Microsoft BASIC.

Atari si rivolse quindi alla società che all'epoca produceva l'interprete più diffuso, la Microsoft, per acquistare la licenza del suo interprete Microsoft 8K BASIC. La scelta della versione ad 8 kB dell'interprete fu dettata dal fatto che le ROM di allora avevano quel taglio massimo. Atari si accorse però che il valore di 8 kB presente nel nome della versione dell'interprete fornito per le CPU MOS 6502 non indicava la dimensione reale del sorgente: il Microsoft BASIC era nato sull'Intel 8080 ed il porting su 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 suo Applesoft 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 al Consumer Electronics Show (CES) del 1979. 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.

Nel mese di settembre del 1978 Atari contattò la Shepardson 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 di Cromemco basati sul bus S-100 (il Cromemco 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.

Il risultato fu un interprete del tutto differente, che fu denominato Atari BASIC. Il nuovo BASIC differiva in particolar modo nella gestione delle stringhe 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 aprile 1979 dell'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.

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 dei bug noti e fu in seguito indicato come Revision A.

• Revision A – Prima versione della cartuccia dell'Atari BASIC (8 kB di ROM). Questa versione conteneva un bug nella funzione che 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 comando PRINT PEEK(43234) inserito al READY della macchina restituiva 162 per la Revision A, 96 per la Revision B e 234 per la Revision C.

L'Atari BASIC usava un editor a 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 comando RUN l'interprete eseguiva il programma presente in memoria. Al comando si poteva passare anche un numero di riga, ad esempio RUN 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'Atari usava un insieme di caratteri leggermente modificato rispetto alla tabella ASCII, denominata ATASCII. 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 in Europa.

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).

Come molti interpreti dell'epoca, anche l'Atari BASIC utilizzava un tokenizzatore che si occupava della conversione dei comandi contenuti nelle righe fisiche dalla forma estesa in cui li inseriva l'utente ad una più stringata detta token, 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 un puntatore a 2 byte: i nomi delle variabili erano memorizzati in un'area detta variable name table mentre i loro valori in un'altra zona detta variable 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 ? per PRINT e ' per REM. 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. e LIS. potevano essere tutte forme brevi e valide di LIST. 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 di REM, 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 esempio GO TO). L'Atari BASIC non adottava questa sintassi anche se aveva 2 eccezioni alla regola nei comandi per l'accesso alle periferiche esterne: OPEN # e PRINT #.

Le istruzioni di salto GOTO e GOSUB permettevano l'uso di variabili al posto del numero di riga esplicitato.

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 del Fortran, ossia le stringhe erano array di caratteri la cui massima dimensione era indicata con il comando DIM, 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 esempio A$; se invece si voleva accedere solo ad una sua parte bastava indicare tra parentesi i caratteri di inizio e fine, ad esempio A$(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 istruzioni LEFT$, 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.

L'Atari BASIC supportava l'accesso al CIO (Central Input/Output), che nel sistema operativo dei computer Atari si occupava dell'accesso alle periferiche di input/output, con le parole chiave OPEN #, CLOSE #, PRINT #, INPUT #, GET #, PUT #, NOTE #, POINT # e XIO #, 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 comandi LPRINT, SAVE, LOAD, CSAVE, CLOAD.

Lo stesso argomento in dettaglio: ANTIC.

I computer Atari ad 8 bit avevano un sofisticato sistema di gestione della grafica dovuto all'uso di appositi chip, l'ANTIC ed il CTIA: 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 agli sprite.

Purtroppo l'Atari BASIC non metteva a disposizione comandi per gestire direttamente gli sprite ma ciò era comunque fattibile mediante l'uso di PEEK e POKE con 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 in linguaggio macchina oppure 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 e GRAPHICS. Mancava un comando FILL per riempire una determinata area con un colore, strana mancanza dato che il sistema operativo aveva una funzione per eseguire questa operazione.

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 salto GOTO e GOSUB, 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 di NEXT nel ciclo FOR...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 notazione BCD per 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.

• 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, ISBN 88-7605-153-8.
• Bill Wilkinson, The Atari BASIC Source Book, COMPUTE! Books, 1983, ISBN 0-942386-15-9. URL consultato il 5 agosto 2012 (archiviato dall'url originale il 26 luglio 2012).
• Bill Wilkinson, Inside Atari DOS, COMPUTE! Books, 1982, ISBN 0-942386-02-7. URL consultato il 5 agosto 2012.
• Chris Crawford et al., 10: ATARI BASIC, in De 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.

• Atari
• BASIC

• Wikimedia Commons contiene immagini o altri file su Atari BASIC

• XFormer, un emulatore Atari per MS-DOS e Windows, su emulators.com.
• De Re Atari, un manuale sui computer Atari

V · D · M Atari
Console	PONG · Atari 2600 · Atari Cosmos · Atari 5200 · Atari 7800 · Atari Lynx · Atari Jaguar (Jaguar CD)
Computer	Atari 8-bit (periferiche) · Atari ST · Atari Falcon030
Hardware e software	Atari BASIC · Atari Microsoft BASIC · MOS 6507 · Television Interface Adaptor · ANTIC · CTIA e GTIA · Atari POKEY · Atari MMU · Atari FREDDIE · EMMU · Porta joystick Atari
Giochi	per Atari 2600 · per Atari 5200 · per Atari 7800 · per Atari Jaguar · per Atari 8-bit · per Atari ST · per Atari Lynx
Società	Atari, Inc. · Atari Games · Atari Corporation · Atari Interactive · Atari, Inc. (gruppo Atari SA) · Atari SA · Tengen · Kee Games · JT Storage
Persone	Nolan Bushnell · Ted Dabney · Jack Tramiel · Howard Scott Warshaw · Allan Alcorn · Lyle Rains · Ed Logg · Dona Bailey · Ray Kassar
Voci correlate	Sepoltura dei videogiochi Atari · Crisi dei videogiochi del 1983

Portale Informatica: accedi alle voci di Wikipedia che trattano di informatica