Newsgroup: it.hobby.elettronica.digitale
Titolo: Semplice controller grafico

Salve a tutti.
E' da un po' di tempo che mi frulla l'idea di fare un "semplice" 
controller grafico partendo da una ram statica di piccolo taglio, tipo 8 
o 16KB
Escludendo l'interfacciamento della ram con il bus di un microprocessore 
8bit classico per scrivere i singoli bit (pixel), qualcuno ha idea di 
come effettuare la scansione della ram per generare riga per riga un 
segnale video da applicare a un televisore o monitor videocomposito?
Con 8KB verrebbe fuori una risoluzione tipo 256x256 pixel monocromatico.
E' una cosa che volevo provare a fare come concetto più che per la sua 
utilità, e possibilmente mi piacerebbe evitare i vecchi controller crt 
degli anni '70 e '80... pensavo a una serie di contatori e shift register.
grazie per l'aiuto e per la compassione. :-)
-- 
Prima di rispondermi devi togliere le dita dal naso!!! :-)

 degli anni '70 e '80... pensavo a una serie di contatori e shift register.
Penso che ti serva un classico convertitore da RGB a PAL... non so se ti 
riferisci a questi quando parli di "vecchi controller crt degli anni '70 e '80".

 serie di contatori e shift register.
Non è banale generare un segnale videocomposito con logica
discreta! Ti servirebbero un mare di contatori e comparatori,
oppure una complessa macchina a stati. Il problema maggiore
sono i sincronismi. Senza considerare il fatto che per scrivere
nella memoria ti serve o un "arbitro" o una memoria a doppia
porta. Generare un segnale VGA invece è relativamente più
semplice...
A.D.

A.D. ha scritto:

ciao!
mi dici quello che già temevo, ovvero della complessità del generare un 
segnale video composito.
questo si può anche scartare comunque, l'idea di pilotare un monitor vga 
è altrettanto interessante.
hai qualche spunto?
grazie, ciao.


pozz ha scritto:

in realtà il controller crt serviva per generare gli indirizzi della 
memoria video e i sincronismi.
il convertitore che dici sarebbe al limite alla fine di tutto il circuito.
ciao.


 Salve a tutti.  (cut)
dai un occhio qui
http://www.rickard.gunee.com/projects/video/pic/pong.php
ha fatto un clone di pong con un pic usando il pic per generare un 
"primordiale" segnale videocomposito
Saluti
AlphaPi

 ha
scritto:

Non è molto complicato, è stato il mio primo progetto "importante" negli
anni
'70. Il problema era soprattutto il costo delle RAM, un KB costava quanto un
GB di oggi, senza considerare l'inflazione!
Contatori che fanno la scansione della memoria, DAC a resistenze per avere
16 livelli di grigio, macchina stati per generare i sincronismi e le varie
temporizzazioni.
In particolare la macchina a stati l'avevo fatta un po' ibrida, usando
logiche e
monostabili per poter regolare la larghezza dei sincronismi, la posizione e
il pixel rate.
La scrittura alla ram avveniva multiplexando brutalmente il bus tra questo
controller video e il bus della CPU (8080). Per evitare i disturbi sul video
la scrittura veniva fatta solo nei periodi di blanking, quando i contatori
della
scansione sono fermi.
In tutto ho impiegato una dozzina tra TTL 74xx e CMOS 40xx. Unico neo, per
un mio errore nella progettazione della macchina a stati, la scansione si
fermava
un pixel prima del necessario, portando una risoluzione di 255x256.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

brown fox ha scritto:

arrivo con trent'anni di ritardo insomma. :-)
D'altra parte in quegli anni ero io stesso in fase di progettazione.
interessante comunque la tua esperienza, hai qualche documentazione 
d'epoca da sottopormi su cui studiare?
se avessi lo schema da spulciare sarebbe ottimo!
in particolare però sarebbero utili i dettagli per sviluppare la 
macchina a stati.
Intanto grazie.


 controller grafico partendo da una ram statica di
<cut>
Ciao, è da un pò di tempo che mi frulla nel capo l' idea di fare
un 'accrocco del genere (per puro studio e divertimento, s' intende).
La cosa me la immagino così:
un buffer ram (RB)che contiene una riga video di 64 caratteri
scandita da un controllore che genera il segnale video. Potrebbe
essere un' uscita VGA con ogni punto di riga formato da 4 bit:3
bit colore e uno di intensità, due pixel per byte. Ad ogni fine
di riga  RB verrebbe rinfrescata dalla ram lato processore
video(RV)(per es. 128K)in questo modo
1)mentre RB viene scandita e la riga inviata in uscita, RV è a
disposizione per scrittura di testo/grafica da parte del
processore video
2)alla fine della riga, durante il blank, viene mandato un bus
request al processore video, una riga di RV viene copiata in RB,
il bus ritorna al processore video e viene scandita la riga
successiva presente in RB.
Questa configurazione comporta l' uso di ram ad alta velocità (12
 ns) per trasferire la riga video da RV a RB nel solo tempo di
blank; questo giustifica la scelta di 64 caratteri come un
compromesso accettabile. Queste memorie si trovano sulle vecchie
schede video con tagli di 32/64 K per quattro soldi.
Il processore video funzionerebbe a tempo pieno, salvo il tempo
di copiatura di una riga. Come processore video si potrebbe usare
anche il buon vecchio Z80 nella versione a 20 Mhz (il motivo è
che lo conosco molto bene, ed è facile da usare; andrebbe bene
qualsiasi altro controllore)
E' solo un' idea che giace da diversi mesi su qualche foglio di
carta, spero ti possa servire.
ciao - S.
-- 
Postato da Alice Newsgroup: lo usi da web ma con le funzioni del newsreader 
http://newsgroup.alice.it
Gerarchie it, italia, it-alt, tin, it.binari. Unico!

Sandro ha scritto:

ciao, grazie anche per i tuoi spunti.
hai qualche appunto, schema a blocchi, ecc... da condividere?
anche se in realtà mi affascina di più l'idea di un controller più 
spartano, a semplici integrati logici anziché a processore.
ciao.


 o 16KB
Ci vuole tanta pazienza!
Per iniziare, prova qui:



--- OOPS: mi è partito un invio (cit.) ---
http://elm-chan.org/works/crtc/report.html
http://elm-chan.org/works/sc/report.html

SilverLeo ha scritto:

grazie, collegamenti molto interessanti.
un buon spunto però per me sarebbe quello di sapere come deve essere la 
sequenza delle operazioni.
Ad esempio, dopo il reset o subito dopo l'arrivo dell'alimentazione, 
qual'è il segnale che deve pertire per primo?
Il sincronismo verticale? Quello orizzontale?
O deve partire subito la scansione dei pixel e il blanking con i 
sincronismi arriva dopo?
Grazie
