OldComp.cz

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


Právě je 29.03.2024, 08:53

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 ... 79, 80, 81, 82, 83, 84, 85 ... 100  Další
Autor Zpráva
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 31.12.2019, 19:58 
Offline
Kecálek

Registrován: 28.10.2016, 21:03
Příspěvky: 122
Has thanked: 13 times
Been thanked: 50 times
Aha. Jestli jsem to časování dobře pochopil, tak průběh signálů pro PAL je jako na obrázku v příloze. HBLN je přesně stejně dlouhý jako to, co je na bitu 7 portu 0CEh?


Přílohy:
signal_line-1600.png
signal_line-1600.png [ 3.7 KiB | Zobrazeno 7053 krát ]
Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 31.12.2019, 21:30 
Offline
Pan Generální

Registrován: 19.07.2013, 15:54
Příspěvky: 2723
Has thanked: 144 times
Been thanked: 422 times
Ano je to tak jak pises. HBLN je uvnitr jen jeden. Ale pozor, log0 u HBLN znamena, ze je to doba
kdy se nezobrazuji data z video ram (mozna bych pouzil vyraz horizontal_video_enable) ale klidne se v te dobe zobrazuje border. Takze vzdy neplati, ze kdyz je HBLN-log0, tak ze vystup cerny. Take neplati to co ma platit, ze HBLN ma sirku 36,088us.

Takze je mozne ze blizke dobe se rekne ze Bit7 z 0CEH neni HBLN ale horizontal_video_enable. Obdobne u bitu6 to bude vertical_video_enable. Zde pockam na vyjadreni Nobomiho a Mikese21. Nechci byt prvni kdo rekne, ze oznaceni snimkove zatemneni v http://archivek.ordoz.com/sharpemu/5555 a Sharp_MZ-800_ROM_Poznamky_Odehnal-Veverka.pdf neni uplne presne.

Jinak to 451ns mas spravne vypocitane. Je to i v technickem navodu sm800.pdf u casoveho prubehu videa pro rezim MZ700.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 01.01.2020, 03:49 
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 na tom premyslel a podle mne Lukz by se to melo u tveho obrazku popsat takto:

1) horizontal_video_enable
2) nHBLK
3) nHSYNC

Cele spatne oznaceni signalu vzniklo uz v manualu pro MZ700 sm700.pdf. Pise se tam ze HBLK ma sirku 38.088us. Pak v manualu sm800.pdf se pise ze na pametovem miste 0E008H se cte HBLK. Nikdo uz nespocital, ze je to presne 40 znaku 320x200 a protoze dle PAL normy musi byt pred a po synchronizacnim impulsu na chvilku cerna barva, tak toto nemuze byt signal Blank v pojeti PAL normy. Proto pojem HBLK u MZ700 je vlastne "horizontal_video_enable". Pri konstrukci MZ800 toto uz autor vedel a tak pridal ten "opravdovy pal" nHBLK do portu 0CEh co realne ukazuje nHBLK dle pojeti PAL normy a co jde i na vystup GDG kde se podle tohoto nHBLK dela cerna barva pred a po sync. Takze vystup video signalu je dle normy.

Kdyz budu vychazet z textu:
http://archivek.ordoz.com/sharpemu/5555

a vemu tyto dva radky:
HSYNC na 41,6 taktu procesoru je v 0, zbytek vidoradku v 1
HBLNK je v 0 o 30,4 taktu pred a 27,2 taktu po HSYNC dele

1) Tak nHBLK opravdu tva 41,6 taktu procesoru.
2) Druhy radek rika, ze k temto 41,6 mam pripocist 27,2 a 30,4 taktu (to je ten cerny border pred a po sync) a tak dostavam 99,2 taktu cpu a to je prave to cislo "62" (99,2*5/8) coz je doba kdy se nezpracovavaji data z video ram (62+80=142). Takze definice "horizontal_video_enable" je platna.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 01.01.2020, 14:50 
Offline
Kecálek

