Ready64 Forum
Commodore 64 => Programmazione, Grafica e Musica => Topic aperto da: infocalimero - 05 Gennaio 2013, 12:17:06
-
Dopo molto tempo mi sono deciso a ampliare un mio vecchio tutorial riguardante la programmazione C64 in linguaggio macchina per mezzo del comando DATA:
E' incredibile quanto sia semplice la programmazione del mitico Commodore 64 usando codici macchina. E' virtualmente possibile realizzare qualsiasi cosa con pochissimi byte... Seguono alcuni argomenti:
-Rudimenti e basi con esempi in LM
-Gestione sprite sia multi color che non ed animazione
-Disegno caratteri e animazione
-Accesso a svariate routine kernal(scoll, posizionamento cursore, random, input...)
-Gestione della pagina grafica
-Suono
-Salvataggio e caricamento dei programmi lm
-Altro ed altro...
Mi scuso per eventuali bug, che appena avrò il tempo correggerò... Questo della programmazione in LM è diventato un pò il mio hobby nei tempi morti durante i periodi di vacanza. :D
Trovate tutto qui: Link (http://www.bertinettobartolomeodavide.it/programmazione/commodore64/PROGRAMMAZIONE%20LINGUAGGIO%20MACCHINA%20COMMODORE%2064.html)
Ciao e spero che sia utile a qualcuno :lol:
Davide
Corretto titolo del thread. -eregil
-
Forse dovresti aggiornare anche il file pdf che include tutti i tutorial.
Comunque questo approccio potrebbe risultare "traumatico" per il neofita, gli assemblatori rendono la cosa più semplice.
Comunque sia programmare a basso livello, sebbene sia incredibilmente affascinante, alla lunga potrebbe essere anche frustrante soprattutto in caso di bugs che non si riusciranno mai a risolvere (tu stesso ametti che ce ne potrebbero essere nei tuoi esempi).
Ci sono degli ottimi compilatori del codice basic che rendono l'applicazione un misto codice macchina/codice basic oppure solo codica macchina che ne migliorano notevolmente le performance generali, anche di parecchio.
All'epoca erano molto usati, molti giochi sono stati fatti così.
Comunque grazie, perchè da che ho visto io in giro di tutorial così non ne ho trovati!
Saluti!
-
Interessante sito, ma IMHO, per imparare qualcosa forse e' meglio un codice testuale scritto in assembler piuttosto che una serie di DATA in coda ad un programma basic.
Aggiungo che oggi giorno se non si vuole per forza utilizzare un c64 reale, si puo' utilizzare editor (preferito), compiltore cc65 (c e asm) e vice (quando possibile) per testare le applicazioni.
Vedere questo come esempio: http://www.pagetable.com/?p=568 (http://www.pagetable.com/?p=568)
ciao e grazie
-
Si è vero al prossimo colpo aggiornerò anche il pdf. Spero di riuscirci presto. Prima però devo riverificare tutti i codici ed inserirli su un immagine d64...
E' vero esistono molte soluzioni probabilmente migliori. Ma il linguaggio macchina inserito dal basic è stato uno dei primi amori/misteri della programmazione di quando ero piccolo ed ora mi piace giocarci...
:P
-
@infocalimero: non e' che voglia sminuire il tuo lavoro, anzi. Probabilmente al tempo era una soluzione rapida e semplice.
Oggi sarebbe bello vedere i tuoi studi in altra forma.
Magari avendoci smanettato ti ricordi il codice macchina associato al mnemonico di ogni istruzione del 6502. Beato te :)
ciao
-
Magari avendoci smanettato ti ricordi il codice macchina associato al mnemonico di ogni istruzione del 6502.
Non ci credo nemmeno se lo vedessi con i miei occhi recitare tutti i mnemonici e relativi codici macchina come se recitasse la Divina Commedia...
-
Ma no ci mancherebbe, sarebbe impossibile memorizzarli tutti e non servirebbe, anche se alla fine lavorandoci un pochino alla fine si usano per lo più sempre gli stessi comandi... In ogni caso e bene annotarli su un bloc notes come promemoria. Questo però, anche se in misura minore, avviene pure per l'assembly(almeno per me).
Trovo comunque fantastica la possibilità afferta dal c64 di accenderlo e attraverso un linguaggio di alto livello come il basic, riusciere ad impartire interi codici in basso livello come col linguaggio macchina, senza alcuno strumento aggiuntivo. Per l'assembly invece serve un software aggiuntivo.
Con un opportuna organizzazione non è così difficile programmare in linguaggio macchina con il comando DATA del basic. E' per esempio possibile per facilitarne la comprensione inserire ogni codice, seguito dagli operandi in ogni linea. Oppure lasciare uno spazio tra il codice e gli operandi. Soluzioni semplici con questa tecnica di programmazione ne esistono moltissime.
;)
-
Ma no ci mancherebbe, sarebbe impossibile memorizzarli tutti e non servirebbe, anche se alla fine lavorandoci un pochino alla fine si usano per lo più sempre gli stessi comandi... In ogni caso e bene annotarli su un bloc notes come promemoria. Questo però, anche se in misura minore, avviene pure per l'assembly(almeno per me).
Trovo comunque fantastica la possibilità afferta dal c64 di accenderlo e attraverso un linguaggio di alto livello come il basic, riusciere ad impartire interi codici in basso livello come col linguaggio macchina, senza alcuno strumento aggiuntivo. Per l'assembly invece serve un software aggiuntivo.
Con un opportuna organizzazione non è così difficile programmare in linguaggio macchina con il comando DATA del basic. E' per esempio possibile per facilitarne la comprensione inserire ogni codice, seguito dagli operandi in ogni linea. Oppure lasciare uno spazio tra il codice e gli operandi. Soluzioni semplici con questa tecnica di programmazione ne esistono moltissime.
;)
Il software aggiuntivo che tu citi è un assemblatore, e cioè un software che traduce un listato in assembly direttamente nel codice macchina, e cioè, in altre parole, un software che esegue in automatico quello che tu fai "a manella" quando "dissimuli" codice macchina nei DATA di un listato basic.
I progettisti del C64, invece dell'interprete basic in ROM avrebbero potuto mettere un interprete assembly, e nulla sarebbe cambiato, nel senso che il C64 sarebbe stato comunque il C64... dal punto di vista dell'utente invece le cose sarebbero state molto più complicate e l'acquisto della macchina sarebbe risultato meno appetibile al consumatore finale.
In linguaggi più evoluti, per esempio nel llinguaggio C, è possibile inserire codice assembly direttamente a livello di sorgente. La verità è che la scelta del BASIC fu quasi obbligata, in quanto è un linguaggio semplicissimo. Ma la sua semplicità, specie parlando del basic V2 che è quello del C64, non permette nemmeno lontamente una sufficiente modularità nel codice. Il risultato è che i listati BASIC V2 sono un qualcosa di spaventoso da un punto di vista informatico, aivoglia a dire "ma io programmo bene!"... è il linguaggio stesso che non permette una buona tecnica di programmazione.
Veniamo alla semplicità dell'assembly. L'assembly altro non è che la traduzione in linguaggio simbolico del codice macchina del calcolatore più le routine del kernel (Il sistema operativo del C64). Questo è vero per ogni computer, anche per quelli moderni. L'assembly del C64 risulta semplice perché l'hardware del C64 è semplice, e tale semplicità si riflette sul fatto che le cose che un C64 può fare sono "cose semplici", forse appetibili per gli utenti base fino a 30-40 anni fa, ma oggi sarebbe una macchina del tutto inutile... tutto qui. In altre architetture, multiutente, multiprogrammabili con CPU a 16, 32 e 64 bit e così via, l'assembly non è per niente semplice, anzi, in ultima analisi è quasi impossibile da gestire senza l'ausilio di ottimi strumenti software che vanno ben oltre il buon "MacroAssembler" della commodore. Il risultato è che quasi sempre, anche per compiti a basso livello quali la programmazione di un controllore per unità esterna (p.es. un lettore floppy disk, o lettore DVD) ci si appoggia sempre ad un linguaggio ad alto livello come il C... ma ce ne sono tantissimi altri.
Voglio fare un altro esempio... all'epoca c'era un'altra CPU per computer di basso livello, e questa era lo Z80. L'assembler dello Z80 è già un po' più complicato dell'assembler del 6502... se poi si passa di livello, abbiamo il famoso 8086. Ecco, l'assembler dell'8086, già è qualcosa di molto-molto più complicato, tra registri dedicati e altre istruzioni potentissime... pensa ora cosa può essere l'assembler di un moderno i7!
-
@macchia71, fai polemiche inutili sminuendo e criticando quanto gentilmente offerto dal nostro amico @infocalimero, il quale ben sottoliena la "potenzialità" offerta dallo scarno basic v2 del c64 che, con pochi e relativamente semplici istruzioni, permette di interagire a basso livello sul nostro amato computer senza la rogna di dover caricare in memoria un assemblatore (ovvero una sorta di traduttore uomo-macchina) e consentendo in questo modo di avere liberi e disponibili tutti i nostri 38 e rutti kb senza preoccuparsi, in caso di errore, di sovrascrivere l'assemblatore stesso, con tutto ciò che ne potrebbe derivare.
E poi, nononstante i suoi 8 miseri bit e il suo unico mhz, il 6510, anche grazie alla sua semplicità, programmato a basso livello il software risultava molto performante a differenza dei primi intel 16bit programmati con linguaggi ad alto livello tipo C o GWBasic. Io me lo ricordo benissimo, i programmi che facevo sul mio 8086 in GWbasic e C risultavano, se non più lenti comunque paragonabili in termini di performance generali, anzi, a dire il vero programmi di grafica mi risultavano più lenti, non erano a colori e poi non mi permetteva di fare musica, visto che non aveva niente di definibile quale un chip audio.
Pagato quasi il doppio del C64 alla fine non era molto meglio nonostante i suoi ben 5mhz e la bellezza di 512kb di RAM.
Il successo del C64 è dipeso anche da questo: le performace delle applicazioni non sono solo legate all'hardware in se stesso ma anche (e sottolinerei, soprattutto) alla qualità del software e al modo in cui lo si scrive. Il fatto di avere un piccolo e semplice processore ad 8bit e 1mhz di frequenza è stato, paradossalmente, il suo punto di forza inquanto permetteva, vista la sua semplicità, di essere programmato a basso livello e quindi di poter alla fine sviluppare software "veloce" e "potente" a differenza di computer concorrenti equipaggiati con processori più veloci ma anche più "complessi".
Qualche tempo fa feci dei test tra il C64, l'Amstrad CPCe l'ultimo Spectrum apparso sul mercato (nato dalla fusione tra Amstrad e Spectrum);
ebbene, nonostante questi ultimi fossero equipaggiati con processori Zilog più veloci, da alcuni test che ho fatto il C64 è risultato vincitore nonostante il suo unico mhz. Ciò significa che era progettato meglio e che gli strumenti di sviluppo che offriva erano migliori, per questo divenne ben presto il preferito dai programmatori e di conseguenza anche dai semplci "consumatori" di software.
L'approccio che noi oggi abbiamo con i computer è stato dettato nel corso degli anni "solo" da logiche commerciali: se un computer è più veloce e più potente va meglio. In un periodo in cui ogni anno ne venivano sfornati sempre di nuovi e di più potenti, tutto questo ha fatto la fortuna dei vari intel, ibm, microsoft, etc......(e aggiungerei anche dei cinesi). Ovviamanente non è così e il Commodore 64 lo dimostra. Un buon 60-80% delle performance sono date dalla qualità del software. Ciò spiega le differenze che ci sono tra lo stesso computer in cui vi sono installati due differenti sistemi operativi: chi si ricorda Windows ME? Bhe, io ne ho un pessimo ricordo; e per non parlare di Windows VISTA. Non so se qualcuno di voi lo usa (o lo ha usato) ma la mia esperienza con esso è durata solo pochi minuti, il tempo di dargli un'occhiata, formattare l'HD e metterci su Windows XP.
Tutto ciò, quindi, dimostra esattamente il contrario: le performance generali di una macchina sono date dal giusto equilibrio software/hardware; la qualità del software è essenziale per poter sfruttare appieno le caratteristiche dell'hardware e il c64 questo lo permetteva appieno; oserei dire che è stato l'unico caso nella (ormai) lunga storia dell'informatica.
-
@macchia71, fai polemiche inutili sminuendo e criticando quanto gentilmente offerto dal nostro amico @infocalimero, il quale ben sottoliena la "potenzialità" offerta dallo scarno basic v2 del c64 che, con pochi e relativamente semplici istruzioni, permette di interagire a basso livello sul nostro amato computer senza la rogna di dover caricare in memoria un assemblatore (ovvero una sorta di traduttore uomo-macchina) e consentendo in questo modo di avere liberi e disponibili tutti i nostri 38 e rutti kb senza preoccuparsi, in caso di errore, di sovrascrivere l'assemblatore stesso, con tutto ciò che ne potrebbe derivare.
Mi dispiace ma anch'io credo che sia oggettivamente insensato fare esperimenti di linguaggio macchina in questo modo, soprattutto ora che ci sono cross-assembler e strumenti comodissimi per scambiare velocemente dati tra C64 e PC.
Usare il Basic con i data, scrivere numeri al posto dei codici mnemonici, essere obbligati al sistema decimale, dover calcolare gli indirizzi per le istruzioni di salto sono tutti fattori che fanno aumentare esponenzialmente il rischio di commettere errori, il che può anche comportare la sovrascrittura del programma Basic stesso. Che cosa ti fa pensare che l'assembler possa essere sovrascritto e il Basic no?
Questo sistema andava bene quando c'era bisogno di realizzare operazioni molto specifiche, una tantum, come ad esempio un cheat per un gioco, quando la maggior parte degli utenti non aveva altro che il Basic. L'esperto di linguaggio macchina escogitava il suo hack e poi lo traduceva in un programma Basic in modo che, una volta pubblicato su una rivista, fosse fruibile da tutti. Non va bene per sperimentare la programmazione a basso livello.
E poi, nononstante i suoi 8 miseri bit e il suo unico mhz, il 6510, anche grazie alla sua semplicità, programmato a basso livello il software risultava molto performante a differenza dei primi intel 16bit programmati con linguaggi ad alto livello tipo C o GWBasic. Io me lo ricordo benissimo, i programmi che facevo sul mio 8086 in GWbasic e C risultavano, se non più lenti comunque paragonabili in termini di performance generali, anzi, a dire il vero programmi di grafica mi risultavano più lenti, non erano a colori e poi non mi permetteva di fare musica, visto che non aveva niente di definibile quale un chip audio.
Pagato quasi il doppio del C64 alla fine non era molto meglio nonostante i suoi ben 5mhz e la bellezza di 512kb di RAM.
Sicuro che fosse molto meglio? I programmi di grafica che realizzavi in C e GWBasic sul tuo 8086 saresti riuscito a farli altrettanto facilmente in linguaggio macchina sul C64, in 64K di memoria? I linguaggi evoluti sono stati inventati per semplificare e velocizzare la scrittura di applicazioni a scapito delle prestazioni (soprattutto velocità e consumo di memoria). Il confronto che hai fatto tu è come dire "La Fiat 126 in quarta è più veloce dell'Alfa 33 in prima, quindi è molto meglio".
Il successo del C64 è dipeso anche da questo: le performace delle applicazioni non sono solo legate all'hardware in se stesso ma anche (e sottolinerei, soprattutto) alla qualità del software e al modo in cui lo si scrive. Il fatto di avere un piccolo e semplice processore ad 8bit e 1mhz di frequenza è stato, paradossalmente, il suo punto di forza inquanto permetteva, vista la sua semplicità, di essere programmato a basso livello e quindi di poter alla fine sviluppare software "veloce" e "potente" a differenza di computer concorrenti equipaggiati con processori più veloci ma anche più "complessi".
Non è che sul 64 "potevi" programmare a basso livello, eri obbligato a farlo se volevi ottenere prestazioni dignitose. Tutti i processori possono essere programmati a basso livello. E anche se questa metodica, con gli anni, è stata adottata sempre meno, rimanendo relegata in ambiti particolari (ma non per questo di scarsa importanza), i processori più complessi hanno impiegato pochissimo tempo a raggiungere una potenza tale da surclassare un 6502 anche quando programmati in linguaggi evoluti.
Qualche tempo fa feci dei test tra il C64, l'Amstrad CPCe l'ultimo Spectrum apparso sul mercato (nato dalla fusione tra Amstrad e Spectrum);
ebbene, nonostante questi ultimi fossero equipaggiati con processori Zilog più veloci, da alcuni test che ho fatto il C64 è risultato vincitore nonostante il suo unico mhz. Ciò significa che era progettato meglio e che gli strumenti di sviluppo che offriva erano migliori, per questo divenne ben presto il preferito dai programmatori e di conseguenza anche dai semplci "consumatori" di software.
Sono macchine diverse. Non puoi fare confronti di benchmark tra architetture così distanti. Troverai sempre delle operazioni che su un sistema saranno eseguite più in fretta e operazioni che saranno più veloci su un altro.
Tutto ciò, quindi, dimostra esattamente il contrario: le performance generali di una macchina sono date dal giusto equilibrio software/hardware; la qualità del software è essenziale per poter sfruttare appieno le caratteristiche dell'hardware e il c64 questo lo permetteva appieno; oserei dire che è stato l'unico caso nella (ormai) lunga storia dell'informatica.
Lo permetteva perché era capillarmente diffuso ed ha avuto una longevità commerciale straordinaria. Il fatto che per così tanti anni ci fossero centinaia di migliaia, milioni di macchine tutte funzionalmente identiche, ha fatto sì che si continuasse a produrre software anche quando il sistema era oggettivamente superato, portando questo software a livelli qualitativi unici, in proporzione alle potenzialità del computer.
-
Bè mi pare di capire che ci sono varie correnti di pensiero... ;)
Si senza dubbio quella del linguaggio macchina è sicuramente da via meno versatile. In ogni caso è bello sapere che è possibile farlo impartendo codici macchina direttamente dal basic senza aggiungere null'altro... Inoltre su tutte le riviste dell'epoca erano mooolto più diffusi i listali basic con codici DATA in linguaggio macchina e ben pochi in assembler. Anche perche scrivere in assembler presenta delle minime differenze a senconda del compilatore usato, mentre il codice macchina è solo uno....
Credo comunque che citare altri linguaggi sia del tutto fuori luogo visto che si tratta di ambiti di programmazione completamente differenti. Tantomedo meno citare la moderna realtà dell'informatica in cui nessuno(o quasi) usa più il linguaggio macchina e nemmeno l'assembler, per ovvi motivi...
Molti programmatori di oggi non hanno la minima idea di come funziona un micropocessore. Il linguaggio macchina ti 'spiega' il funzionamento nell'atto pratico, come del resto anche l'assembler.
Credo che comunque si tratti di un discorso senza uscita, visto che esistono varie strade per ottenere il medesimo risultato.
-
Che cosa ti fa pensare che l'assembler possa essere sovrascritto e il Basic no?
Usare un assembler, magari scritto in basic, aumenta di molto la probabilità di sovrascrivere sia lui sia il basic stesso, per cui sarebbe preferibile la soluzione "solo basic".
Sicuro che fosse molto meglio? I programmi di grafica che realizzavi in C e GWBasic sul tuo 8086 saresti riuscito a farli altrettanto facilmente in linguaggio macchina sul C64, in 64K di memoria?
Si, ci riuscivo altrettanto facilmente, me lo ricordo come se fosse ieri. Conoscevo bene il c64 e a livello di prestazioni erano paragonabili coll'IBM compatibile; il tempo che impiegava il c64 a riempire lo schermo di grafici complessi era lo stesso di quello impiegato dall'8086, ne più e ne meno, con la differenza che con il commodore 64 li facevo anche belli e colorati.
I linguaggi evoluti sono stati inventati per semplificare e velocizzare la scrittura di applicazioni a scapito delle prestazioni (soprattutto velocità e consumo di memoria).
Sul commodore, come ho fatto presente in precedenza, c'era anche la possibilità di "compilare" il codice basic; era un buon compromesso tra la flessibilità e la chiarezza del linguaggio ad alto livello e la velocità e le prestazioni dell'applicativo a basso livello. Analogamente c'erano soluzioni di sorta che includevano la possibilità di usare altri linguaggi evoluti come il C o il Pascal, anche se le prestazioni, per ovii motivi, ne risentivano maggiormente.
Il confronto che hai fatto tu è come dire "La Fiat 126 in quarta è più veloce dell'Alfa 33 in prima, quindi è molto meglio".
Putroppo quell'Alfa 33 non aveva che una o al massimo due marce, l'utilizzo di marce maggiori era un soluzione inutile ed impraticabile: un motore "potente" ma male gestibile dal pilota.
Non è che sul 64 "potevi" programmare a basso livello, eri obbligato a farlo se volevi ottenere prestazioni dignitose. Tutti i processori possono essere programmati a basso livello. E anche se questa metodica, con gli anni, è stata adottata sempre meno, rimanendo relegata in ambiti particolari (ma non per questo di scarsa importanza),
Il C64 è stato fatto appositamente per potere essere programmato così: era la soluzione più economica e la migliore per ottenere prestazioni (all'epoca) da favola. E poi non è che questa tecnica si è addottata sempre meno col tempo, e che è diventata sempre più impraticabile a causa della maggiore complessità dei processori.
i processori più complessi hanno impiegato pochissimo tempo a raggiungere una potenza tale da surclassare un 6502 anche quando programmati in linguaggi evoluti.
si ma erano molto più costosi e già prima del 6502/6510 esistevano processori molto più veloci e potenti. Solo quando i cinesi hanno cominciato a produrli in grande quantità che i loro prezzi sono calati.
Sono macchine diverse. Non puoi fare confronti di benchmark tra architetture così distanti. Troverai sempre delle operazioni che su un sistema saranno eseguite più in fretta e operazioni che saranno più veloci su un altro.
Erano destinate allo stesso tipo di utente finale; avevano lo stesso target di mercato; non erano affato diverse, quindi.
Lo permetteva perché era capillarmente diffuso ed ha avuto una longevità commerciale straordinaria. Il fatto che per così tanti anni ci fossero centinaia di migliaia, milioni di macchine tutte funzionalmente identiche, ha fatto sì che si continuasse a produrre software anche quando il sistema era oggettivamente superato, portando questo software a livelli qualitativi unici, in proporzione alle potenzialità del computer.
All'inizio degli anni ottanta la concorrenza tra produttori di computer, in un mercato che andava via via nascendo in quel periodo, era molto più grande di oggi, dove in tutto il mondo a momenti ci sono più computer che persone.
Progettare una macchina che fosse abbordabile ecomicamente e con caratteristiche tali da poter attrarre sviluppatori software, era la chiave del successo. Chi riusciva in questo, risultava vincitore. Ebbene ci riuscì il Commodore 64, in questo non vi è alcun dubbio. E prima che IBM andasse ad arruffianarsi coi cinesi è stato indubbiamente il miglior computer in circolazione a livello consumer.
Comunque sia il nostro amico @infocalimero non sta obbligando nessuno a usare le sue metodiche di programmazione, vuole solo fare presente che "esite, tra le tante, anche questa possibilità". Tutto qui. Non vi è alcun bisogno di criticarlo nell'iniziativa, magari a qualcuno il suo tutorial può fare comodo.
-
A me sembra che si ignori volutamente una spiegazione molto semplice: degli applicativi software, realizzati con tutti gli strumenti del caso che fossero di ausilio alla programmazione (compreso quindi un buon assembler), venivano poi distribuiti sotto forma di caricatori DATA in BASIC per comodità delle riviste e degli utenti che non necessariamente dovevano capirne il funzionamento, in maniera non dissimile da come oggi si distribuiscono gli installer di molti pacchetti software, anziché i sorgenti da compilare.
Tanto più che sono esistiti programmi appositi per la generazione di righe DATA dalla memoria del C64.
-
Scusate se per qualche tempo mi sono "chiamato fuori" dalla discussione... sì... la cosa è stata voluta. Non era mia intenzione criticare il lavoro del buon infocalimero, né i meriti che ha avuto la commodore nel progettare il computerino più appetibile al consumatore finale nella storia dell'informatica...
Possiamo dire tutto ciò di buono che il commodore 64 è stato, tranne queste:
1. Che è stato progettato bene
2. Che era performante
Progetto e performance andavano a braccetto con quanto costava, e il costo era fortemente competitivo perché:
1. La commodore praticamente possedeva la società che produceva i chip della famiglia 65xx
2. Che la tecnologia (attenzione: non il progetto, ma solo la tecnologia) su cui si basava il commodore 64 era indietro di almeno 5 anni
3. Progettato bene? Forse qualcosettina di più i progettisti avrebbero potuto fare... ma certo i costi sarebbero lievitati.
Il progetto era "avanti" perché Tramiel ebbe un grosso intuito di marketing... sapeva che le RAM sarebbero calate di prezzo e mise 64KByte nel C64, che chiamò appunto C64.... ma la teconologia era indietro di 5 anni, perché il 65xx nel 1982 era vecchia come architettura. Che il C64 sia arrivato fino al 1994 in commercio è stato un vero miracolo... ma col C64 ci si poteva giocare ai videogiochi a basso costo, e fare un po' di cose serie o meglio "professionali" (Già, negli anni 80 vidi un C64 con floppy disk e stampante e altri ammennicoli in una palestra... l'amministrazione ci teneva i pagamenti dei soci e così via... in tutto un 150-200 iscritti... e vabbé).
Certo, è semplice dire: ma un PC compatibile (all'epoca si parlava di IBM compatibili) costava di più e dava solo un misero bianco e nero... già ma l'architettura 8086 era un'altra cosa, e rinuncio pure a farne un confronto qui. Perdonatemi, ma vi assicuro che checché ne dica qualcuno, un qualsiasi clone 8086 era non più veloce di un C64, ma spaventosamente più veloce di un C64, e non è solo per i 5MHz scarsi (mi sembra 4.75, ma un Olivetti M24 con coprocessore matematico andava a 8MHz, forniva una scheda grafica che in bicolore era 640x400... e in multicolor era una CGA standard... e il suono? E' vero, le sound blaster, o che diavolo c'era allora non lo so, costavano un occhio... ma a chi doveva aprire il LOTUS 1-2-3, RE antenato del moderno EXCEL che gliene fotteva? E sapete al LOTUS 1-2-3 che gli faceva il povero fogli(ett)o di calcolo gestibile da un C64? Un baffo gli faceva!!!!) ma per l'architettura a 16 bit, per l'espandibilità, per il coprocessing... per tutti gli standard sulle porte di espansioni, sui bus e così via. E per favore, non apriamo una discussione in tal senso che va oltre gli scopi del forum... ok?!
E poi i costi: C64 + Lettore Floppy disk + Stampante MPS801 appena usciti un paio di milioni di lire li costavano, e con lo stesso prezzo ti portavi a casa un 8088, con HD a 16MByte (che allora era un'enormità), 256KBYte di RAM e un lettore per floppy disk... forse pure due... boh, vabbé, forse ricordo male, ma solo il PC1 della commodore costava lo spaventoso prezzo di 3-4milioni di lire ed era quasi il doppio di uno stesso PC della concorrenza... ed è per questo che la commodore perse il mercato business, mica per altro... (anche l'Olivetti M24 era un altro discorso... anch'esso era costosissimo, ma io ci ho lavorato sul serio e l'ho smontato più di una volta per manutenzione... altro che C64, quello sì che era veramente ben fatto, con lo chassis in metallo... altro che plasticaccia dei cloni di allora... o anche degli IBM di allora).
Ma certo, l'esperienza videoludica che dava un C64 era di gran lunga superiore a moltissimi concorrenti dell'epoca... e punto, su questo non si discute.
Però, e qui sfido chiunque a smentirmi, il basic v2 era (ed è tutt'ora), da un punto di vista informatico, una vera schifezza... e programmarci oggi è da PAZZI ISTERICI... dissimulare righe DATA pure, perché adesso, se proprio vuoi fare qualcosa, ti scarichi un cross-compiler e il C64 lo programmi su PC con il linguaggio che più preferisci (anche in ADA se vuoi) e poi magari lo fai girare sul C64 vero dopo che test, debug e tutto il resto l'hai portato a termine sul VICE... Se poi uno vuole passare il suo poco tempo libero che ha a scrivere righe data, magari sull'hardware nativo (la cui tastiera allora era il top del top... ma oggi è una schifezza) lo può fare... anch'io ogni tanto lo faccio:
10 PRINT "HELLO WORLD"
20 GOTO 10
UhUhUhUhUh... guarda il video come scrolla veloce... non c'è che dire: è proprio velocissimo!
Un saluto.
PS:
Ho rivisto qualche listino prezzi di allora... beh... sui prezzi ricordo male perché l'M24 nel 1986 costava quasi 7milioni di lire. Invece nel 1981 un PC IBM 8088 costava negli USA circa 3000 dollari in versione base... per il commodore 64 invece:
(listino del marzo 1983)
C64: 625mila
FLOPPY DISK DRIVE: 630mila
Monitor mono: 235mila
Che fanno circa 1,5millioni di lire (più IVA) e che in fondo giustificano ampiamente l'acquisto del computer rispetto al PC IBM...
Il concetto di fondo, invece, rimane.
-
Spero che il tenore della discussione finito in scontro di opinioni non abbia fatto passare la voglia al nostro amico di portare avanti e condividere il suo lodevole lavoro di organizzazione dei contenuti sull'argomento.
Personalmente ritengo che sia molto interessante preservare ogni aspetto della conoscenza in materia, indipendentemente dal fatto che poi giustamente si abbiano le proprie preferenze, che non sempre sono dettate dalla logica più ferrea.
Per infocalimero: tornando in tema, ti ho appena girato un messaggio privato per segnalarti un paio di rilievi.
W il basic!
-
Scusate se sfioro l'OT, ma una cosa è stata detta bene: il Commodore 64 era stato progettato e realizzato veramente male, addirittura chip che di loro erano fuori specifica, una PIO che non rispettava le proprie specifiche HW ha generato drive floppy lentissimi che per motivi commerciali tali sono rimasti, bus così sporchi che la ROM caratteri sclerava di suo..... colori mal tarati, all'assemblaggio avvitatori che scappavano di mano e tranciavano piste di board che andavano comunque in vendita, tanto poi c'è l'assistenza, intanto mettiamo in tasca i soldi dei clienti.....
Leggete quì:
http://spectrum.ieee.org/ns/pdfs/commodore64_mar1985.pdf (http://spectrum.ieee.org/ns/pdfs/commodore64_mar1985.pdf)
Il SID? lo definiscono come il CHIP peggio specificato della storia dell'elettronica, chi faceva musica sulle specifiche generava cose insentibili!
Erano i tempi dove chi assemblava macchine in cantina poteva fare fortuna, e la Commodore era un'industria che poteva addirittura produrre i propri CHIP.... trovato il punto di equilibrio tra marketing, economia di progetto e realizzazione, budget di spesa di una nuova razza umana (quelli col pallino del computer) che volevano portarsi in casa una macchina come quella che li faceva giocare al bar.... mescolate il tutto e condite con MOLTA spregiudicatezza, avrete il BOOM del c64!
Per tornare a bomba sul tema: in basic si ricorre al LM ovvero alle linee DATA quando il basic stesso non è in grado di fare adeguatamente quella funzione che deve essere svolta appunto in LM, è quindi una SCONFITTA del Basic così come mamma Commodore l'ha fatto (routine per tracciare linee in HiRes dando solo i punti estremi, o archi o ecc... no?).
Altra storia sono i programmi fatti interamente in LM, come i giochi.
-
Se si fa un confronto tra la tecnologia di ieri ed il relativo mercato, con i tempi di oggi, molte cose risultano apparentemente difficili da comprendere.
Qualche tempo fa, tra il 2007 e il 2009, la Asus commercializzò un pc portatile equipaggiato con un "vecchio" (di almeno 10 anni) PIII da 600mhz, un minuscolo schermo da 7" che accecava la vista dopo 10 minuti, una tastiera che i tasti li poteva usare comodamente solo un bambino di 10 anni e un sistema operativo che, a detta di molti, risulta essere la peggiore distribuzione linux che sia mai esistita.
L'EeePC 701, pagato più di 200 euro, è stato nelle mie mani solo pochi mesi dopodichè me ne liberai per poche decine di euro senza troppi rimpianti.
Eppure è stato uno dei prodotti Asus di maggiore successo, venduti svariati milioni di pezzi in tutto il mondo, con una schiera di appassionati ancora oggi attivi in siti spuntati come funghi un po' ovunque nella rete.
I suoi punti di forza? Beh, la dove venivano meno i concorrenti.
Per prima cosa, il prezzo: poco più di 200 Euro, almeno la metà di un comune pc portatile;
seconda cosa: le ridotte dimensioni, che lo rendevano pratico e comodo da trasportare;
terza cosa: il design, bello, elegante, semplice e con la possibilità di scelta in colori diversi;
quarta cosa: il sistema operativo, anche se è uno schifo per chi conosce linux (come me), ma è talmente semplice e banale che lo può usare anche chi non ha mai visto un computer in vita sua. Per certi versi la sua interfaccia grafica è molto più semplice di quella comune di Windows.
E poi da un punto di vista hardware era fatto in modo tale da avere un ottima gestione energetica che ne rendeva possibile l'utilizzo anche per più di 3 ore sfiorando le 4 ore: è stato il portatile nelle mie mani con la maggiore autonomia della batteria.
La presenza solo di un'interfaccia di rete, di 3 porte USB, del WiFi e di una videocamera frontale (è stato uno dei primi pc ad aver avuto integrati di serie queste periferiche) lo rendeva un'ottima scelta almeno per la stragrande maggiornaza degli utenti di internet; tutto il resto (CD, DVD, modem, etc....) non serve.
Il tutto veniva venduto con un corposo manuale dove Asus consigliava addirittura quale software installare (e come) e una lunga lista di periferiche consigliate; unico caso del genere che io abbia visto in quasi 20 anni di acquisto di pc (Commodore a parte).
E cosa significa tutto questo? Quali sono state le conseguenze nel mercato del successo dell'EeePC? Bhe, facendo una attenta analisi si può affermare che l'Asus EeePC non è stato altro che l'antesignano dei tablet di oggi, oggetti piccoli ed eleganti ma anche comodi e leggeri, in cui si bada alla praticità piuttosto che alla potenza.
I tablet eliminano i "difetti" dell'EeePC, hanno lo schermo (touch) più grande che consente (almeno di serie) di eliminare la tastiera altrimenti scomoda e poco pratica; hanno la stessa connettività con l'aggiunta per molti della possibilità dell'utilizzo di una SIM, quindi internet sempre con se.
Analogamente il Commodore 64 è stato l'antesignano dei computer di oggi, ciò spiega il suo successo e ciò spiega anche l'odierno mondo dell'informatica che non sarebbe (e non sarebbe mai stato) lo stesso senza la sua comparsa per cui è da "apprezzare" anche (e soprattutto) nei suoi difetti, che poi alla fine tali non sono.