OldComp.cz

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

Prijdte se bavit!

Právě je 24.09.2021, 05:30

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




Odeslat nové téma Odpovědět na téma  [ Příspěvků: 1445 ]  Přejít na stránku Předchozí  1 ... 93, 94, 95, 96, 97
Autor Zpráva
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 18.11.2020, 15:16 
Offline
Pan Generální

Registrován: 19.07.2013, 15:54
Příspěvky: 2321
Has thanked: 111 times
Been thanked: 291 times
Tak po urcitem casu jsem se ted podival na to v jakem case se co aktivuje.

Kód:

                                         .                   .                   .         tecka - vynulovany citac 0..7
LD32_impuls_log1               0000 0000 1111 0000 0000 0000 0000 0000 0000 0000 1111 0000
VAx_in_latch1_clk_log1         0000 0000 0000 0001 0000 0000 0000 0001 0000 0000 0000 0001 text data
VAx_in_latch2_clk_log1         0000 0001 0000 0000 0000 0001 0000 0000 0000 0001 0000 0000 atb. data

vysledek                       0000 1100 0000 0000 0000 1100 0000 0000 0000 1100 0000 0000 signal horizontal_counter_carry_in_impuls_log1
CLK0_not                       1010 1010 1010 1010 1010 1010 1010 1010 1010 1010 1010 1010 klicove hodiny 
inkrement hor. citac                  1                   1                  1                                       

nVRAS_out                      0000 0011 1100 0000 0000 0011 1100 0000 0000 0011 1100 0000
nVCAS_out                      1111 0000 1111 0000 1111 0000 1111 0000 1111 0000 1111 0000
nVRWR_out                      1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111
nVOE_out                       1111 0000 1111 0000 1111 0000 1111 0000 1111 0000 1111 0000


Zajimalo mne jak jsou delane impulsy a kdy v case se aktivuji.

Prvni zajimavy signal je paty od leva. Zde Cas jde dolu. V tuto dobu se ulozi adresa ze ktere se bude cist ATB (dummy) informace. Hned nasleduje impuls co inkrementuje horizontalni citac. Potom nasleduje cteni vlastnich dat z ATB (dummy). Pak nastava LD32 - jenz da vysledne data do par/ser modulu a nasledne budou poslany na obrazovku. Za urcitou dobu pri dalsim /CAS se ulozi adresa TEXT do pameti a nasledne za 3x28ns se ctou data (min CAC-60ns). Pak opet nasleduje cast ATB.

Idealni je brat tento hlavni vnitrni "citac" ne jako 8 stavovy ale radeji 16 stavovy aby se to dalo casem lepe predelat na FPGA co ma jen nabeznou hranu. Jeden stav trva 28 ns. Vyuziva se jak nabezna, tak sestupna hrana CKL0 signalu.


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

Registrován: 19.07.2013, 15:54
Příspěvky: 2321
Has thanked: 111 times
Been thanked: 291 times
Tak na http://www.radeksuk.cz/sharp/gdg/program/data20201119/ jsem dal posledni data.
Model je stale stejny jen jsou nove nazvy bloku a cest.

Dalsi krok bude prejmenovat generatory signalu. Konkretne CK32,DQ1,DQ2,DQ3.

Asi je nazvu:
CK32_CLK2 (vystup_oscilatoru_o)
DQ1_CLK4 (CPU_1_delic4_o)
DQ2_CLK8 (vystup_faze1_no)
DQ3_CLK16 (h_counter1_o1_latch)

Prvni je jmeno podle servisniho manualu. V zavorce je to co ted pouzivam. Jmeno za podtrzitkem bude nove jmeno co rika pocet nul a pak pocet jednicek. Cislo za druhym podtrzitkem posunuti oproti vynulovani hlavniho citace DQ1 az DQ2.

napr:
generator_impulsu3_o_signal DQ1_CLK4_2 - ctyri nuly jsou posunute o dve pozice doprava
generator_impulsu3_delay DQ1_CLK4_3 - ctyri nuly jsou posunute o tri pozice doprava
vystup_faze2_o DQ2_CLK8_4 - osm nul jsou posunute o ctyri pozice doprava
faze2_o_mix_oscilatoru_o_delay DQ2_CLK8_10 - osm nul jsou posunute o deset pozic doprava

Techto 8 signalu s pomoci par hradel dela vetsinu ridicich signalu uvnitr GDG.

Jedna horizontalni radka ma 1136 cyklu a jeden trva 56ns. Prevedeno na 28ns je to 2272 cyklu. Zpracovani dvou bajtu trva 32 cyklu po 28 ns a taktovychto je na jednom radku 71. Takze 71x32x28 ns je cca 64us. Z manualu neni uplne zrejme ale je dulezite, ze nejdrive je DISP cycle a pak nasleduje CPU cycle. Uvnitr GDG se neustale generuji signaly jako nVRWR a az kdyz ma tento signal vyjit ven z GDG tak je blokovan a povolen jen kdyz se opravdu zapisuje do video ram. Treba tento signal je hodne vyuzivan uvnitr GDG.


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