Registrován: 28.10.2016, 21:03
Příspěvky: 122
Has thanked: 13 times
Been thanked: 50 times
Upravene popisky podle komentare od Suksoft.

Horizontal line PAL timing


Přílohy:
signal_line_2-1600.png
signal_line_2-1600.png [ 4.02 KiB | Zobrazeno 6989 krát ]
Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 01.01.2020, 17:13 
Offline
Pan Generální

Registrován: 19.07.2013, 15:54
Příspěvky: 2723
Has thanked: 144 times
Been thanked: 422 times
Ted je to podle mne spravne.

Pojdme rozsirit overeni jeste o stranku https://nobomi.cz/8bit/doc/mz800pal.php. Zde si muzete vsimnout cisla 106 a 22. Logicky by melo byt 104 a 24. Ale pozor, pred pouzitim HBLK jsou na ceste dva flip-flop a ty zpozduji signal o dva pixel takty. Proto se to cele posunulo doprava. Takze i tento obrazek je logicky spravny.

Jinak jeste jsem koukal na pallete register a zatim tam vidim to co je v manualu a nic navic. Aby se usetrilo misto na cipu, tak se nepouziva flip-flop registr ale d-latch registr F601 a tak aktivace registru je trosku slozitejsi.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 01.01.2020, 18:07 
Offline
Kecálek

Registrován: 28.10.2016, 21:03
Příspěvky: 122
Has thanked: 13 times
Been thanked: 50 times
Tak horizontální časování je už od suksoft prozkoumané na úrovni hradel, a ověřené.

Mám teď otázku, jak je to ve vertikálním směru? Také je tam nějaký čítač? S bity 6 a 4 hodnoty z portu CEh to bude nějak obdobně jako s těmi 7 a 5? Jestli tam pasuje jméno VBLNK nebo by to mělo být také něco jako vertical_video_enable.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 01.01.2020, 18:44 
Offline
Pan Generální

Registrován: 19.07.2013, 15:54
Příspěvky: 2723
Has thanked: 144 times
Been thanked: 422 times
Zde pocitej ze to bude obdobne:

-vertical_video_enable
-VBLK
-VSYNC

Jinak aby se vedelo ze to neni uplne trivialni to i simulovat. Dulezita informace je, ze RESET uvnitr GDG trva cely jeden snimek a tak docela dlouho musite mit spustenou simulaci, nez cele GDG zacne davat smysluplny vysledek.

Musime mit nekde uvnitr nejakou chybu, protoze se nezobrazuje zadny obrazec. Zatim nemam DAG poradne zpracovany. Vidim tam 3x4 bitovy citac. Coz je malo, musi tam byt jeste alespon jeden bit navic. Je potreba tech 8000 kombinaci. Take u vertikalniho citace je potreba se na to poradne podivat. Ja tam vidim jak pise Nobomi dva bity navic ale musim poradne se na cely FSM podivat. Je mozne ze jen jeden bit cita a druhy je jen vyhodnoceni stavu (samozrejme take cita :-) ) a generovani impulsu dale do systemu (carry-out). Toto je dulezite si uvedomit, to proto, ze po zapnuti muze byt v citaci cislo 0 a tak ne 312 radku tva nez dojde k carry-out ale dokonce to trva 1024 radku! Takze reset muze klidne trvat ne 20ms ale vice nez 65ms.


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

Registrován: 19.07.2013, 15:54
Příspěvky: 2723
Has thanked: 144 times
Been thanked: 422 times
Tak si rikam ze nebude spatne ukazat pracovni schema video vystupu z GDG. To by mohlo zajimat radu lidi i kdyz to jeste neni dokoncene. Uplne vlevo nahore je vstup Attributu v rezimu mz700. Vsimnete si jak bila barva dostane priznak light white. Vpravo od toho je mux co prepina vstup budto ze systemu mz700 nebo z mz800. Vpravo od toho jsou pal registry. Zde si vsimnete, ze pro rezim mz700 pres ne jdou data! Vpravo je mux 1/4. Ten vybira data ze spravne radky pal registru. Vpravo od nej je mux_prepare, ten dela to, ze kdyz je napr. mz800 320x200 16 barev tak pro 12 barev jde vstup primo ze seriovych dat na vystup a 4 barvy jdou pres pal registr a je mozno je zmenit. V systemu vpravo je jen moznost zobrazovani borderu, cerne barvy okolo sync impulsu a nebo barvy bodu co se prave zobrazuje.

