Visualizza Versione Completa : [C64] Routine 80x50 in ASM
Allora gente...
...so che MOLTO probabilmente fotterà una sega a tutti però ho scritto, da stamattina, una routine per Commodore64 che possa gestire una "grafica" in formato 80x50 usando i caratteri del C64.
La routine è:
SYS 49152,X,Y,Colore
con X da 0 a 79, Y da 0 a 49 e Colore da 0 a 15
La routine si occupa di
1. Controllare se la cella video dove verrà allocato il "pixellone" contiene già un carattere del set
2. Trasformare le coordinate passate in cella video ($0400-$07E8)
3. Calcolare il pixellone da accendere
4. Calcolare il nuovo carattere
5. Pokare il carattere ed il suo colore
Il problema è che c'è qualcosa che non va nei calcoli. Non so perché prima funzionava, poi da un certo punto mi sfasa il punto acceso. Inoltre il codice è auto-modificante per ottimizzare la dimensione ed i calcoli.
Qualcuno vuol dare un contributo?
Perché lo sto facendo? Così... per non perdere l'allenamento e perché voglio riprodurre un engine pseudo3d (tipo doom) su C64.
Perché lo sto facendo? Così... per non perdere l'allenamento e perché voglio riprodurre un engine pseudo3d (tipo doom) su C64.
Ma vai a figa va'... :caffe:
brutte persone
non dico altro
Cmq trovato l'errore...
era logico....
adesso le coordinate le converte correttamente.
Adesso c'è n'altra cosa che non funzia... il pixellone sottostante non viene riconosciuto correttamente ... c'è un inversione della coordinata X con quella Y
Falegname Geppetto
14-06-17, 16:53
secondo me
Prima di usare una funzione, il C deve riconoscere il tipo di ritorno e il
tipo dei parametri che la funzione si aspetta.
Lo standard ANSI del C ha introdotto un nuovo e migliore metodo per fare
questa dichiarazione rispetto alle precedenti versioni di C (ricordiamo
che tutte le nuove versioni del C aderiscono ora allo standard ANSI).
L'importanza della dichiarazione e' doppia:
viene fatta per avere un codice sorgente piu' strutturato e percio'
facile da leggere ed interpretare;
permette al compilatore C di controllare la sintassi delle chiamate di
funzioni.
Il modo in cui questo viene fatto dipende dallo scopo della funzione.
Fondamentalmente, se una funzione e' stata definita prima di essere usata
(call) allora e' possibile semplicemente usare la funzione. Nel caso
contrario, e' obbligatorio dichiarare la funzione; la dichiarazione
stabilisce in modo semplice il ritorno della funzione ed il tipo dei
parametri utilizzati da questa.
E' buona norma (e solitamente viene fatto) dichiarare tutte le funzioni
all'inizio del programma, sebbene non sia strettamente necessario.
Per dichiarare un prototipo di funzione bisogna semplicemente stabilire il
ritorno della funzione, il nome della funzione e tra le parentesi elencare
il tipo dei parametri nell'ordine in cui compaiono nella definizione di
funzione.
Ad esempio:
int strlen(char[]);
Questo dichiara che una funzione di nome "strlen" ritorna un valore integer
ed accetta una singola stringa come parametro.
Nota: le funzioni e le variabili possono essere dichiarate sulla stessa
linea di codice sorgente. Questa procedura era molto piu' diffusa
nei giorni del pre-ANSI C; da allora le funzioni solitamente vengono
dichiarate separatamente all'inizio del programma. La prima procedura
risulta ancora perfettamente valida, purche' venga rispettato l'ordine
in cui gli oggetti compaiono nella definizione della funzione.
Ad esempio:
int length, strlen(char[]);
dove "length" e' una variabile, e "strlen" e' la funzione (come
nell'esempio precedente).
Adesso c'è n'altra cosa che non funzia... il pixellone sottostante non viene riconosciuto correttamente ... c'è un inversione della coordinata X con quella Y
Inverti i nomi di X e Y, facile :smugrandom:
risolto... quasi...va tutto bene tranne... quando raggiunge un certo valore di coordinata che mi sballa tutto. avrò dimenticato il CARRY da qualche parte.
Io trovo molto stimolante e rilassante fare ste robe.
E' da stamattina che ci sbatto il crapino.
Non ne fotte un cazzo a nessuno?
Questa la routine che trasforma lo spazio 80x50 in coordinate video/colore: ($58 coordX; $59 coordY)
Per ora nessuna ottimizzazione: l'ho scritto di getto.
trasf_coord
LDA $59
CLC
ROR
CLC
ROL
TAX
INX
LDA tabella_row,X
STA posizione_schermo
STA posizione_colore
LDA tabella_row+1,X
ADC #$04
STA posizione_schermo+1
ADC #$D4
STA posizione_colore+1
LDA $58
CLC
ROR
STA $5A
LDA posizione_schermo
CLC
ADC $5A
BCC trasf_coord1
LDY posizione_schermo+1
INY
STY posizione_schermo+1
trasf_coord1
STA posizione_schermo
; Stessa cosa per il colore
LDA $58
CLC
ROR
STA $5A
LDA posizione_colore
CLC
ADC $5A
BCC trasf_coord2
LDY posizione_colore+1
INY
STY posizione_colore+1
trasf_coord2
STA posizione_colore
RTS
tabella_row
.byte $00,$00, $00,$28, $00,$50, $00,$78, $00,$A0, $00,$C8, $00,$F0, $01,$18, $01,$40, $01,$68, $01,$90, $01,$B8, $01,$E0
.byte $02,$08, $02,$30, $02,$58, $02,$80, $02,$A8, $02,$D0, $02,$F8, $03,$20, $03,$48, $03,$70, $03,$98, $03,$C0
posizione_schermo
.byte 0,0 ; FalegnameGeppetto sukaminchia
posizione_colore
.byte 0,0
No... non va... ma vacca troia!
Superate le coord 11,11 si rincoglionisce ed ho notato che se vado in diagonale (0,0 - 1,1 - 2,2 - 3,3 ... ) ok, ma se plotto in 5,7 e poi in 6,8 swappa x con y
ma vaff
Falegname Geppetto
14-06-17, 17:46
Hai seguito il mio tutorial? Dovrebbe funzionare...
Inviato dal mio iPhone utilizzando Tapatalk
10 print ciao
20 goto 10
run
gnappinox1
14-06-17, 22:24
Posto solo per dire che l'assembler è il linguaggio del demonio e che sono stato fortunato a studiarlo solo 1 anno, mi vengono ancora i brividi se ci penso
Inviato dal mio Nexus 7 utilizzando Tapatalk
Posto solo per dire che l'assembler è il linguaggio del demonio e che sono stato fortunato a studiarlo solo 1 anno, mi vengono ancora i brividi se ci penso
Inviato dal mio Nexus 7 utilizzando Tapatalk
Assembly (https://it.wikipedia.org/wiki/Assembly).
prego.
Ecco mi hai fatto loggare da pc solo per poter indire tu come eretico della programmazione metterti all'indice e aspettare con calma che venga il tuo turno per arderti li, dove fu arso Savonarola.
tie'. immondo:
MY_ASM_START
rD equ r2
rN equ r7
ifdef x64
num_VAR equ r8
table_VAR equ r9
else
data_size equ (REG_SIZE * 5)
crc_table equ (REG_SIZE + data_size)
num_VAR equ [r4 + data_size]
table_VAR equ [r4 + crc_table]
endif
SRCDAT equ rN + rD + 4 *
CRC macro op:req, dest:req, src:req, t:req
op dest, DWORD PTR [r5 + src * 4 + 0400h * t]
endm
CRC_XOR macro dest:req, src:req, t:req
CRC xor, dest, src, t
endm
CRC_MOV macro dest:req, src:req, t:req
CRC mov, dest, src, t
endm
CRC1b macro
movzx x6, BYTE PTR [rD]
inc rD
movzx x3, x0_L
xor x6, x3
shr x0, 8
CRC xor, x0, r6, 0
dec rN
endm
MY_PROLOG macro crc_end:req
MY_PUSH_4_REGS
mov x0, x1
mov rN, num_VAR
mov r5, table_VAR
test rN, rN
jz crc_end
@@:
test rD, 7
jz @F
CRC1b
jnz @B
@@:
cmp rN, 16
jb crc_end
add rN, rD
mov num_VAR, rN
sub rN, 8
and rN, NOT 7
sub rD, rN
xor x0, [SRCDAT 0]
endm
MY_EPILOG macro crc_end:req
xor x0, [SRCDAT 0]
mov rD, rN
mov rN, num_VAR
sub rN, rD
crc_end:
test rN, rN
jz @F
CRC1b
jmp crc_end
@@:
MY_POP_4_REGS
endm
MY_PROC CrcUpdateT8, 4
MY_PROLOG crc_end_8
mov x1, [SRCDAT 1]
align 16
main_loop_8:
mov x6, [SRCDAT 2]
movzx x3, x1_L
CRC_XOR x6, r3, 3
movzx x3, x1_H
CRC_XOR x6, r3, 2
shr x1, 16
movzx x3, x1_L
movzx x1, x1_H
CRC_XOR x6, r3, 1
movzx x3, x0_L
CRC_XOR x6, r1, 0
mov x1, [SRCDAT 3]
CRC_XOR x6, r3, 7
movzx x3, x0_H
shr x0, 16
CRC_XOR x6, r3, 6
movzx x3, x0_L
CRC_XOR x6, r3, 5
movzx x3, x0_H
CRC_MOV x0, r3, 4
xor x0, x6
add rD, 8
jnz main_loop_8
MY_EPILOG crc_end_8
MY_ENDP
MY_PROC CrcUpdateT4, 4
MY_PROLOG crc_end_4
align 16
main_loop_4:
movzx x1, x0_L
movzx x3, x0_H
shr x0, 16
movzx x6, x0_H
and x0, 0FFh
CRC_MOV x1, r1, 3
xor x1, [SRCDAT 1]
CRC_XOR x1, r3, 2
CRC_XOR x1, r6, 0
CRC_XOR x1, r0, 1
movzx x0, x1_L
movzx x3, x1_H
shr x1, 16
movzx x6, x1_H
and x1, 0FFh
CRC_MOV x0, r0, 3
xor x0, [SRCDAT 2]
CRC_XOR x0, r3, 2
CRC_XOR x0, r6, 0
CRC_XOR x0, r1, 1
add rD, 8
jnz main_loop_4
MY_EPILOG crc_end_4
MY_ENDP
end
e si io mi ci sego su sta roba:
https://it.wikipedia.org/wiki/Assembly#C-asm
FOT
TES
EGA
UNE
MER
ITA
NER
CHI
AHH
gnappinox1
14-06-17, 23:32
Assembly (https://it.wikipedia.org/wiki/Assembly).
prego.
Ecco mi hai fatto loggare da pc solo per poter indire tu come eretico della programmazione metterti all'indice e aspettare con calma che venga il tuo turno per arderti li, dove fu arso Savonarola.
cut...
:rotfl::rotfl::rotfl:
C non sei stato il primo e non sarai l'ultimo, ma sarai sempre presente nel mio cuore.
Se dovessi camminare in una valle oscura, non temerei alcun assembler o garbage-collector, perché tu sei con me.
Infine quando un segmentation fault porrà fine alla mia esistenza terrena, finirò nei campi elisi,
un luogo ove una malloc non restituirà mai NULL e mi dimenticherò per sempre delle include guards.
Grazie al sacro GCC la mia parola verrà scritta una volta e compilata per tutte le macchine del mondo :asd: ti lascio questo esempio di riconciliazione
void mergesort(int *a, int *b, int l, int r){
int i,j,k,m;
if(r > l) {
m = (r+l)/2;
mergesort(a,b,l,m);
mergesort(a,b,m+1,r);
for(i = m+1; i > l; i--)
b[i-1] = a[i-1];
for(j = m; j < r; j++)
b[r+m-j] = a[j+1];
for(k = l; k <= r; k++)
a[k] = b[i] < b[j] ? b[i++] : b[j--];
}
}
void ordina(int *a, int l, int r)
{
int *b = calloc(r - l + 1, sizeof(int));
if(!b) { fprintf(stderr,"Errore di allocazione\n"); exit(-1); }
mergesort(a,b,l,r);
free(b);
}
E si, conosco come mischiare C ed Assembly, la cosa è figa, anche se non mi ha mai attirato più di tanto anche per lavorare con i singoli bit preferisco il C :sisi:
Allora gente...
...so che MOLTO probabilmente fotterà una sega a tutti però ho scritto, da stamattina, una routine per Commodore64 che possa gestire una "grafica" in formato 80x50 usando i caratteri del C64.
La routine è:
SYS 49152,X,Y,Colore
con X da 0 a 79, Y da 0 a 49 e Colore da 0 a 15
La routine si occupa di
1. Controllare se la cella video dove verrà allocato il "pixellone" contiene già un carattere del set
2. Trasformare le coordinate passate in cella video ($0400-$07E8)
3. Calcolare il pixellone da accendere
4. Calcolare il nuovo carattere
5. Pokare il carattere ed il suo colore
Il problema è che c'è qualcosa che non va nei calcoli. Non so perché prima funzionava, poi da un certo punto mi sfasa il punto acceso. Inoltre il codice è auto-modificante per ottimizzare la dimensione ed i calcoli.
Qualcuno vuol dare un contributo?
Perché lo sto facendo? Così... per non perdere l'allenamento e perché voglio riprodurre un engine pseudo3d (tipo doom) su C64.
Ma se vuoi lavorare in grafica sul C64, perche' invece di usare quella merda di 80x50 non accedi alla memoria video direttamente tramite il VIC e ti spari i 320x200 ?
Geralt di Rivia
15-06-17, 08:56
Recidivo, rinfrescami, tu eri spectrumiano o commodoriano?
Recidivo, rinfrescami, tu eri spectrumiano o commodoriano?
Ebbi il vic20 bianco e lindo immacolato.
Passai al c64 marroncino con sommo gaudio e da lì partii con la programmazione in BASIC .
Era il 1984 e leggevo:
https://uploads.tapatalk-cdn.com/20170615/0cf38e61db6f3a00d502356bb8fad5b4.jpg
Però con lo spectrum ci giocavo a casa di un mio amico, che poi in fine mi ha donato.
:rotfl::rotfl::rotfl:
C non sei stato il primo e non sarai l'ultimo, ma sarai sempre presente nel mio cuore.
Se dovessi camminare in una valle oscura, non temerei alcun assembler o garbage-collector, perché tu sei con me.
Infine quando un segmentation fault porrà fine alla mia esistenza terrena, finirò nei campi elisi,
un luogo ove una malloc non restituirà mai NULL e mi dimenticherò per sempre delle include guards.
Grazie al sacro GCC la mia parola verrà scritta una volta e compilata per tutte le macchine del mondo :asd: ti lascio questo esempio di riconciliazione
void mergesort(int *a, int *b, int l, int r){
int i,j,k,m;
if(r > l) {
m = (r+l)/2;
mergesort(a,b,l,m);
mergesort(a,b,m+1,r);
for(i = m+1; i > l; i--)
b[i-1] = a[i-1];
for(j = m; j < r; j++)
b[r+m-j] = a[j+1];
for(k = l; k <= r; k++)
a[k] = b[i] < b[j] ? b[i++] : b[j--];
}
}
void ordina(int *a, int l, int r)
{
int *b = calloc(r - l + 1, sizeof(int));
if(!b) { fprintf(stderr,"Errore di allocazione\n"); exit(-1); }
mergesort(a,b,l,r);
free(b);
}
E si, conosco come mischiare C ed Assembly, la cosa è figa, anche se non mi ha mai attirato più di tanto anche per lavorare con i singoli bit preferisco il C :sisi:
Oh e non ci dovrebbe essere bisogno di dire che scherzavo, perché vedo che l'hai presa come dovrebbe.
;-)
Quanto tempo free ha kymya?
Mentre lavori dico
Ma se vuoi lavorare in grafica sul C64, perche' invece di usare quella merda di 80x50 non accedi alla memoria video direttamente tramite il VIC e ti spari i 320x200 ?
Perchè NO.
Mi è venuta 'sta cosa così... tanto per...
lo trovo stimolante.
Ho QUASI risolto tutto. Non ho capito perché se supero le coordinate 11 si rincoglionisce... forse la tabella dove ho mappato le singole righe per velocizzare avrò sbagliato qualcosa.
Avevo pensato di prendere il numero di riga e moltiplicarlo per 40. Per velocizzare la moltiplicazione per 40, posso sommare due moltiplicazioni: una per 32 (che corrisponde a 5 ROL) ad una per 8 (che corrisponde a 3 ROL). Quindi far fare 3 ROL, memorizzare il valore risultante, altri 2 ROL e sommare con il valore memorizzato.
Quanto tempo free ha kymya?
Mentre lavori dico
Lavoro su minimo 3 pc alla volta (2 fisici dai quali mi collego ad almeno 3 VM contemporaneamente) e comunque ogni tanto mi trovo ad aspettare le macchine. O alla pausa pranzo...
gnappinox1
15-06-17, 14:30
Oh e non ci dovrebbe essere bisogno di dire che scherzavo, perché vedo che l'hai presa come dovrebbe.
;-)
Certo, considera che stavo per addormentarmi, ho visto la notifica, letto il messaggio mi sono scompisciato dal ridere :rullezza::rotfl: ed ho acceso il pc per rispondere più o meno a tono :asd::asd:
Geralt di Rivia
16-06-17, 08:03
https://twitter.com/UridiumAuthor/status/875518130239528960
Dunque... so che continuerete a sbattervene il cazzo però...
...adesso la routine di plot 80x50 FUNZIONA!!!!
Adesso sto scrivendo la routine per tracciare una linea tra due punti utilizzando l'algoritmo di Bresenham che mi pare molto veloce.
E' troppo divertente! Cmq la parte per plottare il singolo punto è lunga 380byte circa comprese tabelle e buffer.
http://www.ithistory.org/sites/default/files/honor-roll/Jack%20E.%20Bresenham.jpg
:smugrandom:
https://twitter.com/UridiumAuthor/status/875518130239528960
Avevo trovato un suo vecchio gioco in una compialtion su cassetta (di quelle da edicola) ai tempi del C64 :uhm:
Mi potete aiutare su una questione matematica (byte signed)???
Vabbè, praticamente ho ottenuto e memorizzato il valore assoluto del delta tra due coordinate ( praticamente ABS(x2-x1) ) come byte signed.
Adesso devo calcolare il valore negativo. Come si fa?
praticamente ho:
A = ABS(X2-X1)
B = ABS(Y2-Y1)
C = -ABS(Y2-Y1) = -B
Avendo A e B, come calcolo C?
(tenete presente che i byte sono signed, quindi da -127 a 128 come valore e
00000010 = +2
00000001 = +1
00000000 = 0
11111111 = -1
11111110 = -2)
Mi potete aiutare su una questione matematica (byte signed)???
Vabbè, praticamente ho ottenuto e memorizzato il valore assoluto del delta tra due coordinate ( praticamente ABS(x2-x1) ) come byte signed.
Adesso devo calcolare il valore negativo. Come si fa?
praticamente ho:
A = ABS(X2-X1)
B = ABS(Y2-Y1)
C = -ABS(Y2-Y1) = -B
Avendo A e B, come calcolo C?
(tenete presente che i byte sono signed, quindi da -127 a 128 come valore e
00000010 = +2
00000001 = +1
00000000 = 0
11111111 = -1
11111110 = -2)
https://it.wikipedia.org/wiki/Complemento_a_due
C = ( 0 - B )
cazzo che soluzione semplice ed elegante!
grazie bellooohhh!
Ti mando il prg compilato appena finito.
Ciao Lord...
tu che sei bravo e mi capisci, se volessi "assemblerizzare" questa formula :
x= x + q
y= y + s
d= d + 2 * (a + b)
potrei scrivere, considerando che sono byte signed :
LDA line_x
CLC
ADC line_Q
STA line_X
LDA line_Y
CLC
ADC line_S
STA line_Y
LDA line_A
CLC
ADC line_B
CLC
ROL
ADC line_D
STA line_D
???
Perché ho "tradotto" tutto l'algoritmo ma mi spara punti a capocchia. Non ho mai "lavorato" con byte signed!
Kymy, vado a "rimembranze" in quanto e' una vita che non smanetto l'assembly del 6510, ma se non sbaglio l'ALU della cpu gestisce da sola l'artimetica signed. Dai una occhiata al manuale del set di instruzioni.
LDA line_x // A <-X
CLC
ADC line_Q: // A = A + Q
STA line_X: // Q = A
LDA line_Y // A = Y
CLC
ADC line_S // A = A + S
STA line_Y // Y = A
LDA line_A // A = a
CLC
ADC line_B // A = A + B
CLC
ROL // A = A * 2
ADC line_D // A = A + D
STA line_D // D = A
A occhio e croce direi che va bene :uhm:
Perché ho "tradotto" tutto l'algoritmo ma mi spara punti a capocchia. Non ho mai "lavorato" con byte signed!
Prendi questo parere con molta fotteseganza
https://www.c64-wiki.com/wiki/ROL
Doubling signed integers in this way requires programming efforts to keep the sign bit from mixing with the other bits, causing erratic sign-changes.
Prendi questo parere con molta fotteseganza
https://www.c64-wiki.com/wiki/ROL
Doubling signed integers in this way requires programming efforts to keep the sign bit from mixing with the other bits, causing erratic sign-changes.
Invece credo sia corretto: Usare lo shift per moltiplicare per due rischia di far uscire il bit di segno, es:
ROL 10001011 = 00010110!!
prova cosi:
LDA line_x // A <-X
CLC
ADC line_Q: // A = A + Q
STA line_X: // Q = A
LDA line_Y // A = Y
CLC
ADC line_S // A = A + S
STA line_Y // Y = A
LDA line_A // A = a
CLC
ADC line_B // A = A + B
CLC
STA temp // temp = A
ADC temp // A = A + temp (= 2 * A )
CLC
ADC line_D // A = A + D
STA line_D // D = A
inutile.... l'assembly è ELEGANTE. Bella soluzione. invece di ROLlare, sommare a se stesso... provo...
inutile.... l'assembly è ELEGANTE. Bella soluzione. invece di ROLlare, sommare a se stesso... provo...
Bof, la soluzione "elegante" si comporterebbe in modo diverso a seconda del fatto che l'operando e' positivo o negativo. Sommare se stesso e' un trick ma non la cosa piu' efficente: 3 isturzioni contro 1 del ROL e un byte di memoria extra.
LDA line_x // A <-X
CLC
ADC line_Q: // A = A + Q
STA line_X: // Q = A
LDA line_Y // A = Y
CLC
ADC line_S // A = A + S
STA line_Y // Y = A
LDA line_A // A = a
CLC
ADC line_B // A = A + B
BMI negative
CLC
ROL
JMP end
negative:
CLC
STA temp // temp = A
ADC temp // A = A + temp (= 2 * A )
end:
CLC
ADC line_D // A = A + D
STA line_D // D = A
ottimizzo dopo.
continua a non funzionare. vediamo se riesco a debuggare in qualche modo.
Sto utilizzando Relaunch64 (Java) come IDE (DASM) e Vice.
Sotto di BREAK e Z ... è l'unica strada per giungere alla soluzione. Rottura di palle, ma stimolante.
Fino al calcolo della d, tutto ok...
Dai... che sento che la soluzione è sotto mano dai!
Mi sa che l'algoritmo è come al cazzo. controllato uno step alla volta e, almeno l'unico caso provato, quello che ho scritto segue l'algoritmo:
swap = 0;
DX = x2 - x1;
DY = y2 - y1;
//siccome scambio DY e DX ho sempre DX>=DY allora per sapere quale coordinata occorre cambiare uso una variabile
if (abs(DX) < abs(DY)) {
swap(DX, DY);
swap = 1;
}
//per non scrivere sempre i valori assoluti cambio DY e DX con altre variabili
a = abs(DY);
b = -abs(DX);
//assegna le coordinate iniziali
x = x1;
y = y1;
//il nostro valore d0
d = 2 * a + b;
//s e q sono gli incrementi/decrementi di x e y
q = 1;
s = 1;
if (x1 > x2) q = -1;
if (y1 > y2) s = -1;
disegna_punto(x, y);
disegna_punto(x2, y2);
for (k = 0; k < -b; k+=1) {
if (d > 0) {
x= x + q; y= y + s;
d= d + 2 * (a + b);
}
else {
x = x + q;
if (swap==1) { y = y + s; x = x - q; }
d = d + 2 * a;
}
disegna_punto(x, y);
}
preso da qui : https://it.wikipedia.org/wiki/Algoritmo_della_linea_di_Bresenham
(nb: provata in vb, funziona. quindi l'algoritmo è ok)
Dunque...
sono contento di dirvi che i KymyACommands si vantano di due nuovi comandi. PLOT e LINE in 80x50!
Ho anche fatto un comando per utilizzare la RAM sotto la ROM come spazio RAM virtuale... il vantaggio del mio comando è che utilizza i due banchi come se fossero uno solo (A000-BFFF e D000-FFFF). Quindi posso salvare, che ne so, 9KB contigui con il comando
RAMDISK 0,1024,10000,0
e poi, magari, caricarne solo una parte con un
RAMDISK 1,500,1500,1024
adesso ottimizziamo qua e la...
Una domanda Kymy: ma perche' stai lavorando in "grafica" sulla pagina testo?
GenghisKhan
29-06-17, 08:28
Allora gente...
...so che MOLTO probabilmente fotterà una sega a tutti però ho scritto, da stamattina, una routine per Commodore64 che possa gestire una "grafica" in formato 80x50 usando i caratteri del C64.
La routine è:
SYS 49152,X,Y,Colore
con X da 0 a 79, Y da 0 a 49 e Colore da 0 a 15
La routine si occupa di
1. Controllare se la cella video dove verrà allocato il "pixellone" contiene già un carattere del set
2. Trasformare le coordinate passate in cella video ($0400-$07E8)
3. Calcolare il pixellone da accendere
4. Calcolare il nuovo carattere
5. Pokare il carattere ed il suo colore
Il problema è che c'è qualcosa che non va nei calcoli. Non so perché prima funzionava, poi da un certo punto mi sfasa il punto acceso. Inoltre il codice è auto-modificante per ottimizzare la dimensione ed i calcoli.
Qualcuno vuol dare un contributo?
Perché lo sto facendo? Così... per non perdere l'allenamento e perché voglio riprodurre un engine pseudo3d (tipo doom) su C64.
:sisi:
Prossimo step...
far stampare su schermo utilizzando la 80x50, quindi il singolo carattere occuperà 4x4caselle di testo.
Una domanda Kymy: ma perche' stai lavorando in "grafica" sulla pagina testo?
Perché? Boh. Allenamento... per tenere la mente allenata. Se mi viene qualche altra idea l'implemento!
Adesso vorrei scrivere un programma che mi generi un labirinto 2D ma che lo visualizzi in 2.5D tipo Doom utilizzando la grafica 80x50
Prossimo step...
far stampare su schermo utilizzando la 80x50, quindi il singolo carattere occuperà 4x4caselle di testo.
Perché? Boh. Allenamento... per tenere la mente allenata. Se mi viene qualche altra idea l'implemento!
Adesso vorrei scrivere un programma che mi generi un labirinto 2D ma che lo visualizzi in 2.5D tipo Doom utilizzando la grafica 80x50
Continuo a non capire: è come se tu volessi allenarti alla corsa andando in piscina :uhm:
Inviato dal mio iPad Pro utilizzando Tapatalk Pro
In che senso?
Dici che dovrei passare all'assembler del 68k o processori più "moderni"?
potrei... o all'ARM...
ma non conoscendone le caratteristiche, dovrei partire da 0
In che senso?
Dici che dovrei passare all'assembler del 68k o processori più "moderni"?
potrei... o all'ARM...
ma non conoscendone le caratteristiche, dovrei partire da 0
No: mi chiedevo perche' non stai usando una delle modalita' grafiche native del C64 (HiRes, MCI e Multicolor: http://www.studiostyle.sk/dmagic/gallery/gfxmodes.htm).
Potresti lavorare in 320x200 invece che 80x50
http://www.atarimagazines.com/compute/issue55/64hires.php
La bisogna saper usare bene Caroline ed i timing... raster... interrupt e sarcazzi
Tanta roba...
magari la tiro su, una demo...
vediamo se scrivo una routine per un frattale mandelbrot in 80x50 a colori...
https://preview.ibb.co/iqSzyQ/2017_06_30_1.png (https://ibb.co/dLOHk5)
tenete... sborrateci sopra
http://www.memegen.it/m/dv10aw.jpg
adesso sto facendo un softscroll di una scrittona con quei font (4x4) con la dicitura "J4S COVO DI RICCHIONI" ...
qualche rigo sotto qualche barra con una scrittona 2x con font (4x8) con la dicitura "KYMYA REGNA"
e poi ho quasi completato la conversione di DESTINY per commodore64.
no....
wait...
quest'ultima frase potrebbe essere usata come arma contro di me
https://preview.ibb.co/iqSzyQ/2017_06_30_1.png (https://ibb.co/dLOHk5)
tenete... sborrateci sopra
Quelle righe e quel punto sembrano sborrate a dire il vero
^
"L'uomo che sborrava pixel"
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.