Parere su scelta irq (Z80, cose vecchie)

Il giorno Thu, 19 Aug 2010 10:52:01 GMT, Sandro ha scritto:

In teoria, con cicli macchina di 250nS (4Mhz) potrebbe funzionare, recuperando il tempo alla fine di un ciclo macchina.

L'unica perplessità è che con cicli di 10-20nS occorre disegnare i bus in modo che i dati arrivino in fase e non ci siano problemi di ritardo, e magari avere buffer veloci per commutare in tempo.

Però con un po' di fortuna potrebbe andare.

-- ciao Stefano

Reply to
SB
Loading thread data ...

SB:

Io pensavo di farlo all'inizio, mentre la CPU butta fuori indirizzo e RD ed attende la risposta della memoria. Dovrebbe esserci abbondantissimo tempo, con RAM statiche. L'unico dubbio (non ricordando né avendo consultato i timing diagram) che ho deriva da nebulosi ricordi sul ciclo M1 (opcode fetch), che era più critico come temporizzazioni, ma anche del fatto che fosse in qualche modo segnalato. E comunque di solito l'opcode lo si va a leggere in ROM. Anzi, si potrebbe trarre vantaggio da ciò.

Mah, dovrei andare a riguardarmi manuali che non ho più . :-(

Reply to
F. Bertolazzi

Sandro:

All'importanza del quoting corretto? ;-)

Reply to
F. Bertolazzi

SB ha scritto:

mmmmmm............... ripensandoci non e' cosi' banale: il video controller deve leggere i dati sequenzialmente senza interruzione, salvo che nei periodi di ritorno. Quindi ha una posizione di master, difficile andargli dietro anche con uno Z80 a 20 Mhz. Se il master lo fa il processore potrebbe essere fattibile, ma la scansione del vc perderebbe la sequenzialita'.

nebbia......

ciao S.

--
Postato da Virgilio Newsgroup: lo usi da web ma con le funzioni del newsreader
http://newsgroup.virgilio.it
Gerarchie it, italia, it-alt, tin, it.binari. Unico!
Reply to
Sandro

F. Bertolazzi ha scritto:

anche

-- Postato da Virgilio Newsgroup: lo usi da web ma con le funzioni del newsreader

formatting link
Gerarchie it, italia, it-alt, tin, it.binari. Unico!

Reply to
Sandro

Sandro:

Ne sei certo? Ai miei tempi non era così, ma i monitor (se è per quello anche le TV) a colori erano ancora di là da venire, quindi 1 bit=1 pixel, quindi, per una risoluzione di 320 pixel, 40 byte ogni 52 us, ovvero 1 byte ogni 1,3 us, meno di 800 kHz. Bruscolini. ;-)

Con 4 bit per pixel, in effetti, si arriva giusti giusti (la CPU *deve* essere sincronizzata col controller, per questo io me l'ero fatto con un'altra CPU e lo stesso clock) a poco più di 3 MHz, ovvero 75 ns più dei

250 ns per ciclo per cui SB storceva il naso.

Dovrei andarmi a cercare i diagrammi dello Z-80, ma, da come mi ricordo, si potrebbe comunque fare. E comunque vale la pena di buttarci un occhio.

Reply to
F. Bertolazzi

On 18 Ago, 21:22, Telespalla Bob wrote:

Sar=F2 testardo, ma secondo me l'efficienza maggiore la si ottiene intercalando la scrittura CPU-VRAM con la scansione video della VRAM stessa. Un clock deve indicare se il ciclo in corso =E8 di RD o WR.

La mia idea, seppur incompleta, =E9 questa:

