OldComp.cz

Komunitní diskuzní fórum pro fanoušky historických počítačů


Právě je 28.03.2024, 11:46

Všechny časy jsou v UTC + 1 hodina [ Letní čas ]




Odeslat nové téma Odpovědět na téma  [ Příspěvků: 31 ]  Přejít na stránku 1, 2, 3  Další
Autor Zpráva
PříspěvekNapsal: 07.03.2016, 15:31 
Offline
Prvnička

Registrován: 07.03.2016, 14:56
Příspěvky: 20
Bydliště: HK
Has thanked: 0 time
Been thanked: 1 time
Ahoj, mam takovy sen o moderni univerzalni programovatelne ZX periferii, ktera bude tvorena pouze jednim cipem. O resenich jako 1bis interface nebo DIVIDE+ atp. vim. Ten jeden cip by mohl byt napr. STM32F4 nebo CY8C5888. Ani jedno asi nema dost velkou RAM na to, aby tam (bez druheho cipu tvoriciho RAM) fungoval ResiDOS, ale to by mi ani tak nevadilo, stacilo by mi nacitani/ukladani snapshotu + rozhrani nekam ven (napr. WiFi pres ESP8266).

Problem ovsem je mapovani pameti do prostoru puvodni ROMky. Strucne jsem analyzoval moznosti:

U STM by bylo nutne obsluhovat pozadavky na cteni Z80 z ROM pres preruseni toho ARMu. STM muze jet az na 180MHz (i vic). Do zacatku obsluhy preruseni je to u Cortex M3/M4 minimalne 12 taktu, tedy 66ns. Samotna obsluha (precteni adresy z portu, precteni dat z vnitrni SRAM ARMu, zapsani na vystupni port) by se dala zvladnout myslim v radu dalsich 12 taktu, tedy celkem 120ns. Na ZX je jeden takt 280ms, cteni se deje aspon na 2 takty, ze (?), tedy 570ns. Zda se mi, ze by to ten ARM mohl stihat servirovat rovnou na sbernici, ne?

K tomu podotazka - da se na ZX vyuzit WAIT signal v oblasti prvnich 16kB (tedy ROM)? Tim by bylo mozne v obsluzne rutine ARMu jako prvni vec vystavit WAIT a pak uz bude mit dost casu zbytek (cteni dat treba i z externi seriove RAM/EEPROM), kdyby to melo trvat dele. (Chapu, ze pak nebude casovani stejne, jako pri cteni z normalni ROM, cimz padem asi nepujde emulovat "patchnutou" ROM, kde nektere rutiny budou puvodni a asi spolehajici na standardni casovani; ale to mi moc nevadi).

Nevidel jsem snad zadnou periferii, ktera by WAIT vyuzivala. Neni to divne? Interne vede WAIT i do ULA? Proc? Cte ho ULA, aby taky cekala?

CY8C5888 ma vyhodu, ze ma v sobe i programovatelne pole, takze
1) dekodovani adresy lze udelat v HW (aby ARM nebyl otravovan prerusenim pri kazdem cteni).
2) mozna by slo vyuzit i DMA toho CY ARMu, coz by mohlo byt trochu rychlejsi, nez obsluha na preruseni ARMu (on je zas CY pomalejsi - 80MHz max, takze je to mozna jedno),
3) vystavovani datove sbernice na vystupnim portu ARMu by slo taky udelat v tom programovatelnem poli, takze obsluzna rutina v preruseni by nemusela resit presne casovani, kdy ma byt vystup vybaven a kdy uz ne (aby nedoslo ke kolizi na dat. zbernici Z80).

Co si o tom myslite? Zkousel nekdo emulovat RAM/ROM nebo IO perifierii nejakym rychlym procesorem bez dalsich latchu atp.? Jak je to s WAIT signalem?

P.


Nahoru
 Profil  
 
PříspěvekNapsal: 07.03.2016, 16:06 
Offline
Óm Nejvyšší
Uživatelský avatar

Registrován: 28.01.2016, 23:57
Příspěvky: 3756
Has thanked: 213 times
Been thanked: 388 times
Neco podobneho me taky napadlo, ale dosel jsem k nazoru, ze se to proste neda stihnout. Mozna nejaka dalsi logika na dekodovani adres, ale to uz by asi bylo jednodussi tam dat male FPGA a nahravat ho primo z toho pridavneho procesoru, podle toho, co se ma emulovat.
Ale ted me napada, nektere jednocipy v sobe maji paralelni 'slave' port, ktery je urceny na podobne veci. Ted si nevybavuju, ktere to byly, tipoval bych nejaky PIC - to by se mozna dalo vyuzit.

