OldComp.cz

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


Právě je 28.03.2024, 14:33

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




Odeslat nové téma Odpovědět na téma  [ Příspěvků: 1488 ]  Přejít na stránku Předchozí  1 ... 80, 81, 82, 83, 84, 85, 86 ... 100  Další
Autor Zpráva
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 04.01.2020, 14:19 
Offline
Radil

Registrován: 08.10.2013, 18:00
Příspěvky: 296
Has thanked: 12 times
Been thanked: 228 times
suksoft píše:
Jinak jsem jeste koukal na RESET. Nastesti to pro simulaci neni kriticke. nPORT_in reaguje na reset okamzite a po prvnim h_video_enable signalu jde nahoru a tak GDG muze zacit pracovat. Pro nMNRT_in je to slozitejsi. Zde se nejdrive ceka 2x v_video_enable a pak se udela impuls 1x h_video_enable. To bude vhodne take nekdy zmerit a odsimulovat.
To muzu potvrdit, navic je to prakticky vyzkouseno, unikarta tohle u MZ800 presne pouziva, nahodi na chvili EXRESET (na pinech GDG nMNRT) a s naslednym RESETem (nRSTO) synchronizuje generovani VGA obrazu s GDG, protoze tento signal je aktivni jen a pouze po dobu prvniho zobrazovaneho radku a jen v "aktivni casti" tedy behem zobrazovani pixelu, nikoliv borderu. Coz odpovida internimu popisu vyse.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 04.01.2020, 15:42 
Offline
Kecálek

Registrován: 28.10.2016, 21:03
Příspěvky: 122
Has thanked: 13 times
Been thanked: 50 times
Ohledně těch paletových registrů, já jsem ten dotaz myslel trochu jinak.

Dokud se v režimu mz-700 kreslí text, tak pro každý znak se nejprve přečte 8 bitů s atributy (z nich se použije 6 bitů), a podle atributů se naplní paletové registry, a barvy z paletových registrů se pak použijí, když se vykresluje grafika znaku podle CGRAM.

A pak, když skončí textová oblast, se začne kreslit border, jeho barva se generuje mimo paletové registry. Jenže ty paletové registry jsou připojené i během této doby, kdy se vlastně nepoužívají, a pořád se do nich něco ukládá z obvodů rr_05_mz700_blue_inst, rr_05_mz700_red_inst, rr_05_mz700_green_inst.

Tak mě zajímá, co se do nich ukládá v této době, jestli to bude třeba černá barva, nebo se začnou číst atributy odněkud jinud z paměti, nebo jestli to jenom opakuje hodnotu atributu z posledního znaku na řádku. To by pak ovlivnilo, v jakém stavu budou paletové registry, pokud k přepnutí do mz-800 módu dojde v době po skončení textu v jednom řádku a před začátkem textu ve druhém řádku.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 04.01.2020, 17:06 
Offline
Pan Generální

Registrován: 19.07.2013, 15:54
Příspěvky: 2723
Has thanked: 144 times
Been thanked: 422 times
Co se tyce mz700 a atributu tak tam vidim aktivaci jen v urcity cas a tak predpokladejme ze je to opravdu jen v case kdy se vybira ATR z video ram. Takze pal registr si pamatuje posledni atribut co se zpracovaval v rezimu mz700. Lze i presne definovat jak je cely naplnen. Urcite bude vhodne prepinat rezimy pri pouziti h_video_enable ci v_video_enable. Je jasne, ze skoro nahodne prepnuti synchronizovane prerusenim bude take mozne ale chudaci lide co programuji emulatory, tem to spotrebuje hodne vykonu. Oni budou muset pro kazdy znak presne ukladat pallete registr.

Jinak ja ocekavam algoritmus jako v technickem manualu, takze nejdrive vyber znaku, pak vyber atributu. Z toho se veme 6 bitu a naplni se pal registr. Pak se veme jeden bit z atributu a prida se k bajtu co se nacetl jako prvni a to udela 9 bitu. To je adresa ve video ram kde se precte definice znaku a toto nasledne se bude zobrazovat.

