[SharpMZ] pezik software

Neděle Březen 6 10:43:00 CET 2016

Ahoj,

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.

1) otazka velikosti disku vs obsazeni a poradi portu:
===========================================

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.
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.

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.

Samotny test existence ramdisku se provadi v 0. (0xe8) bance.

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. banka s 
obsahem "1", ale uz nefunguje 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.

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...

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.

2) otazka endianity v nastaveni adresniho latche:
=========================================

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.
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.

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.

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.
Kdyz se divam na to jak fyzicky uklada data Radkuv OS, tak vidim, ze to 
pojal ve stejnem duchu.

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.

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.

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?
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.

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.

Michal

------------- další část ---------------
HTML pĹĂloha byla odstranÄna...
URL: http://mail.ordoz.com/pipermail/sharpmz/attachments/20160306/dd0a44ae/attachment.html 