Parere su scelta irq (Z80, cose vecchie)

Telespalla Bob ha scritto:

Bene, queste sono esattamente le cose che facevo 30 anni fa! Direi che se l'interfaccia video fosse alfanumerica, quindi non grafica, con generazione dei caratteri realizzata in hardware, la soluzione preferibile sarebbe la 3, cioe' il polling fatto sul blank. Ma dipende anche da quanto spesso e da quanti caratteri devi scrivere, se per esempio devi fare lo scroll via software. In questo caso forse sarebbe piu' efficiente un interrupt. Poi ci sarebbe da considerare anche l'uso dell'istruzione LDDR per trasferire dati in modo efficiente, e usare l'interrupt in modo inverso per bloccarla quando il video esce dal blank... Tu pero' parli di interfaccia grafica, quindi immagino che il segnale video sia la diretta rappresentazione dei bit della memoria. In questo caso la quantita' di dati da muovere tra cpu e memoria sarebbe molto piu' pesante e temo che la scelta tra interrupt e polling sarebbe irrilevante ai fini della velocita'. In queste situazioni dovresti considerare altre soluzioni hardware. Per esempio lavorare su due pagine di memoria: scrivi su una mentre visualizzi l'altra e poi le switchi. Oppure una ram dual port, alla quale accedi contemporaneamente senza problemi dalla CPU e dal controller video. Tutto cio' dando per scontato che tu non voglia usare un controller grafico dedicato!

Il giorno Wed, 18 Aug 2010 10:32:10 +0200, Telespalla Bob ha scritto:

Una ram dual port?

Senza sapere le caratteristiche dalla parte grafica (CGA, VGA?) e i tempi che ti occorrono per fare un rinfresco è difficile esprimere pareri.

Le soluzioni che hai elencato possono funzionare tutte e tre, dipenda da cosa ti aspetti dal sistema, un INT\ o un NMI\ magari con una logica di abilitazione sarebbero secondo me una soluzione possibile.

-- ciao Stefano

cut...

Eoni fa, sullo ZX Spectrum (un attimo di rispettoso silenzio), collegai uno Z80 DMA col preciso scopo di trasferire rapidamente blocchi di memoria. Funzionava parecchio bene, anche se non era in grado di copiare i 6144 byte di schermo nel tempo di un frame. Potresti creare un alias della RAM video e in occasione a cambiamenti attivare il DMA. E' 4 volte pi=F9 veloce della LDIR (o LDDR come giustamente consigliato) e si spoccia il bus per i fatti propri sfruttando anche i tempi di porch di riga. La trasparenza sarebbe il suo grande vantaggio; alla fine del trasferimento genera interrupt in daisy-chain. Per contro, la programmazione del DMA richiede un certo impegno: ha cos=EC tanti registri interni che sembra un'espansione RAM.

Piccio.

Telespalla Bob:

Che risoluzione hai? Che velocità di scrittura ti serve?

Eoni fa ne avevo dotato il mio secondo microcomputer, il primo progetto impegnativo al quale ho lavorato. Per poter sfruttare anche la ritraccia di riga, dato che allora il DMA controller era più costoso e meno reperibile dello Z80, avevo messo un secondo Z80 con una Eprom e un 74373 il cui unico compito era generare i sincronismi per lo schermo e gli interrupt e il wait (che poi però mi pare non usai mai) per lo Z80 principale, che poteva abilitare o meno i segnali a lui indirizzati (o addirittura anche i sincronismi del monitor) scrivendo su di un altro 373 letto dal secondo Z80.

Avevo anche implementato la possibilità di cancellare via hardware la RAM video, ma era utile più che altro per motivi estetici all'accensione e poco più. Non ho mai implementato lo scroll via hardware, quello sì che sarebbe stato utile...

cut...

ti

Un NMI con logica di abilitazione non ha molto senso. Tanto vale usare l'INT normale o un un pin di uno Z80 PIO che torna sempre comodo.

Piccio.

cut...

Potresti utilizzare qualche latch per bloccare address e dato che vengono scritti verso la VRAM in modo che durante la scansione video vengano effettuate sempre una lettura ed una scrittura. La lettura sar=E0 sequenziale per scandire lo schermo mentre la scrittura aggiorner=E0 continuamente l'ultima locazione indirizzata. Una logica di wait pu=F2 permettere di evitare degli overrun. La lettura dalla VRAM da parte della CPU dovrebbe avvenire in una zona di memoria alias sovrapposta alla VRAM. In pratica:

- la architettura si compone di una normale, unica RAM di sistema in cui =E8 mappata anche la VRAM.

- la lettura =E8 diretta (normale accesso RAM)

- la scrittura =E8 diretta come la lettura e scrive address e dato anche in 3 latch (tipo 74LS374) e setta un flag-semaforo.