Ted jsem "cistil" adresace. A te delam na mapovani pameti. Je to velmi zajimave.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 05.01.2020, 03:38 
Offline
Pan Generální

Registrován: 19.07.2013, 15:54
Příspěvky: 2723
Has thanked: 144 times
Been thanked: 422 times
Tak jsem ted udelal prvni kolo zpracovani veci okolo mapovani pameti. Je to relativne slozite. Nejhorsi zasek je modul ee_aktivovani_dram1_inst. Zde autor asi moc neznal mnoziny. Zkousi vsechny pametove mista jen proto, ze obcas na konci pameti muze byt dram odpojena. Dulezite je vedet ze je zde 5 RS klopnych obvodu. Ty vubec nema rado FPGA, ale pomoci DELAY clanku jsem to vyresil. Jinak neni tam nic co by neslo prepsat do rovnic a znovu to nechat lepe vygenerovat prekladacem pro FPGA. Cele mi to pripada ze autor GDG mel nejake overene mustr zapojeni a to tam vlozil i presto ze GDG ma implementovane flip-flop obvody s asynchronnim nulovanim a nastavenim.


Přílohy:
schematic.pdf [65.53 KiB]
389 krát
Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 05.01.2020, 12:36 
Offline
Kecálek

Registrován: 28.10.2016, 21:03
Příspěvky: 122
Has thanked: 13 times
Been thanked: 50 times
Tak to mapování paměti mě vždy zajímalo. Pokud vím, že jsem např. v módu mz-700, tak ze servisního manuálu se dá dobře zjistit, co se namapuje nebo odmapuje při provádění jednotlivých in-out instrukcí. Ale už z toho není zřejmé, co se stane, když přepínám z mz-700 do mz-800.

Např. pokud jsem v mz-700 a mám namapovanou nebo odmapovanou VRAM, tak co se stane po přepnutí 700 -> 800 -> zpět 700. Dostanu stejný stav namapované nebo odmapované paměti? Nebo se při té změně může uvnitř nastavení změnit, nějak resetovat?

DMD ovlivňuje, které regiony paměti jsou kam namapovány. Otázka ale je, může samotná změna DMD způsobit nějakou změnu stavu, který se pamatuje uvnitř mapovacích obvodů?


Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 05.01.2020, 15:03 
Offline
Pan Generální

Registrován: 19.07.2013, 15:54
Příspěvky: 2723
Has thanked: 144 times
Been thanked: 422 times
Presne tyto otazky jsem mel vzdy take. Cele to funguje na tomto principu. Je 5 RS klopnych obvodu. Zacnu patym, ted dela memory prohibited. To ma tu vlastnost ze od D000-FFFF v rezimu MZ700 neni nic uvnitr pocitace mapovane (u MZ800 je to E000-FFFF). Tento bit "pretrumfne" i pripadne mapovani rom, vram atd. Takze pak zbyvaji 4 RS.

Prvni je rom 0000-0fff.
Pak je CGROM 1000-1fff ale pozor resi to jen pristup do CGROM i presto ze to vypada podobne jako ovladani video ram.
Treti je video ram pro rezim mz700 mapovani CG RAM od adresy C000 a pro mz800 od 8000h.
Ctvrty jsou veci od d000 (vram pro mz700,key,timer,monitor rom).

Hlavni rozdil mezi druhym a tretim je moznost u druheho pouzit out E0. To treti neumi.

Ted reknu dalsi dulezitou vlastnost. Strasne dulezite je v jakem rezimu jsem, kdyz delam napr. out E4, kdyz jsem v mz700 tak se neprimapuje CG ROM. Ale v rezimu mz800 se to udela.

Lukz vlastni prepnuti mz700 do mz800 a zpet nic neresetuje. Stale mas stejny stav.

Mapovani veci se deje podle rezimu. Pocitac vi ze napr. pro mz700 ma video ram (cgram) na c000 a pro mz800 na 8000h. Proto to i takto zmeni pri zmene rezimu. Pri kazdem vyhodnoceni sbernice se aktualne zpracovava nastaveni.

