OldComp.cz

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


Právě je 28.03.2024, 21:25

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 ... 94, 95, 96, 97, 98, 99, 100  Další
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: 2723
Has thanked: 144 times
Been thanked: 422 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: 2723
Has thanked: 144 times
Been thanked: 422 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: 2723
Has thanked: 144 times
Been thanked: 422 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: 2723
Has thanked: 144 times
Been thanked: 422 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: 2723
Has thanked: 144 times
Been thanked: 422 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 7187 krát ]
Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 26.09.2021, 13:03 
Offline
Pan Generální

Registrován: 19.07.2013, 15:54
Příspěvky: 2723
Has thanked: 144 times
Been thanked: 422 times
Tak v modelu upravuji jmena cest a trosku jsem zmenil do jakeho modulu blok patri. Delam si poznamky jak vypada kazdy dulezity signal uvnitr GDG. Zatim resim rezim MZ700. Zde logicky vse sedi. Pritom ale mam trosku obavu o rezim MZ800. Jeden signal mi tam nesedi. Zjistil jsem ze signal DISP je realne definovany jako nDISP_CPU. Pri log0 je Display cycle a pri log1 je CPU cycle. Cele se to nastavi na CPU tesne nez se zacnou vykreslovat data. Proto pri prvnim znaku a v prvni casti je log0 a tim padem v rezimu MZ700 se zpracovava TEXT a ATB. Pozdeji se to prepne na CPU a ctou se CG Data.

Microlane a Mikesi poslete mi posledni vasi verzi data.txt co pouzivate at vim ze mam uplne stejny model, dekuji. Mikesi posli i posledni platnou verzi testGDG_mod_exp.txt, zkusim pripadne porovnat modely.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 26.09.2021, 13:57 
Offline
Pan Štábní
Uživatelský avatar

Registrován: 24.05.2018, 22:32
Příspěvky: 1972
Bydliště: Most, Praha
Has thanked: 864 times
Been thanked: 697 times
Asi hloupý dotaz - tyhle detaily kolem chování signálů se nedají ověřit v reálném Sharpu napsáním testovacího programu?

_________________
i++ (INC) increment
i-- (DEC) decrement
i@@ (EXC) excrement


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

Registrován: 19.07.2013, 15:54
Příspěvky: 2723
Has thanked: 144 times
Been thanked: 422 times
Panda38 píše:
Asi hloupý dotaz - tyhle detaily kolem chování signálů se nedají ověřit v reálném Sharpu napsáním testovacího programu?

Zadny dotaz neni hloupi.

======

Co se tyce problemu Waitu tak realne jsem na FPGA udelal maly program:

3e 65 32 00 d8 3e 62 32 00 d8 3a 00 d8 c3 b7 e9 00 00 00 00 00 00 00

Je videt ze se deje presne to co je na obrazku v technickem manualu. Prvni zapis od CPU se provede a ulozi do vnitrniho registru uvnitr GDG. Pri druhem zapisu se okamzite udela Wait CPU a pocka se az se prestane dobrazovat znaky. Pak se udela prvni zapis a nasledne i druhy.

Jedine co je spatne napsane je ze to udela wait az pri tretim zapisu. Uz druhy aktivuje Wait.


Přílohy:
wait.png
wait.png [ 85.22 KiB | Zobrazeno 7025 krát ]
Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 28.09.2021, 08:03 
Offline
Pan Generální

Registrován: 19.07.2013, 15:54
Příspěvky: 2723
Has thanked: 144 times
Been thanked: 422 times
Tak dobra zprava. Podarilo se mi rozkodovat klicove signaly GDG co jsem chtel.

Dulezite bylo zjisteni ze neni spravna posloupnost Load, Display cycle, Cpu cycle jak je zobrazeno na obrazcich v technickem manualu. Spravne poradi je Load, Cpu cycle, Display cycle.

Ted mam GDG rozdeleno na 443 modulu. Uvnitr jsou ctyri hlavni citace:

1) horizontalni citac
2) vertikalni citac
3) citac DAG
4) citac horizontalnich linek

Dale je uvnitr cast co generuje hodinove signaly. Vse je synchronni a vystupy signalu nasledne jdou do hradel ktere v presne definovany cas provedou nejakou cinnost. Nektere casti jsou slozitejsi, napr. stavovy automat co prochazi stavy Cycle1 a Cycle2. Asi nejslozitejsi je zastavovani pomoci Wait. Jako ma ZX ULA zastavovani pomoci A14 a A15, tak my mame zastavovani pomoci pristupu do video ram. Staci aby doslo k zapisu/cteni do video ram a "delsi dobu" byl aktivni pristup do GDG a to vyvola zastaveni procesoru. Proto prvni zapis probehne rychle a vse se ulozi do vnitrnich registru. Kdyz ale GDG nemuze ulozit data, protoze prave treba v rezimu MZ700 zobrazuje data, tak ceka na prvni volny CPU cykl. Kdyz prijde opet dalsi zapis, tak prave ta aktivace video ram (bez aktivniho /RD nebo /WR) zajisti zastaveni CPU az do doby nez prvni zapis se realne dodela. V tu dobu v rezim MZ700 je snimkove zatemneni a proto se okamzite udela i ten druhy zapis.


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

