Mený principale
 Notizie
 Grafica
 Forum
 Links
 Retro Trailer
 Recensioni
 Modelli Amiga
 Storia Amiga
 Retro-Gamers
 Lista Utenti
 Contatti
 Policy sito
Ricerca Google

Login

Nick


Password


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: 20  Aggiungi  - Leggi

Indice: Forum / L'angolo degli 8Bit


amig4be

Post inviati: 2697

Visulizza profilo Messaggio Personale
93.37.178.*** Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36
Commento 1
amig4be 16 Settembre 2020    00:50:34
Se non ricordo male sono molti i giochi che sfruttano i bordi verticali (sopra e sotto) meno quelli a sx e dx. In genere però non c'è della bitmap grafica che scrolla, ma animazioni realizzate con gli sprite. Come giochi mi vengono in mente Draconus e Creatures 2...

Commento modificato il 16/09/2020 alle ore 00:53:59


[ EBOOK/LIBRO - Blender 2.8 Grafica e Animazione 3D]

[free EBOOK - Evoluzione della Computer Grafica 3D]

[ EBOOK/LIBRO - 64K Ram (64kB che sconvolsero l'informatica) Edizione 2020]

[Commodore Computer Blog]

[librologica]

[free eBook: "Amiga, da informatica a religione"]

Jay Miner (Hi-Toro) e Tony Wilen (WinUAE). L'alfa e l'omega della storia Amiga.


Post inviati: 6923

Visulizza profilo Messaggio Personale
79.12.104.*** Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36
Commento 2
DanyPPC 16 Settembre 2020    08:28:08
Qualche vecchio gioco e nuovi pd di questo periodo sfruttano il bordo laterale con righe colorate come continuo dello schermo centrale, ma come dice amig4be raramente i bordi laterali sono usati per qualche effetto con gli sprites, specie demo grafiche.

La maggior parte sfrutta i bordi superiore ed inferiore come Turbo Out Run (per il cruscotto auto), Galencia per i punteggi, Frogger Arcade per replicare lo schermo originale in verticale tipico da bar, ecc...

Gli unici 8bit sui quali ho visto sfruttare il bordo per intero per la grafica sono l'Amstrad CPC e l'Atari 800 XL. Niente MSX o Spectrum.

In ambito Vic20 invece c'è qualche gioco che lo sfrutta come Bewitched, oltre a qualche altro.
Curioso che il Vic20 permettesse una cosa del genere mentre il C64 ci riesce solo attraverso l'uso degli sprites.

In ogni caso il C64 ha una risoluzione grafica superiore al fratellino e resta la migliore macchina 8bit dell'epoca. Basta guardare una qualsiasi demo della scena per rendersi conto che non potrai mai vedere cose del genere sugli altri 8bit.

L'unico che può superarlo è la serie CPC PLUS dell'Amstrad, e basta guardare la conversione di PANG della Ocean per rendersene conto, ma era comunque una serie uscita dopo ed in ritardo quando già i 16bit si erano insediati sul mercato facendo strabuzzare gli occhi di milioni di ragazzi appassionati di videogiochi.

A1200T OS3.9 BB4 PPC 240/060/256MB/BVision/IndivisionAGA MK2cr/BMon Switch/HD 80GB/DVD-RW/Drive 1,76Mb/Honey Bee CD32 Pad

A1200 OS3.9 BB4 ACA030/42/128MB/CF8GB/PCMCIA 4GB/PSX Adapter

A1200 OS3.1.4 030/50/64MB/CF16GB/PCMCIA 4GB/PSX Adapter

A1200 OS 3.1 2MB

A600 OS2.0 2MB/Gotek/Sega Pad

Post inviati: 117

Visulizza profilo Messaggio Personale
37.120.137.*** Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36
Commento 3
ivano9999 16 Settembre 2020    12:35:55
Grazie delle risposte, comunque anche il T994/a i giochi erano a schermo intero per quanto riguarda l' msx molti giochi erano a schermo intero mi vengono in mente
Yie Ar Kung Fu 2 penguin e H.E.R.O.

Utente maleducato messo in ignore amiwell79

Post inviati: 6923

Visulizza profilo Messaggio Personale
79.12.104.*** Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36
Commento 4
DanyPPC 16 Settembre 2020    14:01:57
In risposta a ivano9999
ivano9999

Grazie delle risposte, comunque anche il T994/a i giochi erano a schermo intero per quanto riguarda l' msx molti giochi erano a schermo intero mi vengono in mente
Yie Ar Kung Fu 2 penguin e H.E.R.O.



L'MSX usa uno schermo di 256 x 192 pixel con aspect ratio di tipo pixel rettangolare esteso in orizzontale. I bordi laterali erano limitati, quasi invisibili, ma non per questo si può dire che i giochi usassero tutto lo schermo intendendo anche l'uso del bordo. Assolutamente.

A1200T OS3.9 BB4 PPC 240/060/256MB/BVision/IndivisionAGA MK2cr/BMon Switch/HD 80GB/DVD-RW/Drive 1,76Mb/Honey Bee CD32 Pad

A1200 OS3.9 BB4 ACA030/42/128MB/CF8GB/PCMCIA 4GB/PSX Adapter

A1200 OS3.1.4 030/50/64MB/CF16GB/PCMCIA 4GB/PSX Adapter

A1200 OS 3.1 2MB

A600 OS2.0 2MB/Gotek/Sega Pad

Post inviati: 117

Visulizza profilo Messaggio Personale
82.102.24.*** Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36
Commento 5
ivano9999 16 Settembre 2020    20:14:03
Ma poi perche si usavano le bande nere attorno al gioco e ai programmi il processore troppo limitato, ma questo succedeva anche sul c128 che era un tantino piu veloce.

Utente maleducato messo in ignore amiwell79

Post inviati: 514

Visulizza profilo Messaggio Personale
2.32.199.*** Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:80.0) Gecko/20100101 Firefox/80.0
Commento 6
saimo 16 Settembre 2020    23:02:09
ivano9999
Ma poi perche si usavano le bande nere attorno al gioco e ai programmi il processore troppo limitato, ma questo succedeva anche sul c128 che era un tantino piu veloce.

Al tempo i computer erano fatti per essere connessi ai televisori CRT, la cui area ettettivamente utilizzabile e il suo centramento variava da modello a modello, per non parlare dell'estrema deformazione dell'immagine verso i bordi dello schermo fisico. Perciò i computer mandavano un segnale che sfruttasse una buona area che si supponeva finisse più o meno al centro di ogni schermo. Tutto ciò che era al di fuori di tale area era considerato "bordo". Oggi il problema non si pone più perché usiamo dispositivi digitali, che hanno i pixel definiti con esattezza.

Commento modificato il 17/09/2020 alle ore 18:27:03

Post inviati: 6923

Visulizza profilo Messaggio Personale
79.12.104.*** Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36
Commento 7
DanyPPC 17 Settembre 2020    07:43:06
Infatti all'epoca giocavamo in una "finestra" dello schermo, ma per noi era normale, non ci facevamo caso. Quando un gioco impiegava parte del bordo era un evento perchè metteva in risalto ,a nostro modo di vedere, le capacità di una macchina di sfruttare anche il bordo schermo.

Bordo schermo che noi credevamo servisse solo per le famose "righe colorate" di caricamento da tape. Nient'altro.

Lo spectrum era l'8bit con il bordo più esteso.

Già con i 16bit e la possibilità di utilizzo dell'area overscan il problema (se così possiamo definirlo) è stato in parte superato. Oggi, come dice Saimo, grazie alla tecnologia digitale si ha una perfetta corrispondenza dei pixel sull'area di tutto lo schermo.

A1200T OS3.9 BB4 PPC 240/060/256MB/BVision/IndivisionAGA MK2cr/BMon Switch/HD 80GB/DVD-RW/Drive 1,76Mb/Honey Bee CD32 Pad

A1200 OS3.9 BB4 ACA030/42/128MB/CF8GB/PCMCIA 4GB/PSX Adapter

A1200 OS3.1.4 030/50/64MB/CF16GB/PCMCIA 4GB/PSX Adapter

A1200 OS 3.1 2MB

A600 OS2.0 2MB/Gotek/Sega Pad

Post inviati: 3146

Visulizza profilo Messaggio Personale
151.60.168.*** Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Commento 8
Mck 17 Settembre 2020    08:03:14
Forse mi sbaglio io ma non utilizzavano tutto lo schermo per il costo eccessivo delle ram di allora.
Per aumentare la dimensione dello schermo visibile occorreva aumentare la ram video.

I MIEI AMIGA

4000T OS 3.9 PPC/68060 + CyberVisio 64/3D + HD 20g + DVD - 4000D in Tower OS 3.9 PPC/68060 Ram 128M + ram scheda 2+16M + zip 100M + Ide HD 40G + usb Deneb + V-Lab + Toccata + Mediator con: Woodoo 3 + Scheda rete + Impact Vision 24 - 4000D OS 3.9 68060 ram 32m + ram scheda 2+16M + HD 20g + zip 100 ide + DVD + V-lab + Seriale veloce + Scheda video EGS- 3000T OS 3.9 PPC/68060 128M + HD scsi 10G + Usb Deneb + CD sCSI + mediator con: scheda rete + controllo SCSI Adaptec + scheda audio + Voodoo 5 - 3000 OS 3.1 68040 + emulatore pc 286 - 2000 processore 68030 + genlock + espansione ram + emulatore pc 8080 - 1200 Tower OS 3.9 PPC/68060 + HD 20G + Mediator con: scheda rete - 1200 OS 3.1 68060 + HD 20G + Scheda rete pcmcia - 1000 espansione Ram 4M - 600 con espansione ram + HD5G - 500 Plus con espansione ram - 500 con espansione ram - CDTV - CD32

CLONI AMIGA

Sam440ep-Flex OS 4.1 - EFIKA MorphOS 2.6

Post inviati: 6923

Visulizza profilo Messaggio Personale
79.12.104.*** Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36
Commento 9
DanyPPC 17 Settembre 2020    08:54:51
Bhè, se questo era uno dei motivi principali (ram video disponibile) e quindi l'utilizzo di un maggior numero di pixel sullo schermo è comprensibile.
Adattare la finestra a tutto schermo d'altra parte avrebbe ingrandito i pixel, già blocchettosi per conto loro, specie su Amstrad, C64 e Atari, rendendo il tutto troppo simile ai "LEGO" (famoso giocattolo per costruzioni).



Accontentiamoci, dai su !

A1200T OS3.9 BB4 PPC 240/060/256MB/BVision/IndivisionAGA MK2cr/BMon Switch/HD 80GB/DVD-RW/Drive 1,76Mb/Honey Bee CD32 Pad

A1200 OS3.9 BB4 ACA030/42/128MB/CF8GB/PCMCIA 4GB/PSX Adapter

A1200 OS3.1.4 030/50/64MB/CF16GB/PCMCIA 4GB/PSX Adapter

A1200 OS 3.1 2MB

A600 OS2.0 2MB/Gotek/Sega Pad

Post inviati: 514

Visulizza profilo Messaggio Personale
2.32.199.*** Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:80.0) Gecko/20100101 Firefox/80.0
Commento 10
saimo 17 Settembre 2020    18:33:00
Mck
Forse mi sbaglio io ma non utilizzavano tutto lo schermo per il costo eccessivo delle ram di allora.
Per aumentare la dimensione dello schermo visibile occorreva aumentare la ram video.

