OldComp.cz

Prosim, prosim ja se hlasim, ja to vim. Odpoved je videt v priloze.

Jinak s tim pojmem "synchronizace" nesouhlasim, ja tam vidim "video enable".

Jeste doplnim ze v Sharp_MZ-800_ROM_Poznamky_Odehnal-Veverka.pdf v sekci 21.11 je ten bit 2 popsan jako superimpose bit.

Tak jo, nevim jestli to vsichni vidi v obrazku , ale je to tak, je to opravdu stav bitu CKSW. Ale to uz popisoval Petr Odehnal ve zminovane knizce. Jak na to ti kluci tenkrat prisli, je mi zahadou. A opet si zaslouzi muj obdiv.

To je presne pojem, ktery pouzili Petr a Martin v "Poznamkach ...". Uz je to historie, skoro jako vytesano do kamene.

Opravdu to tam je, ja si to neuvedomil, ze se to toho tyka. Tak to byl pro me tak trochu novy objev.

---
Pokud by se suksoft nestavel do role vedouciho , zaslouzil by si pochvalu pred nastoupenym kolektivem. Jenze ono by to mohlo byt pochopeno jako podlezani, tak nic

_________________
Sharp MZ-800++, MZ-1500++, MZ-2500++, SM-B-80T, MK-14_replica, HP-85, ZX-80+replica, ZX81, ZX-Spectrum+replica++, PMI-80+replica, SAM coupe++, PMD-85-2A+3, Didaktik-M, SORD-M5, TI-57, TI-59+PC-100, TI99/4A, ZetaV2+ppp, ZX-uno, Petr

Ja se ale nestavim do role vedouciho, ja jsem . Ale konec srandy.

Ty knizky od Petra Odehnala jsou stale super. Na dobu kdy to vyslo je to zazrak.

Ohledne te synchronizace. Bezne se pouziva pojem "video enable" na dobu kdyz generator obrazu zobrazuje data. V dobe kdy nezobrazuji data, se po urcitou dobu generuje synchronizacni impuls ale ten je vzdy kratsi nez neaktivni video enable. Podle mne je vhodne pro oba signaly pouzivat rozdilna jmena. Jiny signal uvnitr pocitace opravdu dela fyzickou synchronizaci a ta jde ven z GDG smerem k monitoru/modulatoru. Toto je vhodne tema na diskusi.

Jinak muj nazor na servisni manual je stejny jako ma Nobomi. Vse je tam napsano ale bohuzel pri precteni to neni poradne videt. Az pri laborovani s GDG nebo signaly, se v manualu najde informace jak to funguje. A to je napr. i ten pripad jednoho bitu v RF a WR (skoda ze nepouzivaji zkratky RFR a WFR). Pro WR se jinde v manualu pouziva WF.

Mikesi prijedes na OCP? Muzes sebou vzit klidne Sama. Nebo Sama a Sama.

Tak po urcitem casu jsem se ted podival na to v jakem case se co aktivuje.



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.

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.

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/

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.

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