OldComp.cz

Jak jiste vite, na desce klonu SAMa chci pouzit dva procesory Z80. Jeden hlavni a druhy oddeleny pro podporu periferii. Resim ted moznosti, jak by se dal vyresit dvoji pristup do jedne spolecne pameti sram. Oba procesory maji mit moznost cist i zapisovat do spolecne pameti. Tu bude zastupovat rychla sram a logicky bude mozne aby v jednu dobu s pameti pracoval jen jeden CPU. Pristup k pameti se bude stridave povolovat pro prvni a druhy procesor. Bud bych musel pri pristupu prvniho CPU do pameti pripadne pozastavit druhy CPU, a po ukonceni zapisu/cteni by se opet povolil, nebo to resit pres cpld, ktere by multiplexovalo adresy i data z obou procesoru a samo ridilo pristup do sram. Jenze multiplexovat tak velke mnozstvi signalu v cpld je masakr, sezralo by to vetsinu pinu. Jeste by se dalo usetrit na adresach a podstatne tim snizit pristupne oblasti pameti jen na desitky bajtu. Ale to se mi moc nezda... Bude potreba, aby nebyl zpomalovany hlavni procesor, takze musi mit i nejvyssi prioritu. Po dobu pristupu hlavniho CPU do spolecne sram bych mohl druhy CPU odpojit od sbernice(jako pri dma pristupu) ale tam by stejne vznikala casova prodleva, nez druhy CPU dokonci instrukci a zareaguje na odpojeni sbernice. Pri vyssi rychlosti CPU uz by se nemuselo stihat. Varianta s multiplexovanim adres a dat z obou CPU by se dala realizovat i radou MUXu, ale to je zase hodne soucastek... Chci se proste vyhnout malym orig. dvouportovym sramkam.

_________________
http://velesoft.speccy.cz/

Jestli ten projekt spravne chapu, tak druhy procesor pobezi jen z RAM. Pokud hlavni procesor bude rychly, muze vzdy pred zapocetim operace druhy procesor "vypnout", stejne tam tahle vlastnost bude kvuli plneni RAMky po resetu, a po ukonceni pristupu opet uvolnit. Takze to bude nejspis nejaka I/O operace - druhy procesor behem te doby snad bude mit dokonceny aktualni instrukcni cyklus a bude moci uvolnit sbernici pro hlavni procesor... Pripadne by se dalo jeste ctenim zkontrolovat, zda uz je BUSACK aktivni...

Pokial viem, dual-port ramky sa robia az do kapacity pol megabajtu. To nestaci ?
Alebo ty chces, aby obidva procesory mali plnohodnoty pristup do celej SAMovej ramky vratane videoram ?

Multiplexovat v CPLD mi přijde nejelegantnější i kdyby se tam mělo kvůli tomu přidat jedno navíc. Takové XC9572XL (nebo ekvivalentní Altera) by mělo být dostatečné na 2x Z80 <-> SRAM a mohly by obě CPU jet paralelně bez zdržování s prokládaným přístupem do SRAM. Synchronizovat pak dvě nebo více CPLD s dalšími komponenty (hlavně video) se dá už triviálně jedním signálem a společnými hodinami.

Máš blokové schéma?

_________________
Atari 600XL, 800XL/XE, 130XE, ST, STE, MegaST, 7800, JaguarCD, Commodore C64, Amiga 500/Plus, 1200, CDTV, Sinclair QL + GC, Sharp MZ800, Sord M5, CPC 6128, Spectravideo SVI X'Press, Sony HB-750, Philips CDi 370, Ohio Scientific Challenger, Eureka.

Blokove schema nemam, kreslim si to tak nejak "po svem". Myslenky mam vzdy hlavne v hlave Ale nakres propojeni tu tvorim. Akorat me zabrzdila cast s tim druhym CPU. Druhe CPLD zastoupi funkci MUXu s prehledem a bude to nejcistsi reseni. Souhlas, udelam to tak. Vse odvozene od hlavnich hodin. CPU2 bude po startu zablokovan/odpojen pridrzenim resetu a CPU1 mu naplni pamet ram kodem. Po uvolneni resetu se CPU2 spusti od adresy 0 a uz nebude funkcne nijak zavisle na CPU1.