Era il più semplice dei fattori: più pixel = più dati = più RAM, ma soprattutto più roba che viaggia su bus e più roba da scrivere = servivano bus e CPU più potenti.

Post inviati: 1791

Visulizza profilo Messaggio Personale
109.53.22.*** Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:80.0) Gecko/20100101 Firefox/80.0
Commento 11
schiumacal 17 Settembre 2020    19:12:09
Quelli erano anni in cui il limite massimo di RAM era stato raggiunto.

64 Kbyte di RAM ad indirizzamento diretto, era il limite a cui poteva arrivare la CPU del Commodore 64.
Ed il Commodore 64 era uno degli home computer più potenti dell'epoca degli 8 bit.

Anche altri sistemi ad 8 bit non andavano oltre l'indirizzamento dei classici 64 Kbyte di RAM.
Ad esempio lo ZX Spectrum aveva addirittura meno RAM, erano solo 48 Kbyte di RAM.

Ovviamente tutta questa RAM doveva essere suddivisa tra: Audio, Video, e codice sorgente.

Si può immediatamente immaginare quanto un Commodore 64 fosse spremuto fino all'ultimo byte nel momenmto in cui si realizzavano creazioni Video di notevole impatto.
I limiti in cui con il chip video Vic II si potevano creare solo immagini a 320x200 a due colori, oppure 160x200 a 4 colori presi da una palette di 16 colori in totale, erano stati superati con tecniche di programmazione da veri geni.