Jinak je zde vyhodnovaci obvod co hlida aby se nahodou neco neaktivovalo navic. Cele to funguje trivialne. Kdyz je aktivovana romka tak se automaticky vypina DRAM (64KB ram) a takto se vypina dram i pri cteni (zapis) z video ram.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 05.01.2020, 17:00 
Offline
Kecálek

Registrován: 28.10.2016, 21:03
Příspěvky: 122
Has thanked: 13 times
Been thanked: 50 times
Díky za vysvětlení.

Prošel jsem si schéma od suksoft, porovnal to s popisem v service manuálu, a vše jsem si shrnul do několika málo tabulek. Teď už je to pro mě jasnější. Narazil jsem dřív u jednoho japonského emulátoru na podivné chování právě při přepínání 700 -> 800, a říkal jsem si že je to así špatně, ale z informací na internetu jsem to nemohl potvrdit. Tak tohle je teď lepší popis správného chování.


Přílohy:
map_p1_c.png
map_p1_c.png [ 4.81 KiB | Zobrazeno 7187 krát ]
map_p2_c.png
map_p2_c.png [ 9.33 KiB | Zobrazeno 7187 krát ]
Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 05.01.2020, 17:29 
Offline
Pan Generální

Registrován: 19.07.2013, 15:54
Příspěvky: 2723
Has thanked: 144 times
Been thanked: 422 times
Osobne byl ale prejmenoval VRAM1 na VRAM8 a VRAM2 na VRAM7. Bude to lepe citelne.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 05.01.2020, 17:41 
Offline
Kecálek

Registrován: 28.10.2016, 21:03
Příspěvky: 122
Has thanked: 13 times
Been thanked: 50 times
To je dobrý nápad.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 05.01.2020, 20:22 
Offline
Pan Generální

Registrován: 19.07.2013, 15:54
Příspěvky: 2723
Has thanked: 144 times
Been thanked: 422 times
Mala odbocka od vlastniho GDG.

Jak planujete kdo testovat funkcnost GDG? Ja predpokladam umyslne na realnem Sharpovi MZ800 prerusit tri spoje. Vstupni oscilator a ty dva resety. To prenest na uroven 3,3V a dat to dovnitr FPGA, nasledne to zpet vyvest a opet zmenit napajeci uroven na 5V a dat do zpet do realneho GDG. Takto bych mel uplne stejne vstupni hodnoty pro oba systemy a mohl bych "garantovat" signaly. Nasledne bych vetsinu sbernice na Z80 prevedl na 3,3V a to take vyvedl do FPGA. Take bych asi tak 20 dalsich vodicu jako napr. nKEY vyvedl ze Sharpa do FPGA. Da se rici ze FPGA by byl logicky analyzator. Takto upraveny Sharp by bezel jako "originalni" bez upravy. FPGA by mohl v urcitych intervalech kontrolovat stav vyvodu vypocitaneho uvnitr FPGA a vstup z realneho. Kdyz by byl rozdil tak by to nejak nahlasil.

Kdyz by se to i rozumne upravilo aby treba vystup iorq a mreq sel pres fpga a jeste kdyz by se fpga napojilo primo na z80 data sbernici tak by to mohlo delat i dalsi funkce.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 06.01.2020, 19:29 
Offline
Pan Generální

Registrován: 19.07.2013, 15:54
Příspěvky: 2723
Has thanked: 144 times
Been thanked: 422 times
Tak prvni "pred alfa verze" je pripravena. Udelal jsem kontrolu zda alias.txt a blocks.txt obsahuji spravne hodnoty a prave jednou. Takze kontrola na duplicitu je udelana. Ted mam definovano 1261 aliasu jmen cest. Oba soubory maji 52 tisic znaku.

V dalsi fazi vyvoje zkusim plne rozjet vertikalni citac, vse je pripraveno. Zde se bude spise jednat o vyvody z citace. Pak prejdu na DAG citac. Zamerim se na "srdce" pocitace co dela ovladaci signaly a pak i na Wait signal. Pomalu schema zacina krystalizovat.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 09.01.2020, 08:23 
Offline
Pan Generální