_________________
Nikdy nediskutujte s blbcem. Stáhne vás na svoji úroveň a vyhraje zkušeností.


Nahoru
 Profil  
 
PříspěvekNapsal: 07.03.2016, 17:48 
Offline
Radil

Registrován: 08.10.2013, 18:00
Příspěvky: 296
Has thanked: 12 times
Been thanked: 228 times
Ahoj, tak teroreticky i prakticky to možné je. Z80 je dost pomalá na to, aby to STM32F4xx stíhal obsloužit. Příklad je třeba tady. U MZ700 (Z80 na 3.5469MHz) to emuluje externí ROM, mrak periférek (16bitové IO porty) a odposloucháváním zápisu do video RAM následně generuje paralelní obraz na VGA. Porty a zápis do paměti je celkem pohoda, čtení paměti už je docela honička, ale kdyžtak se to dá řešit s tím vybavením WAIT. Problém je když nějaká periférka uvnitř STM požaduje DMA (generování VGA), to pak dokáže během DMA burstů stlačit výkon procesoru na polovic. Výhoda STM32F4xx řady je možnost přetaktování, běžně zvládají stabilně přes 140% uváděné taktovací frekvence procesoru, samotné periferie pak ještě víc. Zde běží 180MHz varianta na 216MHz.
Pro inspiraci zdrojáky a schéma zde je to pro verzi k MZ800, ale schéma je stejné.

Kubik: ten slave port u PICů je bohužel jen 8 bitový, to je tak na chytání konkrétního portu, ale né na nějaké komplexní sofistikované řešení. Něco na odchytávání proudu dat z kamer má i ten STM32F4xx, ale zase šířka jen 14 bitů.


Nahoru
 Profil  
 
PříspěvekNapsal: 14.03.2016, 12:49 
Offline
Prvnička

Registrován: 07.03.2016, 14:56
Příspěvky: 20
Bydliště: HK
Has thanked: 0 time
Been thanked: 1 time
Diky za pozitivni odpoved!

Zvazuji, kterou cestou se dat (rychly ARM vs. PSoC) a objevil jsem jeste NXP LPC4337, coz jsou dva ARMy (Cortex M4 + Cortex M0) v jednom pouzdre (dual core) taktovane na 204 MHz, sdilejici pamet a nektere periferie a propojene pres IRQ (jeden muze vyvolat preruseni ve druhem a pres pamet si predaji prikaz/data). Tam by slo udelat, ze jedno jadro by obsluhovalo aktivni smyckou nad GPIO pozadavky do pameti/periferii (tj. usetrime par taktu jinak potrebnych pro zahajeni rutiny preruseni; urcite by to zefektivnilo i to odposlouchavani zapisu do video RAM) a druhe jadro by se staralo o zbytek (cteni z SD karty, komunikace s ESP8266, generovani VGA,... atd.).

Kity s LPC:
1) (s debuggerem na desce) http://www.nxp.com/products/microcontro ... rd:OM13070
2) (bez debuggeru na desce) http://www.ebay.com/itm/NXP-LPC-LPC4337 ... xy2YtRwtBA

P.


Nahoru
 Profil  
 
PříspěvekNapsal: 23.04.2016, 11:04 
Offline
Prvnička

Registrován: 07.03.2016, 14:56
Příspěvky: 20
Bydliště: HK
Has thanked: 0 time
Been thanked: 1 time
Tak si uz chvili hraju s LPC4337 (ARM Core-M4@204MHz) pripojenym k Didaktik Gama. V ARMu se snazim emulovat ROM namapovanou od adresy 0, zatim pomoci aktivni smycky.
Kod v ARMu vypada takto (pole myrom je jen tech par bajtu - viz assembler nize):

Kód:
   while (1) {
      if (ZX_IS_MEM_READ() && ((address = ZX_ADDR()) < MY_ROM_SIZE)) {
         data = myrom[address];
         ZX_DATA_OUT(data);
         ZX_DATA_READY_FLAG_ON(); // bit pro zobrazeni v log. analyzatoru
         while (ZX_IS_MEM_READ()) {}
         ZX_DATA_HI_Z();
         ZX_DATA_READY_FLAG_OFF();  // bit pro zobrazeni v log. analyzatoru
      }
   }

ARMovska smycka ma celkem zruba 15 instrukci.