Quello che salvava tutto era sempre il famoso raster, che gestito nella maniera oppurtuna, permetteva l'utilizzo anche di 196 colori virtuali e di sprite multipli, tutto in contemporeanea.

Creare grafica sui bordi dello schermo era possibile grazie ad un bug del chip Vic II che venne scoperto negli anni successivi e sempre grazie anche alla gestione del raster.

Anche gli Atari erano inferiori al C=64... l'atari 800 che era il modello di punta della casa madre non raggiungeva ler stesse qualità del Commodore 64.
E cosi pure il BBC micro, famoso in England per l'uso che se ne faceva nelle scuole, ma niente a che vedere con il Commodore 64.

Solo dopo divewrsi anni molti sviluppatori iniziarono a creare per Amstrad CPC, perchè dotato di una gestione della grafica leggermente migliore rispetto al C=64.

Ma ormai il C=64 lo conoscevano tutti fino all'ultimo suo segreto di programmazione.
Niente poteva superare le caratteristiche del nostro piccolo Commodore.


Un giorno o l'altro risolverò equazioni di grado superiore a cinque.



http://www.schiumacal.altervista.org/

Post inviati: 514

Visulizza profilo Messaggio Personale
2.32.199.*** Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0
Commento 12
saimo 17 Settembre 2020    22:56:03
@schiumacal