- la VRAM =E8 mappata in una zona della RAM di sistema

- la scansione video legge solo quest'ultima e non intacca gli accessi di quella di sistema

- quando un dato nei latch =E8 disponibile viene scritto il pi=F9 presto possibile nella VRAM, intercalato con la scansione per avere tempo di risposta brevissimo; il flag viene resettato.

- se la CPU tenta di scrivere nella VRAM con il flag settato, vengono inseriti dei cicli di wait.

Piccio.

Il giorno Wed, 18 Aug 2010 03:01:00 -0700 (PDT), Piccio ha scritto:

Se deve usare un DMA esterno tanto vale usare uno Z180 o meglio uno Z8S180 che oltre alla compatibilità sw con Z80 ha anche 2 TIMER, 2 UART e 2 canali DMA integrati con una velocità di clock fino a 24Mhz.

Oltretutto indirizza fino ad A19 (1M) non in banchi ma con una MMU, un bell'oggettino, l'ho usato proficuamente sino a pochi anni fa.

-- ciao Stefano

Il giorno Wed, 18 Aug 2010 04:51:28 -0700 (PDT), Piccio ha scritto:

Dipende, se gli serve un INT\ per usarlo con quella specie di vettorizzazione con le periferiche che ha lo Z80 può sempre usare NMI\ con mascheratura esterna se gli serve disabilitarlo, io ho fatto così in un paio di occasioni.

Ad esempio NMI\ era usato nel TRS80 per tentare il ripristino in caso di piantamenti software, ma non recuperava mai niente, per cui lo modificai per essere usato come INT\ aggiuntiva per collegare un floppy esterno. La prima versione ne era sprovvista e usava un registratore a cassette.

Bei, tempi (adesso aspetto che F.B. mi ricordi che sono un dinosauro) :-)

-- ciao Stefano

SB:

"dal dsesign piuttosto curato"??? Una delle cose più brutte viste in vita mia.

Ebbeh, se nei primi anni 80 ti potevi permettere un TRS-80 con addirittura un floppy vuol dire che già lavoravi. O che non avevi genitori genovesi?

cut...

Ho dei cloni HITACHI: HD64180

Piccio.

Il giorno Wed, 18 Aug 2010 05:34:15 -0700 (PDT), Piccio ha scritto:

Veo, Hitachi ha fatto un clone Z180 chiamato HD64180 che andava a 6Mhz, ma poi la Zilog ha fatto lo Z8S180 che con il duplicatore interno di clock arriva a più di 24Mhz.

Un bell'oggettino, poi hanno fatto eZ80, inutile perchè oramai erano arrivati gli AVR e poi anche gli ARM.

-- ciao Stefano

Il giorno Wed, 18 Aug 2010 14:29:08 +0200, "F. Bertolazzi" ha scritto:

Studiavo, lavoravo (anche se saltuariamente), trombavo abbastanza e riuscivo pure a fare un paio di attività sportive a buon livello.

Il TRS80 lo recuperai negli USA e con qualche aiuto lo feci arrivare qui, dove poi mi servì come base per costruire un computer industriale eurocard su rack.

Non mi hanno mai fatto mancare nulla ma io ho sempre cercato di approfittare il meno possibile del loro aiuto, che è comunque stato molto grande (UCSB non è una univarsità economica, per esempio)

-- ciao Stefano

Il 18/08/2010 10:32, Telespalla Bob ha scritto:

Caspita quante risposte. Allora, vedo di fornire alcuni dettagli. La risoluzione grafica è 320x204 (204, non 240) pixel indirizzabili singolarmente con 4 bit per pixel (32K di ram statica che pensavo di mappare "sotto" la rom nella prima metà di indirizzamento dello Z80, con la possibilità però di poterla leggere scambiando all'occorrenza il segnale _oe fra rom e ram video, una volta che si è copiato il codice necessario sugli altri 32K di ram statica che completano lo spazio dei

Il tutto è piuttosto rudimentale, niente sprites, niente scroll hardware (a proposito, come dovrei fare?), niente cursori, generatori caratteri, ecc.. e il tutto serve per puro divertimento, con la possibilità però volendo di farci girare qualcosa di più o meno funzionante.

i tempi di refresh sono quelli del PAL.

L'idea della ram dual port può essere interessante, ma se posso mediare con soluzioni accettabili usando una normale ram statica di quelle che si ricavano dalla cache dei vecchi 486 mi va meglio :-)

un esperimento con grafica monocromatica l'avevo già fatto un paio di anni fa e funzionava, ora si tratta di aggiungere il colore (sto verificando propagazione e temporizzazioni, e a livello logico dovrei essere a posto) e interfacciare meglio che posso con la massima semplicità possibile.

Per completare il quadro ho pensato anche ad un'interfaccia per tastiera AT e 5-6 slot in cui inserire eventuali altre periferiche mappate sugli i/o dello Z80.

consigli e/o obiezioni? :-)

