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>MZIX - memory model:</B></td><td align=right valign="middle"></td></tr></table><BR><pre>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 <img src="BODY_IMAGES_WRAP_GIF"> 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 <img src="BODY_IMAGES_WRAP_GIF">1.0 je to 7FFF). Mozne je ale i jine reseni - jadro v dolnich adresach pameti, aplikace v <img src="BODY_IMAGES_WRAP_GIF">hornich. Melo by to tu vyhodu, ze pro pouziti VRAM jadrem (8000-BFFF) by bylo lehci uhlidat strankovani, <img src="BODY_IMAGES_WRAP_GIF">jelikoz by se strakovalo v pametovem prostoru aplikaci. Taktez to plati pro pripadne vyuziti horni ROM <img src="BODY_IMAGES_WRAP_GIF">(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 - <img src="BODY_IMAGES_WRAP_GIF">pri zvetseni, popr. pri zmenseni (optimalizace) jadra by se tento zacatek hybal. Ale pri <img src="BODY_IMAGES_WRAP_GIF">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 <img src="BODY_IMAGES_WRAP_GIF">ni - dle uvazeni; jine zobrazovaci rezimy - 320x200 (8 kB pro zobrazeni + 24 kB pro potreby <img src="BODY_IMAGES_WRAP_GIF">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 </pre>