Ti chiedo scusa in anticipo perché la mia risposta potrà sembrare antipatica e pedante, ma la mia intenzione è solo fare alcune precisazioni al fine di evitare che chi legge si possa fare idee sbagliate.


schiumacal
Quelli erano anni in cui il limite massimo di RAM era stato raggiunto.

64 Kbyte di RAM ad indirizzamento diretto, era il limite a cui poteva arrivare la CPU del Commodore 64.
Ed il Commodore 64 era uno degli home computer più potenti dell'epoca degli 8 bit.

Per l'esattezza, il Commodore 64 è dotato di 64 kB + 1000 nybble (l'equivalente di 500 byte) di RAM: i 1000 nybble sono quelli della COLOR RAM, cioè la RAM che definisce i colori dei caratteri dello schermo.
Poco, ma comunque oltre i 64 kB di RAM. Segnalo questo per chiarire che il limite di indirizzamento della CPU non è un limite assoluto, che impedisce di aggiungere RAM. Tant'è che poi c'erano anche le espansioni tipo REU e, per restare alla macchina base, anche 8 kB di BASIC ROM, 8 kB di KERNAL ROM, 4 kB di CHARGEN ROM e lo spazio di indirizzamento di VIC, SID, CIA e I/O (il tutto per 88 kB di spazio di indirizzamento totale).
Secondariamente, devo ribadire che la quantità di RAM non era l'unico (e nemmeno il principale) fattore che limitava la risoluzione dello schermo (si veda il mio post precedente), tant'è che il VIC-II, così com'è, riesce a vedere 16 kB di RAM alla volta, e in 16 kB ci si può mettere ben più che una schermata 320x200 (che richiede 8000 byte per i pixel e 1000 byte per i colori, cioè 9000 byte in totale).

Citazione
Quello che salvava tutto era sempre il famoso raster, che gestito nella maniera oppurtuna, permetteva l'utilizzo anche di 196 colori virtuali e di sprite multipli, tutto in contemporeanea.

Lasciami chiarire il significato di "virtuali" (ammesso che abbia indovinato a cosa ti riferisci). L'effetto di apparente moltiplicazione dei colori si ottiene in maniera simile all'interlacciamento, e cioè mostrando a frame alternati immagini diverse: poiché questo avviene a 50 Hz e grazie alla persistenza dei fosfori del CRT, due colori diversi sembrano mischiarsi in un colore nuovo. Però era solo un trucco (che, peraltro, con i monitor moderni funziona molto meno perché la persistenza è nettamente ridotta). I colori, quindi, restano sempre 16.
Mentre la moltiplicazione degli sprite, pur con specifici (e pesanti) limiti, è reale.

