OldComp.cz

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

Vstava historickch poctacu

Právě je 05.12.2022, 22:09

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




Odeslat nové téma Odpovědět na téma  [ Příspěvků: 32 ]  Přejít na stránku 1, 2, 3  Další
Autor Zpráva
 Předmět příspěvku: EmuSys
PříspěvekNapsal: 31.01.2019, 22:05 
Offline
Kecálek

Registrován: 10.10.2014, 10:40
Příspěvky: 85
Has thanked: 2 times
Been thanked: 44 times
Jak mozna nekteri vite, jsem autorem jednoho z emulatoru pocitace MZ-800. Neskromne si dovolim tvrdit, ze jednoho z nejlepsich :) Nicmene s nim stale nejsem spokojeny, coz je IMHO dobry hnaci motor pro dalsi vyvoj...

Jednotlive casti emulatoru lze tematicky rozdelit na mnoho ruznych casti. Ja bych jej nyni chtel rozclenit na jadro, interface, emulovany stroj a debugger. Myslim si, ze presnost, rychlost, ci proste pouzitelnost samotneho emulovaneho stroje je u mojeho emu dostatecna a chtel bych se zamerit predevsim na ty zbyvajici dily. Chtel bych je zrychlit, zmodularizovat a udelat je pokud mozno vice univerzalnimi. Tim bych se chtel zabyvat v tomto tematu.

Chci se pokusit udelat EMUlatorovy SYStem (EMUSYS), ktery bude:

a) schopen modularne emulovat libovolny pocitac, ktery je synchronizovan s pixelclk (v tuto chvili se zameruji predevsim na vsechny Sharpy s CPU Z80 :sharp:, protoze ty znam asi nejlepe)
V mem stavajicim emu existuje neco, cemu v tuto chvili rikam tabulka eventu - tedy ruzne HW udalosti, ktere maji vazbu na pohyb paprsku - pixelclk. Nektere eventy jsou pevne dany (napr. radkove / snimkove zatemneni), nektere vznikaji dynamicky (interrupt z CTC, zmena signalu z CMT, atd.).
Praci s temito eventy bych chtel zahrnout do kategorie "jadro", protoze pokud budu chtit misto soucasneho MZ-800 emulovat napr. MZ-1500, tak prvni co musim zmenit je prave tato tabulka eventu (pak uz zbyva jen prace s pametmi, generovani framebufferu a jsme skoro tam :)

b) interface (video, audio, keyboard, joy) by mel byt rovnez modularni a do budoucna lehce zamenitelny s cimkoliv jinym, nez je stavajici libSDL, nicmene popravde z toho vseho co jsem doposud vyzkousel mi SDL prislo nejlepe fungujici, ale treba do budoucna... Alespon nejaka abstraktnejsi vrstva se urcite hodi.

c) debugger ... Pokud chci mit schopnost podporovat emulaci vice typu ruznych pocitacu a mozna i platforem, tak samozrejme nezbyva nic jineho, nez byt modularni i zde... Ale ja chci jit jeste dal :) Chtel bych, aby debugger nebyl nezbytnou soucasti jednoho konkretniho emulatoru. Chci, aby mi bezel jako samostatny proces, ktery se propoji s ... hmmm ... "cimkoliv" :) ... Tedy nejen s nejakym mym emulatorem na PC, ale napr. emu spustim na RasPI a debugger k nemu attachnu po siti z PC. Pripadne emulator muze byt VHDL model a PC debugger se s nim propoji nejakym standardizovanym com-linkem.

To je prozatimni nastrel toho, cim bych se chtel v nasledujicich mesicich. resp. mozna i letech bavit. Pokud vas to nejakym zpusobem zaujalo, nebo mate k tomu co rici, tak piste!

Michal


Nahoru
 Profil  
 
 Předmět příspěvku: Re: EmuSys
PříspěvekNapsal: 31.01.2019, 22:36 
Offline
Kecálek

Registrován: 10.10.2014, 10:40
Příspěvky: 85
Has thanked: 2 times
Been thanked: 44 times
Samozrejme s nejakymi experimenty, s tvorbou jakesi abstraktni vrstvy a s honbou za vykonem uz jsem zacal :)

V tuto chvili ladim prvni nastrel toho, jak by mohlo probihat rendrovani obrazoveho framebufferu. (Tech operaci s framebufferem je v emulaci samozrejme vic, ale ja jsem se ted zameril na to, co je nejvetsim zroutem strojoveho casu - tedy na picture rendering.)

