<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<font size="+1"><br>
Ahoj,<br>
<br>
prozatim tu mam k dispozici 2 programy pracujici s ramdiskem PEZIK
a jak se ukazuje, tak programatori s timto kusem HW pracovali tak,
jak se jim zrovna v danou chvili zamanulo. Nic proti nicemu.
Vzhledem k tomu, ze se nejedna o zalohovany disk, tak se tyhle
rozdily v kompatibilite zrejme nikdy nikde neprojevovaly tak, aby
dochazelo ke kolizim.<br>
<br>
<br>
1) otazka velikosti disku vs obsazeni a poradi portu:<br>
===========================================<br>
<br>
Radek tady v nekterem z predchozich postu uvedl, ze jako prvni
banka by se mela obsadit ta, ktera se nachazi na adrese 0xec a
nasledne se pokracuje od 0xe8 nahoru. <br>
Radku, vsumnul jsem si, ze v nastaveni tveho OS je jakasi moznost
nastavovat jednotlive banky, nicmene moc jsem to nezkoumal.
Kazdopadne v zaklanim nastaveni, kdyz ve tvem systemu neco na
ramdisk nahraju, tak se to uklada od banky s nejnizsim poradovym
cislem 0xe8 a nikoliv od 0xec.<br>
<br>
JSS si pred praci s diskem udela test velikosti disku tak, ze na
nulty bajt kazde banky v poradi 0xe8 - 0xef ulozi cislo banky
(zvyseno o 1), tedy 1 - 8. Nasledne provede kontrolu ctenim z 0.
(0xe8) a 4. (0xec) banky, cimz tedy dela test pouze zda se jedna o
256, nebo 512 kB verzi. Pritomnost, ci nepritomnost dalsich bank
se pri testu vubec neresi. Nejak mi unika smysl toho, proc tedy
ovsem na zacatku pred testem precte obsah z 8 bank, pak zapisuje
do vsech a na konci testu potom vraci puvodni hodnotu do vsech 8
bank.<br>
<br>
Samotny test existence ramdisku se provadi v 0. (0xe8) bance.<br>
<br>
Autor JSS ROM se vsak zrejme nechal zmast tim, ze do bank uklada
jejich cislo zvysene o 1, takze pokud identifikoval, ze mu funguje
0. </font><font size="+1"><font size="+1">banka </font>s obsahem
"1", ale </font><font size="+1"><font size="+1">uz nefunguje </font>4.
banka s obsahem "5" tak zpristupni v seznamu banky 0. - 4. =>
320 kB, misto puvodne zamyslenych 256 kB. Spravme by mely byt
zpristupneny banky 0. - 3.<br>
<br>
Az na tu chybu s poctem bank, ke ktere zrejme doslo tak, ze bohati
Brnaci zrejme meli vzdy jen 512 kB ramdisky, mi prijde, ze takovy
postup obsazovani a urcovani poradi bank je nejlogictejsi. Co se
tyka moznych kapacit tohoto disku, tak to uz je jina... <br>
<br>
Muj zaver je, ze mozna nekdo nekdy zamyslel variabilne i peziky s
mensi, ci atypickou kapacitou, nicmene v miste s jejich
pravdepodobne nejvetsim vyskytem bylo zrejme standardem 256, nebo
512 kB obsazeni a nic mezi tim.<br>
<br>
<br>
<br>
2) otazka endianity v nastaveni adresniho latche:<br>
=========================================<br>
<br>
Kdysi jsem mel od Zdenka nejaky dokument s navodem jak obsluhovat
PEZIK. Nemohu to ted najit, ale pokud si vybavuju, tak tam byl
popsan princip 16 bitoveho adresovani, ktery jsem pochopil tak, ze
se uvnitr ramdisku nachazi 8 bitovy latch. Pri praci s ramdiskem
se 16 bitova adresa v ramci banky nastavi tak, ze se posklada s
aktualni MSB datove sbernice (tedy obsahu regB pri instrukci out
(c),a ) a z obsahu, ktery je jiz ulozen v latchi. <br>
Pokud prave probehla operace cteni - tedy IN a, (c), tak se po
dokonceni operace ulozi adresni MBR do vyse zmineneho latche.
Pokud probihal zapis, tak se latch nezmeni.<br>
<br>
Co ovsem neni nikde popsano je to, zda se ma v latchi machazet
MSB, nebo LSB cast pezikovske adresy. Ono je to ve sve podstate
jedno, protoze at uz je tam jedno, nebo druhe, tak ramdisk bude
vzdy fungovat naprosto spolehlive. Jedine, cim se tyto 2 metody
lisi je to, zda bude v driveru malinko slozitejsi rutina zapisu,
nebo rutina cteni a tim, ze v jednom pripade budou fyzicka data
ulozena usporadane a v druhem budou od sebe bajty rozlozeny v
ramci cele banky s odstupem 256 bajtu.<br>
<br>
Ja osobne jsem to pojal tak, ze jsem vychazel z bezne intelovske
endianity, kdy se nejprve udava LSB a az za nim MSB. Z tohoto
pravidla jsem si pak ucinil svuj vlastni zaver, ze pokud se pri
plnem 16 bitovem urceni adresy musi vzdy nejprve provest cteni, po
jehoz dokonceni se nastavi novy obsah latche, tak tedy do latche
vkladame LSB. <br>
Kdyz se divam na to jak fyzicky uklada data Radkuv OS, tak vidim,
ze to pojal ve stejnem duchu.<br>
<br>
Kdyz jsem se podival jak jsou fyzicky ulozena data zapsana pomoci
JSS, tak jsem zjistil, ze tam je te presne naopak a kdyz se nad
tim zamyslim, tak mi takovy pristup prijde mozna lepsi, protoze
pokud budu touto metodou zapisovat data na disk, tak si nejprve
pomoci prvniho IN nastavim obsah latche. Nasledne uz pak mohu s
kazdym OUT jen incrementovat regB a na latch neni potreba sahat
dokud regB nedosahne hodnoty 0xff.<br>
<br>
K logickemu zaveru o tom, ze je spravne ten Svehluv pristup mne
privadi to, ze kdybych chtel podobnym "zrychlenym" pristupem cist,
tak by to rozhodne nefungovalo, protoze prave pri cteni se vzdy
nastavuje obsah latche a tedy zde opravdu VZDY musi nasledovat dva
IN po sobe.<br>
<br>
Zajimalo by mne, jak se k vyse uvedenym problemum postavili
ostatni programatori. Mate nekdo BASIC, ci nejake oficialni
utility pro PEZIK? Neumi nahocou nejaka kazetakova kopirka
pouzivat ramdisk?<br>
Nenapsal Zemcik i svou vlastni ramdiskovou cp/m? Mam totiz pocit,
ze nejaka tady kdysi nejaka takova kolovala i s doprovodnym
textem, ze se jedna o jeho diplomovou praci, ale je mozne, ze se
mi popletli lidi.<br>
<br>
BTW: kdyby jste se chteli podivat na fyzicke ulozeni bajtu v
ramdisku, tak bohuzel v posledni vydane verzi emulatoru jeste
nefunguje spravne memory dump pro peziky. Pokud bude zajem, tak
zase nekam ulozim ke stazeni devel verzi s opravou - kvuli takove
drobnosti vsak zatim nebudu vydavat dalsi release.<br>
<br>
Michal<br>
<br>
<br>
</font>
</body>
</html>