Citazione
Creare grafica sui bordi dello schermo era possibile grazie ad un bug del chip Vic II che venne scoperto negli anni successivi e sempre grazie anche alla gestione del raster.

Personalmente non lo chiamerei bug: semplicemente, viene sfruttata la logica con cui è implementata la chiusura dei bordi.

Commento modificato il 17/09/2020 alle ore 22:58:40

Post inviati: 6923

Visulizza profilo Messaggio Personale
79.12.104.*** Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36
Commento 13
DanyPPC 18 Settembre 2020    07:33:48
In risposta a schiumacal
schiumacal

I limiti in cui con il chip video Vic II si potevano creare solo immagini a 320x200 a due colori, oppure 160x200 a 4 colori presi da una palette di 16 colori in totale, erano stati superati con tecniche di programmazione da veri geni.


Forse ti riferivi al fatto che si potevano usare solo 2 colori per carattere in 320 x 200 e 4 colori per carattere in 160 x 200. Ma tutti e 16 i colori sono visualizzabili sullo schermo senza alcun limite.
Per contro invece l'Atari 800 XL ne usa al max 5 colori su schermo, ma la CPU ha anche la capacità di cambiare colori sull'intera area dello schermo permettendo di superare il limite dei colori presenti.
In 80 x 200 invece l'Atari visualizza 16 colori, sempre scelti dalla (per allora) ampia palette di 256.

Ogni macchina ha i suoi PRO ed i suoi CONTRO, per quanto comunque il C64 resti una spanna superiore agli altri 8bit. Su questo non ci sono dubbi.

A1200T OS3.9 BB4 PPC 240/060/256MB/BVision/IndivisionAGA MK2cr/BMon Switch/HD 80GB/DVD-RW/Drive 1,76Mb/Honey Bee CD32 Pad

A1200 OS3.9 BB4 ACA030/42/128MB/CF8GB/PCMCIA 4GB/PSX Adapter

A1200 OS3.1.4 030/50/64MB/CF16GB/PCMCIA 4GB/PSX Adapter

A1200 OS 3.1 2MB

A600 OS2.0 2MB/Gotek/Sega Pad

consulenza informatica ambito aziendale - appliance sicurezza - ambienti server multipiattaforma - servizi hosting - networking

Post inviati: 4711

Visulizza profilo Messaggio Personale
94.35.37.*** Mozilla/5.0 (iPhone; CPU iPhone OS 12_4_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1.2 Mobile/15E148 Safari/604.1
Commento 14
divina 18 Settembre 2020    07:50:46
In risposta a DanyPPC
DanyPPC


Ogni macchina ha i suoi PRO ed i suoi CONTRO, per quanto comunque il C64 resti una spanna superiore agli altri 8bit. Su questo non ci sono dubbi.



Se invece dovessimo fare un confronto con le console 8bit, la migliore sarebbe il NES ?

MorphOS 3.13 PowerMac G5 &&Pegasos2 G4 &&AmigaOne G4 //AmigaOS4.1 FE - AMiGA4000T&D PPC/060 &&3000D &&2000 &&1200T&D &&600 &&500+ &&500 &&C=64 - Mac Intel &&PowerPc - x64 servers -

Post inviati: 6923

Visulizza profilo Messaggio Personale
79.12.104.*** Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.102 Safari/537.36
Commento 15
DanyPPC 18 Settembre 2020    08:13:05
@Divina

Il Nintendo ha anche i suoi PRO e CONTRO, se fai una ricerca in rete molti sostengono il Sega Master System (rivale del NES) perchè a differenza di quest'ultimo non adopera chip all'interno delle cartucce e le sue capacità grafico/sonore sono frutto delle scelte hardware originali di Sega.

Ma alla fine non sono le caratteristiche hardware a decretare il successo di una macchina, bensì il software che vi gira. Ed entrambe direi che se la cavano abbastanza bene, per quanto io comunque preferisca leggermente il NES (emulato o attraverso il MiST).

Si è parlato anche di BBC Micro in questa discussione, io la sto provando in questi giorni attraverso il Core BBC sempre su MiST, e devo dire che come hardware non è niente male.
Ho provato la conversione di Phoenix che adopera overscan verticale per simulare lo schermo arcade del gioco e sono rimasto piacevolmente sorpreso dalla qualità di questa conversione, superiore a tutte quelle per gli altri 8bit. Dalla grafica al sonoro sembra di stare davanti al gioco arcade originale. Veramente ben fatto.
E come questo ci sono tanti altri giochi che dimostrano le buone capacità di questo bistrattato 8bit.
Ha una palette del tutto simile all'Amstrad CPC e da quanto provato ci sono giochi che adoperano risoluzioni basse tipiche di C64 e CPC e altri che adoperano l'alta in 4 colori.
Ma il tutto con una fluidità dei movimenti degli sprites che ha dell'incredibile per una macchina di quell'epoca.

A1200T OS3.9 BB4 PPC 240/060/256MB/BVision/IndivisionAGA MK2cr/BMon Switch/HD 80GB/DVD-RW/Drive 1,76Mb/Honey Bee CD32 Pad

A1200 OS3.9 BB4 ACA030/42/128MB/CF8GB/PCMCIA 4GB/PSX Adapter

A1200 OS3.1.4 030/50/64MB/CF16GB/PCMCIA 4GB/PSX Adapter

A1200 OS 3.1 2MB

A600 OS2.0 2MB/Gotek/Sega Pad

Post inviati: 1791

Visulizza profilo Messaggio Personale
109.53.20.*** Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:80.0) Gecko/20100101 Firefox/80.0
Commento 16
schiumacal 18 Settembre 2020    12:09:34
@ DanyPPC
- Si, mi riferivo ovviamente al fatto che i 2 colori in 320x200 e i 4 colori in 160x200 potevano essere variati carattere per carattere, con l'unica limitazione che in 160x200, 3 colori potevano essere variati totalmente, mentre il quarto colore doveva essere uguale tra due griglie di caratteri adiacenti.