[FIDOCAD] RV 50 110 75 285 RV 120 235 135 285 RV 120 180 135 230 RV 120 110 135 160 TY 130 125 5 3 270 0 0 * 74LS374 TY 130 195 5 3 270 0 0 * 74LS374 TY 130 250 5 3 270 0 0 * 74LS374 MC 165 200 3 0 074 MC 200 200 3 0 074 MC 270 200 3 0 074 MC 235 200 3 0 074 LI 135 205 140 205 LI 140 205 265 205 LI 265 205 270 200 LI 230 205 235 205 LI 230 205 235 200 LI 195 205 200 200 LI 160 205 165 200 LI 135 260 140 260 LI 140 260 145 260 LI 145 260 150 255 LI 150 255 150 210 LI 150 210 155 205 MC 115 205 0 0 074 MC 115 260 0 0 074 LI 115 205 75 205 LI 115 260 75 260 LI 135 225 140 225 LI 135 280 140 280 SA 140 280 LI 140 225 140 285 MC 140 285 0 0 040 LI 115 135 75 135 MC 115 135 0 0 074 TY 80 200 5 3 0 0 0 * ADDR (15..8) TY 80 255 5 3 0 0 0 * ADDR (7..0) TY 80 130 5 3 0 0 0 * DATA (7..0) TY 165 185 5 3 0 0 0 * 74LS157 RV 160 195 190 180 RV 195 195 225 180 RV 230 195 260 180 RV 265 195 295 180 TY 200 185 5 3 0 0 0 * 74LS157 TY 235 185 5 3 0 0 0 * 74LS157 TY 270 185 5 3 0 0 0 * 74LS157 RV 160 110 295 160 TY 220 130 5 3 0 0 0 * VRAM MC 175 165 3 0 074 MC 210 165 3 0 074 MC 245 165 3 0 074 MC 280 165 3 0 074 LI 175 165 175 180 LI 210 165 210 180 LI 245 165 245 180 LI 280 165 280 180 MC 155 135 0 0 074 LI 155 135 135 135 MC 150 90 3 0 074 LI 150 90 150 130 LI 150 130 155 135 RV 160 225 295 240 TY 190 230 5 3 0 0 0 * CONTATORI SCANSIONE VIDEO MC 175 200 3 0 074 LI 175 225 175 200 LI 245 225 245 200 MC 245 200 3 0 074 LI 280 225 280 200 MC 280 200 3 0 074 LI 210 225 210 200 MC 210 200 3 0 074 TY 140 75 5 3 0 0 0 * 74LS374 RV 125 85 175 70 RV 125 65 175 50 MC 150 70 3 0 074 RV 200 25 235 50 TY 210 35 5 3 0 0 0 * 74F74 LI 150 50 150 30 LI 150 30 195 30 MC 195 30 0 0 074 TY 130 55 5 3 0 0 0 * 74LS165 TY 155 55 5 3 0 0 0 * SR LI 180 55 215 55 LI 215 55 215 70 MC 180 55 2 0 074 MC 215 55 3 0 074 TY 168 52 5 3 0 0 0 * CK TY 202 27 5 3 0 0 0 * D TY 231 28 5 3 0 0 0 * Q TY 212 45 5 3 0 0 0 * CK MC 300 230 2 0 074 MC 300 235 2 0 074 TY 288 227 5 3 0 0 0 * CK TY 285 232 5 3 0 0 0 * RST LI 300 230 305 230 LI 300 235 305 235 LI 305 235 315 235 LI 305 230 325 230 LI 235 30 255 30 MC 255 30 0 0 690 MC 280 35 0 0 074 LI 255 40 255 45 LI 255 45 255 70 TY 245 70 5 3 0 0 0 * Blanking MC 350 235 2 0 690 LI 350 225 370 225 TY 350 220 5 3 0 0 0 * Clock continuo MC 50 240 2 0 074 MC 50 230 2 0 074 MC 45 250 0 0 074 TY 52 227 5 3 0 0 0 * MREQ TY 52 237 5 3 0 0 0 * WR TY 52 247 5 3 0 0 0 * WAIT RV 170 295 255 345 LI 110 305 105 300 LI 105 300 105 260 LI 105 260 105 210 LI 105 210 100 205 LI 105 265 100 260 MC 165 315 0 0 074 MC 165 325 0 0 074 MC 170 335 2 0 074 TY 172 312 5 3 0 0 0 * MREQ TY 172 302 5 3 0 0 0 * ADDR (15:14) TY 172 322 5 3 0 0 0 * WR TY 172 332 5 3 0 0 0 * WAIT LI 165 315 35 315 LI 35 315 35 230 LI 35 230 45 230 LI 165 325 40 325 LI 40 325 40 240 LI 40 240 45 240 LI 165 335 45 335 LI 45 335 45 250 LI 165 305 110 305 MC 165 305 0 0 074 LI 120 225 110 225 LI 110 225 110 360 LI 110 360 205 360 LI 205 360 205 345 LI 110 280 120 280 TY 120 222 5 3 0 0 0 * CP TY 129 222 5 3 0 0 0 * OE TY 120 277 5 3 0 0 0 * CP TY 129 277 5 3 0 0 0 * OE TY 53 184 5 3 0 0 0 * Z80CPU LI 365 225 365 295 LI 365 325 255 325 LI 365 295 365 325 LI 300 150 320 150 LI 320 150 320 305 LI 320 305 255 305 MC 300 150 2 0 074 TY 288 147 5 3 0 0 0 * WR TY 287 32 5 3 0 0 0 * Video Out TY 351 233 5 3 0 0 0 * Logica di scansione TY 200 320 5 3 0 0 0 * BUS LOGIC

Piccio.

Reply to
Piccio

Piccio:

Mmmm... Se però vuoi fare grafica vettoriale, la CPU deve poter anche leggere la RAM video, sennò quando scrive 1 pixel, in questo caso, cancella tutti i colori già presenti sul pixel, più il pixel a fianco. Secondo me non c'è bisogno di bufferare i dati della CPU. Ovvero, se ce n'è bisogno allora son dolori...

Reply to
F. Bertolazzi

ella

me

gno

Vista la piccola dimensione della RAM, si pu=F2 creare un alias in quella di sistema, una sorta di cache-memory. In lettura la VRAM non =E8 coinvolta e la CPU =E8 sempre full-speed; in scrittura, nella peggiore delle ipotesi, si deve allungare di qualche ciclo wait, ma non si sospende il programma.

