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> Taky si myslim, ze se neda vychazet z casu bootu z RD, ktery dela monitor. Uz drive mi psal Zdenek, ze v Markove Reilability testu cteni HD dosahovalo 50KB/s, zapis byl zhruba na polovicni rychlosti. Takže na swapovani by se dal bez problémů použít i HD - ve srovnání s Pezikem <img src="BODY_IMAGES_WRAP_GIF"> bych řekl, že bude o dost rychlejší. Pezik je ovládán rotovaným adresovým registrem, který je nutné celý updatnout při každém čtení / zápisu.. Reálně se mi ale zdá, že ani jeden z diskutovaných typů ukládání <img src="BODY_IMAGES_WRAP_GIF">dat nebudeme moct použít jinak než jako "pomalý swap". Pokud budeme mít problémy s velikostí jádra a skončíme s tím, že se nám nepodaří <img src="BODY_IMAGES_WRAP_GIF">rozběhnout tak, aby zůstalo dost volné paměti pro programy, možná budeme muset přehodnotit základní požadavky na MZIX a zkusit se přeci jen poohlédnout <img src="BODY_IMAGES_WRAP_GIF">po nějakém způsobu, jak reálně mapovat víc než 64k RAM na Sharpu. Takové rozšíření by se hodilo na víc věcí než jen MZIX - šlo by do NIPOSu <img src="BODY_IMAGES_WRAP_GIF">dodělat multitasking v CP/M, použít paměť při předělávání nových věcí na ZX <img src="BODY_IMAGES_WRAP_GIF">z ruských dílen apod.). Dokázal bych si i představit projití současných programů a her tak, aby bylo možné z nich kdykoli vyskočit zpět do <img src="BODY_IMAGES_WRAP_GIF">systému a pak zase zpět do programu (něco jako hibernate)... R. <span class="replyquote1">>Dne 19.09.2003 08:31:40 "Zdenek Adler (sharpemu@pandora.cz)" napsal: > >Nerad bych ted kecal, ale myslim ze Fuzzyho vypocet byl spravny - pokud se >nemylim (je to mozne, rutiny monitoru pro praci s RD nemam moc >prostudovane), tak se nejprve program prenese z ramdisku do pameti od </span>adresy <span class="replyquote1">>0x1200 a teprve potom se LDIRem prenasi na spravne misto v pameti. Krom </span>toho <span class="replyquote1">>asi Feri pocital i cas, ktery trva inicializace samotneho monitoru .... >Pokud se jeste bavime o rychlosti, jednoznacne nejlepsi je v tomto >zalohovany RD kompatibilni s originalem ktery disponuje automatickou >inkrementaci adresoveho citace po kazdem cteni/zapisu bytu. Nezalohovany </span>RD <span class="replyquote1">>typu Pezik ma nevyhodu v tom, ze se navic musi pred kazdym ctenim/zapisem </span>do <span class="replyquote1">>nej nastavit nova adresa a take zbytecne zabira moc portu (512K verze </span>obsadi <span class="replyquote1">>8 portu). > >Zdenek > </span><span class="replyquote2">>> >> tie casy budu asi blizsie ku tej pomalsej bitrate. ak sa riadim SRAM, </span>tak <span class="replyquote2">>> aj napriek optimalnejsiemu citaniu (INIR) trva nacitanie niekolko </span>desiatok <span class="replyquote2">>> kB softu cas porovnatelny so sekundami. >> vid rychlost, akou sa otvara Flappy zo SRAM: v UMZE alebo trebars aj v >> Zdenkovou EMU - 44kB za odhadom 2-3s, nech som superoptimista tak 1s - </span><span class="replyquote1">>cize </span><span class="replyquote2">>> urcite menej ako 44kB/s. >> >> z toho vyplyva, ze strankovanie je natolko pomale, ze nieco ako >> multitasking moze mat vazne problemy. >> >> co s tym? >> >> Feri. </span> </pre>