<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix"><br>
      Ahoj Vasku,<br>
      <br>
      a) nejedna se o 0. stopu, ale o 1. stopu (diky invertovanym
      stranam)<br>
      <br>
      b) radici je uplne jedno jaky je format sektoru, prikaz znel
      jasne: READ SECTOR a nikdo uz do FDC nepredesilal zadny predpoklad
      o tom jak by mely byt ty data velka... Existuje jeste prikaz READ
      SECTOR(S) s platnosti do konce stopy, ale to nas nyni moc
      nezajima.<br>
      <br>
      Problem je tedy v rutine vykonavajici cteni.<br>
      <br>
      Po vyse zminenem prikazu si to radic chvili necha honit hlavou.
      Cteci program v tu chvili zurive stale dokola kontroluje status
      registr, dokud se mu v nem neobjevi flag DRQ - data request, to je
      pro cteci program signal, ze si ma vyzvednout bajt - coz udela
      zpravidla pres IN, nebo jeste lepe pres INI.<br>
      <br>
      Jakmile si program prevezme svuj vytouzeny datovy bajt, tak se
      opet vrhne na cyklicke nacitani status registru a z nej si
      testuje:<br>
      <br>
      1) je radic stale ve stavu BUSY? (resp. neskoncila ta uz operace
      cteni?)<br>
      <br>
      2) je DRQ? (nejake dalsi bajty by nebyly?)<br>
      <br>
      3) neni nahodou DATA_LOST? (treba pokud jsme se nekde zakecali a
      nestihli jsme si vcas prevzit vyse avizovany bajt)<br>
      <br>
      V pripade, ze nedoslo k zadne chybe, tak nam radic predal vsechno
      co mel v sektoru, ve statusu neni zadny ERROR a status hlasi OK...
      Idealni vesmir - v takovem by se ten tvuj vetsi sektor nacetl.<br>
      <br>
      Jedina neprijemnost, ktera by v tomhle idealnim vesmiru mohla
      nastat je to, ze by treba tech nadbytecnych 256 bajtu neco
      prepsalo.<br>
      <br>
      Protoze programator nikdy nemuze zcela duverovat HW, tak bud uz u
      toho IN, ci INI, nebo alespon po ukonceni celeho cteni se provede
      kontrola poctu prenesenych bajtu ... Pri tehle kontrole jde ovsem
      o to, ze jsme cekali 256 bajtu - ani vic, ani min. Nikoho tedy
      nijak vyznamne nepotesi, ze jich bylo nacteno dvojnasob - cteci
      program se tedy neodvratne vyda cestou k FDC ERROR!<br>
      <br>
      <br>
      A to se porad bavime jen o tom 1. sektoru ve kterem se neocekaval
      zadny opravdovy program - jen IPLPRO header s informaci o tom od
      ktereho alokacniho bloku se ma program nacist a kolik bajtu bude
      mit. Kdyby jsme teoreticky preskocili tu cast, kdy si Sharp ROM
      nacte IPLPRO header, tak:<br>
      <br>
      - ROM si spocita z cisla alokacniho bloku fyzicky sektor, stopu a
      stranu, odkud ma zacit cist zavadec: pocita natvrdo s tim, ze
      stopa ma 16 sektoru, mohlo by tedy dojit k tomu, ze ROM pozada
      radic o cteni neexistujiciho sektoru (tva disketa jich ma jen 9)<br>
      <br>
      - (ted si nejsem uplne jisti, zda tohle dela jen BASIC, nebo zda
      to dela i ROM): aby se data nacitala "rychleji", tak se pouziva
      vyse zminene sequencni cteni od pozadovaneho sektoru az do konce
      stopy a az tam, kde se cteci rutina dopocita k tomu, ze uz nema
      duvod cist do konce stopy, tak zacne cist jednoblokove. Musel by
      jsi tedy ROMku i nejak sikovne mystifikovat o tom, jak je tvuj
      zavadec velky, aby byl nacteny spravne... Jenomze ouvej - IPL
      zavadec nacetl nas program na adresu 0x1200 a na pozadovanou
      adresu jej presune az po uspesne dokoncenem cteni - pokud jsme
      kecali s delkou, tak mame dalsi duvod ke kolizi ...<br>
      <br>
      <br>
      No a proto se na Sharp disketach pouziva 1. stopa v MZFS formatu
      ;)<br>
      <br>
      Michal<br>
      <br>
      <br>
      Dne 24.1.2016 v 15:55 Vaclav Peroutka napsal(a):<br>
    </div>
    <blockquote cite="mid:F2R.JIdr.6uRsFqEHFER.1MfENb@seznam.cz"
      type="cite">
      <meta http-equiv="Context-Type" content="text/html; charset=utf-8">
      <div>Ahoj,
        <br>
        <br>
        mam takovou kacirskou myslenku, nicmene nevim, nakolik je
        schudna. Je to dotaz spise na Radka, Martina nebo Petra, kteri
        maji skutecne floppy radice.
        <br>
        <br>
        Vim, ze nulta stopa pro Sharpa ma format 16 sektoru po 256B. Co
        se ale stane, kdyz se da do Sharpa disk s nultou stopou 9x512B a
        korektnim 0. sektorem s IPLPRO textem a v 1. sektoru loader pod
        256B?
        <br>
        <br>
        Zkousne to WD279x nebo bude error ?
        <br>
        <br>
        Vasek
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
SharpMZ mailing list
<a class="moz-txt-link-abbreviated" href="mailto:SharpMZ@mail.ordoz.com">SharpMZ@mail.ordoz.com</a>
<a class="moz-txt-link-freetext" href="http://mail.ordoz.com/mailman/listinfo/sharpmz">http://mail.ordoz.com/mailman/listinfo/sharpmz</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>