V emulovane ROM (pole myrom) mam tento testovaci programek (mel by delat pruhy v BORDERu, v emulatoru funguje):
Kód:
.org 0
   di               ; disable interrupts.
main:
   ld a,2              ; 2 is the code for red border
   out (254),a         ; write to port 254.
   ld b,255           ;waiting loop
wt1:      
   djnz wt1
   ld a,0             
   out (254),a         ; write to port 254.
   ld b,255           ;waiting loop
wt2:
   djnz wt2
   jp main


No a ono to aspon par milisekund po resetu ZX i bezi, ale pak ZX "vykoleji".
Na prilozenem obrazku je zaznam z log. analyzatoru (bohuzel mam jen 8-bitovy), kde je videt misto, kde to "vykoleji". Spravne by mel pokracovat ve smycce ctenim adres 7 a 8. Vyznacil jsem pravitky posledni MEMREQ, ktery vypada dobre a nasledny, ktery je nejaky kratsi. Navic je videt, ze i adresova sbernice se po tom kratkem MEMREQ rychle zmeni (rychleji, nez se deje treba prechodem na REFRESH cyklus po M1; i kdyz presnost mereni uz je na hrane vzorkovaci frekvence analyzatoru). Koukam do Z80 manualu a takto kratky MEMREQ+RD cyklus tam nevidim.
Preruseni je v testovaci ROM zakazane hned prvni instrukci, montuje se do toho nejak ULA?
Netusite, co se tam deje? Uz jsem z toho docela bezradny...

Pavel


Přílohy:
Screenshot 2016-04-23 10.34.20.png
Screenshot 2016-04-23 10.34.20.png [ 85.98 KiB | Zobrazeno 10802 krát ]
Nahoru
 Profil  
 
PříspěvekNapsal: 24.04.2016, 08:26 
Offline
Kecálek

Registrován: 07.05.2014, 12:10
Příspěvky: 197
Bydliště: Jbc
Has thanked: 0 time
Been thanked: 39 times
Napad sice nemam, ale dival jsem se do popisu signalu Z80: M1 je aktivni 2 takty, RD i MREQ jsou aktivni 1.5 taktu. Vypada to, ze neco jineho se do toho vlozi - pokud analyzator ukazuje spravne, tak na 266us je videt, ze se ukonci cteni a zaroven se tam zmeni adresa. Nemuze treba byt v tu chvili pripojena RAM, ze by do toho nejak zasahoval obvod PLA? Pouziva se pro dekodovani take signal ROMCS-D? Jestli to spravne chapu, tak emulace ROM drzi signal ROMCS v L a jen podle adresy generuje data...?


Nahoru
 Profil  
 
PříspěvekNapsal: 24.04.2016, 10:14 
Offline
Prvnička

Registrován: 07.03.2016, 14:56
Příspěvky: 20
Bydliště: HK
Has thanked: 0 time
Been thanked: 1 time
ROMCS trvale drzim v log. 1. Tim by mela byt vnitrni ROM trvale odpojena. ARM pokud dekoduje adresu 0..23 (tj. velikost toho assemblerovskeho kodu + jeste par bajtu s hodnotou 0), tak dava na datovou sbernici byte z "myrom". Jinak ARM nedela nic - tady by mohl byt problem, ze ve zbylych bajtech do adresy 16384 tim padem neni definovana hodnota, ale vadit by to nemelo (preruseni zakazano, NMI negeneruju; neni duvod vyskocit mimo tu smycku v assembleru, ktera se cela provadi na tech dolnich adresach).

ROMCS-D pokud vim Didaktik Gama nema.

Jeste jsem koukal do manualu Z80, ze RD, MEMREQ i adresova sbernice jsou tristavove. Existuje tedy hypoteza, ze Z80 se od sbernice odpoji a ja ctu nejaky plovouci stav. Ale jestli to chapu dobre, tak Z80 ma duvod se od sbernice a ridicich signalu odpojit jen po BUSREQ (tedy DMA pozadavku), coz se nas snad netyka. Ze strany ULA mam za to, ze RD a MEMREQ jsou jeji vstupy, tedy do nich se nema co montovat. U adresove sbernice je ULA v Didaktik Gama oddelena pres nejake multiplexery, takze ani tam bych nemel videt nic jineho, nez co tam posila Z80.

Jeste si rikam, jestli neni nejaky problem v tom, ze jak logicky analyzator, tak ARM jsou primarne na 3,3V a tolerantni na 5V. Tedy jestli nedochazi k nejake mylne intepretaci napeti na "zmitajicich" se signalech.

Pavel


