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">> Jak jsem se hrabal v novejch systemech a delal zmeny, tak jsem vyzkousel
> i jakesi setreni RAMky pro Bios. Uvodni vypisy po spusteni CPM a hlasky
> o spatne verzi a chybe pri bootu jsem nacpal na konec biosu a ukoncil je
> .DEPHASE. Uplne na konci mam CHK_ a ALL_ pro disky a 128 byte DIRBUF.
> Pred tyhle hlasky jsem dal .PHASE "zacatek tech textu". Protoze jsou
> hlasky potreba jen dokud se poprve neskoci do CCP, tak jsem presvedcenej,
> ze jsou v pameti zbytecne. Na jejich misto se po! sune CHK_, ALL_
> a DIRBUF.
</span>
Áno. To je bežná prax, že sa pri studenom štarte buffre pre CHK, ALL a
<img src="BODY_IMAGES_WRAP_GIF"> DIRBUF využívajú pre kód, ktorý už potom nie je potrebný. Musí to byť
<img src="BODY_IMAGES_WRAP_GIF">ale dobre premyslené.
<span class="replyquote1">> U me je to "zkraceni biosu" o 180 byte, coz skoro 1/5 dylky celyho
<img src="BODY_IMAGES_WRAP_GIF">biosu.
> Pro biosy dlouhy do 400H jen na systemovych stopach to maka perfektne.
> Jenze ted co delam ty dlouhy biosy 800H s ulozenim zbytku do nevyuzitych
> sektoru na 76 stope jsem narazil u tohodle "zkraceni biosu" na jeden
> problem. U boot sektoru to je jasny, ze musim natahnout uplne celej
> system a spustit. Ale co u WBOOT? Tam by se sice nemela vypisovat uvodni
> hlaska ale muze to skoncit na chybe nacitani systemu a potom by chybel
> text pro hlasku Boot error, protoze na jeho miste by byly ALL_ a CHK_
> a DIRBUF. Znamena to tedy pri WBOOT natahovat taky uplne cely system?
</span>
Obvykle sa pri teplom štarte doťahuje iba CCP a BDOS. Celý systém, vrátane
<img src="BODY_IMAGES_WRAP_GIF">BIOSu, sa naťahuje zvyčajne iba pri bootovaní.
Nebol by samozrejme problém naťahovať celý systém aj pri teplom štarte, to
<img src="BODY_IMAGES_WRAP_GIF">by ale malo za následok, že by to musel byť v konečnom dôsledku zrejme
<img src="BODY_IMAGES_WRAP_GIF">studený štart, lebo by sa doťahovaním celého BIOSu museli nainicializovať
<img src="BODY_IMAGES_WRAP_GIF">aj buffre, či tabuľky diskov, kde už BDOS mohol mať svoje behové
<img src="BODY_IMAGES_WRAP_GIF">informácie. Naviac, pokiaľ by bol systém aj v 76 stope (zbytok BIOSu),
<img src="BODY_IMAGES_WRAP_GIF">znamenalo by to seekovanie hlavy disku pri každom teplom štarte systému.
Pokiaľ je potrebné vypisovať nejakú chybovú hlášku pri studenom aj teplom
<img src="BODY_IMAGES_WRAP_GIF">štarte, tak sa nedá nič robiť a ten text musí byť v časti kódu, ktorá
<img src="BODY_IMAGES_WRAP_GIF">"zostáva" v pamäti.
<span class="replyquote1">> Mam v tom nejaky nejasnosti, navic jsem si vsiml, ze pocatecni boot z 0
> sektoru je jinaci, nez z WBOOTU. Proste se cte jiny pocet sektoru
> a dokonce se ukladaji v jiny posloupnosti. Nad timhle jsem nikdy nebadal
> a neni mi to moc jasny. Asi si budu muset tyhle dva booty zkusebne
> naadresovat od 100H posunout body umisteni systemu do Ram a odladit si
> to Slapem. Kdyz koukam do vypisu prekladu, tak mi to nak nedava smysl.
> Mluvim treba o Bios0502 a Boot0502, co mam v Sapiman.
</span>
BOOT kód samozrejme naťahuje celý systém, teda CCP, BDOS a BIOS a následne
<img src="BODY_IMAGES_WRAP_GIF">sa skáče do BIOSu na studený štart, kde sa robí počiatočná
<img src="BODY_IMAGES_WRAP_GIF">inicializácia.
Pri teplom štarte sa opätovne doťahuje iba CCP a BDOS. Preto je počet
<img src="BODY_IMAGES_WRAP_GIF">čítaných sektorov menší ako pri BOOTe. CCP sa doťahuje preto, že
<img src="BODY_IMAGES_WRAP_GIF">spustený program môže slobodne využiť aj túto oblasť pamäti. BDOS sa
<img src="BODY_IMAGES_WRAP_GIF">doťahuje "pre istotu", keby nejaký program BDOS poškodil, alebo ho pre
<img src="BODY_IMAGES_WRAP_GIF">vlastné účely modifikoval. Ak by bol nejakým programom "zasiahnutý" aj
<img src="BODY_IMAGES_WRAP_GIF">BIOS, tak to pravdepodobne skončí nejakou "haváriou".
Teplý štart robí oproti studenému štartu obvykle už iba nejaké "malé"
<img src="BODY_IMAGES_WRAP_GIF">inicializačné práce (napr. už sa nezisťujú pritomné mechaniky a pod.),
<img src="BODY_IMAGES_WRAP_GIF">riadenie sa vráti CCP a aktuálna mechanika a užívateľ sa berú z adresy
<img src="BODY_IMAGES_WRAP_GIF">0004h (CDISK).
<span class="replyquote1">> Jinak Ramdisky jsem vcera moril dva mezi sebou neustalym kopirovanim
> s kontrolou asi 4 hodiny a ani jednou to nespadlo do verify error.
> Vypada to, ze ty tabulky, co jsi napsal jsou v poradku. Jeste mi prozrad,
> podle ceho je delas, zda to jen tak spocitas, ci na to mas nejakej
> manual. DPB je mi snad podle par prikladu jasna, ale jak vytvaris dylku
> ALL a CHK? Potreboval bych vyzkouset par atyp disku a nechci Te s tim
> pokazdy zatezovat. -:))
</span>
Som rád, že RMD-1/1MB šlape.
Nemám to, samozrejme, všetko z vlastnej hlavy, ale mám na to múdru knižku
<img src="BODY_IMAGES_WRAP_GIF">"Operační systém CP/M pro mikropočítače" od autorov Ing. Karel Richta a
<img src="BODY_IMAGES_WRAP_GIF">Ing. Jan Zajíc, z roku 1986, 286 strán.
Tabuľka DPH (Disk Parameter Block): (v zátvorke je veľkosť položky)
XLT (2) - adresa prekladovej tabuľky. 0, ak preklad logických sektorov na
<img src="BODY_IMAGES_WRAP_GIF">fyzické nie je potrebný. Veľkosť prekladovej tabuľky je SPT bytov. Ak XLT u
<img src="BODY_IMAGES_WRAP_GIF">niektorých diskov obsahuje adresu a u niektorých diskov je 0, musí byť
<img src="BODY_IMAGES_WRAP_GIF">zodpovedajúco upravená aj rutina TRANS, ktorá musí prípad nulového XLT
<img src="BODY_IMAGES_WRAP_GIF">ošetriť.
WRK (6) - pracovná oblasť BDOSu
DIRBUF (2) - adresa buffra (128 bytov) pre operácie s adresárom. Môže byť
<img src="BODY_IMAGES_WRAP_GIF">spoločná pre všetky jednotky.
DPB (2) - adresa tabuľky parametrov disku. Pre jednotky s rovnakými
<img src="BODY_IMAGES_WRAP_GIF">parametrami môže byť DPB spoločná.
CSV (2) - adresa zóny kontrolných súčtov. Jej veľkosť musí byť CKS bytov
<img src="BODY_IMAGES_WRAP_GIF">a musí byť samostatná pre každú jednotku. Ak je CKS = 0, CSV môže byť
<img src="BODY_IMAGES_WRAP_GIF">tiež 0.
ALV (2) - adresa bitovej alokačnej mapy. Oblasť musí byť samostatná pre
<img src="BODY_IMAGES_WRAP_GIF">každú jednotku. Veľkosť tejto oblasti má byť (DSM / 8) + 1.
DPH tabuľky musia byť v RAM, keďže sú BDOSom modifikované v ich pracovnej
<img src="BODY_IMAGES_WRAP_GIF">oblasti.
Tabuľky DPB (Disk Parameter Block): (v zátvorke je veľkosť položky)
SPT (2) - počet logických sektorov (128 bytov) na stopu. Ak je veľkosť
<img src="BODY_IMAGES_WRAP_GIF">fyzického sektoru väčší ako 128 bytov, je SPT rovný súčinu počtu
<img src="BODY_IMAGES_WRAP_GIF">logických sektorov na fyzický sektor a počtu fyzických sektorov na stopu.
BSH (1) - block shift - dvojkový logaritmus počtu logických sektorov v
<img src="BODY_IMAGES_WRAP_GIF">alokačnom bloku - log2 (BLM + 1)
BLM (1) - block mask - počet logických sektorov v alokačnom bloku mínus
<img src="BODY_IMAGES_WRAP_GIF">jedna
EXM (1) - extent mask - maska rozšírenia - počet logických rozšírení
<img src="BODY_IMAGES_WRAP_GIF">(16kB) adresovaných jednou položkou adresára mínus jedna. Je určená
<img src="BODY_IMAGES_WRAP_GIF">veľkosťou alokačného bloku (BLS) a celkovým počtom alokačných blokov
<img src="BODY_IMAGES_WRAP_GIF">(DSM) takto:
BLS DSM<256 DSM>255
1kB 0 -
2kB 1 0
4kB 3 1
8kB 7 3
16kB 15 7
DSM (2) - disk size max - veľkosť disku - celková kapacita diskovej jednotky
<img src="BODY_IMAGES_WRAP_GIF">v alokačných blokoch mínus jedna (číslo posledného alokačného bloku)
DRM (2) - directory max - veľkosť adresára - maximálny počet položiek
<img src="BODY_IMAGES_WRAP_GIF">adresára mínus jedna. Adresár zaberá celistvý počet alokačných blokov.
<img src="BODY_IMAGES_WRAP_GIF">Každý logický sektor obsahuje 4 položky adresára, takže:
DRM = (X * (BLM + 1) * 4) - 1
kde X je počet alokačných blokov adresára
AL0,AL1 (1,1) - prvé dva byty bitovej mapy určujúce alokačné bloky
<img src="BODY_IMAGES_WRAP_GIF">rezervované pre adresár. Jednotka v 7. bite AL0 rezervuje 0. blok, v 6. bite
<img src="BODY_IMAGES_WRAP_GIF">1. blok atď. až jednotka v 0. bite AL1 rezervuje 15. blok.
CKS (2) - check sum - počet sektorov adresára testovaných na neregulérnu
<img src="BODY_IMAGES_WRAP_GIF">výmenu média. U výmenného média (DRM + 1) / 4, u pevného média 0.
OFF (2) - offset - počet stôp rezervovaných na začiatku diskovej jednotky.
<img src="BODY_IMAGES_WRAP_GIF">Umožňuje to aj rozdeliť veľký pevný disk na viac logických jednotiek.
DPB tabuľky nie sú BDOSom modifikované a teda môžu byť aj v ROM.
Roman
</pre>