Ve stavajicim emu prozatim pouzivam multitasking jen velmi sporadicky a to pouze na par drobnosti. Takze blokove se da rici, ze mi v jednom vlaknu bezi emulovany stroj s internim debuggerem, pak nastane event pro vygenerovani audio samplu, pak je event na vyrendrovani framebufferu, pak nejaka obsluha UI ... tohle vse bezi seriove a v ramci jednoho snimku se mi to musi vejit do 20ms ... vetsinou vejde. Nicmene kdyz najdeme zpusob jak to zrychlit, tak ziskany cas se jiste vzdy hodi.

Napsal jsem tedy zakladni abstraktni vrstvu iface_framebuffer a take jednoduchy procesor, ktery mi kresli kosticky na obrazovku. Pro zjednoduseni pocitam s tim, ze by kazda zmena screenu byla tak rozsahla, ze je potreba vzdy aktualizovat celou obrazovku.

No a napsal jsem 4 ruzne metody renderingu:

1) seriovy - ten uz jsem popsal vyse
2) thread - pro tvorbu kazdeho snimku se vytvori novy thread
3) daemon - na zacatku nastartujeme samostatny thread se kterym komunikujeme pomoci signalu a sdilene pameti
4) nic :) pro ucely mereni chci vedet jak to vypada, kdyz se zadny fb rendering nedela

Zde jsou vysledky (spusteno na Linuxu bezicim ve vmware pod Win7 - i5 3.4 GHz, nVIDIA GTX 970 ) - na nevirtualizovanem HW by to behalo samozrejme podstatne lepe:
(uvedene vysledky jsou v mikrosekundach, prg je cas straveny kreslenim ctverecku a render je cas straveny zavolanim fb renderu dle vyse popsane metody. avg - je aritmeticky prumer, med - je median, testovaci program se snazi synchronizovat tak, aby byl vygenerovan kazdych 20ms novy snimek)
Je zajimave sledovat to, jak se multitasking projevil na zpomaleni casti prg, nicmene i tak je v tom rozdeleni cinnosti videt zisk.

*** Program started! ***
INFO: count CPUs found: 4
INFO: Linked SDL ver.: 2.0.9
LOG: initializing audio driver 'pulseaudio': OK
LOG: audio device format: 16, freq: 48000, ch: 2, pic. samples: 960
INFO: iface - set fb render type: serial

*** Start rendering tests ***
Test: 0
INFO: iface - set fb render type: serial
avg prg: 679,00, avg render: 2746,00
min prg: 426, min render: 1179
max prg: 2584, max render: 15661
med prg: 630, med render: 2489
Test: 1
INFO: iface - set fb render type: thread
avg prg: 795,00, avg render: 168,00
min prg: 462, min render: 23
max prg: 8256, max render: 3277
med prg: 684, med render: 120
Test: 2
INFO: iface - set fb render type: daemonised
avg prg: 778,00, avg render: 102,00
min prg: 425, min render: 2
max prg: 5496, max render: 4795
med prg: 671, med render: 41
Test: 3
INFO: iface - set fb render type: none
avg prg: 711,00, avg render: 0,00
min prg: 462, min render: 0
max prg: 2974, max render: 1
med prg: 641, med render: 0
Exiting SDL...


Nahoru
 Profil  
 
 Předmět příspěvku: Re: EmuSys
PříspěvekNapsal: 01.02.2019, 11:38 
Offline
Kecálek

Registrován: 28.10.2016, 21:03
Příspěvky: 120
Has thanked: 13 times
Been thanked: 50 times
Mě vývoj tohoto emulátoru rozhodně zaujal, emulace je velmi věrná, když chce člověk provádět nějaké experimenty.

Zeptal bych se na jednu věc - využití cpu. Jsem zatím stále u verze 1.0.3, na Win 10, a nejde o to, že by emulátor nestíhal. Ale kdykoli běží, tak jedno jádro cpu je vždy využité na 100 %.

Můj nejoblíbenější emulátor je STMZ800WINv13, ten můžu nechat běžet celý den, a využití cpu je minimální. Takže to neomezuje jiné programy na systému a cpu se klidně podtaktuje.

Je toto už nějak řešeno v dalších verzích? Případně bude v plánu nějaké nastavení, kterým zapnu úsporný mód? Že by třeba hlavní smyčka neběžela pro každý frame, ale řekněme jednou za 400 ms, pak by se najednou odsimulovaly všechny eventy za tu dobu, přehrál zvuk, vykreslil jeden frame, a usnulo na dalších 400 ms. Samozřejmě by se tam projevila prodleva, tj. zvuk by se přehrával se zpožděním těch 400 ms, a reakce na klávesnici by byla se zpožděním.
Takový jako pohotovostní mód, nebo pro přehrávání hudby na pozadí, a podobně.