Piccio.

Reply to
Piccio
[Telespalla Bob] cut...

Anni fa realizzai un emulatore di EPROM con logiche TTL ed una RAM da

32K. Il software girava su PC in DOS, utilizzava la porta parallela pilotata direttamente ed era scritto totalmente in assembly. L'input era un file INTEL-8 (.HEX) standard e il trasferimento non richiedeva pi=F9 di pochissimi secondi. Inutile annoverare l'incredibile versatilit=E0 di tale strumento. Se ti pu=F2 servire per lo sviluppo, posso rispolverare il progetto, anche se era cablato su scheda millefori. Oggi lo realizzerei con un micro sulla seriale, per=F2...

Piccio.

Reply to
Piccio

Il 19/08/2010 20:33, Piccio ha scritto:

oh, grazie, mi farebbe comodo lo schema, e magari il programma dos. pochi anni fa ne tentai la realizzazione, e il programma fu scritto da qualche amico del ng, ma dopo aver constatato dei problemi di funzionamento (qualche byte veniva sbagliato durante il trasferimento e non ho mai capito perché) ho accantonato il progetto.

Reply to
Telespalla Bob

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

dunque, vaglierò le innumerevoli proposte che mi avete dato, ma credo siano più complicate di come intendo risolvere la questione. Mi farò un'idea sulle dual port, ma al momento sarei orientato a campionare all'occorrenza il segnale di blanking tramite una porta di input, o al massimo ricorrere ad un interrupt. Valuterò anche la proposta della doppia ram da scambiare, ma anche qui credo si complichi oltre le mie aspettative :-)

ad ogni modo se può interessare posterò lo schema che attualmente è in fase di verifica e presto passerò alla realizzazione pratica (dove presto è un valore compreso fra poche settimane e qualche mese)

ciao.

Reply to
Telespalla Bob

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

Nel natale 1981, con la mia prima tredicesima, mi sono regalato due floppy (tandon TM-100A) per il computer Z80 di nuova elettronica.

Capacita' dei floppy 104 kilobyte cadauno.

Prezzo della coppia, un milione e centomila lire.

Bei tempi.

Reply to
vincenzux

Piccio:

Invece, io che allora ero già pigro, contattai la neonata Parallaxed acquistai il loro, passando poi ore al telefono col mio amico Chip, che poi lasciò da solo il socio Lance. Tornato in Italia avrei potuto fare il loro importatore, ma poi pensai che non c'era granché mercato. Se solo fosse la peggior cazzata che ho fatto in vita mia...

A chi occorresse un ROM emulator da 8k, se ne ho ancora più d'uno (era una rete di V25) potrei anche regalarlo.

Reply to
F. Bertolazzi

Piccio:

L'importante è sempre lo scappellamento a destra, come se fosse Antani.

Reply to
F. Bertolazzi

vincenzux:

Eh, averceli. Non solo il miloneeccento, ma i bei tempi, insieme. :-)

Reply to
F. Bertolazzi

Non posso non ricordare un aneddoto svoltosi alla fiera di Gonzaga molti anni fa davanti ad un drive-floppy da 360Kb in vendita su una bancarella. il mio amico, interessato, chiedeva informazioni tecniche sul prodotto al commerciante per niente competente (anzi, molto grezzo, sul rottamaio): "Ha due testine quel drive?" Commerciante: "S=EC, una qui (toccandosi la fronte) e una qua (toccandosi sotto al pube)!". Amico: "E funzionano bene tutte e due?"

Siamo scappati.

Piccio.

Reply to
Piccio

Piccio:

Ah, ricordarselo...

Reply to
F. Bertolazzi

Il giorno Thu, 19 Aug 2010 11:33:58 -0700 (PDT), Piccio ha scritto:

In ne ho realizzato uno alla fine degli anni '80, ho trovato anche una foto:

formatting link

Funziona ancora, anche se non lo uso da diverso tempo, era una delle prima cose fatte con lo Z180 - HD64180. Supporta la seriale, la parallela, emula fino a 128 Kbyte di EPROM e può anche programmarle.

Dopo aver assemblato e linkato in programma con un pc spedivo il codice in formato ASCII-INTEL sulla porta con un comando DOS COPY

Il tutto ovviamente scritto in assembler Z80 con diverse macro per emulare le nuove istruzioni Z180 (INT0, OUT0, TST e forse qualche altra che non ricordo)

Ah, emula in RAM fino a un clock di 33MHz su Z8S180.

Not bad,

-- ciao Stefano

Reply to
SB

Telespalla Bob:

Il modo più semplice, anche dal punto di vista hardware, in quanto non devi isolare gli address della CPU, è usare il BUSREQ, che è fatto apposta.

Il secondo modo più semplice, che comporta mettere dei buffer tri-state su address e data, è quello di fare il refresh video mentre MREQ è alto. Se il tempo non basta (non ci hai detto il clock della tua CPU), allora dovrai anche memorizzare gli address quando MREQ va basso.

Reply to
F. Bertolazzi

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.