OldComp.cz

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ť.

_________________
Sharp MZ-821
Milsa MZ-841

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.

Drobná poznámka ze světa velkých ptáků: https://linux.die.net/man/3/sleep

_________________
Rok 2020:
1. Nabootujeme M$ Linux.
2. Spustíme M$ Chromium.
3. Zaplatíme M$ poplatek.

Á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.

_________________
Sharp MZ-821
Milsa MZ-841

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 ...

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.

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.

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.

_________________
"...they never believe me. They don't even believe me about you... You believe me, don't you, Abigail?"
Call me Mr.Hellwide!

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.

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)

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...

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ý .
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 ...

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.