Rozhodně nechci vnucovat směr vývoje emulátoru, je to spíš jen takový dotaz.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: EmuSys
PříspěvekNapsal: 01.02.2019, 12:49 
Offline
Kecálek

Registrován: 10.10.2014, 10:40
Příspěvky: 85
Has thanked: 2 times
Been thanked: 44 times
lukz píše:
Zeptal bych se na jednu věc - využití cpu. Jsem zatím stále u verze 1.0.3, na Win 10, a nejde o to, že by emulátor nestíhal. Ale kdykoli běží, tak jedno jádro cpu je vždy využité na 100 %.


To je zvlastni. Zkusil jsem si ted ve Win7 spustit Flappy ve verzi 1.0.3 a v 1.0.4 a sledoval jsem graf CPU (4 jadra). Je na nem znat, ze tam "neco" bezi, nicmene zadne jadro mi mi ani ve spickach neslo nad 50 %. Podle toho grafu je tezke soudit, ktera verze to zatezovala vic ... Ta nova by na tom rozhodne mela byt o neco lepe.

Nemluvis nahodou o provozu se zapnutym debuggerem?
Neni to treba nejaky notebook? Tam ty graficke karty byvaji dost slabe a nekdy se to renderuje pres CPU.
Predpokladam, ze po Alt+p ti ta 100% zatez spadne dolu.

Verze mz800emu 1.0.4 obsahuje spoustu vylepseni a jsou tam samozrejme i nejake vykonove optimalizace - doporucuju stahnout si posledni snapshot. Je tam u nej i Changelog_CZ https://www.ordoz.com/mz800emu/snapshot/

lukz píše:
by třeba hlavní smyčka neběžela pro každý frame, ale řekněme jednou za 400 ms, pak by se najednou odsimulovaly všechny eventy za tu dobu, přehrál zvuk, vykreslil jeden frame, a usnulo na dalších 400 ms. Samozřejmě by se tam


400 ms to uz je opravdu hodne - to by bylo nepouzitelne ... Ono i 100 ms uz je docela neprijemne. Kdysi na zacatku jsem experimentoval s tim, ze jsem vynechaval nektere snimky, tak jako to dela ve svem emulatoru napr. Zdenek Adler, nicmene vykonovy prinos, ktery to melo mi prisel tak zanedbatelny, ze jsem nakonec tuto moznost do emulatoru vubec neimplementoval. Je vsak pravdou, ze i kdyz jsem vynechal nejaky snimek, tak jsem vynechal pouze jeho renderig, ale framebuffer jsem vzdy poctive kreslil - to je z toho duvodu, ze mnohe obrazove efekty ve screenu vznikaji v zavislosti na tom kde se prave nachazi paprsek obrazovky, takze kdybych ve snimku, ktery nechci vyrendrovat zamerne nevyrabel obsah framebufferu a ty by jsi zrovna vyvolal pauzu, tak bych uz jen podle obsahu VRAM zrejme nedokazal sestavit obraz, ktery by v danou chvili odpovidal skutecnosti.

Kazdopadne jednim z cilu toho nove planovaneho emulatoru je samozrejme i vytezeni maximalniho mozneho vykonu, tedy je tva pripominka na miste...


Nahoru
 Profil  
 
 Předmět příspěvku: Re: EmuSys
PříspěvekNapsal: 01.02.2019, 13:45 
Offline
Kecálek

Registrován: 10.10.2014, 10:40
Příspěvky: 85
Has thanked: 2 times
Been thanked: 44 times
Tak jsem se konecne dostal k tomu, ze jsem testovaci program nakompiloval pro Win32 a spustil na nativnim HW ve Windows 7. Vykonovy rozdil mezi seriovou variantou a variantou s vyuzitim multitaskingu je doslova propastny :)

*** Start rendering tests ***
Test: 0
INFO: avg prg: 13,00, avg render: 1100,00
min prg: 0, min render: 1000
max prg: 2000, max render: 9001
med prg: 0, med render: 1000
Test: 1
INFO: avg prg: 0,00, avg render: 3,00
min prg: 0, min render: 0
max prg: 0, max render: 1000
med prg: 0, med render: 0
Test: 2
INFO: avg prg: 0,00, avg render: 0,00
min prg: 0, min render: 0
max prg: 0, max render: 0
med prg: 0, med render: 0
Test: 3
INFO: avg prg: 3,00, avg render: 0,00
min prg: 0, min render: 0
max prg: 1001, max render: 0
med prg: 0, med render: 0


