Ready64 Forum
Commodore 64 => Programmazione, Grafica e Musica => Topic aperto da: MarC=ello - 04 Aprile 2004, 23:53:53
-
Ciao!
Oltre alle tecniche di compattazione che troverete nella Guida C64 (cospicuo aggiornamento previsto per la fine del mese...), esistono altri accorgimenti per rendere più veloci i programmi BASIC.
1. Utilizzare SEMPRE variabili, specialmente entro i cicli.
2. Evitare i calcoli se possibile.
Esempio:
10 FORT=0TO7999:POKE8192+T,0:NEXT
Questo brevissimo programma serve per azzerare il segmento di memoria da 8192 a 8192+7999 = 16191.
Osserviamo che entro il ciclo FOR c'è un calcolo che può essere evitato. Basta sostituire i valori iniziale e finale del contatore del ciclo FOR (T) come segue:
10 FORT=8192TO16191:POKET,0:NEXT
Infine, per occupare meno memoria e rendere più veloce il codice, utilizziamo delle variabili per rappresentare la locazione iniziale e la locazione finale:
10 A=8192:B=16191:FORT=ATOB:POKET,0:NEXT
Queste possono sembrare cose di poco conto ma in realtà, specialmente in programmi lunghi, si guadagna molto in termini di velocità.
Ciao a tutti!
-
Ciao Marcello
Quel che dici è vero,ma quando si intendono scrivere programmi in cui è importante la velocità di esecuzione ( che debbano,ad esempio,richiedere la pulitura di un intero segmento di memoria.come sopra ),conviene spostare il proprio interesse verso il linguaggio macchina ;)
-
Ciao Alberto
Beh questo è fuori discussione...
Questi accorgimenti sono utili quando vuoi, per tua soddisfazione e/o divertimento, spingere il BASIC oltre i suoi limiti. Io ad esempio ho scritto un programma che realizza un semplice scrolling fluido in puro BASIC (Rob mi ha proposto di scrivere un articolo in merito a ciò... spero di trovarne il tempo un giorno).
A me è sempre piaciuto cercare di spingere il BASIC al massimo... semplicemente perché "it can be done" :)
Ciao!
-
Ti dirò poi che sono riuscito a creare effetti "raster" in BASIC... e anche un effetto 3D abbastanza carino... vorrei rilasciare un demo interamente in BASIC ma il problema è il tempo. Ad esempio ho finito solo stasera la seconda parte del vocabolario CBM BASIC a denti stretti... sono sempre molto indaffarato... Ora credo che la sezione dedicata alla Guida C64 sarà aggiornata fra pochi giorni.
Rinnovo i saluti!
-
L'ottimizzazione del linguaggio è fondamentale, quando si utilizza una macchina come il Commodore64, dove ogni byte è prezioso quanto un kilo di platino! E questo indipendentemente dal linguaggio utilizzato.
Questo è quello che ho imparato in base alle mie modeste esperienze in merito di programmazione e soprattutto grazie al mio diavolo custode: ian coog, che è stato per me un vero pozzo di consigli.
Per imparare ancora meglio altre tecniche di ottimizzazione, sarebbe utile analizzare alcuni programmi scritti in maniera non ottimizzata e cercare di capire come fare per ripulirli. Se magari qualcuno all'ascolto ha scritto o sta scrivendo qualche breve programma, potrebbe postarlo in questa sede, si potrebbe cercare di migliorarlo insieme. Sicuramente non si farà avanti nessuno... ma sicuramente potrebbe essere interessante.
-
sarebbe utile analizzare alcuni programmi scritti in maniera non ottimizzata e cercare di capire come fare per ripulirli.
Il tutorial sui dischi contiene un paio di consistenti listati Basic non ottimizzati...
La stessa Guida del programmatore ne contiene parecchi...
Sicuramente non si farà avanti nessuno...
Perchè questo pessimismo? :mellow:
-
Questi accorgimenti sono utili quando vuoi, per tua soddisfazione e/o divertimento, spingere il BASIC oltre i suoi limiti.
Certo,è una gran bella cosa ;)
Io ad esempio ho scritto un programma che realizza un semplice scrolling fluido in puro BASIC
Perchè non lo pubblichi? :fagiano:
A me è sempre piaciuto cercare di spingere il BASIC al massimo... semplicemente perché "it can be done"
Ottima filosofia...
Ciao
Alberto
-
Sì, penso che prima o poi lo pubblicherò... ;)
-
La stessa Guida del programmatore ne contiene parecchi...
Sì, infatti. Questo perché è stata messa come prioritaria la chiarezza dei programmi. Un programma "compattato" è più difficilmente leggibile di uno non compattato. Inoltre, sui programmi non compattati si possono inserire agevolmente dei commenti (REM) esplicativi.
-
Questi cicli da basic ci impiegano sempre troppo.
Se proprio vogliamo andare veloci come razzi eccovi una routinetta:
;fill routine da Basic
;[iAN CooG/HokutoForce]
;uso: SYS820,8192,16384,0
*=$0334
JSR $AEFD ; salta la virgola
JSR $A96B ; leggi un intero in $14/$15
lda $14
ldx $15
sta $fb ; indirizzo di partenza
stx $fc
JSR $AEFD
JSR $A96B
lda $14
ldx $15
sta $fd ; indirizzo di fine
stx $fe
JSR $AEFD
JSR $A96B
lda $14 ; valore di riempimento
ldy #$00
lp sta ($fb),y
ldx $fe
cpx $fc
bne inc1
ldx $fb
cpx $fd
beq exit
inc1
inc $fb
bne lp
inc $fc
jmp lp
exit
rts
e per implementarlo in un listato basic
10 forx=820to881:ready:pokex,y:next
15 sys820,8192,16191,0
20 end
90 data 032,253,174,032,107,169,165,020,166,021,133,251,134,252,032,253
91 data 174,032,107,169,165,020,166,021,133,253,134,254,032,253,174,032
92 data 107,169,165,020,160,000,145,251,166,254,228,252,208,006,166,251
93 data 228,253,240,009,230,251,208,238,230,252,076,090,003,096
anche se io sono per il link diretto delle routines senza usare READ/DATA che occupano tempo e *tanto* spazio inutilmente. Ma forse questo risultera' arabo per la maggior parte dei niubbi :overkiller:
-
Questi cicli da basic ci impiegano sempre troppo.
Infatti,per quello ho detto che,in questi casi,conviene usare il linguaggio macchina...
anche se io sono per il link diretto delle routines senza usare READ/DATA che occupano tempo e *tanto* spazio inutilmente.
Vero,del resto i caricatori Basic sono utili specialmente per le routines lunghe,in cui è bene controllare l'esattezza dei codici macchina inseriti con l'introduzione di una somma di controllo :)
-
Vero,del resto i caricatori Basic sono utili specialmente per le routines lunghe,in cui è bene controllare l'esattezza dei codici macchina inseriti con l'introduzione di una somma di controllo :)
Io direi proprio il contrario! :mellow:
Per una routinetta di 62 bytes come questa mi sta anche bene un caricatore in basic, per qualcosa di piu' lungo e' meglio scriverla direttamente in assembler, senza bisogno di checksum vari: e' meglio sapere cosa si sta scrivendo che immettere numeri a caso senza significato ;)
-
Io stavo parlando di ottimizzazione dei programmi BASIC, ed ho scelto un compito non adatto per il BASIC in modo da far vedere meglio i guadagni di tempo che si ottengono con l'ottimizzazione (considerando un lasso di tempo più lungo, i guadagni sono relativi ad una grande quantità e pertanto risultano più evidenti).
Nessuno, Alberto, sosteneva che bisogna usare il BASIC per azzerare un segmento di 8K. Il mio thread aveva come argomento L'OTTIMIZZAZIONE DEI PROGRAMMI BASIC, non l'azzeramento (o comunque il filling) di un segmento di memoria wink.gif
Bellissimo comunque il programma di Ian, che, previa sua autorizzazione, gradirei molto inserire nella Guida al futuro capitolo sull'interfacciamento fra BASIC e linguaggio macchina (spero che Ian sarà d'accordo; ovviamente ci saranno tutti i crediti del caso :-)).
In ogni caso, l'ottimizzazione dei programmi BASIC è importante. Infatti, guardate un po' la differenza fra il programma non ottimizzato e quello ottimizzato:
5 TI$="000000"
10 FORT=0TO7999:POKE8192+T,0:NEXT:PRINTTI$
15 A=8192:B=16191
20 TI$="000000":FORT=ATOB:POKET,0:NEXT:PRINTTI$
Digitando RUN (e, se siete su VICE, premendo ALT + W onde evitare di attendere una vita) si otterrà:
000111
000028
Questo significa che il programma non ottimizzato impiega 1 minuto e 28 secondi per svolgere l'azzeramento delle locazioni da 8192 a 16191; il programma ottimizzato impiega "solo" 28 secondi... a me non sembra una cosa da poco.
L'esempio del segmento di memoria non è certo dei più felici per il BASIC.
Consideriamo allora il seguente programma:
Programma LENTO:
100 REM FINTO RASTER
110 REM VERSIONE NON OTTIMIZZATA
240 PRINTCHR$(147);
250 FORT=1TO24:FORK=1TO40:PRINTCHR$(63+T);:NEXTK:NEXTT
260 FORT=12288TO12288+(8*24):POKET,0:NEXT
270 POKE 53272,(PEEK(53272)AND240)OR12
280 FORK=0TO192:POKE12288+K,255:NEXTK
290 FORK=192TO0STEP-1:POKE12288+K,0:NEXTK
300 GOTO280
Programma VELOCE (fa la stessa cosa del precedente, ma è ben più veloce):
100 REM FINTO RASTER
110 REM VERSIONE PARZIALMENE OTTIMIZZATA
240 PRINTCHR$(147);
250 FORT=1TO24:FORK=1TO40:PRINTCHR$(63+T);:NEXTK:NEXTT
260 FORT=12288TO12288+(8*24):POKET,0:NEXT
270 POKE 53272,(PEEK(53272)AND240)OR12
275 S=12288:F=12480
280 A=255:FORK=STOF:POKEK,A:NEXTK
290 A=0:FORK=FTOSSTEP-1:POKEK,A:NEXTK
300 GOTO280
Basta eseguire i due programmi, per rendersi conto che l'ottimizzazione può consentire il conseguimento di risultati stimolanti anche in BASIC (that's BASIC hacking, guys!!).
Ovviamente il programma può essere ottimizzato ancora... basta abbassare i numeri di linea, modificare la routine che effettua delle POKE direttamente sullo schermo con delle istruzioni PRINT, ecc... ecc... Non mi sono concentrato sulla velocità di visualizzazione dei caratteri sullo schermo, quanto alla "raster" routine vera e propria (ovviamente questo programma simula una routine raster, per questo il termine è fra virgolette - lo dico per chi non ha mai programmato il raster; per le vere routine raster è indispensabile il linguaggio macchina). I numeri di linea sono grandi perché ho preso il programma da un altro mio programma più grande (e non ho avuto voglia di cambiare i numeri di linea...).
(Se qualcuno non capisse qualcosa, chiedetemi pure :-)).
Comunque, buona Pasqua a tutti!
-
Quanto ai caricatori, sono in tutto e pertutto d'accordo con Ian. ;)
-
Ah, sensa offesa: per interrompere i programmi FINTO RASTER premere RUN/STOP e RESTORE.
-
ops!! sostituire il "sensa" con "senza"!!!!!! :doh:
-
Perchè non lo pubblichi?
Cos'era Alberto quell'icona fagiano? Non ci credi?
Beh... potrai ricrederti ben presto! (io non racconto frottole).
-
Non metto in dubbio le tue parole...l'icona l'ho messa senza un motivo preciso...
( siamo permalosetti,mi pare... :dotto: )
-
"FAGIANO" è sinonimo di "fessacchiotto" - ma è un termine indicativo e restrittivo di un concetto ben più ampio e sfumato -
Un fagiano è, in altre parole, una persona poco furba.
Quindi chi usa questa icona, lo fa per ammettere in un certo senso una sua debolezza: ad esempio per aver fatto una figura da persona poco sveglia (succede a tutti).
Del resto: questa vi sembra un'espressione intelligente?
:fagiano:
Non è assolutamente un'offesa, anzi è un termine che può essere usato tranquillamente da amici che vogliono prendersi in giro tra loro.
Ho cercato di spiegare al meglio, la filosofia di essere un "fagiano".
(L'icona fagiano arriva dal mio passato di utente del forum di html.it, inventata da quel pazzerello di saibal)
In questo caso pare evidente caro Marcello, che il ruolo di "fagianone" lo assegnerei a te ;) A quanto pare invece Alberto ha utilizzato l'icona a casaccio... in effetti non c'entrava molto, in quel contesto :)
approfondimenti:
http://www.lorenzone.it/news/wmview.php?ArtID=28 (http://www.lorenzone.it/news/wmview.php?ArtID=28)
Scusate se sono andato OT, ma avere due collaboratori che si tirano le palle di cacca non rientra negli scopi principali della mia esistenza :angry: :P
-
Marcello mi ha chiesto di mettere online la sua routine di scrolling scritta in basic, ed eccola qua:
Scroller Basic (http://ready64.altervista.org/misc/SCROLLER_BASIC.T64)
:metallica:
-
avere due collaboratori che si tirano le palle di cacca non rientra negli scopi principali della mia esistenza
Non ho mai tirato palle di cacca addosso a nessuno...nè ne ho mai avuto l'intenzione
Marcello mi ha chiesto di mettere online la sua routine di scrolling scritta in basic
Non capisco tutto questo accanimento per una semplice domanda... :mellow:
-
ellà ragazzi...
è evidente che il mio messaggio era scritto in tono scherzoso.
vi invito tutti a casa mia per una camomilla ok ;)
Non capisco tutto questo accanimento per una semplice domanda...
hai chiesto tu di pubblicare lo scrolling in basic, e marcello ha chiesto gentilmente se potevo fare l'upload nel sito! tutto qua.
-
è evidente che il mio messaggio era scritto in tono scherzoso
ma sì,certo,ho semplicemente "mangiato la foglia"... ;)
comunque l'effetto dello scrolling è decisamente suggestivo :sabber:
-
Marcello mi ha chiesto di mettere online la sua routine di scrolling scritta in basic, ed eccola qua:
Scroller Basic (http://ready64.altervista.org/misc/SCROLLER_BASIC.T64)
:metallica:
Tempo fa Rob mi passo' questo sorgente. Ne approfitto per chiedere a Marc=ello:
Non capisco il perche' del conteggio
11 FORt=6TO0STEP-1
anziche'
11 FORt=7TO0STEP-1
nel primo caso salta un pixel. Nel secondo c'e' sempre la pausa dovuta alla lentezza del basic per "rifare il giro" ma almeno IMO e' piu' fluido.
Cmq complimenti per l'idea di usare i caratteri ridefiniti, volere e' potere, a quanto pare :D
-
cosi' mi sembra ancora piu' fluido
9 f=peek(c)andw
10 POKEc,f+7:POKEd,3:POKEe,6
11 FORt=7TO0STEP-1:POKEc,f+t:gosub20:NEXT
12 POKEc,f+7:POKEd,6:POKEe,3
13 FORt=7TO0STEP-1:POKEc,f+t:gosub20:NEXT
14 goto10
20 waitc+1,128:FORk=1TOh:NEXT:return
wait 53266,128 serve per sincronizzarsi con il rasterbeam per evitare il flikering ;)
da asm sarebbe un
lda #$80
cmp $d012
bne *-3
-
Grande Ian!!! Sei un mito :hail:
-
Non capisco il perche' del conteggio
11 FORt=6TO0STEP-1
anziche'
11 FORt=7TO0STEP-1
nel primo caso salta un pixel. Nel secondo c'e' sempre la pausa dovuta alla lentezza del basic per "rifare il giro" ma almeno IMO e' piu' fluido.
Ehm... si tratta di un errore ;)
Cmq complimenti per l'idea di usare i caratteri ridefiniti, volere e' potere, a quanto pare
Grazie tante :)
-
ellà ragazzi...
è evidente che il mio messaggio era scritto in tono scherzoso.
vi invito tutti a casa mia per una camomilla ok ;)
Anche a me che sono di Messina? E se si raffredda nel frattempo?:D :D
-
@ian: ho provato le tue modifiche (linee 9-20) ma non riesco a farle funzionare, il programma si blocca all'inizio.
per caso hai il programma già modificato da spedirmi?
-
@ian: ho provato le tue modifiche (linee 9-20) ma non riesco a farle funzionare, il programma si blocca all'inizio.
Molto strano... In teoria avrei cambiato solo quelle linee
per caso hai il programma già modificato da spedirmi?
Hai posta.
-
Non capisco il perche' del conteggio
11 FORt=6TO0STEP-1
anziche'
11 FORt=7TO0STEP-1
nel primo caso salta un pixel. Nel secondo c'e' sempre la pausa dovuta alla lentezza del basic per "rifare il giro" ma almeno IMO e' piu' fluido.
Ehm... si tratta di un errore
In realtà ho fatto delle prove ed è meglio come avevo fatto io... nel secondo causo si viene a creare una pausa eccessiva nell'istante in cui avviene il cambio da un fotogramma all'altro...
ciao!