Risposta Stile Testo Dimensione:  10 12 14 16 18 20 24 30 Colore:  Rosso Viola Verde Blu Giallo Grigio Arancio Rosa Allinea:  Centrato Giustificato Linea vuota A capo Altri comandi Emoticons Clicca per riportare il codice nell'area di testo oppure posizionati su un'immagine per vederne il relativo comando. Testo In risposta a saimo [quote=saimo] [quote=schiumacal]Detto questo, volevo però fare io alcune precisazioni, considerando che: non lavoro più ormai sul C=64 dal 1989, oggi ho 50 anni (ottimamente portati... :P ) quindi tutto quello che dico qui, è solo frutto di vecchi ricordi da sviluppatore in assembly su questa stupenda macchina, ma pur sempre sviluppatore di 31 anni fà...[/quote] Grazie del chiarimento. Purtroppo il tempo ci annebbia i ricordi (a me in maniera particolare :eheh:). [quote]Il Commodore 64 come ogni altro sistema ad 8bit dell'epoca, aveva una CPU che poteva accedere ad indirizzi della RAM di 64Kbyte in modalità diretta, ovviamente mediante l'uso di alcune tecniche di sviluppo, si poteva anche andare oltre come quantità di RAM, (si prenda come esempio in Commodore 128...) ma sempre e solo in banchi di memoria di 64Kbyte. Per il Commodore 64 uscirono espansioni di RAM da 256Kbyte, che potevano essere utilizzate con il GEOS ad esempio... ma il sistema poteva accedere massimo a finestre di 64Kbyte per volta, questo era un limite di moltissime CPU ad 8bit. Forse solo la CPU del Dragon64 e del Dragon32 poteva accedere a una quantità di RAM maggiore, se non erro era una CPU con registri interni a 16 bit anche se esternamente usciva sempre ad 8bit (questo però non lo ricordo di preciso). Ritornando al discorso del Commodore 64, i famosi 64Kbyte di RAM erano in effetto 65535 byte, (perchè un Kbyte equivale a 1024 byte), e considerando il byte iniziale uguale a zero(0), da questo a 65535 si hanno appunto 65536 byte in totale.[/quote] Al riguardo dell'ultima riga, ti si è incartato un po' il discorso, però mi è chiaro cosa volevi dire, e cioè (lo dico per chi non ha le conoscenze necessarie) che gli indirizzi vanno da 0 a 65535, per un totale di 65536 byte. Comunque, certo, la CPU (6510) ha uno spazio di indirizzamento di 64 kB, ma, appunto come confermi tu stesso, quello non è il limite della RAM del sistema (è esattamente lo stesso concetto che ho espresso io). [quote]Sempre di questi 65536 byte, il VIC II ne utilizza 1000 byte per il set di caratteri dello schermo e 24 byte per i puntatori degli 8 sprite hardware. Da qui si deduce che in pratica 1Kbyte viene riservato a questo scopo... penso ti riferivi a questo quando parlavi sopra del nybble riservato ai caratteri.[/quote] La quantità di memoria usata dal VIC e il modo in cui la usa dipende dalla modalità video. I 1000 byte di cui parli tu sono quelli della memoria schermo nelle modalità a caratteri. I puntatori degli sprite richiedono solo 8 byte, non 24, ma immagino che tu ti confonda perché erano gli ultimi 8 byte del kilobyte in cui è allocata la memoria dello schermo. In pratica, partendo da un offset pari a 0: * 0...999: indici dei caratteri * 1000...1015: inutilizzati * 1016...1023: puntatori sprite. [quote]Insomma questo per dire che alla fine sempre 64Kbyte aveva il Commodore 64... Corregimi se ho capito male io, quello che intendevi dire...[/quote] No, non volevo dire quello, ma volevo proprio dire che il C64 ha 64 kB + 1000 nybble, cioè l'equivalente di 65536 + 500 = 66036 byte di memoria. La COLOR RAM, il cui spazio di indirizzamento va da $d800 a $dbff (quindi di grandezza 1 kB), è una memoria di 1000 celle a 4 bit. [quote]La moltiplicazione degli sprite, era sempre virtuale,[/quote] Devo fare una premessa circa l'uso della parola "virtuale": in assoluto, nella tua frase va bene, nel senso che l'hardware di sprite ne ha solo 8, però se ne possono mostrare di più, come se, "virtualmente", l'hardware ne possedesse di più; però, siccome la stessa parola era stata usata anche per i colori, allora non va bene perché mentre i colori disegnati su schermo sono effettivamente sempre e solo 16, e sembrano di più (in modo sfarfallante) solo per effetti visivi, gli sprite disegnati sullo schermo possono essere effettivamente di più di 8 (cioè, non è un'impressione, ma sono proprio fisicamente disegnati su schermo). Di nuovo mi scuso per la puntigliosità, ma chi non è esperto in materia potrebbe farsi un'idea errata e magari pensare che gli sprite "moltiplicati" siano solo un'illusione come i colori "moltiplicati". [quote]ma fattibilissima perchè, grazie all'uso magistrale dell'interrupt raster, potevi duplicare 8 sprite diversi per ogni riga larga 21 pixel sullo schermo del C=64, i 21 pixel erano l'altezza di uno sprite (mi pare... fosse 24x21, ragazzi 31 anni fà sono veramente tanti, quindi perdonate se commetto qualche errore, ma il concetto spero si capisca.[/quote] Sì, le dimensioni degli sprite sono 24x21, però anche qui devo chiarire un paio di cose: * la duplicazione di uno sprite può avvenire a partire dalla riga successiva a quella in cui termina lo sprite stesso - cioè, non ci sono righe di 21 pixel, come se fossero una proprietà dello schermo; * l'interrupt non è necessario per la duplicazione: è molto comodo, ma non necessario (infatti, nei miei giochi lo uso ben poco - ad esempio, se la memoria non mi inganna, in [url=https://retream.itch.io/quod-init-exit]QUOD INIT EXIT[/url] non lo uso affatto). A dirla tutta, in realtà è addirittura possibile una moltiplicazione orizzontale: grazie al fatto che il VIC inizia a leggere i dati degli sprite 0, 1 e 2 verso la fine della riga precedente (cicli 58-63, dove 63 è l'ultimo ciclo della riga in assoluto), è possibile fare apparire lo sprite 0 in fondo a quella stessa riga, producendo così un nono sprite sulla stessa riga! Questo effetto fu mostrato per la prima volta nella demo Krestage, se non ricordo male. [quote][quote]Personalmente non lo chiamerei bug: semplicemente, viene sfruttata la logica con cui è implementata la chiusura dei bordi.[/quote] Si, solo che all'epoca, quando ancora non esisteva neanche internet, l'unico modo per documentarsi erano le riviste mensili che compravi in edicola... e una tra le più gettonate in quegli anni, era Personal Computer Club dove queste tecniche venivano spiegate in dettaglio... su queste riviste veniva definito come un bug del Chip VIC II, ecco perchè l'ho derfinito cosi... solo per una mia personale forma di abitudine di vecchi ricordi. :angelo:[/quote] E non è errata ;) Nessuno può dire se si tratta di un bug o meno senza conoscere le intenzioni originali dei progettisti: se la loro intenzione era evitare in modo assoluto che venisse disegnata grafica nei bordi ed erano convinti di aver implementato tale caratteristica correttamente, allora è un bug; altrimenti, hanno semplicemente lasciato la porta aperta (probabilmente per evitare di complicare il VIC-II). [/quote] formattazione A sinistra Giustificata Nessuna

15 Settembre 2020 Postato da: ivano9999 [8Bit e giochi] Utilizzo del bordo schermo

Volevo chiedere se esiste qualche gioco per il c64 che non abbia le classiche bande nere attorno, cioè un gioco che sfrutti tutto lo schermo. Grazie a tutti. Modificato il 18/09/2020 alle ore 07:34:32

Commenti: 23  Aggiungi - Pagine: 1-2

Post inviati: 695	Commento saimo 18 Settembre 2020    13:38:22
	schiumacal Detto questo, volevo però fare io alcune precisazioni, considerando che: non lavoro più ormai sul C=64 dal 1989, oggi ho 50 anni (ottimamente portati... ) quindi tutto quello che dico qui, è solo frutto di vecchi ricordi da sviluppatore in assembly su questa stupenda macchina, ma pur sempre sviluppatore di 31 anni fà... Grazie del chiarimento. Purtroppo il tempo ci annebbia i ricordi (a me in maniera particolare ). Citazione Il Commodore 64 come ogni altro sistema ad 8bit dell'epoca, aveva una CPU che poteva accedere ad indirizzi della RAM di 64Kbyte in modalità diretta, ovviamente mediante l'uso di alcune tecniche di sviluppo, si poteva anche andare oltre come quantità di RAM, (si prenda come esempio in Commodore 128...) ma sempre e solo in banchi di memoria di 64Kbyte. Per il Commodore 64 uscirono espansioni di RAM da 256Kbyte, che potevano essere utilizzate con il GEOS ad esempio... ma il sistema poteva accedere massimo a finestre di 64Kbyte per volta, questo era un limite di moltissime CPU ad 8bit. Forse solo la CPU del Dragon64 e del Dragon32 poteva accedere a una quantità di RAM maggiore, se non erro era una CPU con registri interni a 16 bit anche se esternamente usciva sempre ad 8bit (questo però non lo ricordo di preciso). Ritornando al discorso del Commodore 64, i famosi 64Kbyte di RAM erano in effetto 65535 byte, (perchè un Kbyte equivale a 1024 byte), e considerando il byte iniziale uguale a zero(0), da questo a 65535 si hanno appunto 65536 byte in totale. Al riguardo dell'ultima riga, ti si è incartato un po' il discorso, però mi è chiaro cosa volevi dire, e cioè (lo dico per chi non ha le conoscenze necessarie) che gli indirizzi vanno da 0 a 65535, per un totale di 65536 byte. Comunque, certo, la CPU (6510) ha uno spazio di indirizzamento di 64 kB, ma, appunto come confermi tu stesso, quello non è il limite della RAM del sistema (è esattamente lo stesso concetto che ho espresso io). Citazione Sempre di questi 65536 byte, il VIC II ne utilizza 1000 byte per il set di caratteri dello schermo e 24 byte per i puntatori degli 8 sprite hardware. Da qui si deduce che in pratica 1Kbyte viene riservato a questo scopo... penso ti riferivi a questo quando parlavi sopra del nybble riservato ai caratteri. La quantità di memoria usata dal VIC e il modo in cui la usa dipende dalla modalità video. I 1000 byte di cui parli tu sono quelli della memoria schermo nelle modalità a caratteri. I puntatori degli sprite richiedono solo 8 byte, non 24, ma immagino che tu ti confonda perché erano gli ultimi 8 byte del kilobyte in cui è allocata la memoria dello schermo. In pratica, partendo da un offset pari a 0: * 0...999: indici dei caratteri * 1000...1015: inutilizzati * 1016...1023: puntatori sprite. Citazione Insomma questo per dire che alla fine sempre 64Kbyte aveva il Commodore 64... Corregimi se ho capito male io, quello che intendevi dire... No, non volevo dire quello, ma volevo proprio dire che il C64 ha 64 kB + 1000 nybble, cioè l'equivalente di 65536 + 500 = 66036 byte di memoria. La COLOR RAM, il cui spazio di indirizzamento va da $d800 a $dbff (quindi di grandezza 1 kB), è una memoria di 1000 celle a 4 bit. Citazione La moltiplicazione degli sprite, era sempre virtuale, Devo fare una premessa circa l'uso della parola "virtuale": in assoluto, nella tua frase va bene, nel senso che l'hardware di sprite ne ha solo 8, però se ne possono mostrare di più, come se, "virtualmente", l'hardware ne possedesse di più; però, siccome la stessa parola era stata usata anche per i colori, allora non va bene perché mentre i colori disegnati su schermo sono effettivamente sempre e solo 16, e sembrano di più (in modo sfarfallante) solo per effetti visivi, gli sprite disegnati sullo schermo possono essere effettivamente di più di 8 (cioè, non è un'impressione, ma sono proprio fisicamente disegnati su schermo). Di nuovo mi scuso per la puntigliosità, ma chi non è esperto in materia potrebbe farsi un'idea errata e magari pensare che gli sprite "moltiplicati" siano solo un'illusione come i colori "moltiplicati". Citazione ma fattibilissima perchè, grazie all'uso magistrale dell'interrupt raster, potevi duplicare 8 sprite diversi per ogni riga larga 21 pixel sullo schermo del C=64, i 21 pixel erano l'altezza di uno sprite (mi pare... fosse 24x21, ragazzi 31 anni fà sono veramente tanti, quindi perdonate se commetto qualche errore, ma il concetto spero si capisca. Sì, le dimensioni degli sprite sono 24x21, però anche qui devo chiarire un paio di cose: * la duplicazione di uno sprite può avvenire a partire dalla riga successiva a quella in cui termina lo sprite stesso - cioè, non ci sono righe di 21 pixel, come se fossero una proprietà dello schermo; * l'interrupt non è necessario per la duplicazione: è molto comodo, ma non necessario (infatti, nei miei giochi lo uso ben poco - ad esempio, se la memoria non mi inganna, in QUOD INIT EXIT non lo uso affatto). A dirla tutta, in realtà è addirittura possibile una moltiplicazione orizzontale: grazie al fatto che il VIC inizia a leggere i dati degli sprite 0, 1 e 2 verso la fine della riga precedente (cicli 58-63, dove 63 è l'ultimo ciclo della riga in assoluto), è possibile fare apparire lo sprite 0 in fondo a quella stessa riga, producendo così un nono sprite sulla stessa riga! Questo effetto fu mostrato per la prima volta nella demo Krestage, se non ricordo male. Citazione Citazione Personalmente non lo chiamerei bug: semplicemente, viene sfruttata la logica con cui è implementata la chiusura dei bordi. Si, solo che all'epoca, quando ancora non esisteva neanche internet, l'unico modo per documentarsi erano le riviste mensili che compravi in edicola... e una tra le più gettonate in quegli anni, era Personal Computer Club dove queste tecniche venivano spiegate in dettaglio... su queste riviste veniva definito come un bug del Chip VIC II, ecco perchè l'ho derfinito cosi... solo per una mia personale forma di abitudine di vecchi ricordi. E non è errata Nessuno può dire se si tratta di un bug o meno senza conoscere le intenzioni originali dei progettisti: se la loro intenzione era evitare in modo assoluto che venisse disegnata grafica nei bordi ed erano convinti di aver implementato tale caratteristica correttamente, allora è un bug; altrimenti, hanno semplicemente lasciato la porta aperta (probabilmente per evitare di complicare il VIC-II).
	RETREAM - sogni retro per Amiga, Commodore 64 e PC