Takze CPLD by muselo mit dva oddelene vstupy adres,dat a ridicich signalu z CPU1 a CPU2 a na vystupu jeden vystup adr+data+ridici signaly do rychle sram. A ted budeme pocitat. Pro 512kB sram potrebujeme adresy A0-A18, ale CPU ma jen A0-A15. Vyssi adresy uz musi generovat jeste samo CPLD. Ve skutecnosti budeme z CPU zpracovavat jen A0-A12 pro pristup do 8kB bloku a A13-A15 pro detekci do jake 8kB casti adresoveho prostoru procesor pristupuje. Interne uz podle toho CPLD vygeneruje vlastni nove adresy A13-A18 pro spolecnou sramku. A jestli pocitam dobre, na vstupu do cpld bude:

z CPU1:
A0-A15 = 16 adres
D0-D7 = 8 dat
MREQ,RD,WR,IORQ = 4 ridici signaly
celkem 28 pinu

z CPU2:
A0-A15 = 16 adres
D0-D7 = 8 dat
MREQ,RD,WR,IORQ = 4 ridici signaly
celkem 28 pinu

z hlavniho CPLD:
CLK = 1 pin
celkem 1 pin

Na vystupu z CPLD bude:
A0-A18 = 19 adres
D0-D7 = 8 dat
SRAM_CS,SRAM_OE,SRAM_WE = 3 ridici signaly
celkem 30 pinu

A dohromady to mame 28+28+1+30=87 pinu.
Na to uz mi XC9572XL nepostaci, protoze by zvladlo maximalne 72 pinu. Volba padne na nejake vetsi cpld.

Diky pouziti CPLD bude mozne menit i smer muxu a zajistit, aby se CPU1 odpojilo a CPU2 zastoupilo jeho ulohu, cili by mohl i CPU2 pristupovat do hlavni ramky s videoram. Je tu vsak omezeni. Hlavni sram1 jako jedina obsahuje videoram a ULA z ni neustale vycita data. Zaroven s touto sram1 pracuje CPU1 jako s hlavni pameti. Vzhledem k vyssi rychlosti procesoru a rychlosti vycitani dat ulou nebude uz moc volneho casu pro pristup druheho procesoru. Uz proto jsem s tim od zacatku radeji nepocital. Pokud bych opravdu chtel do jedne spolecne pameti zajistit pristup obema procesorum i ule, musel bych snizit rychlost druheho procesoru (pri pristupu do sram ho dodatecne brzdit). Tim bych dosahl toho, ze by se trochu zmenilo zapojeni, CPU2 by mohl v pripade potreby sahat do hlavni ram/videoram ale primarne by CPU2 pracoval jen se svou zcela oddelenou pameti, do ktere by uz hlavni procesor nemel pristup.(tato oddelena sram by nemusela byt vubec pouzita, ale musela by se zvetit kapacita hlavni ramky z 512kB na 1MB, protoze druhy procesor musi mit vlastni kod v jine casti pameti, aby ho jiny software nepremazal.

_________________
http://velesoft.speccy.cz/

A ted jak by to vypadalo s dvouportovou sramkou.

Tyto pameti se delaji i v 5V verzich a s rychlou pristupovou dobou. Bohuzel jejich cena pri vetsi kapacite raketove roste. Napriklad 128kB pamet by vysla kolem 60 Euro, 8kB na 16 Euro, 2kB na 11 Euro a 1kB na 6 Euro. Ted ale je treba vzit v uvahu, za jakym ucelem potrebujeme mit dvoji pristup do jedne pameti. Puvodni navrh pocital s tim, ze by druhy procesor vykonaval nejaky kod a na jeho zaklade by do urcite casti pameti zapisoval vygenerovana data. Prvni procesor by pak pri cteni urcitych portu dostaval data z oblasti teto sdilene sram pameti. Sdileny prostor by nemusel byt az tak velky, klidne by stacilo par desitek bajtu. Akorat ze druhy procesor musi mit stejne vlastni pamet ram pro kod.

Pri zapojeni s dvouportovou sram by pripadaly tyto varianty:
a) CPU1 + hlavni pamet SRAM1 + mensi dvouportova sram o kapacite nekolik kB + CPU2 pripojene pouze k dvouportove sram.
Tato varianta je jednoducha, ale druhy procesor ma jen par kB pameti, takze od nej nemuzeme cekat nejaka kouzla. Nicmene na obsluhu periferii by mala pamet pro CPU2 dobre vystacila.