Takze prepnuti z rezimu mz800 do rezimu mz700 poskodi pal registry. Ne vsak sw0 a sw1. To jsem predtim nikdy neslysel.


Přílohy:
schematic.pdf [203.65 KiB]
386 krát
Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 02.01.2020, 17:15 
Offline
Kecálek

Registrován: 28.10.2016, 21:03
Příspěvky: 122
Has thanked: 13 times
Been thanked: 50 times
Schválně, jestli tomu dobře rozumím. Obvod rr_03_reg_blue_inst jsou čtyři jednobitové registry. Každý registr obsahuje modrou složku jednoho paletového registru. Takže společně s rr_03_reg_green_inst,
rr_03_reg_red_inst a rr_03_reg_yitn_inst je to šestnáct bitů, neboli čtyři čtyřbitové paletové registry.

Když se má změnit hodnota paletového registru 0 v rr_03_reg_blue_inst, tak se aktivuje write_pal_reg0, a zároveň se někde musí poslat nová hodnota pro modrou složku tohoto registru. Vidím tam dva neoznačené vstupy, P4880533 a P5230464, takže asi jeden z nich to je.

Ale na co je ten druhý vstup? Tj. proč jsou tam dva, P4880533 a P5230464? Jo možné, že jeden z nich aktivuje nějaký speciální režim, kdy se nic v registru nemění, ale data procházejí skrz?


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

Registrován: 19.07.2013, 15:54
Příspěvky: 2723
Has thanked: 144 times
Been thanked: 422 times
Obrazek jsem rozklikal aby jedna cesta sla videt v datailu.

Jinak mam tam chybu u te light white, spravne je black. Vsechny barvy jsou automaticky svetle a pro cernou se upravdu pouzije cerna barva (ne seda).

Ten vstup VA0_in_latch2_o je "back" modre barvy. VA4_in_latch2_o je "front" modre barvy - presne jak to dela Sharp MZ700. Oba vstupy projdou pres rr_04_mux_700_800_blue_inst do rr_03_reg_blue_inst, kde kazdy tento vstup "obsadi" dve pametove mista. Takze ve dvou bitech BACK a ve dvou je FRONT.

V pripade ze je rezim MZ800 tak vstup od CPU je DT0_in_vstup_reg. V rr_04_mux_700_800_blue_inst se zdvoji a je videt na obou vystupech, nasledne v rr_03_reg_blue_inst se dostane do vsech 4 bitu. Takze opravdu je schopen se dostat do vsech ctyrech registru jako bit0. To rika i manual.


Přílohy:
schematic.pdf [190.67 KiB]
383 krát
Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 02.01.2020, 19:48 
Offline
Kecálek

Registrován: 28.10.2016, 21:03
Příspěvky: 122
Has thanked: 13 times
Been thanked: 50 times
Už rozumím. Ten přenos barev do paletového registru by měl jít vyzkoušet na reálném Sharpu. Např. tímto programem.
Kód:
 .org 2000h
 ld a,72h     ; attribute
 ld hl,0d800h
 call 9d5h    ; fill memory
 ld b,1
 call 02c8h   ; wait
 xor a        ; dmd=0
 out (0ceh),a ; switch to 320x200
 in a,(0e0h)  ; map VRAM
 ld a,3       
 out (0cch),a ; single write
 ld hl,8000h
 ld sp,hl
 call 9d5h    ; fill memory
 halt


