Celé vlákno · 3 zprávy

Zdarec,

Jelikoz pripravuji nejakou vychozi verzi zdrojaku MZIX, tak
vas chci informavat o mych rozvahach ohledne memory modelu:

Zaklad vychoziho pametoveho modelu:
- vyuziti 64 kB RAM, 16kB + 384B z VRAM pouzito pro jadro (setrit se musi s
 kazdym bajtikem, ze :-)
a 16000B VRAM pro zobrazovani. Obsah ROM - puvodni Sharp.

Zatim ne uplne jasno mam v rozlozeni vyuziti zminenych pametovych prostoru.
Pamet pro aplikace: Zde se nabizi prevzit reseni UZIXu, to je 0000-xxxx (v UZIX 
1.0 je to 7FFF).
Mozne je ale i jine reseni - jadro v dolnich adresach pameti, aplikace v
hornich. Melo by to tu vyhodu,
ze pro pouziti VRAM jadrem (8000-BFFF) by bylo lehci uhlidat strankovani,
jelikoz by se strakovalo
v pametovem prostoru aplikaci. Taktez to plati pro pripadne vyuziti horni ROM
(E000-FFFF) v jine
variante pametoveho modelu. Zatim se spise priklanim k te druhe variante:
0000 - XXXX-1 jadro (bude variabilni - dle velikosti jadra)
XXXX - FFFF prostor pro aplikace
8000 - BE79 (1. stranka VRAM) - zobrazeni, rezim 640x200/2
BE80 - BFFF (1. stranka VRAM) - jadro
8000 - BFFF (2. stranka VRAM) - jadro

Mozna by se mohlo zdat jako nevyhoda variabilni zacatek prostoru pro aplikace - 
pri zvetseni,
popr. pri zmenseni (optimalizace) jadra by se tento zacatek hybal. Ale pri
vyhledu relokovatelneho kodu
aplikaci by tato nevyhoda padla. Zatim by se dalo brat napr. XXXX = 8000.

Dalsi volitene pametove modely (do budoucna) bych videl:
- bez rozsirene VRAM; uzpusobena ROM - bud se zpetnou kompatibilitou, nebo nez
ni - dle uvazeni;
jine zobrazovaci rezimy - 320x200 (8 kB pro zobrazeni + 24 kB pro potreby
jadra), bud 40x25 znaku
nebo 80x25 se znaky 4x8.


Pri uvahach o vyuziti VRAM/ROM bych se rad zeptal:
Vite nekdo, jake to ma nasledky na rychlost provadeni kodu?
VRAM i ROM maji pomalejsi pristupove doby - je
tedy procesor zpomalovan nejakymi cekacimi stavy?
Nekdy jsem neco takovaho cetl o VRAM; ROM je
jeste pomalejsi. Takze - mate nekdo nejake konkretni
informace o tomhle?
V zavislosti na tom by se do VRAM umistily rutiny jadra,
pro ktere rychlost neni az tak velky pozadavek.

Dale: Zabyvali jste se nekdo upravami ROM Sharpa?
Vim, ze existuji nejake uzpusobene ROM napr. pro
rychlejsi load z kazety - ale ted mam spise na mysli
systemove sluzby - napr. podpora textovych zobrazeni
v grafickych rezimech, podpora dalsiho HW (treba IDE16),
sofistikovanejsi rutiny pro RD atd.
Jiste by to bylo uzitecne treba i pro NIPOS.
Z original ROM Sharpa by se dala odparat treba
podpora QD (majitele QD prominou....) a jiste se
najdou i dalsi veci, ktere by nemely velky dopad dopad
na kompatibilitu. Jestli by tohle nekoho zaujalo a chtel by
se to ho ujmout - byl bych vdecen, a zasoboval bych ho namety.

zatim zdar.

Fuzzy

