OldComp.cz
http://oldcomp.cz/

EmuSys
http://oldcomp.cz/viewtopic.php?f=81&t=7151		 Stránka 2 z 3
Autor:  Milsa [ 02.02.2019, 10:08 ]
Předmět příspěvku:  Re: EmuSys
Priznám sa, že neviem ako to robia ostatní, nepozeral som ani do zdrojákov. Ja som si ako hlavný časový interval vybral vykreslenie obrazovky a potom spomaľujem emuláciu do doby, kedy má začať nová obrazovka. Performance timer zatiaľ neviem používať.
Autor:  Panda38 [ 02.02.2019, 10:53 ]
Předmět příspěvku:  Re: EmuSys
Milsa píše:
...Sleep(1). Až potom som testoval čas. Využitie jadra rapídne kleslo. Zjavne to uvoľní aj procesor, čo ma vtedy prekvapilo...
Lze použít i Sleep(0) - nečeká, ale zajistí předání procesoru v multitasku když je potřeba. U Sleep je malý problém, že nebývá přesné a bývá časované granularitou systému, která bývá asi tak 15ms. Systém při Sleep(1) nečeká přesně 1 ms, ale občas čeká 15 ms a občas nečeká vůbec, tak aby zprůměrovaně to udělalo 1 ms. Granularita se dá řídit nastavením multimediálního časovače pro daný proces, aby časoval s přesností příp. až na 1 ms, ale musí se to systému říct, nedělá to automaticky.
Autor:  faraon [ 02.02.2019, 11:28 ]
Předmět příspěvku:  Re: EmuSys
Drobná poznámka ze světa velkých ptáků: https://linux.die.net/man/3/sleep

Citace:
Name
sleep - sleep for the specified number of seconds

Synopsis
Kód:
#include <unistd.h>
unsigned int sleep(unsigned int seconds);
Autor:  Milsa [ 02.02.2019, 14:59 ]
Předmět příspěvku:  Re: EmuSys
Panda38 píše:
Milsa píše:
...Sleep(1). Až potom som testoval čas. Využitie jadra rapídne kleslo. Zjavne to uvoľní aj procesor, čo ma vtedy prekvapilo...
Lze použít i Sleep(0) - nečeká, ale zajistí předání procesoru v multitasku když je potřeba. U Sleep je malý problém, že nebývá přesné a bývá časované granularitou systému, která bývá asi tak 15ms. Systém při Sleep(1) nečeká přesně 1 ms, ale občas čeká 15 ms a občas nečeká vůbec, tak aby zprůměrovaně to udělalo 1 ms. Granularita se dá řídit nastavením multimediálního časovače pro daný proces, aby časoval s přesností příp. až na 1 ms, ale musí se to systému říct, nedělá to automaticky.

Áno, všimol som si, že to časovanie nebolo veľmi presné, ale uľavilo to procesoru, tak som to tam nechal. Keďže 100 % rýchlosť si mohla dovoliť pozastavenie, tak to nevadilo.

Síce odbočujem trochu od pôvodnej témy, ale táto téma mi dala inšpiráciu, ako zrýchliť môj emulátor. Mám OpenGL verziu, ktorá bola mierne pomalšia ako klasická, ale dokáže zoomovať v reálnom čase. Skúsim OpenGL zobrazenie napratať do druhého vlákna.

Doplnené: Možno synchronizácia vlákien spomalí emuláciu ešte viac, ale som zvedavý, čo z toho vznikne.
Autor:  chaky [ 02.02.2019, 15:12 ]
Předmět příspěvku:  Re: EmuSys
Jo, az se mi podari nejak smysluplneji presestavit pevne a rychle jadro, tak zacnu premyslet na tom debugovacim protokolu ... Nejakeho VHDL Sharpa tu mam na Nexysu, takze to na nem budu zkouset ...