Nahoru
 Profil  
 
PříspěvekNapsal: 24.04.2016, 15:39 
Offline
Kecálek

Registrován: 07.05.2014, 12:10
Příspěvky: 197
Bydliště: Jbc
Has thanked: 0 time
Been thanked: 39 times
Rozhodovaci urovne 5V tolerantnich vstupu 3.3V CMOS procesoru byvaji kolem 1.2V. Logicka nula na TTL byva max 0.8V. Problem by mohl byt, pokud by pouzite vstupy na procesoru byly se schmittovym komparatorem...
BUSREQ by nemel zasahovat do probihajiciho sbernicoveho cyklu, ale mel by se obslouzit az po skonceni probihajici operace.

Napada me, ze by slo pripojit dalsich 8 bitu na datovou sbernici a kontrolovat, zda tam je to, co tam byt ma - pripadne pak na nejaky ladici UART posilat informaci, kdyz to tak neni - tj. co se na datove sbernici vlastne ukaze...

Urcite je divne, ze cteci cykly jsou najednou kratke. Pri 3.5MHz ma byt delka M1 570ns, u RD a MREQ 430ns. Ze to zabloudi je pak dusledek spatne prectene hodnoty - v tomto pripade to je zrejme velikost skoku DJNZ (instrukce na adrese 7 se zrejme nacte OK, z adresy 8 uz to precte chybnou hodnotu).
Jedine, co se da poradit, je zkusit zjistit pricinu nahleho zkracovani RD, MREQ - zda se to deje i v normalnim rezimu pri behu programu z ROM, pri behu programu z video RAM, z nesdilene RAM...

ROMCS-D jsem videl na nejakem schematu - asi to bylo od jineho Didaktiku - mam v tom docela zmatek :-)


Nahoru
 Profil  
 
PříspěvekNapsal: 24.04.2016, 22:21 
Offline
Prvnička