b) CPU1 + hlavni pamet SRAM1 + vetsi dvouportova sram o kapacite nekolik desitek kB + CPU2 pripojene pouze k dvouportove sram.
Tato varianta je take jednoducha a druhy procesor ma uz k dispozici desitky kB pameti. To by uz melo stacit na obsluhu periferii + dalsi kravinky. Ale diky vetsi dvouportove sram by cena vzrosla radove v desitkach Euro = az tisice korun. To je podle meho nazoru dost draha sranda.

c) CPU1 + hlavni pamet SRAM1 + mala dvouportova sram o kapacite 1 kB + CPU2 pripojene k teto dvouportove sram a zaroven k dalsi vlastni obycejne velke sram.
Tato varianta vyzaduje dalsi cip sram a druhy procesor ma k dispozici jak 1kB dvouportove pameti, tak dalsi velkou sram pro vlastni kod. Diky male kapacite dvouportove sram by se dal sdilet jen velmi maly adresovy prostor, napriklad pro praci s porty. Velka sramka pro CPU2 by mu dovolila vykonavat slozitejsi kod, nebo primo multitasking.

d) varianta bez dvouportove sram by byla realizovana pomoci CPLD a dvouportovou pamet by nahradila velkokapacitni levna rychla sramka.

Takze co se zda jako nejlepsi reseni ?

Napriklad zde je seznam dualport sramek: http://cz.mouser.com/Semiconductors/Memory/SRAM/_/N-4bzpt?P=1yzmm18&Keyword=dual+port&FS=True&Ns=Pricing%7C0

_________________
http://velesoft.speccy.cz/

Velesofte kdyz to ctu tak treba mne by se nejvice libilo aby to CPU2 byl kompletni Z80 pocitac. CPU + pamet + mala flash na boot. Klidne at je ve flash jen zavadec co nacte treba po dvouvodicove sbernici program z hlavniho pocitace (CPU1).

Kdyz bych problem pro zacatek zjednodusil jen na klavesnici tak bych si umel predstavit jako hlavni cip XC95144XL. Z CPU1 by do nej slo 9 vodicu - a8-a15+status. Vychazim z obrazku http://velesoft.speccy.cz/samcoupe_keyboard-cz.htm Pak z obou cpu by slo 2x8 bitu jako datova sbernice. U CPU1 by to bylo pripojeno na vstup klavesnice. Z CPU2 by jeste slo 4 bity - to by urcovalo jaky 8 bitovy vnitrni registr v CPLD se ma prave plnit (je jich 9). Pak mozna nejaky WR signal od CPU2. Z CPLD co nahrazuje ASIC Sam Coupe by sel signal ze CPU1 je prave odstaven a pristup do video ram ma ASIC, takze CPU2 muze bezpecne zapisovat data do CPLD, stejne to nikdo nemuze cist. Kdyz to shrnu, tak CPLD by mel 69 bitu a kazdy by simuloval stisk jedne klavesy. CPLD by na d0-d7 do ASICu daval v realnem case vystup podle vstupnich signalu a8-a16+status.

Toto reseni by melo vyhodu ze by se dalo pouzit pri drobne zmene i u jinych pocitacu.

