Původní podoba příspěvku
Surová data tak, jak byla v roce 2013 stažena z Pandory (HTML zdroj bez úprav, osobní e-mailové adresy jsou maskované).
<!-------------------------------------------------------------->
<!-------------------------------------------------------------->
<table width="100%"><tr><td align="left" valign="middle"></td><td align=right valign="middle"></td></tr></table><BR><pre><span class="replyquote1">> Tak to mam Romane nejaky jiny vydani. Na 241 az 244 mam prehled funkci
> modulu BDOS. Viz scan, co jsem dal na Drop. Ja to mam na strankach 177-184.
</span>
Strany 241 až 244 platia pre tú oscanovanú knihu na Dropboxe
\'SAPI_DOKU\'skeny_dokumentace_bez_retusi_Petr\'MANUAL_CP-M\'
Pre knihu, ktorú zrejme obaja máme, platia strany 177 až 184.
<span class="replyquote1">> Ty delky CSV=CKS a ALV=(DSM/8)+1 jsem jiz nasel, maji to popsany u tabulky
> DPH. Uz tomu zacinam trochu rozumet. Jen mi neni jasne, jak se urcuje pro
> konkretni disk BLM - pocet vet v alokacnim bloku. A taky co to je BLS, ze
> kteryho se urcuje EXM.
> Je to spravne, ze DSM je kapacita disku minus kapacita systemovych stop?
</span>
Príklad vytvorenia tabuliek diskových parametrov v prílohe.
<span class="replyquote1">> Taky jak se pomoci Offestu a DSM udela dalsi logicky disk. Pokud bych chtel
> RMD-1/1MB rozdelit na dva 0,5 Mb tak takhle? On je totiz docela problem s
> treba s vypisem adresare na velkym disku. Navic je to dost neprehledny. Me
> vypis zastavuje az po 24 radku a AND-1 ma jen 20 radku. Asi by to slo
> upravit v CCP.
> ;pro RMD1, 256 alokacnich bloku velikosti 2kB, 64 polozek adresare
</span>
Opravené tabuľky:
DPB_1: DW 16 ; SPT
DB 4 ; BSH
DB 15 ; BLM
DB 1 ; EXM
DW 255 ; DSM
DW 63 ; DRM
DB 128 ; AL0
DB 0 ; AL1
DW 0 ; CKS
DW 0 ; OFF
DPB_2: DW 16 ; SPT
DB 4 ; BSH
DB 15 ; BLM
DB 1 ; EXM
DW 255 ; DSM
DW 63 ; DRM
DB 128 ; AL0
DB 0 ; AL1
DW 0 ; CKS
DW 256 ; OFF
ALV_1: DS 32 ;ALOKACNI VEKTOR
ALV_2: DS 32 ;ALOKACNI VEKTOR
<span class="replyquote1">> A jeste jednu vec. Pokud bude mit disketa sektor 256 nebo 512byte,
> predpokladam, ze se pri BOOT ctou primo 256 (512) byte sektory do pameti. Uz
> jsem sice videl, ze jeden formatovaci program nabizel formatovani
> systemovych stop na 128 byte a zbytek disku 256 bytu. Chodi potom Sysgen?
> Ten je prece nastavenej natvrdo na 128 byte a pocet sektoru a stop na 8".
</span>
BOOT je zvyčajne špeciálny prípad a často existujú osobitné rutiny,
<img src="BODY_IMAGES_WRAP_GIF"> ktoré systém načítavajú.
To ako bude BOOT systém načítavať závisí teda aj od SYSGENu.
Štandardný SYSGEN (ktorého zdrojáky boli dodávané s pôvodným CP/M)
<img src="BODY_IMAGES_WRAP_GIF">predpokladá, že systém je umiestnený na prvých dvoch stopách, na ktoreých
<img src="BODY_IMAGES_WRAP_GIF">je po 26 sektorov a skew factor je 1, teda, že sektory nie sú poprehadzované.
<img src="BODY_IMAGES_WRAP_GIF">Sektory sú čítané a zapisované priamo rutinami BIOSu.
To znamená, že aj keď bude fyzický sektor väčší ako 128 bytov, rutiny
<img src="BODY_IMAGES_WRAP_GIF">READ a WRITE BIOSu budú zapisovať správne, keďže musia mať implementovaný
<img src="BODY_IMAGES_WRAP_GIF">blokovací-deblokovací algoritmus pre "transformáciu" logického sektora na
<img src="BODY_IMAGES_WRAP_GIF">fyzický.
Ak si vezmeme náš ukážkový príklad s 5,25" diskom, tak SYSGEN zapíše
<img src="BODY_IMAGES_WRAP_GIF">systém pripravený od adresy 0900h v pamäti na disk tak, že na 0. stope bude
<img src="BODY_IMAGES_WRAP_GIF">prvých 26 logických sektorov systému a na 1. stope bude zostávajúcich 26
<img src="BODY_IMAGES_WRAP_GIF">logických sektorov systému. Na každej stope bude teda nevyužitých po 10
<img src="BODY_IMAGES_WRAP_GIF">logických sektorov.
Takže BOOT kód musí rovnakým spôsobom systém načítať. Pochopiteľne s
<img src="BODY_IMAGES_WRAP_GIF">použitím nejakého kódu v EPROM, keďže BIOS sa ešte len bude
<img src="BODY_IMAGES_WRAP_GIF">načítavať.
Pokiaľ by mal byť systém rozložený inak, alebo by mal byť väčší, musel
<img src="BODY_IMAGES_WRAP_GIF">by sa SYSGEN upraviť pre daný prípad.
Roman
</pre>