Nahoru
 Profil  
 
 Předmět příspěvku: Re: EmuSys
PříspěvekNapsal: 01.02.2019, 14:51 
Offline
Kecálek

Registrován: 28.10.2016, 21:03
Příspěvky: 120
Has thanked: 13 times
Been thanked: 50 times
chaky píše:
tam "neco" bezi, nicmene zadne jadro mi mi ani ve spickach neslo nad 50 %

Já jsem to napsal nepřesně. Když program běží, tak celkové zatížení cpu je 25 %, což na mém systému znamená maximální zatížení jednovláknovou aplikací. V grafu jader cpu to tak samozřejmě vidět není, protože ten samý proces se neustále stěhuje mezi jednotlivými jádry.
Je to jako kdyby program měl neustále co na práci, a nikdy neusnul. Většina her takto funguje, protože jejich hlavní smyčka běží neustále.

chaky píše:
Predpokladam, ze po Alt+p ti ta 100% zatez spadne dolu.

Ne, po Alt+p se v nadpisu okna objeví Paused, ale využití cpu je úplně stejné.

Tak jestli u vás to nedělá, možná je nějaký problém v konfiguraci mého systému, a ne přímo v programu. A jestli to nikomu dalšímu nedělá, asi není potřeba se tím zabývat.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: EmuSys
PříspěvekNapsal: 01.02.2019, 16:08 
Offline
Kecálek

Registrován: 10.10.2014, 10:40
Příspěvky: 85
Has thanked: 2 times
Been thanked: 44 times
Aha! Opravdu, uz to taky vidim! Kdyz je emulator v pauze, tak uplne nesmyslne zere max. vykon CPU a je to samozrejme bug.
V pauze je zatez vetsi, nez pri normalnim behu programu :)

Opravil jsem to: dal jsem tam 20ms sleep. Nebudu kvuli takove drobnosti vydavat novy snapshot, takze jsem jen prihral opraveny exe do adresare s poslednim snapshotem https://www.ordoz.com/mz800emu/snapshot ... 24_rev194/


Nahoru
 Profil  
 
 Předmět příspěvku: Re: EmuSys
PříspěvekNapsal: 01.02.2019, 16:35 
Offline
Kecálek

Registrován: 28.10.2016, 21:03
Příspěvky: 120
Has thanked: 13 times
Been thanked: 50 times
Nová verze výborně funguje. Dobrá práce. :-)


Nahoru
 Profil  
 
 Předmět příspěvku: Re: EmuSys
PříspěvekNapsal: 01.02.2019, 17:35 
Offline
Site Admin
Uživatelský avatar

Registrován: 11.05.2013, 23:48
Příspěvky: 9358
Bydliště: Praha
Has thanked: 1680 times
Been thanked: 1303 times
Proč mi to na 64bit 8.1 hází, že nemám libcairo-2.dll? Hádám, že by se to mělo samo kouknout do /runtime/gtk-3/, ne? Moc se mi je nechce kopírovat do system32...

_________________
Amiga/Amstrad/Atari/Commodore/Mac/Nintendo/PS/PC/Sega/Tandy/ZX


Nahoru
 Profil  
 
 Předmět příspěvku: Re: EmuSys
PříspěvekNapsal: 01.02.2019, 18:45 
Offline
Prvnička

Registrován: 12.12.2016, 23:40
Příspěvky: 13
Has thanked: 0 time
Been thanked: 4 times
Ahoj

Logicky, mě se tvá snaha líbí a pochopitelně nejvíc mě zajímá ten remote debug :-)

J.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: EmuSys
PříspěvekNapsal: 01.02.2019, 20:45 
Offline
Kecálek

Registrován: 10.10.2014, 10:40
Příspěvky: 85
Has thanked: 2 times
Been thanked: 44 times
misticjoe píše:
Proč mi to na 64bit 8.1 hází, že nemám libcairo-2.dll? Hádám, že by se to mělo samo kouknout do /runtime/gtk-3/, ne? Moc se mi je nechce kopírovat do system32...


Koukne se to do toho runtime jen tehdy, kdyz to spoustis pres ten .bat co je v archivu.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: EmuSys
PříspěvekNapsal: 01.02.2019, 22:25 
Offline
Kecálek

Registrován: 10.10.2014, 10:40
Příspěvky: 85
Has thanked: 2 times
Been thanked: 44 times
ladmanj píše:
Ahoj
Logicky, mě se tvá snaha líbí a pochopitelně nejvíc mě zajímá ten remote debug :-)
J.