Registrován: 07.03.2016, 14:56
Příspěvky: 20
Bydliště: HK
Has thanked: 0 time
Been thanked: 1 time
Tak to vypada na nejaky jiny problem :(. Ted jsem udelal jeste nekolik mereni a pri nich tam zadny podezrele kratky RD cyklus neni a stejne to vykoleji.

Zkousel jsem si do log. analyzatoru pripojit mj. CLK (jestli tam neco neuvidim) a nejak ho nemuzu namerit (jen misty par pulsu, ani neodpovidajici sirky), ale treba ho ma ta Gama nejaky rozbity...

Jinak ten ARM ma na vstupech buffery se Schmittem, ktery nejde vypnout. Log. analyzator je bez Schmitta.

Z80 program je v poradku, bezi z RAM bez problemu, i z Video-RAM (s pozorovatelnym zpomalenim presne podle ocekavani).

Pavel


Nahoru
 Profil  
 
PříspěvekNapsal: 25.04.2016, 07:46 
Offline
Kecálek

Registrován: 07.05.2014, 12:10
Příspěvky: 197
Bydliště: Jbc
Has thanked: 0 time
Been thanked: 39 times
Moje myslenka s behem programu z ROM/RAM/VRAM byla: podivat se, jestli tam take dochazi k podivnemu zkracovani RD, MREQ signalu...
Ted me jeste napadlo, jestli by treba neslo zkusit posadit ten program na nejakou nevyuzitou adresu v ROM. Nechat system normalne nabehnout a pak spustit program v simulovane casti ROM. Simulator musi ovladat ROMCS signal - blokovat skutecnou pamet pouze pri pristupu na simulovane adresy. Mimo jine pak lze udelat program pro cteni/kontrolu teto casti ROM, takze pokud bude dochazet k chybam, nemuze nic zabloudit. Az bude cteni dat ze simulovane ROM fungovat na 100%, tak teprve pak ten kod spustit...?


Nahoru
 Profil  
 
PříspěvekNapsal: 25.04.2016, 11:00 
Offline
Radil
Uživatelský avatar

Registrován: 12.05.2013, 20:32
Příspěvky: 457
Bydliště: Kladno
Has thanked: 46 times
Been thanked: 118 times
a řešíš nějak ten signál Wait? Jestli se nepletu tak ULA ho nečte, ale generuje, jestli se ti to nehádá právě s ULA...

_________________
>>eLeMeNt, MB03+, Amiga 1200, ZX Spectrum 128 +2A, ZX Spectrum+, Didaktik Gama, LnxSpectrum, LnxTracker, LnxAmigaImageConvertor, https://www.ilnx.cz <<


Nahoru
 Profil  
 
PříspěvekNapsal: 25.04.2016, 11:39 
Offline
Prvnička

Registrován: 07.03.2016, 14:56
Příspěvky: 20
Bydliště: HK
Has thanked: 0 time
Been thanked: 1 time
WAIT neresim. ARM by mel stihat odpovidat vcas (zpozdeni je videt ve screenshotu na signalech RD&MEMREQ vs. D_READY), takze nastavovat ho nepotrebuju. A naopak cist (kdyby ho ULA nastavovala) ho snad taky nepotrebuju - pro me, jako ze emulovanou externi ROM, jsou snad smerodatne jen signaly RD+MEMREQ, ne? Skutecna externi ROM by snad taky WAIT necetla.

Podle schematu Didaktik Gama je WAIT pritazeny pull-upem na log. 1 a do ULA zapojeny neni. Nicmene nekde jsem cetl, ze nejake pozdejsi generace ZX (Issue +2?) delaji contention pres WAIT misto protahovani CLK signalu ("zastavovani hodin") - overeno to nemam a jelikoz se me to zatim snad netyka, tak jsem to neresil.

Diky,
Pavel


Nahoru
 Profil  
 
PříspěvekNapsal: 25.04.2016, 13:37 
Offline
Óm Nejvyšší

Registrován: 22.05.2013, 21:14
Příspěvky: 3642
Bydliště: Bratislava
Has thanked: 371 times
Been thanked: 788 times
pavkriz píše:
Nicmene nekde jsem cetl, ze nejake pozdejsi generace ZX (Issue +2?) delaji contention pres WAIT misto protahovani CLK signalu ("zastavovani hodin") - overeno to nemam a jelikoz se me to zatim snad netyka, tak jsem to neresil.
Contention cez WAIT robi ruska PLA pouzita v Didaktiku M a Kompakt. CLK sa generuje napevno 4 MHz (bez predlzovania pulzov) a WAIT-om sa vytvara priestor pre citanie videoram kvoli zobrazovanu.


Nahoru
 Profil  
 
PříspěvekNapsal: 25.04.2016, 18:55 
Offline
Prvnička

Registrován: 07.03.2016, 14:56
Příspěvky: 20
Bydliště: HK
Has thanked: 0 time
Been thanked: 1 time
Jeste me napada, zda neni nejaky problem v tom, ze mezi datovou sbernici ARMu a ZX mam 120R odpory v duchu http://velesoft.speccy.cz/protector.htm ?
Ono jinak pri tech chybach behem vyvoje bych se dost casto "pral" na datove sbernici s necim jinym a nerad bych mazlika odpalil...
Prekvapuje me, ze na MZ UNICARD zminene vyse nic takoveho neni - neni to "u usta" nebo spis o ULA ;) ?


Nahoru
 Profil  
 
PříspěvekNapsal: 25.04.2016, 23:02 
Offline
Radil

Registrován: 08.10.2013, 18:00
Příspěvky: 296
Has thanked: 12 times
Been thanked: 228 times
pavkriz píše:
Prekvapuje me, ze na MZ UNICARD zminene vyse nic takoveho neni - neni to "u usta" nebo spis o ULA ;) ?
No není se čemu divit. 1) Všechny signály na sběrnici MZ800 jsou oddělené budiči, takže max. odejde budič. 2) V použitém ARMu lze zvolit, jaký max. výstupní proud bude IO pin dávat. 3) GDG (obdoba ULA) se v MZ800 s procesorem nepřetahuje o data na sběrnici a nic Z80 nebrzdí, časování je tak vždy stejné. 3) V UNICARD nejsou v obsluze sběrnice chyby ;)


Nahoru
 Profil  
 
Zobrazit příspěvky za předchozí:  Seřadit podle  
Odeslat nové téma Odpovědět na téma  [ Příspěvků: 31 ]  Přejít na stránku 1, 2, 3  Další

Všechny časy jsou v UTC + 1 hodina [ Letní čas ]


Kdo je online

Uživatelé procházející toto fórum: Žádní registrovaní uživatelé a 9 návštevníků


Nemůžete zakládat nová témata v tomto fóru
Nemůžete odpovídat v tomto fóru
Nemůžete upravovat své příspěvky v tomto fóru
Nemůžete mazat své příspěvky v tomto fóru
Nemůžete přikládat soubory v tomto fóru

Hledat:
Přejít na:  
Založeno na phpBB® Forum Software © phpBB Group
Český překlad – phpBB.cz