V monitoru, příkaz M2000 a pak zadat hodnoty
3E 72 21 00 D8 CD D5 09
06 01 CD C8 02 AF D3 CE
DB E0 3E 03 D3 CC 21 00
80 F9 CD D5 09 76

Pak spustit J2000 .

Nastaví se atribut 72, tj. bílá na červené, pak se přepne do módu mz-800 a v horní části obrazovky se nakreslí svislé čáry. Pokud se přenesou data do paletového registru, tak by barvy měly být také bílá na červené.

V emulátoru mi to nefunguje, tam mi to zobrazuje bílá na modré.


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

Registrován: 19.07.2013, 15:54
Příspěvky: 2723
Has thanked: 144 times
Been thanked: 422 times
Asi mas spatny emulator :D . V priloze je realny Sharp s pravym monitorem.


Přílohy:
pal_obraz.JPG
pal_obraz.JPG [ 769.03 KiB | Zobrazeno 7292 krát ]
Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 03.01.2020, 19:50 
Offline
Kecálek

Registrován: 28.10.2016, 21:03
Příspěvky: 122
Has thanked: 13 times
Been thanked: 50 times
Paráda. Tak teorie je potvrzena.

Ještě může být dobré prozkoumat, jestli ovlivňování paletových registrů se děje jenom při kreslení v části grafiky, nebo i během kreslení borderu.

Kdyby to bylo jen při kreslení v části grafiky, tak to znamená, že registry jsou ovlivněné popředím a pozadím posledního skutečně kresleného znaku. Jestli to ale prochází skrz paletové registry i během výstupu borderu, tak v tu chvíli se tam může dostat asi kdovíco.

To ovlivňují signály write_pal_reg0, write_pal_reg1, write_pal_reg2, write_pal_reg3. Dá se ze schematu poznat, jestli jsou někdy během generování řádku signály vypnuté (v módu mz-700)?


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

Registrován: 19.07.2013, 15:54
Příspěvky: 2723
Has thanked: 144 times
Been thanked: 422 times
Lukz ted prejmenovavam cesty a koukam se co se kde nastavuje. Radeji napisi jeste ted, at to treba si prectes jeste pred spanim.

Border je nadrazen, ten to neovlivnuje. Osobne to vidim, ze opravdu jen pri rezimu mz700 a pri zapisu ATR jsou nastavene pallete registry PLT0 az PLT3. Pocitej ze na 99,99% to je tak. Samozrejme pri rezimu mz800 je to jak se ocekava. Ale zde je podle vseho jedna zrada a to, ze to nefunguje jen na F0 ale take na OUT F1. To musime take odzkouset.


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

Registrován: 19.07.2013, 15:54
Příspěvky: 2723
Has thanked: 144 times
Been thanked: 422 times
-v modulu mz800_frameB_no_log1 je cast pro mz700 a pro mz800
-mz800_FrameB_log0 v modulu rr_07_pal_sel2_inst funguje i v rezimu mz700 a tak odsud se podle vseho berou seriove data z ser_store_blue2_plane1_o


nastavani selektru pal registru v mz700 rezimu
pal_sel_1a_o log1
pal_sel_1a_no log0
pal_sel_2_o not(ser_store_blue2_plane1_o) {log0-back}
pal_sel_2_no ser_store_blue2_plane1_o {log1-front}

rezim mz700
back se uklada do PLT0 a PLT2
front se uklada do PLT1 a PLT3

Tak na prvni nastel to vypada ze aktivni data v rezimu mz700 prochazi pres PLT2-Back a PLT3-Front.
Idelani test bude, az to bude fungovat, tak umyslne "poskodit" dummy cesty a zkontrolovat zda to stale funguje.

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.


Přílohy:
schematic.pdf [126.11 KiB]
388 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 ... 79, 80, 81, 82, 83, 84, 85 ... 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 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:  
cron
Založeno na phpBB® Forum Software © phpBB Group
Český překlad – phpBB.cz