CPU2 samozrejme bude da se rict samostatny pocitac. CPU+PAMET. Cpat tam dalsi flash je podle me zbytecne. Po startu pocitace nabehne CPU1 s pripojenou flash rom 512kB, ktera obsahuje jednoduche rutiny pro prenos kodu z rom do ram. Flash rom je jen pro start a konfiguraci systemu. Take narve do pameti pro CPU2 potrebny kod a ten take pobezi kompletne ze sram. Proste za behu nebude romka vubec vyuzita. Rychla sram bude misto rom podstrkovat vlastni stranky se zakazanym zapisem. Stejny zpusob uz leta pouzivam v PROFI interface. Zaroven to otevre nove moznosti, muzete si kdykoli modifikovat kod romky,atd...



No nevim jestli jsem to dobre pochopil, ale ted zase ja trochu reality:
- CPU2 bude muset neustale vykonavat kod, ktery bude obsluhovat 24 az 26 pinovy vyvod notebookove membrany klavesnice. Matice v teto klavesnici je zcela odlisna od te v ZX/SAM COUPE. CPU2 tredy musi nejprve nacist stav vsech klaves a pak je po jedne pekne prevest na virtualni matici kompatibilni se SAM COUPE membranou (neboli ZX membranou, ta je stejna). Stav teto tabulky/matice bude zapsany do vyhrazene casti sdilene spolecne pameti (pripadne dualport sram) pekne po bajtech. Co zapsany bajt, to hodnota, ktera bude predstavovat primo data vycitana z portu klavesnice (vyuzije se ve skutecnosti jen pad prvnich bitu se stavem klaves a horni bity se stavem kazetaku vraci uz ULA). Bez CPU2 bych mohl klavesnici konvertovat primo v CPLD, ale to uz nenabizi takove moznosti jako prefiltrovani klaves,eliminace zrcadleni nebo realizace predstihu klavesy shift, atd... Udelat toto ciste na HW by bylo nemozne. Navic CPU2 bude muset jeste obsluhovat touchpad a prevadet jeho stav na souradnice mysi. Z pohledu software pujde o jednoduche rutinky ale se znalosti assebleru se s tim clovek muze nadherne vyblbnout. Tabulka se stavem portu klavesnice bude mit 257 bajtu. 256 bajtu bude stav pro ruzne nulove kombinace A8-A15 a posledni byte 257 ponese stav pro A8-A15=#FF. Pritom CPU2 si tuto tabulku vzdy pripravi a az po jejim kompletnim vygenerovani ji zpristupni pro CPU1 ve sdilene sram (prepne se stranka teto sram, takze tabulka se objevi cela najednou v jeden jediny okamzik). Pak CPU2 znovu vygeneruje dalsi tabulku dle aktualniho stavu klavesnice a zase ji pristrankuje celou az najednou.

Kdyby CPU2 prestalo generovat tuto tabulku, tak hlavni CPU1 neuvidi stav sklavesnice. Ale i tak CPU2 muze sam spustit nejaky software akorat klavesnici by musel zpracovavat primo bez konverze, tedy pocitat s jinou matici. Ale nikdy nebude CPU2 pracovat stejne jako sam coupe. Rozdeleni pameti bude mit jine a nebude mit pristup na sam coupe porty.

_________________
http://velesoft.speccy.cz/

Pravda, ale to by tak nevadilo. Horší je, že to těsně přesahuje i možnosti TQFP100 pouzdra a TQFP144 jsou už za dvojnásobné peníze. Možná Altera bude mít něco cenově rozumnějšího.



Já si myslím, že ne, ale muselo by se to nejdřív spočítat. Jak rychlé budou ty Z80 CPU a kolik bude potřeba alokovat pro nejnáročnější grafický režim? Kromě toho SRAM by se dala dát 16bit a CPLD řešící video a případně i nějaká DMAčka by tak ušetřila polovinu cyklů SRAM.

_________________
Atari 600XL, 800XL/XE, 130XE, ST, STE, MegaST, 7800, JaguarCD, Commodore C64, Amiga 500/Plus, 1200, CDTV, Sinclair QL + GC, Sharp MZ800, Sord M5, CPC 6128, Spectravideo SVI X'Press, Sony HB-750, Philips CDi 370, Ohio Scientific Challenger, Eureka.