Registrován: 19.07.2013, 15:54
Příspěvky: 2723
Has thanked: 144 times
Been thanked: 422 times
Microlane ted jsem asi zjistil toto:
Na souradnice 161,739 neprichazi signal P1690532 ze souradnice 169,532 ale signal ze souradnice 123,533. Signal P1690532 se asi vubec nezpracovava. A na cele ceste k 161,739 je prave ten signal z 123,533.

Muzes se na to podivat? Jedna se o to ze DAG citac co ma citat od 0 do 7999 necita ted spravne. Realne nefunguje posledni bit. Ted jsem to takto ve Verilogu upravil a uz to cita jak ma. Pred upravou je v zapojeni rada obvodu co nic nedelaji ale je videt ze je to synchronni citac ale nema vubec vyveden vystup a vstup je z not_dag_citac3_i3 (P1690532).


Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 09.01.2020, 15:14 
Offline
Pan Generální

Registrován: 19.07.2013, 15:54
Příspěvky: 2723
Has thanked: 144 times
Been thanked: 422 times
Tak strucne popisi pokrok za par dni.

Toto je aktualni popis verikalniho citace:

vertical counter PAL

200 preset
200 Vertical_video_enable stop
242 VBLN start
245 VSYNC start
248 VSYNC stop
267 256+11 VBLN stop
312 Vertical_video_enable start
312 256+56 prvni radka s daty
312 reset dag - zacne pocitat od nuly
512 posledni radka s daty - 200 zobrazenych radek

Zde vse sedi. Mam trosku jiny nahled nez Nobomi. On rika ze se cita do 1024, ja vidim citani jen 512 a dalsi flip-flop clen dela jen resetovani celeho citace. Osobne mam simulaci nastavenou tak, ze po zapnuti mam vsude log0 (cislo neni definovane). Citac cita, takze prvnich 200 horizontalnich radku je zde navic, a presne toto se i dela, prvni vertikalni cyklus po zapnuti netrva 312 radku ale 512. Nasledujici ramce (frejmy) jsou uz vsechny tak jak se ocekava. Vzdy, kdyz zacina "Vertical_video_enable start" tak se nuluje DAG citac, coz je citac co cita od 0 do 7999. DAG citac se inkrementuje tak, ze na jednu horizontalni radku pripadne 40 inkrementaci. To je tech 40 znaku nebo 80. Pri 80 znacich se jen udela to, ze pixel clock je 2x rychlejsi a 2x se vybere z video ram obsah a tak je mozno za stejny cas zobrazit 2x vice informaci.

Ted se asi zamerim na srdce GDG. Uvnitr je ctyrstavovy citac. Osobne jsem to pracovne nazval faze1 a faze2. To dela zakladni impulsy co nasledne aktivuji ruzne casti GDG. Bude zajimave to lustit. Pak je jeste uvnitr system na Wait cpu. Ten je docela slozity ale uz to pomalu zacina mit najakou citelnou podobu. Take co budu muset pri tom zjistit jak je to presne se zapisem do DMD registru. Opravdu je tam 2x.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 09.01.2020, 21:19 
Offline
Pan Generální

Registrován: 19.07.2013, 15:54
Příspěvky: 2723
Has thanked: 144 times
Been thanked: 422 times
Microlane podivej se na souradnice 171,540 - mozna tam neni v layer2 spoj. Ale pak se musi najit privod pro spodni cast cest. Horni nikam asi nevede, je to negace citace.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 09.01.2020, 21:57 
Offline
Kecálek

Registrován: 28.10.2016, 21:03
Příspěvky: 122
Has thanked: 13 times
Been thanked: 50 times
Přikládám upravené tabulky mapování paměti s přejmenováním na VRAM7 a VRAM8 jak navrhl suksoft.


Přílohy:
map_p3.png
map_p3.png [ 34.21 KiB | Zobrazeno 7758 krát ]
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ů: 1488 ]  Přejít na stránku Předchozí  1 ... 80, 81, 82, 83, 84, 85, 86 ... 100  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 13 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