FreeLists / zxspectrum / [zxspectrum] Re: ResiDOS sul badaloc

["Alessandro Poppi" <apoppi@xxxxxxxx>]

Mario wrote:

> Ma nello scan converter non usi una dual port?
Si, ma sull'altro lato. La dual port e` da 32K (due banchi video, come 
necessario sul 128). Ha una porta sul bus Z80 e l'altra sulla cpld che ne 
esegue la lettura. Questa lettura deve pero` essere fatta nel rispetto delle 
temporizzazioni spectrum (ovvero a 50Hz, comprese le eventuali variazioni di 
border) e quindi non puo` finire direttamente sul connettore VGA, che 
funziona a 100Hz.
Ho allora inserito un ulteriore banco da 128K (che e` il vero cuore dello 
scan converter) dove c'e' spazio per due distinti frames, ciascuno da 
64KBytes, in cui ciascun pixel occupa 4 bit (RGB +  BRIGHT) (2 pixel per 
byte) con dimensioni 320 x 256 pixel (= 256x192 schermo spectrum + 32 pixel 
di border tutto intorno, che viene anch'esso convertito in singoli pixel 
letti momento per momento dal registro del border ($FE) in modo che anche 
tutte le variazioni dinamiche (leggi: strisce di caricamento da nastro) 
vengano correttamente riprodotte). Ho due puntatori da 8 bit ciascuno per 
indirizzare riga e colonna del pixel; in ciascuna riga uso solo 160 bytes 
(320 pixel) per cui una parte dello spazio non e` usato (in pratica 
basterebbero 40960 bytes invece di 65536, ma in questo modo l'indirizzamento 
e` piu` semplice (e soprattutto altrimenti non ci stavo con la logica)) :-)
E` questa ram da 128K che viene contemporaneamente anche letta al doppio 
della frequenza di scrittura (ovvero 100Hz) e genera il quadro video inviato 
al monitor. Mentre una parte di logica sta leggendo la dual-port da 32K e 
scrivendo in una delle due meta` della 128K alla velocita` di 50 quadri al 
secondo (convertendo lo schema bitmap+attributi dello spectrum --> in 
singoli pixel da 4 bit ciascuno), altra logica (nella stessa cpld) legge DUE 
VOLTE (100Hz) l'altra meta`, che contiene il risultato della conversione 
precedente.
In realta` anche la 128K e` quindi una "dual port", ma in questo caso la ram 
e` normalissima ed il meccanismo e` implementato nella cpld. Cio` pero` 
comporta delle temporizzazioni un po` estreme. Questa e` una sequenza base 
(8 cicli del clock a 85MHz) che genera 2 pixel, scandita dai 3 bit meno 
significativi del contatore di RIGA dei pixel VGA. Address bus e Data bus 
sono quelli della ram da 128K e non sono in comune con nient'altro: vanno 
solo alla CPLD.
Come si vede, in un "blocco" da 8 clock avviene la lettura di un byte (che 
contiene 2 pixel) e (se necessario) la scrittura di un byte proveniente 
dalla conversione dal formato spectrum. Quest'ultima cosa accade esattamente 
solo 1 volta su 3, ovvero una nuova coppia di pixel ogni 24 clock a 85MHz. 
Infatti, la corrispondenza c'e':  lo spectrum produce due pixel ogni ciclo 
di clock da 3.5MHz, e 85/24 fa proprio 3,5 (per la precisione 3,54).
"000"    ADDRESS_BUS <= read_address; DATA_BUS CPLD tri-stated; deactivates 
WR (goes high)
"001"    Ram RD pin is activated (low)

"010"    No changes (data setup time)

"011"    CPLD LATCH <= databus (data read, registered); deactivates RD 
(combinatorial)
"100"    ADDRESS_BUS <= write_address; waiting for ram to go tri-state;

"101"    DATA_BUS <= data to be written (CPLD databus turns in OUTPUT MODE)

"110"    Activates the ram WR pin, ONLY IF SOME DATA NEEDS TO BE WRITTEN

"111"    No changes


Per poterci far stare tutto, Il RD ed il WR restano bassi solo 23ns.

> comunque buono a sapersi, stavo pensando come implementare i 16
> colori per ciascun pixel lasciando la compatibilita' con
> l'organizzazione classica dato+attributo ma per fare questo bisogna
> per forza prelevare 4 byte alla volta, uno per ciascun colore + la
> luminosita'. Per fare questo non bastano i 70ns classici (siamo
> proprio al limite).. una da 15ns e' addirittura sprecata :)
Gia`

> durante le vacanze ho finito l'interfaccia mouse ps2 della quale ti
> parlavo tempo fa, usa il segnale di wait per lasciare il tempo al
> microcontrollore collegato al mouse di gestire l'istruzione di in
> dello Z80, e nonostante diversi cicli di clock vengano persi durante
> l'operazione, il funzionamento e' perfettamente fluido e stabile.
Si, in effetti immagino che qualche clock ogni tanto non possa essere 
percepibile, come del resto non lo e` l'effetto dell'ula
>  qui
> http://velesoft.speccy.cz/kmsoft.htm ci sono diversi giochi e
> applicazioni modificate per l'uso del mouse e devo dire che e' troppo
> divertente giocare a r-type senza tastiera, il gioco delle mine e'
> quasi identico a quello di windows :)
Bene! Quando ho un attimo di tempo li provo anche io :-)

> Inoltre esiste un'estensione dell'interfaccia kempston per utilizzare
> il terzo pulsante e la rotella del mouse, si usa il terzo bit della
> porta 64223 per il pulsante centrale mentre sempre sulla stessa porta
> i 4 bit piu' significativi vengono utilizzati per leggere la rotella.
> al momento pero' non esistono applicazioni che usano la rotella,
> forse qualche roba russa, visto che c'ero l'ho implementato lo stesso
> :)
Accidenti, io credo di non poterlo fare: il bottone centrale l'ho 
implementato, ma ricordo abbastanza bene che in quella cpld non c'era piu` 
spazio nemmeno per 1 bit. Non credo di poterne aggiungere 4. Mah.
Ciao!



--
Email.it, the professional e-mail, gratis per te: http://www.email.it/f

Sponsor:
Corso base ASP Gratis - Video con trucchi e segreti per imparare a creare il 
tuo Sito Web Dinamico con la tecnologia ASP
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=5146&d=10-1