ladmanj píše:
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.
Autor:  chaky [ 02.02.2019, 15:20 ]
Předmět příspěvku:  Re: EmuSys
Popuzivam glib, coz je velice pekne vybavena multiplatformni knihovna. Pokud chci, aby nejaky thread predal zezlo nekomu dalsimu, tak je nejlepsi pouzit g_thread_yield () ... https://developer.gnome.org/glib/2.58/g ... read-yield
Nicmene jsem to jeste nikdy nepotreboval.
Pri komunikaci procesu je dobre pouzivat cond - tedy semafory, kterymi se rika, ze nejaky prostredek je uz volny a nebo to, ze jsem do threadu poslal novy prikaz... Cekani na cond zabira minimum strojoveho casu a ma trochu jiny smysl, nez sleep-ovani.

Panda38 píše:
Milsa píše:
...Sleep(1). Až potom som testoval čas. Využitie jadra rapídne kleslo. Zjavne to uvoľní aj procesor, čo ma vtedy prekvapilo...
Lze použít i Sleep(0) - nečeká, ale zajistí předání procesoru v multitasku když je potřeba. U Sleep je malý problém, že nebývá přesné a bývá časované granularitou systému, která bývá asi tak 15ms. Systém při Sleep(1) nečeká přesně 1 ms, ale občas čeká 15 ms a občas nečeká vůbec, tak aby zprůměrovaně to udělalo 1 ms. Granularita se dá řídit nastavením multimediálního časovače pro daný proces, aby časoval s přesností příp. až na 1 ms, ale musí se to systému říct, nedělá to automaticky.
Autor:  chaky [ 02.02.2019, 15:23 ]
Předmět příspěvku:  Re: EmuSys
Jinak moje experimenty s rendrovanim v mutithreadove aplikaci ponekud selhavaji. V Linuxove verzi je to super a vse se chova tak jak by clovek ocekaval, ale ve win32 verzi se program zasekne ve chvili, kdy se pokusim obsluhovat eventy jinde, nez v hlavnim threadu :( Pokusim se na to naspat nejaky zjednoduseny program a poptam se v konferenci libSDL.
Autor:  misticjoe [ 02.02.2019, 19:40 ]
Předmět příspěvku:  Re: EmuSys
Tak jsem emulátor pořádně otestoval na Hotelu u Zelené Sedmy, který fachá. Zexas taky běží, ale např. Flappy ani ZXEmu nenačtu. Emulace vytuhne :-(
Tak beru zpět. Mám asi z nějakého důvodu nakopnuté image kazet.
Autor:  ladmanj [ 02.02.2019, 23:09 ]
Předmět příspěvku:  Re: EmuSys
ladmanj píše:
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.


Našel jsem teď na disku klon tohohle: https://github.com/legumbre/z80-stub

Možná by se dalo odpíchnout od toho. Pamatuju si jen mlhavě, že jsem to nějak zkoušel zbuildit, ale ne že bych to někdy úspěšně použil. Buď to nějak nešlo (blokování sériové linky, což je jinak, v tuto chvíli, můj jediný způsob interakce s hw), nebo jsem na to zapomněl ještě než jsem to stihl vyzkoušet.
Autor:  chaky [ 02.02.2019, 23:23 ]
Předmět příspěvku:  Re: EmuSys
ladmanj píše:
Našel jsem teď na disku klon tohohle: https://github.com/legumbre/z80-stub

Možná by se dalo odpíchnout od toho. Pamatuju si jen mlhavě, že jsem to nějak zkoušel zbuildit, ale ne že bych to někdy úspěšně použil. Buď to nějak nešlo (blokování sériové linky, což je jinak, v tuto chvíli, můj jediný způsob interakce s hw), nebo jsem na to zapomněl ještě než jsem to stihl vyzkoušet.


Jo gdb + sdcc +z80 jsem se take kdysi marne pokousel rozchodit - libilo by semi, kdybych mohl pres gdb napichnout ceckove programy spustene v emu ... Ale ten projekt je asi mrtvy.
Autor:  hynek [ 06.02.2019, 09:14 ]
Předmět příspěvku:  Re: EmuSys
chaky píše:
Jo, az se mi podari nejak smysluplneji presestavit pevne a rychle jadro, tak zacnu premyslet na tom debugovacim protokolu ... Nejakeho VHDL Sharpa tu mam na Nexysu, takze to na nem budu zkouset ...

ladmanj píše:
chaky píše:
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.


Jednoduchy protokol pro rizeni jadra CPU by se mohl inspirovat u eZ80. Rozhrani je podobne I2C. Umoznuje cteni/zapis registru, cteni/zapis pameti, vykonani libovolne instrukce mimo poradi, spusteni/zastaveni behu, par breakpointu. Popis protokolu a moznosti je napr. v manualu PS0139 pro eZ80L92 v kapitole ZiLOG Debug Interface (http://www.zilog.com/docs/ez80/PS0130.pdf, str. 160)
Autor:  hynek [ 06.02.2019, 18:43 ]
Předmět příspěvku:  Re: EmuSys
chaky píše:
ladmanj píše:
Našel jsem teď na disku klon tohohle: https://github.com/legumbre/z80-stub

Možná by se dalo odpíchnout od toho. Pamatuju si jen mlhavě, že jsem to nějak zkoušel zbuildit, ale ne že bych to někdy úspěšně použil. Buď to nějak nešlo (blokování sériové linky, což je jinak, v tuto chvíli, můj jediný způsob interakce s hw), nebo jsem na to zapomněl ještě než jsem to stihl vyzkoušet.


Jo gdb + sdcc +z80 jsem se take kdysi marne pokousel rozchodit - libilo by semi, kdybych mohl pres gdb napichnout ceckove programy spustene v emu ... Ale ten projekt je asi mrtvy.


Jeste mam dotaz k tomuto tematu: podarilo se zde nekomu rozbehnout sdcdb na Z80? Kdyz se obcas vratim k Z180, hodilo by se mit tuto moznost funkcni...
Autor:  hynek [ 07.02.2019, 19:15 ]
Předmět příspěvku:  Re: EmuSys
hynek píše:
chaky píše:
ladmanj píše:
Našel jsem teď na disku klon tohohle: https://github.com/legumbre/z80-stub

Možná by se dalo odpíchnout od toho. Pamatuju si jen mlhavě, že jsem to nějak zkoušel zbuildit, ale ne že bych to někdy úspěšně použil. Buď to nějak nešlo (blokování sériové linky, což je jinak, v tuto chvíli, můj jediný způsob interakce s hw), nebo jsem na to zapomněl ještě než jsem to stihl vyzkoušet.


Jo gdb + sdcc +z80 jsem se take kdysi marne pokousel rozchodit - libilo by semi, kdybych mohl pres gdb napichnout ceckove programy spustene v emu ... Ale ten projekt je asi mrtvy.

Jeste mam dotaz k tomuto tematu: podarilo se zde nekomu rozbehnout sdcdb na Z80? Kdyz se obcas vratim k Z180, hodilo by se mit tuto moznost funkcni...

Pokusim se odpovedet si sam: o sdcdb jsem toho moc nenasel. Ale zrejme je pouzitelny jen ve spojeni s ucsim. Nenasel jsem zadny parametr ani priklad, jak by se to dalo pouzit s realnym HW.
Nicmene existuje port GDB pro Z80: https://github.com/legumbre/gdb-z80, ktery by mel umet pripojeni treba i pres seriovou linku k realnemu HW. Je to projekt od stejneho autora jako zminovany z80-stub.
Take jsem nasel nejake poznamky zde a zde.
Je vice nez pravdepodobne, ze prace na rozchozeni GDB se skutecnym Z80 by bylo vic, nez kolik by to prineslo uzitku ;) Nehlede na velikost obsazene pameti timto kodem a tedy tim mensi pamet pro vlastni aplikaci...
Autor:  ladmanj [ 14.02.2019, 21:30 ]
Předmět příspěvku:  Re: EmuSys
chaky píše:
ladmanj píše:
Našel jsem teď na disku klon tohohle: https://github.com/legumbre/z80-stub

Možná by se dalo odpíchnout od toho. Pamatuju si jen mlhavě, že jsem to nějak zkoušel zbuildit, ale ne že bych to někdy úspěšně použil. Buď to nějak nešlo (blokování sériové linky, což je jinak, v tuto chvíli, můj jediný způsob interakce s hw), nebo jsem na to zapomněl ještě než jsem to stihl vyzkoušet.


Jo gdb + sdcc +z80 jsem se take kdysi marne pokousel rozchodit - libilo by semi, kdybych mohl pres gdb napichnout ceckove programy spustene v emu ... Ale ten projekt je asi mrtvy.


Tak mě to momentálně částečně funguje.
Umí se to zastavit na breakpointu, uložit (a zobrazit) stav registrů, načíst paměť, gdb ukazuje disassembly, vlastně docela dobrý :like: .
Problém mám zatím s logikou přesunu breakpointu na další adresu, tam je nějaká chyba a já to zatím marně louskám, ale rozhodně to nevypadá beznadějně.

Je to teda čistě softwarová záležitost, zabírá to včetně mých debug bordelů přes 5 kilobajtů, ale když se to rozchodí, tak to podle mě půjde zopakovat i v hw, je to celkem jednoduchá stavová mašina a to co je na tom nejkomplikovanější, to vyčtení a zapsání stavu cpu bude v fpga naopak mnohem jednodušší.
Zrovna tak v emulátoru.

Jdu se podívat na fork co udělal ten kolík pro FUSE emulátor ZXS, třeba tam tuhle chybu má vychytanou ...
Autor:  ladmanj [ 15.02.2019, 21:08 ]
Předmět příspěvku:  Re: EmuSys
ladmanj píše:
Jdu se podívat na fork co udělal ten kolík pro FUSE emulátor ZXS, třeba tam tuhle chybu má vychytanou ...


Tak kolík tam toho moc neopravil, nicméně já jsem zase o kus dále a jsem schopen to po omezenou dobu udržet funkční.
Takže jsem schopen po resetu hw skočit do obsluhy breakpointu, lineárně krokovat po instrukcích a vyčítat při tom registry a paměť.

Co tam asi vůbec nikdy nebylo zprovozněné, je plácnutí breakpointu na konkrétní adresu.
Jakmile tedy přestanu krokovat po instrukcích, program mi ujede někam do ahoj a už ho nikdy nepřeruším.
Mohl bych na to použít tlačítko NMI, kdybych ho připojil, ale v mém hw běžím z předinicializované RAM a když mi ji program přepíše, tak nepomůže nejen NMI, ale ani RESET. musím desce odpojit napájení a po novém připojení se v rámci uploadu FPGA naplní ta RAM.

Vede mě to ale ke změně plánu,
a) láká mě debug C kódu, abych mohl ladit ten gdb-stub samotný - potřebuju nějak dostat symboly ze sdcc do gdb, nevím jak na to, ale nemůže to být nic neřešitelného. Kdyby někdo z přihlášených měl zájem přiložit ruku k dílu, tohle je momentálně docela dobře ohraničený úkol. Dovedu si představit nějakého pythonistu jak to za dva dny udělá. Podle čitelnosti dokumentace těch formátů.
b) začnu psát komunikační protokol do programovatelné logiky, zatím část popsanou níže, podle toho jak budu úspěšný se dá rozhodnout jak dál.

