Celé vlákno · 8 zpráv

Ahoj

Tonoucí se stébla chytá.

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.

Co potřebuju?

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.

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.

Díky

Jakub

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.

Zdravim,

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.
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.
Zkousel jsem neco podobneho zprovoznit na Z180, ale tam jsem zatim nebyl 
uplne uspesny, hlavne kvuli slozitemu hlidani strankovani.

Hynek

Dne 8.1.2019 v 18:01 Jakub Ladman napsal(a):

> Ahoj
>
> Tonoucí se stébla chytá.
>
> 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.
>
> Co potřebuju?
>
> 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.
>
> 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.
>
> Díky
>
> Jakub
>
> 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.

Tak tedy opět do konference, nevím jak moc vám to vadí, kdyžtak mě někdo 
okřikněte.

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.

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.

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.

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.

Potřebuju nápad, který se zakládá na nějaké pozitivní zkušenosti.

Díky

Jakub

Dne 08. 01. 19 v 18:51 Hynek Sladký napsal(a):

> Zdravim,
>
> 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.
> 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.
> Zkousel jsem neco podobneho zprovoznit na Z180, ale tam jsem zatim 
> nebyl uplne uspesny, hlavne kvuli slozitemu hlidani strankovani.
>
> Hynek
>
> Dne 8.1.2019 v 18:01 Jakub Ladman napsal(a):
>> Ahoj
>>
>> Tonoucí se stébla chytá.
>>
>> 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.
>>
>> Co potřebuju?
>>
>> 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.
>>
>> 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.
>>
>> Díky
>>
>> Jakub
>>
>> 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.
>
> _______________________________________________
> SharpMZ mailing list
> SharpMZmail.ordoz.com
> http://mail.ordoz.com/mailman/listinfo/sharpmz

Ahoj Jakube,

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

Temat je v jednom mailu hned nekolik, tak se je pokusim udrzet:

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.

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

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.

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.

Potrebujeme vytvorit FPGA modul HW debuggeru, ktery bude mit nekolik funkci:

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

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

- posledni moduly slouzi k precteni Z80 registru a bloku pameti (lze to rozsirit i o zapis, ale to muze byt uz trochu komplikovanejsi)

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 :)

Michal

Tak tedy opět do konference, nevím jak moc vám to vadí, kdyžtak mě někdo okřikněte.

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.

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.

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.

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.

Potřebuju nápad, který se zakládá na nějaké pozitivní zkušenosti.

Díky

Jakub

Dne 08. 01. 19 v 18:51 Hynek Sladký napsal(a):

Zdravim,

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.
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.
Zkousel jsem neco podobneho zprovoznit na Z180, ale tam jsem zatim nebyl uplne uspesny, hlavne kvuli slozitemu hlidani strankovani.

Hynek

Dne 8.1.2019 v 18:01 Jakub Ladman napsal(a):

Ahoj

Tonoucí se stébla chytá.

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.

Co potřebuju?

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.

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.

Díky

Jakub

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.

_______________________________________________
SharpMZ mailing list
SharpMZmail.ordoz.com
http://mail.ordoz.com/mailman/listinfo/sharpmz

_______________________________________________
SharpMZ mailing list
SharpMZmail.ordoz.com
http://mail.ordoz.com/mailman/listinfo/sharpmz

Ja jsem takhle komunikoval tusim s Nexys2, ci s AvNet-kou a tam je krom JTAGu jeste PSoC ze ktereho leze do PC USB a tim slo nejen to FPGA naprgat, ale uz to samo o sobe umelo i nejakou formu komunikace s FPGA.

Mozna bude lepsi - pokud mas volne FPGA piny, tak si na to vyclenit extra ftdi a mluvit s tim HW debuggerem jako s RS232.

Jinak ten komunikacni protokol se ti bude docela rychle rozrustat o dalsi a dalsi prikazy, tak s tim je dobre pocitat uz v zacatku. Zatim by to mohlo umet napr.:

Zakladni prikazy:

GETSTS ... debugger by mel rict co se prave deje [running, paused, pripadne bussy]
RESET
STOP
RUN
STEP
SET/RESET <BPT_ID> <ADDR> ... asi se ti hodi mit tam pamet na vice adresnich breakpointu

Po zastaveni:

GET_ACTIVE_BPT ... aby jsi vedel ktera udalost ti to zastavila
Z80_GET_REGS
MEM_GET_SEG <ADDR> <SIZE> ... precteni segmentu pameti

Casem te samozrejme bude zajimat i stav jinych zarizeni. Stav zdroju pro Z80 interrupt, atp...

Aby jsi to mel komunikacne otevrene pro dalsi blbnuti, tak ten (treba RS232) komunikacni driver muzes rozdelit na kanaly a v komunikaci pak kanalem budes rikat, zda chces prave komunikovat s debuggerem, nebo s nejakym jinym zarizenim... Tohle meli prave docela pekne vymyslene prave na tom Nexysu.

Michal

Ahoj Michale

Díky ta odpověď

Z80 je ve fpga. Volného místa je tak odhadem na ještě jednu z80, čili docela dost.

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

 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. 

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

J.

Ahoj Jakube, tak co? povedlo se ti uz udelat nejaky integrovany FPGA debugger? Ja jsem hledal nejake povidani o tom komunikacnim protokolu co meli na tom Nexys2 - na webu uz jsem nasel prd. U mne na disku jsou jakesi pdf a zdrojaky, nicmene to maji hodne vezane na ten PSoC a taky to zere spoustu FPGA pinu a cert vi, zda jsou ty knihovny vubec open source - s nejvetsi pravdepodobnosti asi ne.... Nicmene ty pdf + nejake headery k tem knihovnam by mozna pro inspiraci neby marne ... Pro tebe ale bude asi lepsi komunikovat seriove a veskerou logiku vyrobit primo na FPGA.

Michal