Hlavni sram/videoram je 16bitova a dostatecne rychla (10ns) a je pripojena jen k CPLD. To zajisti 2x mene pristupu do sram a tim vice casu pro pristup CPU. Ano, presne jak pises. Musi se spocitat jak rychle pobezi CPU1 a jaky datovy tok bude pro lepsi graficky rezim. Dale ale zalezi, jak rychle pobezi i druhy procesor(pokud se z obou vymackne maximum). Ja pocitam s maximem pro CPU1 kolem 18-21MHz (na 24MHz pretaktovavat Z80 se mi nechce). Delky spoju na desce budou minimalizovany jak jen to pujde, ale i presto by mela byt jejich delka stejna, aby na sbernici nedochazelo ke zpozdeni. Klasicka sbernice tam bude, ale funkcne omezena. Pokud ma CPU1 bezet v plne rychlosti, budou ridici signaly na sbernici blokovane, aby si pripojena periferie nevsimala stavu procesoru. V rezimu povolene sbernice bude take mozne, aby CPU1 bezel s rychlejsim taktem, ale mel by se zpomalit takt procesoru pri kazdem pristupu do oblasti rom nebo pri praci s porty. To zajisti, ze starsi periferie bude moct jeste reagovat a treba pripojit vlastni externi pamet rom/ram.

U sam coupe je hlavni problem s nizsim vykonem procesoru vzhledem k datovemu objemu videoram (jedna videoramka muze mit az 24kB). S vyssim taktem CPU1 se vykon zlepsi ale hodne udela take fakt, ze sram diky sve rychlosti muze fungovat i jako nezpomalena(konkretne ze rychlost sram nemusi omezovat rychlost behu cpu). Dalsi zlepseni nastane s realizaci TXT rezimu s pruhlednosti barev. Tady se az 32x zmensi objem dat potrebnych k vyplneni cele videoram v pripade znaku/bloku velikosti 8x8 pixelu. Pri blocich 16x16 pixelu by to bylo uz 128 nasobne odlehceni. Pak se muze SAM i pri 6MHz totalne flakat

_________________
http://velesoft.speccy.cz/

Velesofte preci u toho pocitace CPU2 je skoro jedno jestli tam bude mala flash ci ne. Urcite flash je levnejsi nez dvouportova ram. Nevidim problem aby neco najelo z flash, pak presunulo obsah flash pameti do ram, nasledne vypnulo zpozdovani Wait signalu a pripadne z neceho jineho nacetlo i novejsi "system".


Myslim si Velesofte ze jsem te pochopil proc chces pouzit tu pamet a jak. Presne takto jsem uvazoval drive. Jen si myslim ze at budes jakkoliv zpracovavat tu klavesnici z notebooku, tak stejne budes ve vysledku mit 69bitu co budou popisovat stav virtualni klavesnice Sam Coupe. Je jasne ze budes muset se nejak vyporadat treba s predstihem shift klavesy a proto souhlasim ze tam musi byt nejaky procesor. Ja osobne mam nejradeji Z80 a proto podporuji tvoji volbu. I kdyz asi jiny jednocip by mozna byl levnejsi. Na druhou stranu reseni ktere bude trosku otevrene nebude na skodu. Take si myslim ze pripojeni bezne PS2 klavesnice be se melo podporovat.

Duvod proc jsem navrhl misto dvouportove pameti to cpld je ten ze stejne budes muset resit nejakeho arbitra a takto by skoro jiste sel udelat arbitr primo v cpld. Napr. tak ze CPU2 by zapisoval do vyrovnavaciho bufferu. Po zaplneni tohoto bufferu by se nastavil signal Wait pro CPU2 a to by ho mohlo zastavit. Tento buffer by se vypraznovat vzdy kdyz by prisel z CPU1 signal M1-log0. Takze kdyz bude vse ok tak se vlastne nemusi ani realne blokovat. Mozna by se dalo uvazovat ze by se udelala verze THT ale to by se muselo udelat pomoci dvou CPLD, proste rozdelit data do dvou cipu.