- Il BBC Micro non era bistrattato, anzi tutto il contrario. Solo che era famosissimo in Inghilterra perchè utilizzato nelle scuole inglesi, e poco conosciuto in altri paesi. In pratica ogni istituto scolastico inglese all'avanguardia, aveva un'aula con tanti BBC Micro dove studiare. Questo perchè era, credo, l'unico 8bit degli anni '80 ad avere di serie uno schermo ad 80 colonne con risoluzione 640x200.


@ Saimo
Citazione
Ti chiedo scusa in anticipo perché la mia risposta potrà sembrare antipatica e pedante, ma la mia intenzione è solo fare alcune precisazioni al fine di evitare che chi legge si possa fare idee sbagliate.

Ma veramente, stai tranquillissimo, anzi è bello che si possa fare totale chiarezza su argomenti di questo genere. Studiare e imparare cose nuove su tecnologie ad 8bit, è sempre stato di notevole interesse.

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à...

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.

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.
Insomma questo per dire che alla fine sempre 64Kbyte aveva il Commodore 64...

Corregimi se ho capito male io, quello che intendevi dire...

Citazione
Lasciami chiarire il significato di "virtuali" (ammesso che abbia indovinato a cosa ti riferisci). L'effetto di apparente moltiplicazione dei colori si ottiene in maniera simile all'interlacciamento, e cioè mostrando a frame alternati immagini diverse: poiché questo avviene a 50 Hz e grazie alla persistenza dei fosfori del CRT, due colori diversi sembrano mischiarsi in un colore nuovo. Però era solo un trucco (che, peraltro, con i monitor moderni funziona molto meno perché la persistenza è nettamente ridotta). I colori, quindi, restano sempre 16.
Mentre la moltiplicazione degli sprite, pur con specifici (e pesanti) limiti, è reale.

Si, era una tecnica molto utilizzata negli ultimi anni di vita del Commodore 64, l'immagine era sempre uguale, ma con colori diversi, su monitor che avevano frequenza a 50Hz una doppia immagine veniva mostrata due volte con colori differenti per ciclo di clock e grazie anche alla persistenza della retina, oltre che dei vecchi monitor, sembrava di vedere sul Commodore 64 immagini a 192 sfumature di colore.
Dico 192 che ricordi a mente, perchè molti colori erano duplicati di altri e altri colori era impossibile vedere per il limite del famoso quarto colore in comune tra due caratteri adiacenti... insomma alla fine dei 256 colori virtuali, se ne potevano distinguere soltanto 192.

La moltiplicazione degli sprite, era sempre virtuale, 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.

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.

