Ready64 Forum
Commodore 64 => Programmazione, Grafica e Musica => Topic aperto da: Roberto - 24 Ottobre 2007, 00:44:53
-
Postato su Lemon64, un listato in BASIC per simulare le "righine" di caricamento, davvero molto interessante (ma per me, del resto, questa è tutta Black Magic).
L'ho digitato, per chi volesse scaricarlo eccolo in allegato :)
-
figo! mi ero sempre chiesto come si facessero le righine di caricamento
MA dove va salvato questo programmino in basic? Prima di quello da caricare?
O sono solo righe da inserire in una applicazione per fare giusto un po di effetti?
-
Postato su Lemon64, un listato in BASIC per simulare le "righine" di caricamento, davvero molto interessante (ma per me, del resto, questa è tutta Black Magic).
Tutt'altro che black magic, e' un semplice incremento del colore del bordo intervallato da un ritardo fisso.
*=$8000
inc $d020
inx
bne *-1
jmp *-6
Ecco qua alcuni altri esempi che tentano di imitare alcuni loader classici, variando anche il ritardo tra un cambio colore e l'altro
*=$0326
word newintro
word $F6ED
newintro
loop
inc $d020
l2 lda $a2
eor $a1
asl
asl
tax
l1
dex
bne l1
beq loop
*=$0326
word newintro
word $F6ED
newintro
ldx #$01
stx $d020
dex
stx $d021
loop
dec $d020
lda $a2
eor $a1
tax
l1
dex
bne l1
inc $d020
bne loop
*=$0326
word newintro
word $F6ED
newintro
ldx #$01
stx $d020
dex
stx $d021
ldy #$08
loop
stx $d020
jsr delay
sty $d020
jsr delay
jmp loop
delay
lda $a2
eor $a1
tax
l1
dex
bne l1
rts
*=$0326
word newintro
word $F6ED
newintro
loop
lda $d020
eor #$08
sta $d020
jsr delay
iny
bne loop
inc $02
lda $02
and #$0f
bne loop
inc $d020
jmp loop
delay
lda $a2
eor $a1
asl
tax
l1
dex
bne l1
rts
-
MA dove va salvato questo programmino in basic? Prima di quello da caricare?
O sono solo righe da inserire in una applicazione per fare giusto un po di effetti?
Sono solo simulazioni fini a se' stesse, di utilizzo pratico nullo.
-
Dire che è in BASIC è un tantinello fuorviante, no?
Ho trovato un BUG! Se carico il programma avendo spostato l'area BASIC a partire da 32640, non funziona! :lol:
-
insomma quindi diciamo da utilizzare come presentazione nei propi programmi.
Ian, io sono subentrato da poco qui su ready ma mi sono sempre chiesto...sei un personaggio importantE???
come fai a sapere tutte ste cose?? dove si studiano???
comuqnue a parte questa parentesi, mi sono sempre chiesto come mai i miei programmi caricavano sepre a schermo azzurro senza far aparire le righe? il caricamento a righe era solo una questione di sboroneria o aveva una utilità a se stante?
-
insomma quindi diciamo da utilizzare come presentazione nei propi programmi.
No, non si possono usare da nessuna parte. Sono loop infiniti senza possibilita' di uscita, quindi non hanno, come gia' detto, alcun utilizzo pratico se non quello di simulare il flash del bordo che avviene in alcuni tapeloaders.
Ian, io sono subentrato da poco qui su ready ma mi sono sempre chiesto...sei un personaggio importantE???
Dipende da cosa intendi per importante. C'e' chi mi vuole bene e c'e' chi mi vuole male. Sono contento di esistere per entrambe le categorie.
come fai a sapere tutte ste cose?? dove si studiano???
Anni di studio e continue prove, iniziando da CCC, Enciclopedia "Input", per poi finire nei numerosi dox che si trovano in rete (compreso questo sito e forum), il tutto condito da migliaia di ore perse disassemblando programmi altrui cercando di capire come funzionassero. Cerco di non limitarmi a considerare "magia nera" ogni cosa che succede in un programma, se possibile e nelle mie capacita'.
comuqnue a parte questa parentesi, mi sono sempre chiesto come mai i miei programmi caricavano sepre a schermo azzurro senza far aparire le righe? il caricamento a righe era solo una questione di sboroneria o aveva una utilità a se stante?
Dipende dal loader con cui erano registrati, alcuni hanno l'incremento del bordo, altri no. Il CBM loader normale non ha nessun tipo di effetto, cosi' come il Turbotape64. Alcune varianti di Galadriel/biturbo, che dovrebbero averlo, sono state modificate inserendo 3 NOP al posto della INC $d020 per non aver effetti...
-
mmm input...
comincerò a leggerlo meglio =)
da piccolo mi dilettavo semplicemente a copiarne i listati...ora che sono ingegnere info potrei rivederlo in chiave differente
comunque per importante intendevo se magari appartenevi a quelche gruppo storico che craccava i giochi o robe simili.
-
comunque per importante intendevo se magari appartenevi a quelche gruppo storico che craccava i giochi o robe simili.
Si, la /HF sta per HokutoForce
http://noname.c64.org/csdb/scener/?id=6662 (http://noname.c64.org/csdb/scener/?id=6662)
Non e' un gruppo storico ma relativamente recente. Ma la mia conoscenza non deriva dal fatto di appartenervi, casomai il contrario. :)
-
Dire che è in BASIC è un tantinello fuorviante, no?
Molto, dato che di basic non ha praticamente nulla, introduce il programma in asm con le poke e lo esegue con la sys.
Ho trovato un BUG!
Puo' essere uno spunto per realizzarne una versione rilocabile. Vediamo se c'e' qualcuno che si cimenta in questo difficiliZZimo programma da 5 righe :sonno:
-
Magia nera?
Lo schermo di un televisore viene disegnato riga per riga. Per disegnare l'intero schermo serve 1/50 di secondo (1/60 nel sistema americano NTSC).
Se il colore dello schermo (o del bordo) viene cambiato piu' velocemente di 50 volte al secondo, alcune righe vengono disegnate col vecchio colore, e le successive col nuovo. E' questo che causa le famose "righe". Tanto piu' velocemente cambia il colore, tanto piu' sottili saranno queste "righe".
Questo e' anche il principio di funzionamento di molte routine grafiche, che sfruttano il fatto che il C64 puo' generare un interrupt proprio mentre lo schermo sta disegnando una determinata riga. In questo modo si puo' cambiare il colore del bordo a una riga fissata (e questo permette il bordo a righe fisse, o animate in maniera specifica, tra le altre cose), si possono spostare tutti gli 8 sprite dalla parte sopra quella riga alla parte sotto (e questo permette piu' di 8 sprite sullo schermo), si puo' fare lo scrolling della parte superiore dello schermo e non di quella inferiore (questo permette di avere scorrimento fluido sopra e punteggio sotto, ed e' anche il motivo per cui non si vede quasi mai scorrimento orizzontale con schermo diviso verticalmente) ecc.
-
Magia nera?
Suvvia, l'espressione "Black Magic" è usata in contesti ironici... :sonno:
Ad ogni modo, un conto è il principio teorico che tu hai (ben) illustrato e che funziona ottimamente a livello divulgativo.
Un altro conto invece è la realizzazione concreta dello stesso principio tramite un linguaggio di programmazione. Attività che in ogni caso resta appannaggio di chi ha una conoscenza sufficientemente approfondita della macchina. Cosa non da tutti, indubbiamente.
-
e fa sempre molto piacere scopire cose che ti erano rimaste oscure per anni e anni....
ah ah =)
-
insomma quindi diciamo da utilizzare come presentazione nei propi programmi.
I loader sono programmi scritti in linguaggio macchina che -come dice la parola- servono a caricare in RAM il codice macchina dell'applicazione vera e propria.
Di solito vengono allocati in una "nicchia" di memoria al sicuro dall'area riservata al programma (che in genere parte da $801).
Alcuni programmatori erano così bravi che oltre al caricamento riuscivano a far loro fare un mucchio di altre cose come suonare,visualizzare bitmap e persino intrattenere l'utente con dei simpatici giochini.
Il trucco per far questo però non te lo diciamo! :overkiller:
-
Alcuni programmatori erano così bravi che oltre al caricamento riuscivano a far loro fare un mucchio di altre cose come suonare,visualizzare bitmap e persino intrattenere l'utente con dei simpatici giochini.
Il trucco per far questo però non te lo diciamo!
Se è per questo il loader di Hawkeye e di Delta consentivano di "mixare" la musica del caricamento combinando varie sequenze di bass, drum, lead + fx ;)
Semplicemente fenomenali. Cronologicamente credo che il primo esempio di questo tipo di loader fosse quello di Delta e, ma qui potrei sbagliarmi, l'ossatura del codice si doveva a John Twiddy. Ripeto, non sono per niente sicuro del nome del coder, anche se ovviamente tutti sanno che è l'autore di quel capolavoro che è Tau Ceti :P
-
Loky wrote:
"comuqnue a parte questa parentesi, mi sono sempre chiesto come mai i miei programmi caricavano sepre a schermo azzurro senza far aparire le righe? il caricamento a righe era solo una questione di sboroneria o aveva una utilità a se stante?"
mah, per quello che ne so io (ma posso benissimo sbagliare) era puramente una questione estetica, senza nessuna utilità a se' stante, tranne quella di deliziarti con le righine colorate... :P
I tuoi giochi durante il caricamento non mostravano le righe (e comunque è strano perché erano assai diffusi i giochi in turbo con le righe, specie nella seconda metà anni 80) perché i turbo con i quali erano salvati non prevedevano le righine.
Un turbo molto famoso che faceva le righe era il Turbo 202. C'era poi il "Turbo chiocciolina"(qua lo chiamavamo così, perché nella fase di run, appariva sullo schermo la chiocciolina (alias la A commerciale), e di quel turbo ricordo ne avevo 2 versioni: quello con le righe e quello senza le righe.
Inizialmente fu utilizzato, come è stato già detto il Turbotape ma divenne scomodo dal momento che dovevi prima caricare il loader e poi il gioco turbizzato.
Fu presto soppiantato da Turbo più funzionali, tra i quali, ripeto, il Turbo 202, che mi pare partiva con sys727.
-
A proposito del Turbo 202, se qualcuno me lo può confermare, io ricordo che era un piccolo programmino in linguaggio macchina che scriveva in quella parte di ram che va da $02A7 a $02FF, precisamente poco prima del warm start del basic.
Tutto considerato, tanto di cappello ai programmatori, che riuscirono in così poco spazio a programmare un turbo così efficiente, senza ovviamente esserci il pericolo che il programma che andava a caricare sovrascrivesse quell'area di memoria, dato che, come tutti sappiamo, i programmi scrivevano da $0800 in poi.
Non so infatti da che locazione di memoria si posizionasse il Turbotape, (forse da $C000 o addirittura ancora prima, nella Ram Basic?), ma era comunque limitato perché poteva caricare programmi che non potevano superare una data dimensione, a differenza del Turbo 202, che per la suddetta caratteristica, poteva caricare programmi anche da $0800 a $FFFF.
-
Turbo 202, che per la suddetta caratteristica, poteva caricare programmi anche da $0800 a $FFFF.
Quel 202 sta per i numeri di blocchi disco gestiti, quindi da $0800 a $cfff, basta fare 2 conti. Confondi con il Turbo250 di Mr.Z/Triad,
-
A proposito di Turbo 250, io c'è l'ho tra i miei programmi del Win Vice 64, ma sfortunatamente non sono MAI riuscito a salvare un solo programma su cassetta virtuale. Mi spiego. Creo una nuova immagine TAP, Carico il Turbo 250, carico il programma da salvare e poi, come da istruzioni scrivo [freccia]S"nome programma" e premo record. Le spie di play e record si accendono ma di fatto il contatore sta fermo, non si muove da"000" e perciò la cassetta non va avanti e la registrazione non avviene. Sembra che la cassetta sia bloccata perché neanche play o ffwd o rwd la smuovono.
Non ho mai capito cosa ci sia che non va. Qualcuno di voi l'ha provato?