10ns SRAM je superrychlá, teoreticky až 100M čtení nebo zápisů za sekundu. Kolik trvá jeden BUS cyklus u Z80? 4 takty? Takže i když by obě CPU jely neustále na 20MHz, tak je to 10M R/W za sekundu neboli 10%. Prakticky tu SRAM asi nebudeš zdaleka časovat tak rychle, ale i tak já tam nevidím problém když se to rozhodí od časových slotů.

_________________
Atari 600XL, 800XL/XE, 130XE, ST, STE, MegaST, 7800, JaguarCD, Commodore C64, Amiga 500/Plus, 1200, CDTV, Sinclair QL + GC, Sharp MZ800, Sord M5, CPC 6128, Spectravideo SVI X'Press, Sony HB-750, Philips CDi 370, Ohio Scientific Challenger, Eureka.

No na desce to bude dalsi cip navic, dalsi tahani vsech adresovych a datovych vodicu k dalsimu cipu, dalsi spotreba, dalsi kapacita, vesti cena, vetsi plosnak. Ikdyz od kazdeho jen trochu. Na to, k jakemu ucelu ta flash slouzi je naprosto zbytecna. CPU1 prece po startu presune kod z jedne spolecne flash pameti do ram pro CPU2 a zaroven si z flash vytahne romky pro sebe. Az po teto akci se oba procesory rozjedou a cast ramky pro CPU2 se samozrejme bude chovat jako rom(zakazany zapis). Ve finale to bude tedy vypadat tak, ze CPLD zajisti dualporting pro jednu velkou sram, ve ktere bude nejen sdilena pamet pro oba procesory, ale take obsah nekterych portu (klavesnice/mys,atd...). Druhe cpld by resilo jednoduchy dualport pristup a zbytek jeho obsahu bych vyuzil radeji k jinym ucelum, nez jen k matici klavesnice. Vlastne kdyz uz bude ta druha sramka spolecna, neni jediny duvod, proc do ni nedat i ty porty klavesnice a zaroven se CPLDcku odlehci.



Jednocip mi na desku nesmi. Hlavnim cipem bude CPLD a po nem CPU Z80. Nechci tam mit pomocny cip, ktery je vykonejsi nez hlavni procesor a uz vubec nechci podporovat nejake protokoly ze sveta PC... Branim se tomu jen co se hlavni desky tyce. Prave proto jsem zvolil klavesnici, ktera ma membranu, nak kterou mame absolutni kontrolu a navic je tu mozne softwarove odstranit vetsinu problemu se zrcadlenim, coz u PS/2 ci USB klavesnice neudelate ani ve snu. Z80 ve funkci pomocneho procesoru umozni Z80 nadsencum bez potreby nejakeho upgrade ci flashovani upravit funkci klavesnice/mysi nebo podstrcit CPU2 zcela jiny kod. A to vse primo z pocitace a primo v assembleru, bez potreby pripojovat PC
Bude mozne zapojit do slotu ci na sbernici nejaky modul pro PC periferie PS/2 ci USB, takze kdyz bude potreba PC klavesnice, proc ne... Kdyz uz klavesnice externi, spis bych byl pro USB:
http://zx-pk.ru/showthread.php?t=24088

_________________
http://velesoft.speccy.cz/