Jsem trochu doufal, ze jej treba napises ty, pro ten svuj VHDL pocitac a ja si jen prihreju polivecku ;)


Nahoru
 Profil  
 
 Předmět příspěvku: Re: EmuSys
PříspěvekNapsal: 01.02.2019, 22:50 
Offline
Pan Štábní
Uživatelský avatar

Registrován: 09.10.2013, 19:04
Příspěvky: 1184
Has thanked: 120 times
Been thanked: 50 times
lukz píše:
Mě vývoj tohoto emulátoru rozhodně zaujal, emulace je velmi věrná, když chce člověk provádět nějaké experimenty.

Zeptal bych se na jednu věc - využití cpu. Jsem zatím stále u verze 1.0.3, na Win 10, a nejde o to, že by emulátor nestíhal. Ale kdykoli běží, tak jedno jádro cpu je vždy využité na 100 %.

Můj nejoblíbenější emulátor je STMZ800WINv13, ten můžu nechat běžet celý den, a využití cpu je minimální. Takže to neomezuje jiné programy na systému a cpu se klidně podtaktuje.

Je toto už nějak řešeno v dalších verzích? Případně bude v plánu nějaké nastavení, kterým zapnu úsporný mód? Že by třeba hlavní smyčka neběžela pro každý frame, ale řekněme jednou za 400 ms, pak by se najednou odsimulovaly všechny eventy za tu dobu, přehrál zvuk, vykreslil jeden frame, a usnulo na dalších 400 ms. Samozřejmě by se tam projevila prodleva, tj. zvuk by se přehrával se zpožděním těch 400 ms, a reakce na klávesnici by byla se zpožděním.
Takový jako pohotovostní mód, nebo pro přehrávání hudby na pozadí, a podobně.

Rozhodně nechci vnucovat směr vývoje emulátoru, je to spíš jen takový dotaz.

Info hlavne pre chakyho. Keď som robil môj emulátor, tak som tiež mal jedno jadro naplno. Potom som dal medzi testovanie času po vykreslení snímky príkaz Sleep(1). Až potom som testoval čas. Využitie jadra rapídne kleslo. Zjavne to uvoľní aj procesor, čo ma vtedy prekvapilo. Jedná sa o príkaz z Free Pascalu / Delphi na pozastavenie činnosti na jednu milisekundu. Neviem aký je ekvivalentný príkaz s rovnakou funkčnosťou (s uvoľnením jadra) v C. Nie som tak zbehlý v C. Ale možno môj komentár pomôže. Samozrejme pri max. rýchlosti CPU treba tento príkaz vynechať, lebo by zbytočne brzdil.

Doplnené: Opäť boli ruky rýchlejšie ako oči. Mal som si to prečítať komplet aj s ďalšou diskusiou.

_________________
Sharp MZ-821
Milsa MZ-841


Nahoru
 Profil  
 
 Předmět příspěvku: Re: EmuSys
PříspěvekNapsal: 02.02.2019, 08:26 
Offline
Kecálek

Registrován: 07.05.2014, 12:10
Příspěvky: 188
Bydliště: Jbc
Has thanked: 0 time
Been thanked: 35 times
Kdyz jsem psal realne simulatory na PC, tak jsem porovnaval cas potrebny na realnem stroji s poctem strojovych cyklu, a podle toho jsem volal funkci sleep - tedy vzdy na tak dlouho, aby se proces zpomalil na rychlost realneho stroje.


Nahoru
 Profil  
 
 Předmět příspěvku: Re: EmuSys
PříspěvekNapsal: 02.02.2019, 08:49 
Offline
Prvnička

Registrován: 12.12.2016, 23:40
Příspěvky: 13
Has thanked: 0 time
Been thanked: 4 times
chaky píše:
ladmanj píše:
Ahoj
Logicky, mě se tvá snaha líbí a pochopitelně nejvíc mě zajímá ten remote debug :-)
J.


Jsem trochu doufal, ze jej treba napises ty, pro ten svuj VHDL pocitac a ja si jen prihreju polivecku ;)


No část určitě, ale celý to nedám. Já jsem hardwarář, mě to složitější programování tak moc dobře nejde. Den přemýšlím kterou ze tří cest se vydat a mezitím totéž někdo jiný má za půl hodiny hotové. Ale když zafixujeme nějaké rozhraní, tak se můžu o svoji část začít starat.


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ů: 32 ]  Přejít na stránku 1, 2, 3  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:  
Založeno na phpBB® Forum Software © phpBB Group
Český překlad – phpBB.cz