Registrován: 19.07.2013, 15:54
Příspěvky: 2321
Has thanked: 111 times
Been thanked: 291 times
Tak jsem prejmenoval casove signaly. Vse jsem dal k sobe. Citace citaji neustale dokola. Rucne jsem kontroloval signaly, to dalo hodne prace a hodin. Ted ale muzu v klidu rici ze casove jadro je samostatne a cele se to meni jednou za 28 ns. Zpozdeni (zrychleni) hradel na ceste neni uvnitr GDG kriticke. Samozrejne je to ale dulezite k vnejsim soucastkam jako je treba video ram. Ve finalni verzi repliky GDG bude potreba zajistit podobne casovani signalu co vedou ven. Ted par mist uvnir GDG, kde jsou zpozdovace pomoci hradel zasebou se budou muset nejak vyresit. Hlavne zpozdeni signalu "load" smerem na par2ser obvod.

Data jsem opet zverejnil. Jsou zde http://www.radeksuk.cz/sharp/gdg/program/data20201120/


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

Registrován: 19.07.2013, 15:54
Příspěvky: 2321
Has thanked: 111 times
Been thanked: 291 times
Tak v noci jsem se podival na cast co obsahuje paralelni/serial konvertor a pak nasleduji zpracovani ktere posilaji data na monitor.

Udelal jsem si rozbor kdy se meni jake signaly. Je mi jasne ze zde se neda nic "synchronne" nebo bezpecne udelat, protoze to jede na maximalni frekvenci GDG.

toto je mala ukazka kdy se co meni.
Kód:
00001111000011110000111100001111 pixel_clock - 4x zvetsene
          D       D       D      par2ser - vyda dalsi bit
        L                        par2ser - serial_load_log1
        D       D       D        ulozi vystup par2ser do registru
            U       U       U    BLUE_out


Je jasne ze na dvou mistech se meni data. To neni problem, obe mista maji stejne hodiny. Problem je ale v kombinaci LOAD signal a "par2ser - vyda dalsi bit". Proste "par2ser - vyda dalsi bit" je umyslne v realnem GDG zpozden pres 7 bufferu. Asi se pocitalo 7x2ns=14 ns. Osobne jsem to vyresil v FPGA zpozdenim 3ns. Jinak bez toho to dela to, ze okraje znaku jsou nesmyslne. Proste to zabrazuje jine deformovane znaky. Je zde hazard.

Dnes jsem se podival na dalsi problem. Druhy zasek je v "external_CPU_in". Uz pri lusteni schematu jsem si rikal ze je divne ze signal se generuje uvnitr a pak jde "skoro" ven a vraci se opet zpet. Bez zpozdeni na tomto signalu nedochazi k zastaveni GDG pres Wait. Proste je tam hazard a obcas to funguje a obcas ne. Opet staci v FPGA to zpozdit o 3 ns a problem je vyresen.

Jinak jak ted testuji GDG ukazuji nasledujici radky. Upravuji primo mz800_rom.coe, coz je virtualni epromka. V miste kde uz je vse inicializovane a resi se stisk klavesy si odzkocim na cast kde je bezne obsluha QD. Zde mam testovaci prikazy co delaji smycku a tak pekne vidim co se deje. Ted mam nastaveno 8000 vzorku a tak muzu logovat cca 60% jednoho horizontalniho radku v rozliseni 3ns. Najednou ted loguji 64bitu abych videl hodne signalu soucasne. To je obrovska vyhoda Artix7 co mam. Ma relativne velkou vnitrni pamet.

ea6c zmena z cd 03 00 na 11 a3 11 cd 3 0 -> c3 b7 e9 - Label QBT: sluzby quick disku
puvodni 11 a3 11 cd 3 0
nove 11 a3 11 c3 b7 e9

Label QBT: sluzby quick disku
na e9b7 cd 13 eb 3e 2- muzu prepsat
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 2223 24 25 26 27 28 29 3031 32
CD 13 EB 3E 2 20 EC CD EC EE CD 27 EF 11 A7 ED 38 6B CD 59 EA 3E D 32 A3 11 CD 5F F2 3E 1 32

nove zadano:
1 2 3 4 5 6 7 8 9 0 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
3e 65 32 00 d8 3e 62 32 00 d8 3a d8 00 c3 b7 e9 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


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

Registrován: 19.07.2013, 15:54
Příspěvky: 2321
Has thanked: 111 times
Been thanked: 291 times
Tak dobra zprava. Model neustale predelavam. Ted mam uz i DISP signal. Hodne veci je ted srozumitelnejsi nez drive.

Zatim jsem narazil na nesrovnalost u Waitu. Na strane 13 se pise ze nez prijde zatemneni tak v rezimu MZ700 je pozastaven cpu. To stejne se da odvodit z technickeho manualu pro MZ700. Ale na strane 16 je tento obrazek a text. Podle toho bych ocekaval ze prvni zapis do video ram se da do nejakeho vyrovnavaciho registru. Az druhy zapis zastavi procesor. Text u obrazku se dokonce da pochopit ze az treti zapis zastavi procesor? V nasem realnem modelu ale okamzite jak se dokonci zapis od cpu a nWR signal jde nahoru, tak jsou splneny vsechny podminky pro wait cpu? Protoze je nastaven rezim MZ700, tak neustale se opakuje vnitrni DISP_Cycle a neni tak mozno ulozit data do video ram. Az pri zatemneni je video ram uvolnena a muzou se ulozit.

Jinak jsou zajimave ty CPU_Cycle1 a CPU_Cycle2. Je tam stavovy automat co prochazi stavy. Jen u rezimu MZ800 320x200 je dulezity i stav CPU_Cycle1. Jinak se na nej ani automat nediva a je maskovan log1.


Přílohy:
wait.png
wait.png [ 13.75 KiB | Zobrazeno 125 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ů: 1445 ]  Přejít na stránku Předchozí  1 ... 93, 94, 95, 96, 97

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 2 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