<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <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 class="moz-cite-prefix">Dne 8.1.2019 v 22:13 Jakub Ladman
      napsal(a):<br>
    </div>
    <blockquote type="cite"
      cite="mid:85a91d09-a018-4b88-d6f8-7dffde061ce7@volny.cz">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 type="cite">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 type="cite">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 class="moz-txt-link-abbreviated" href="mailto:SharpMZ@mail.ordoz.com">SharpMZ@mail.ordoz.com</a>
        <br>
        <a class="moz-txt-link-freetext" href="http://mail.ordoz.com/mailman/listinfo/sharpmz">http://mail.ordoz.com/mailman/listinfo/sharpmz</a>
        <br>
      </blockquote>
      _______________________________________________
      <br>
      SharpMZ mailing list
      <br>
      <a class="moz-txt-link-abbreviated" href="mailto:SharpMZ@mail.ordoz.com">SharpMZ@mail.ordoz.com</a>
      <br>
      <a class="moz-txt-link-freetext" href="http://mail.ordoz.com/mailman/listinfo/sharpmz">http://mail.ordoz.com/mailman/listinfo/sharpmz</a>
      <br>
    </blockquote>
  </body>
</html>