<div dir='auto'>Ahoj Michale<div dir="auto"><br></div><div dir="auto">Díky ta odpověď</div><div dir="auto"><br></div><div dir="auto">Z80 je ve fpga. Volného místa je tak odhadem na ještě jednu z80, čili docela dost.</div><div dir="auto"><br></div><div dir="auto">Čili začít bych měl nějakým rozhraním mezi pc a dedikovaným hw ve fpga. Pro zastavování a očuchávání stavu cpu.</div><div dir="auto"><br></div><div dir="auto"> Máte někdo představu co jsou minimální požadavky na takovou komunikaci? Něco mi říká, že by mohl stačit obousměrný přenos obsahu registrů a zastavování hodin. </div><div dir="auto"><br></div><div dir="auto">Zkusím se podívat na to, jestli se nějak uživatelsky na to dá použít jtag hardware, protože ten už do pc je propojený (přes ftdi).</div><div dir="auto"><br></div><div dir="auto">J.</div></div><div class="gmail_extra"><br><div class="gmail_quote">Dne 9. 1. 2019 10:27 dopoledne napsal uživatel Michal Hučík - ORDOZ <ordoz@ordoz.com>:<br type="attribution" /><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<p><font size="+1">Ahoj Jakube,</font></p>
<p><font size="+1">co se tyka OT tematu, tak mi osobne tady nevadi.
Nejen, ze v Sharpich tematech je zde uz pomerne zanedbatelny
provoz, ale i proto, ze se ta tva temata v mnohem stykaji s
ruznymi Sharp emulatory - jak PC, tak FPGA... O cp/m 3, ani
nemluve...<br />
</font></p>
<p>Temat je v jednom mailu hned nekolik, tak se je pokusim udrzet:</p>
<p>1) Znasilneni meho emu na to, aby emuloval nejaky jiny HW by
zrejme dalo docela dost prace - hlavne proto, ze se cely emulator
Sharpa podrizuje tomu, aby byl co nejvice synchronni s procesy,
ktere probihaji v GDG a v i8253 ... Kdybych videl trochu vic
alespon do blokoveho schematu Tveho pocitace, tak bych to mozna
dokazal posoudit presneji.</p>
<p>Trochu odskocim: co se tyka debuggeru, tak mam v planu jej nekdy
v budoucnu uplne oddelit od emulatoru tak, aby spolu mohli
komunikovat napr. pres TCP/IP, ci jakykoliv jiny system, ve kterem
by si emulator a debugger posilali zpravy pomoci packetu. Ale
tezko rict, jestli se k tomu dostanu vyhledove drive, nez za 5
let...<br />
</p>
<p>2) Co si pamatuju ze svych nekdejsich experimentu s FPGA, tak tam
je zpravidla nejaka moznost implementovat si do modelu ruzne sondy
a kolektory, nicmene to je asi dobre predevsim na trigrovani a na
zkoumani toho, zda funguje spravne ten namodelovany HW. Ja jsem
experimentoval s Xilinxem a mam pocit, ze ten analyzacni SW
neumoznoval oboustrannou komunikaci a ani zadnou lepsi vizualizaci
tech nasbiranych dat - proste jen zakladni logicky
analyzer/osciloskop.<br />
</p>
<p>3) Z popisu jsem nepochopil, zda mas ve sve aplikaci skutecny
Z80, nebo zda jej emulujes. Budu predpokladat, ze emulovany, coz
je ta jednodussi varianta. Ted budu psat mozna trochu naivne z
cesty, protoze nemam uplne jasnou predstavu o tom, jak tvuj HW
vypada, kolik mas volneho mista v FPGA, jake mas moznosti
komunikace s PC a co vsechno si dokazes na PC naprogramovat. Budu
spise popisovat jak bych si predstavoval HW debugger, ktery bych
implementoval do sveho nekdejsiho (dnes uz asi nespustitelneho)
FPGA emulatoru Sharpa.<br />
</p>
<p>Potrebujeme vytvorit FPGA modul HW debuggeru, ktery bude mit
nekolik funkci:<br />
</p>
<p>- prvni z nich je nejaka obousmerna komunikace s nasim PC
programem. Potrebujeme napr., aby PC dokazalo cekat na zpravu, ze
byl aplikovan breakpoint a aplikace ceka na dalsi prikaz z PC. PC
posle dotaz na stav registru, dotaz na obsah kusu pameti,
nastaveni dalsiho breakpointu, step, run, atp. <br />
</p>
<p>- nasleduje naimplementace synchronniho WAITu, kterym muzeme cele
zarizeni krokovat. Tento WAIT system by mel mit moznost napr.
online cist Z80.regPC a Z80.M1, aby se pres nej daly
naimplementovat breakpointy. Pripadne by mel mit pristup k dalsim
systemovym signalum, pokud by se podle nich melo breakpointovat.</p>
<p>- posledni moduly slouzi k precteni Z80 registru a bloku pameti
(lze to rozsirit i o zapis, ale to muze byt uz trochu
komplikovanejsi)<br />
</p>
<p>Ja vim, ze jsem vlastne nic svetoborneho neporadil, ale z toho co
pises jsem mel pocit, ze nevis odkud zacit, tak tohle zpusob, jak
bych se v tom asi zacal topit ja :)</p>
<p>Michal<br />
</p>
<br />
<div>Dne 8.1.2019 v 22:13 Jakub Ladman
napsal(a):<br />
</div>
<blockquote>Tak tedy
opět do konference, nevím jak moc vám to vadí, kdyžtak mě někdo
okřikněte.
<br />
<br />
Já si taky dovedu představit, že bych v pc kusem C kódu a
úložištěm v souboru emuloval svoje paměti S25FL116K a spi
kontrolér který je ve fpga, ale nevím jak to napojit na dobře
debugovatelný emulátor. Když bych po pár dnech nastudoval, jak to
připojit k YAZE-AG, který normálně používám na pc k buildění
systému pro svůj HW, tak tam by mi zase chyběla možnost kvalitního
viditelného krokování. Čili cca dva týdny bych jen připravoval
emulaci a použitelnost by pak byla s velkým otazníkem. Napojení na
emulátor typu toho od Michala Hučíka, kde je důstojné krokování se
zobrazením registrů a paměti v libovolném, nebo téměř libovolném
okamžiku by asi bylo výrazně užitečnější, ale o to méně tuším jak
bych tam tu emulaci hw dobastlil.
<br />
<br />
Teď debuguju tak, že používám Reveal Inserter/Analyzer, což je v
prostředí pro fpga firmy Lattice logický analyzátor vložený přímo
do fpga, kde mám tak akorát paměti pro nasbírání 4096 vzorků, kde
vzorek je jeden přístup do paměti, a přístup na io zabere dva až
tři vzorky. Vzorkování začne tím, že do kódu vložím zápis na
specifický port, který logický analyzátor vyhodnotí jako trigger.
<br />
<br />
Tím tak dokážu vyhodnotit, že moje rutiny pro přístup na hw docela
dobře fungují, ale co se pak děje uprostřed BDOSu je trasovatelné
jen obtížně a to přesto, že mám plné originální zdrojáky. Vypadá
to tak, že na jeden několika-milisekundový záznam analyzátoru,
několik hodin trasuju binární hexadecimální výpis co cpu čte a
zapisuje do ram a na io porty na zdrojáky v asm, přičemž obsah
registrů a flagů si jen domýšlím podle toho kam bylo řízení
programu předáno.
<br />
<br />
Kdybyste někdo měl nějakou vymyšlenou cestu, jak si třeba pomocí
RST38 zastavovat program a jeho dloooooouhý běh ukládat přes
sériovku někam k vyhodnocení, abych tam neměl 0.001% běhu od
resetu po zbloudění, ale celých 100%, to by třeba pomohlo, akorát
se to musí umět vyrovnat se stránkováním paměti (které mám ovšem
pod kontrolou, protože na registry hw, co fyzicky stránky přepíná
přistupuje jen můj kód a navíc můžu v hw udělat fígl, že si
instrukce RST38, nebo i jiná, sama přepne stránku a RET ji pak
přepne zpět), nebo něco takového.
<br />
<br />
Potřebuju nápad, který se zakládá na nějaké pozitivní zkušenosti.
<br />
<br />
Díky
<br />
<br />
Jakub
<br />
<br />
Dne 08. 01. 19 v 18:51 Hynek Sladký napsal(a):
<br />
<blockquote>Zdravim,
<br />
<br />
kdysi jsem si 'hral' s CP/M na eZ80 - nebyl to port CP/M, ale
prepsany system do C se souborovym systemem FAT na SD karte. Pro
ladeni jsem si napsal simulator na PC, jadro systemu jsem pouzil
stejne, souborovy system pak pristupoval na disk PC.
<br />
Pro cteni/zapis jsem tam mel pole 512B sektoru v RAM. Protoze
eZ80 i PC ma dostatek pameti, nebyl s tim zadny problem. Tato
pamet byla mimo beznou aplikacni pamet 64KB CP/M.
<br />
Zkousel jsem neco podobneho zprovoznit na Z180, ale tam jsem
zatim nebyl uplne uspesny, hlavne kvuli slozitemu hlidani
strankovani.
<br />
<br />
Hynek
<br />
<br />
Dne 8.1.2019 v 18:01 Jakub Ladman napsal(a):
<br />
<blockquote>Ahoj
<br />
<br />
Tonoucí se stébla chytá.
<br />
<br />
Již několik zim se vracím ke svému projektu - jedná se o port
CP/M 3 na můj vlastní hardware (s ničím nekompatibilní,
respektive kompatibilní s tím, co se mi zachce). HW je z větší
části v FPGA, takže když se mi něco zdá neelegantní řešit v
sw, modifikuji hw v programovatelném poli.
<br />
<br />
Co potřebuju?
<br />
<br />
Dobrovolníka, který mi nabídne, že když mu napíšu svoje stesky
co se mi zrovna nedaří (debug cp/m biosu na hw, nemožnost
debugu v emu, případně nalezení cesty k němu), že si je přečte
a zkusí se zamyslet, co bych měl dělat lépe nebo jinak. Možná
nejdůležitější bude to, že mě vyslechne a že budu muset někomu
popsat, kde jsem a tím si sám něco uvědomím.
<br />
<br />
Jediné co mohu nabídnout na oplátku je to že jsem totéž
schopen nabídnout někomu dalšímu. Taky uvažuji nad tím, že
bych potom začal zprovozňovat cp/m 3 a gsx taky na sharpu.
<br />
<br />
Díky
<br />
<br />
Jakub
<br />
<br />
PS: mám funkční verzi, která ovšem nešetrně zachází s flash
pamětí a při každém zápisu 128B bloku, smaže a přepíše 4KB,
čili, když systém zapisuje na disk (na té flash) 4KB dat v
souvislém bloku, tak se paměť smaže a přepíše 32x. Když jsem
to začal přepisovat tak jsem se dostal do stavu, kdy mi to bez
zjevné příčiny nenabootuje, zabloudí v kódu během bootu.
Potřebuju nápad jak na ten debug. Nechci se příliš rozepisovat
tady v konferenci.
<br />
</blockquote>
<br />
_______________________________________________
<br />
SharpMZ mailing list
<br />
<a href="mailto:SharpMZ@mail.ordoz.com">SharpMZ@mail.ordoz.com</a>
<br />
<a href="http://mail.ordoz.com/mailman/listinfo/sharpmz">http://mail.ordoz.com/mailman/listinfo/sharpmz</a>
<br />
</blockquote>
_______________________________________________
<br />
SharpMZ mailing list
<br />
<a href="mailto:SharpMZ@mail.ordoz.com">SharpMZ@mail.ordoz.com</a>
<br />
<a href="http://mail.ordoz.com/mailman/listinfo/sharpmz">http://mail.ordoz.com/mailman/listinfo/sharpmz</a>
<br />
</blockquote>
</div>
</blockquote></div><br></div>