Teoreticky ano. Musi se to rozdelit do slotu pekne za sebou. Take zalezi jak budu taktovat CPLD, zpozdeni logiky v cpld,atd.. Ale to dualportovaci CPLD by toto melo krasne zvladnout. Horsi by to bylo s poctem pinu CPLD, pokud bych chtel mit jednu spolecnou pamet jak pro hlavni cpld(videoram), tak pro oba procesory. Ikdyz.... ted koukam do zapojeni, ze by se to dalo zjednodusit. No asi bude lepsi kdyz to nakreslim a popisu.... Ale s jednim pomocnym cpld by melo byt realne pro oba CPU i pro ULU pouzit spolecnou pamet. Chce to propocitat. Pokud nebudu chtit brzdit procesory, bude treba jim priradit vyssi prioritu nez ule. CPLD by melo tedy jakousi rezervu(casovy usek) ve ktere by melo pustit ke slovu oba CPU a jeste stihnout vycist videodata. Pri cteni operacniho kodu instrukce je signal RD u Z80 aktivni jen asi 1.5 taktu CPU. Pri 18MHz(nasobek original samackeho taktu 6MHz) trva jeden takt neco pres 55ns. Ale co kdyz ve stejnou dobu bude chtit druhy procesor z pameti cist take a zaroven bude videodata vycitat ula. Takovy okamzik bude nastavat dost pravidelne. Idealni stav by byl, aby se kazdy takt 18MHz(coz je moje predpokladane maximum) casove rozdelil na tri sloty/useky, kde prvni bude prideleny ULE,druhy pro CPU2 a treti pro CPU1. Kdyz bych tech rekneme 70ns rozsekal na 3 sloty, tak na tri samostatne pristupy to neni moc. To je trochu masakr v tak kratkem useku neco delat. Pri zapisu by casovani nevadilo, byte bych si ulozil a se zpozdenim zapsal. Ale pri cteni musim procesoru vratit data hned, jinak bych ho musel pozastavit(WAIT). I kdybych si odmyslel ulu, tak se onen takt a pul rozdeli na dva sloty zhruba 35ns a tam by to bylo take s odrenyma usima.

K casovani CPLD, ktere by resilo dualni pristup do pameti:
- pokud bude chtit CPU cist bajt z pameti, musi projit adresa muxem v cpld, coz nejakou dobu trva. Az dorazi ridici signaly z CPLD do pameti sram, tak zase nejakou dobu potrva odezva samotne pameti (treba onech 10ns). No a nakonec data ze sram musi projit zase zpet skrz CPLD do datovky CPU, coz zase trva. To jsou celkem 3 pruchody a jejich casovy odstpup musi byt taktovan pomoci CPLD, pricemz takt by mel byt dostatecne dlouhy, aby za jeho dobu prosel signal od CPU>CPLD>SRAM ci opacne. Je take nutne pripocitat i zpozdeni vznikle delkou vodicu. A kam se dostavame ? Cele to brzdi logika CPLD, kterym jednim smerem musi projit adresovka a druhym smerem data ven (pri cteni). Zapis by byl rychlejsi, protoze adresovka i data lezou skrz cpld jen jednim smerem.

Nakonec budu rad, ze pobezi nebrzdene ULA + rychly CPU1 a druhy CPU2 uz bude treba brzdit (v pripade, ze bude pristupovat do pameti ve stejnou dobu jako ula ci CPU1, musi pockat az bude sram volna)

_________________
http://velesoft.speccy.cz/

Jak už jsem psal, obě CPLD by se střídaly o přístup do společné SRAM, do které by byly zapojené paralelně. Jedno by vždy bylo master a obsloužilo si svůj cyklus a druhé by mělo směrem ku SRAM signály ve vysoké impedanci.

Ad latence. CPLD má latenci mezi 5 až 10ns. Při 18Mhz trvá jeden takt Z80 cca 55ns, takže i kdybys provozoval SRAM s pomalejším 20ns časováním a měl 4 timesloty, tak během jednoho cyklu Z80 (3 takty, případně 4 u M1) projede celé "kolečko" hned několikrát, takže se nikdy nemůže stát, že bys včas nepřečetl a nevystavil platná data, o zápisu nemluvě.

_________________
Atari 600XL, 800XL/XE, 130XE, ST, STE, MegaST, 7800, JaguarCD, Commodore C64, Amiga 500/Plus, 1200, CDTV, Sinclair QL + GC, Sharp MZ800, Sord M5, CPC 6128, Spectravideo SVI X'Press, Sony HB-750, Philips CDi 370, Ohio Scientific Challenger, Eureka.