Registrován: 19.07.2013, 15:54
Příspěvky: 2723
Has thanked: 144 times
Been thanked: 422 times
Tak dalsi uspech je tu. Snazim se rozchodit GDG na emulovanem Sharpovi v FPGA. To je docela velka vyzva. Nekopiruji cizi reseni a jdu pekne od zacatku. Ted jsem vyresil postupne par problemu. Prvni a hodne dulezity je, ze T80 emuluje Z80 hodne nepresne. Pro Sharp MZ800 spatne. Duvod je v tom ze /mreq vypada uplne nijak nez na realnem Z80. Pak nefunguje Wait signal. Nastesti to jsem vyresil malou upravou zastavovaciho obvodu. Druhy problem je take v zastavovacim obvodu. Je tam logicky pouzity spatny obvod. Musel jsem ho vymenit za jiny a uz to funguje. Casem se podivam se do zdrojovych obrazku zda zde se nestala chyba. Logicky ale to co ted mam muze i reagovat oproti puvodnimu modelu. Ten nezastavoval CPU kdyz byl pristup do GDG a soucasne se zobrazoval text.


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

Registrován: 19.07.2013, 15:54
Příspěvky: 2723
Has thanked: 144 times
Been thanked: 422 times
Tak zatim jsem zjistil ze emulace T80 co jsem pouzil negeneruje /mreq uz v T1 jako realny cip. Sama emulace kontroluje Wait az na konci T2 a ne uprostred T2. Proto jsem prozatim pouzil reseni, ze zastavovaci obvod nereaguje na signal CPU ale na !CPU. To vypada jako dostatecne funkcni. Bezne totiz GDG se rozhoduje pri nabezne hrane T2 zda bude zastavovat procesor a v pripade ze ano, tak log0 na Wait signalu pri sestupne hrane T2 zajisti pozastaveni procesoru. Az soucasny rozpracovany pristup do GDG bude dokoncen, tak bude GDG opet odblokovano a muze se zpracovat dalsi pristup do GDG. Proto az druhy zapis/cteni zablokovava GDG. Prvni se jen zacne zpracovavat a ceka se na vhodny okamzik kdy GDG muze operaci dokoncit - bezne je to v CPU cyklu nebo pri zatemneni.

Jinak jsem si cvicne naemuloval sramdisk a ulozil tam maly program 3e 57 32 00 d8 c3 00 12 abych na obrazovce videl zmenu. I on funguje a po zapnuti pocitace se automaticky aktivuje.
CRC jsem spocital rucne.

08 00 00 12 00 12 17 00 09 3e 57 32 00 d8 c3 00 12
crc-prg 2+3+2+3+2+1+3+1+2+2+1+1=23 16+4+2+1 10111
crc-all 5+4=9

Otazka je zda se zajimat o emulaci Z80. Je to zajimave tema ale i hodne slozite. Existuji mnoho zajimavych stranek. Bohuzel je to opet zabijak casu. Asi na toto otevru samostatne tema.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 04.10.2021, 15:58 
Offline
Pan Štábní

Registrován: 11.11.2013, 10:29
Příspěvky: 1198
Has thanked: 360 times
Been thanked: 304 times
Samostatne tema na emulaci Z80 urcite otevri, treba se pak muze pridat nekdo mimo skupinu Sharp.
Jinak GDG predpoklada, ze Z80 funguje spravne. Pokud tomu tak neni u emulovane Z80, tak to muze byt docela slozite. Nejdrive musis zjistit, jak moc to bude vadit. A nebo muzes 'fixnout' ten emulator a prispet tak k lepsimu poznani sveta :-)

Pozn: Pripravujes se na TM? Takze bude predvadecka? ;-)

_________________
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


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

Registrován: 19.07.2013, 15:54
Příspěvky: 2723
Has thanked: 144 times
Been thanked: 422 times
Otazka proc cesta pro VA je zpozdena oproti ceste na VC? Jedine logicke zduvodneni je aby se soucasne neaktivovalo 16 vyvodu ale nejdrive 8 a pak dalsich 8 a nebyl tak nejaky proudovy naraz.

p.s. Co se tyce tech Delay co jsou na schematu, tak to jsem tam vlozil ja aby tam bylo najeke "vyznamne" zpozdeni.


Přílohy:
va_vc_out.pdf [42.68 KiB]
244 krát
Nahoru
 Profil  
 
 Předmět příspěvku: Re: GDG foto cipu
PříspěvekNapsal: 02.11.2021, 14:39 
Offline
Pan Generální

Registrován: 19.07.2013, 15:54
Příspěvky: 2723
Has thanked: 144 times
Been thanked: 422 times
Panda38 píše:
Asi hloupý dotaz - tyhle detaily kolem chování signálů se nedají ověřit v reálném Sharpu napsáním testovacího programu?


Tak na Bytefestu byl Michal Hucik a mohl jsem s nim kratce pohovorit o GDG. Dela emulator https://sourceforge.net/p/mz800emu/acti ... 62f7175a46 . Zde se zjistilo ze na originalnim MZ700 stroji se zastavuje procesor uplne jinak nez na MZ800 v rezimu MZ700. Uz prvni zapis do video ram na originalnim MZ700 okamzite zastavuje procesor. U MZ800 stale jeste procesor bezi a zastavi se az pri naslednem zapisu do video ram. Testovalo to vice lidi na cele planete :D .

Take realne zmeril pomoci sond, ze GDG reaguje jeste chvili pred tim nez zobrazi prvni pixel ve znaku. To je co vidim i ja - 4 pixely pred zobrazenim se GDG rozhodne zda bude nasledovat DISP nebo CPU cykl. Podle toho take nacita data v video ram a pripadne zobrazuje.


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

Registrován: 19.07.2013, 15:54
Příspěvky: 2723
Has thanked: 144 times
Been thanked: 422 times
Upravil jsem rozmisteni bunek do modulu. Take jsem prejmenoval nejake cesty. Aktualni data jsem dal http://www.radeksuk.cz/sharp/gdg/program/data20220129/ . Zde je zip file. Obsahuje vse aby model sel otevrit ve Vivadu 2018.


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 ... 94, 95, 96, 97, 98, 99, 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 6 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