Un giorno o l'altro risolverò equazioni di grado superiore a cinque.



http://www.schiumacal.altervista.org/

AfAOne

Post inviati: 3560

Visulizza profilo Messaggio Personale
87.19.253.*** Mozilla/5.0 (Windows NT 6.1; rv:80.0) Gecko/20100101 Firefox/80.0
Commento 17
AfAOne 18 Settembre 2020    12:25:15
In risposta a schiumacal
schiumacal

non lavoro più ormai sul C=64 dal 1989, oggi ho 50 anni (ottimamente portati... )..

Be non posso che confermare, oltre che confermare la simpatia e la "brava persona", ci siamo conosciuti un paio di anni fa nella mia Città, scusate il piccolo OT

Commento modificato il 18/09/2020 alle ore 12:27:06


Immagine AfA One - AROS One x86
- AROS One 68K - AfA One PPC - Amilator AfA One - Amithlon AfA One - WinUAE OS 4.1 Immagine

Immagine


Post inviati: 514

Visulizza profilo Messaggio Personale
2.32.199.*** Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0
Commento 18
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).

Commento modificato il 18/09/2020 alle ore 13:44:44

Post inviati: 1791

Visulizza profilo Messaggio Personale
109.53.4.*** Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:80.0) Gecko/20100101 Firefox/80.0
Commento 19
schiumacal 18 Settembre 2020    17:19:13
@ AfaOne
Citazione
Be non posso che confermare, oltre che confermare la simpatia e la "brava persona", ci siamo conosciuti un paio di anni fa nella mia Città, scusate il piccolo OT


Grande Carlo... persona squisita veramente come poche, non dimentico la tua pazienza nell'avermi fatto vedere la città da un capo all'altro. Ti ho sempre considerato una persona di fortissima esperienza, sia nella vita che in qualità d'informatico.
Ps. Guarda che non era un paio di anni fà... ahahahahah!!!... è stato soltanto l'anno scorso ad agosto, quando sono venuto in Puglia in vacanza con la mia ragazza.
La mente vacilla...
(scherzo ovviamente... mi permetto solo perchè ci rispettiamo tanto, amico mio).


@saimo
Un pò ti invidio, per la tua freschezza che ancora hai nei confronti del Commodore 64.
Io non tocco un libro sul C=64 da troppi anni ormai...
... oggi, studio e lavoro con tecnologie troppo avanzate per le nostre meravigliose macchine ad 8/16bit.
E' il tempo che mi manca, più che altro, altrimenti mi piacerebbe tantissimo riprendere a svilupparci sopra.

Un giorno o l'altro risolverò equazioni di grado superiore a cinque.



http://www.schiumacal.altervista.org/

AfAOne

Post inviati: 3560

Visulizza profilo Messaggio Personale
87.19.253.*** Mozilla/5.0 (Windows NT 6.1; rv:80.0) Gecko/20100101 Firefox/80.0
Commento 20
AfAOne 19 Settembre 2020    02:00:14
In risposta a schiumacal
schiumacal


La mente vacilla...
(scherzo ovviamente... mi permetto solo perchè ci rispettiamo tanto, amico mio).

Ebbene si amico mio, forse colpa del CoronaVirus che è come se lo avessimo da anni.

Commento modificato il 19/09/2020 alle ore 02:02:36


Immagine AfA One - AROS One x86
- AROS One 68K - AfA One PPC - Amilator AfA One - Amithlon AfA One - WinUAE OS 4.1 Immagine

Immagine



Utenti Online
Utenti registrati: 956 dal 1 Gennaio 2006
di cui online: 1 registrati - Fl@sh -
9 non registrati

Benvenuto all'ultimo utente registrato: giagy80

Buon Compleanno a turok641 - 

© Amigapage 1998 - 2007 - Sito italiano dedicato alla piattaforma Amiga ed evoluzioni varie.
Struttura del sito interamente ideata e realizzata da Marco Lovera e Alessandra Lovera - Tutto il materiale inserito all'interno del sito Ť dei rispettivi autori/creatori.
E' assolutamente vietata la riproduzione o la manipolazione di tutti i contenuti o parte di essi senza l'esplicito consenso degli amministratori e degli autori/creatori.

Eseguito in 0.10033917427063 secondi