zial, mam fofry, tak len strucne:
- pamatovy model je fajn, ale vcelku by sa mi pozdavalo aj jadro v hornej
casti - primapovanim hornej vram dostanes linearny priestor (8000-9FFF
resp. BFFF). tak by sa do tych zvyskovych 384 Bajtov dalo dat nieco, co
nadvazuje dalej - A000....
- spominanych 384 bajtov ma vyznam pouzit LEN vtedy, ako nenarastie objem
jadra pristrankovavanim VRM pre ich vyuzitie. preto sa priklanam aj k
(takmer) trvalejsiemu primapovaniu VRAM.
- neadresujes problem mapovania - pri namapovanej VRAM je 1000-1FFF
namapovana CGROMkou... co s aplikaciou (ak bude volat jadro prave z tej
adresy?)
- preferoval by som skor mod 640x400, napriek usetrenym 8kB by sa s 320x200
asi robilo horsie...
- ROM/VRAM udajne je pomalsia, myslim ze Zdenek bude v tejto teme cennym
zdrojom
- ako som sa uz raz vyjadril: nesiel by som cestou zmeny ROM. stane sa to
raritou pre 1-2 ludi... (ja osobne nie som ochotny preprogramoovavat)


Feri

> - preferoval by som skor mod 640x400, napriek usetrenym 8kB by sa s
> 320x200
> asi robilo horsie...

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
 dalsi moznosti (vcetne jinych grafickych rezimu a vyuziti ROM) jsem myslel jako
alternativni moznosti - nastavovane nejakymi parametry pri prekladu jadra; kdo
bude mit zajem, nastavi si prislusny parametr, prelozi jadro a bude mit jadro
uzpusobene napr. pro vyuziti preprogramovane ROM. Samozrejme, ze tyto
alternativy zatim implementovat nebudeme, jde o to, aby se na tyto moznosti
myslelo
do budoucna a aby jadro bylo podle toho navrzeno.

> - spominanych 384 bajtov ma vyznam pouzit LEN vtedy, ako nenarastie > objem
> jadra pristrankovavanim VRM pre ich vyuzitie. preto sa priklanam aj 
> (takmer) trvalejsiemu primapovaniu VRAM.

tech 384B jsem myslel napr. pro rutiny pro vypis znaku do VRAM, kdyz je tato
stranka stejne namapovana.

> - neadresujes problem mapovania - pri namapovanej VRAM je
> 1000-1FFF
> namapovana CGROMkou... co s aplikaciou (ak bude volat jadro prave z
> tej adresy?)

Pro aplikace by se system tvaril, jako ze pro ne ma urcity prostor RAM. Aplikace
o strankovani nebude vubec vedet. Jestlize system (at uz pri volani sluzby
jadra, prepinani kontextu nebo jindy) bude potrebovat nastrankovat VRAM, tak to 
jednoduse provede. vubec nevadi, ze se odstrankuje prave bezici aplikace - jadro
je odpovedne za to, ze nevrati rizeni aplikaci, ktera je odstrankovana nekde pod
vram nebo cgrom.
Prakticky bych to videl tak, ze obsah VRAM se proste musi zvolit tak vhodne, aby
bylo mozno v prubehu jejiho nastrankovani zakazat zmenu kontextu na aplikace.
Proste nejake neblokujici rutiny, pri nichz se 1) zakaze prepinani kontextu, 2) 
nastrankuje VRAM, 3) zavole se rutina, 4) udstarnkuje se VRAM, 5) povoli se
prepinani kontextu.
Entry point pro sluzby jadra musi byt samozrejme mimo strankovatelne adresy.

> pamatovy model je fajn, ale vcelku by sa mi pozdavalo aj jadro v
> hornej casti - primapovanim hornej vram dostanes linearny priestor
> (8000-9FFF resp. BFFF). tak by sa do tych zvyskovych 384 Bajtov
> dalo dat nieco, co nadvazuje dalej - A000....

Ano, to by vyhoda byla ale myslim ze ne az tak velka, separace jadra na 16kB ve 
VRAM + zbytel nekontinualne jinde by myslim nebyl velky problem.

Fuzzy