ciao.

Il 18/08/2010 11:46, Dimonio Caron ha scritto:

beh, dopo un po' ci sono arrivato pure io! :-)

niente generatore di caratteri, solo bitmap

interessante

questa è la mia situazione.

l'idea era quella di fare tutto nel modo più semplice e rudimentale possibile

esatto :-)

ciao.

Telespalla Bob:

sia i cursori che gli altri sprite si fanno con dei comparatori di indirizzo che mostrano una sezione della RAM anziché quella "giusta". In pratica, fermi restando gli address più bassi (nel tuo caso direi 3), quando l'indirizzo del refresh video è uguale a quello che la CPU ha impostato come posizione dello sprite, gli altri addess vengono forzati all'indirizzo dello sprite.

Lo scroll hardware si fa con dei sommatori sul bus degli indirizzi, sempre lasciando "dritti" i primi tre o quattro. Per "riga", da qui in avanti, intendo tutte le celle indirizzate dagli address lasciati "dritti". All'inizio all'indirizzo di refresh verrà sommato 0. Per fare il primo scroll la CPU cancellerà la riga 0 e scriverà 1 sui sommatori, in modo tale che la prima riga visualizzata sarà la 1 e non la 0. Visto che non c'è riporto, quando verrà rinfrescata l'ultima riga verrà in realtà visualizzata la riga 0.

Chi li genera? Se hai accesso al generatore di sincronismi puoi farti mandare degli interrupt anticipati in modo che la CPU inizi a scrivere, salvati e ricaricati i registri (o dopo aver eseguito exx), immediatamente dopo il sincronismo di riga.

Telespalla Bob ha scritto:

Due ram statiche (o banchi di ram) ad alta velocita?, come quelle che si trovano sulle vecchie mb da 15/20 ns. Una ram dal lato Z80, chiamiamola RZ, l? altra dal lato video, RV; nel mezzo un ?DMA? hardware composto da contatori sincroni e porte di isolamento (74F161/74F245). Durante la scansione di un quadro RV e? letta dal video controller, RZ e? disponibile per qualsiasi operazione RW; le due memorie sono isolate. Nel periodo di ritraccia lo Z80 rilascia il bus (BUSRQ), entrano in azione i contatori e RZ viene copiata alla massima velocità, compatibilmente con il tempo di accesso, in RV. Alla fine della copia i due banchi divengono di nuovo indipendenti. Ad esempio, 64K /15 ns si trasferiscono abbastanza comodamente nel periodo di ritorno verticale. Un? altra osservazione: per trasferire blocchi alla massima velocita? conviene utilizzare LDI (16 cm) al posto di LDIR (21 cm) eg: LDI LDI LDI ?. ?. ?. RET Se LDI viene ripetuto un numero congruo di volte (64/128??) il tempo risparmiato e? considerevole, recuperando il tempo ?perso? con la chiamata della sbr.

ciao - S.

Sandro:

Sarebbe interessante vedere se, con queste memorie moderne, si potesse memorizzare in dei latch l'indirizzo richiesto della CPU ed invece indirizzare e leggere la locazione necessaria al refresh. Dopodichè la RAM dorebbe ancora fare in tempo ad essere letta o scritta dalla CPU con l'indirizzo precedentemente memorizzato. In tal modo, con solo un paio di latch tri-state (il contatore di refresh dovrebbe già essere tri-statizzabile), si otterrebbe il sistema più veloce e semplice possibile, con l'accesso alla RAM assolutamente libero, per la CPU.

Eh, bei tempi... Mi fai ricordare anche lo XOR A, A, molto più veloce e compatto del LD A, 0.

Per non parlare del codice eseguito da RAM (già allora spesso più veloce) ed al codice automodificantesi, tipo mettere un jump in una serie di LDI per uscire da un FOR simulato. Utile in casi come questi, in cui sai in anticipo il numero di iterazioni.

F. Bertolazzi:

Sì, come se non fosse la norma sapere in anticipo quante interazioni avrai per un FOR. I WHILE li hanno inventati dei perdigiorno. :D

Intendevo dire "in casi in cui, anche se perdi un sacco di tempo a mettere e togliere jump (o RET), lo fai usando tempo non critico, mentre il tempo che risparmierai dopo è molto più prezioso".

F. Bertolazzi ha scritto:

Interessante, non ci avevo mai pensato....... In altre parole, se ho capito bene, essendo la ram molto veloce verrebbe "potenzialmente" indirizzata dalla cpu, letta dal video controller e quindi letta/scritta dalla cpu. Il tempo di lettura del vc sarebbe "inglobato" nel ciclo macchina?

ciao - S.