[SharpMZ] pezik software
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
