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"><B>Re: Re: MZIX - memory model:</B></td><td align=right valign="middle"></td></tr></table><BR><pre><span class="replyquote1">&gt; - preferoval by som skor mod 640x400, napriek usetrenym 8kB by sa s
&gt; 320x200
&gt; asi robilo horsie...
</span>
tenhle mod bych preferoval taky, ale bohuzel na Sharpu neni k dispozici :-)
Oukej, vim ze to byl preklep.
Jinak jsem to myslel tak, ze zakladni pametovy model MZIX pocita s 640x200, ty
<img src="BODY_IMAGES_WRAP_GIF"> dalsi moznosti (vcetne jinych grafickych rezimu a vyuziti ROM) jsem myslel jako
<img src="BODY_IMAGES_WRAP_GIF">alternativni moznosti - nastavovane nejakymi parametry pri prekladu jadra; kdo
<img src="BODY_IMAGES_WRAP_GIF">bude mit zajem, nastavi si prislusny parametr, prelozi jadro a bude mit jadro
<img src="BODY_IMAGES_WRAP_GIF">uzpusobene napr. pro vyuziti preprogramovane ROM. Samozrejme, ze tyto
<img src="BODY_IMAGES_WRAP_GIF">alternativy zatim implementovat nebudeme, jde o to, aby se na tyto moznosti
<img src="BODY_IMAGES_WRAP_GIF">myslelo
do budoucna a aby jadro bylo podle toho navrzeno.

<span class="replyquote1">&gt; - spominanych 384 bajtov ma vyznam pouzit LEN vtedy, ako nenarastie &gt; objem
&gt; jadra pristrankovavanim VRM pre ich vyuzitie. preto sa priklanam aj 
&gt; (takmer) trvalejsiemu primapovaniu VRAM.
</span>
tech 384B jsem myslel napr. pro rutiny pro vypis znaku do VRAM, kdyz je tato
<img src="BODY_IMAGES_WRAP_GIF">stranka stejne namapovana.

<span class="replyquote1">&gt; - neadresujes problem mapovania - pri namapovanej VRAM je
&gt; 1000-1FFF
&gt; namapovana CGROMkou... co s aplikaciou (ak bude volat jadro prave z
&gt; tej adresy?)
</span>Pro aplikace by se system tvaril, jako ze pro ne ma urcity prostor RAM. Aplikace
<img src="BODY_IMAGES_WRAP_GIF">o strankovani nebude vubec vedet. Jestlize system (at uz pri volani sluzby
<img src="BODY_IMAGES_WRAP_GIF">jadra, prepinani kontextu nebo jindy) bude potrebovat nastrankovat VRAM, tak to 
<img src="BODY_IMAGES_WRAP_GIF">jednoduse provede. vubec nevadi, ze se odstrankuje prave bezici aplikace - jadro
<img src="BODY_IMAGES_WRAP_GIF">je odpovedne za to, ze nevrati rizeni aplikaci, ktera je odstrankovana nekde pod
<img src="BODY_IMAGES_WRAP_GIF">vram nebo cgrom.
Prakticky bych to videl tak, ze obsah VRAM se proste musi zvolit tak vhodne, aby
<img src="BODY_IMAGES_WRAP_GIF">bylo mozno v prubehu jejiho nastrankovani zakazat zmenu kontextu na aplikace.
<img src="BODY_IMAGES_WRAP_GIF">Proste nejake neblokujici rutiny, pri nichz se 1) zakaze prepinani kontextu, 2) 
<img src="BODY_IMAGES_WRAP_GIF">nastrankuje VRAM, 3) zavole se rutina, 4) udstarnkuje se VRAM, 5) povoli se
<img src="BODY_IMAGES_WRAP_GIF">prepinani kontextu.
Entry point pro sluzby jadra musi byt samozrejme mimo strankovatelne adresy.

<span class="replyquote1">&gt; pamatovy model je fajn, ale vcelku by sa mi pozdavalo aj jadro v
&gt; hornej casti - primapovanim hornej vram dostanes linearny priestor
&gt; (8000-9FFF resp. BFFF). tak by sa do tych zvyskovych 384 Bajtov
&gt; dalo dat nieco, co nadvazuje dalej - A000....
</span>
Ano, to by vyhoda byla ale myslim ze ne az tak velka, separace jadra na 16kB ve 
<img src="BODY_IMAGES_WRAP_GIF">VRAM + zbytel nekontinualne jinde by myslim nebyl velky problem.

Fuzzy</pre>