Pokud se tedy máme mezi sebou nějak synchronizovat, tak já navrhuju adoptovat tenhle "gdb target remote" formát a to bez ohledu na to, jestli nakonec gdb bude použitelné nebo ne. Ten komunikační protokol na gdb samotném žádnou závislost nebuduje.
Super je, že je navržen tak, že obě komunikující strany jednoduše ignorují pakety, kterým nerozumí, jen tuto skutečnost oznámí protistraně. Protistrana tak může postupovat od sofistikovanějších příkazů k jednodušším až najdou společnou sadu podporovaných funkcí.

Vítám k tomuto návrhu komentáře.

Kód:
 Remote communication protocol.

   A debug packet whose contents are <data>
   is encapsulated for transmission in the form:

        $ <data> # CSUM1 CSUM2

        <data> must be ASCII alphanumeric and cannot include characters
        '$' or '#'.  If <data> starts with two characters followed by
        ':', then the existing stubs interpret this as a sequence number.

        CSUM1 and CSUM2 are ascii hex representation of an 8-bit
        checksum of <data>, the most significant nibble is sent first.
        the hex digits 0-9,a-f are used.

   Receiver responds with:

        +       - if CSUM is correct and ready for next packet
        -       - if CSUM is incorrect

   <data> is as follows:
   All values are encoded in ascii hex digits.
Stránka 2 z 3 Všechny časy jsou v UTC + 1 hodina [ Letní čas ]
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/