Neumann talan tulelne, elvegre a Harvard architektura pont ilyen, amit sok uC is hasznal pl (mondjuk a PIC).  Amugy pl egy modern x86-os CPU-ban (vagy lehetne mas peldat is hozni persze) 4K meretu lap szintjen lehet dolgokat szabalyozni. Nyilvan a Z80-nak nincs eppen fejlett MMU funkcionalitasa, de az is megoldas lehetne, ha nem csak "lapozni" lehet a 4db 16K-s "szeletet" a Z80 cimtartomanyanak a Dave 4 regisztere segitsegevel, hanem pl az is megadhato lenne, hogy read-only vagy read-write ...

Amugy meg a Z80 kapcsan: lehet az eZ80-al kene foglalkozni, ma is kaphato, 50Mhz orajelen is elmegy, es mivel azonos orajelen kb 4x gyorsabb mint az eredeti Z80, egy ilyen ugy erzodne mint "egy 200MHz-es Z80" ... Ami azert szep fejlodes

Még volna itt valami. Lehet hogy félreértettelek téged LGB, de azt tudnod kell, hogy a 386-os prociktól felfelé MINDEN alkalmazásnak (programnak, processznek) 4GB memória állt rendelkezésre, mert a processzor ennyit tudott megcímezni. Nem volt szükség lapozásra. Azért mondom, hogy mindegyik programnak (processnek), mert képes volt elszeparálni egymástól a memóriaterületeket, és ami A programnak 0x00ba13A2h memóriacímen található információ az B proginak már teljesen más értéket adott ki ugyanazon címen, nyilván azért, h. ne láthassák egymás adatait, mert akkor ha képes felülírni, beláthatatlan hibához vezet. Itt viszont már beszélhetünk "lapozásról" amikor az OP rendszer átadja mondjuk 100us idõre a másik alkalmazásnak az irányítást, akkor a neki megfelelõ memóriakörnyezetet is felépíti.

 - Mielõtt belekezdek szeretném kiemelni, hogy a Win95/98 másképp mûködött mint a Windows NT, az elsõ DOS alapú volt nem volt benne igazi újítás, nem foglalkozok vele. Láthatjátok is, hogy amint lehetett számûzték, és minden mostani Windows-os OP rendszer NT alapú

 Szóval, mivel akkor még nem volt ennyi (4GB) EDO-RAM elérhetõ ezért a Windows NT virtuális memóriát használt, amit a merevlemezen tárolt. És amikor a program hozzáférést kért ehhez a memóriához, azon belül pedig ahhoz a részhez, ami éppen nem volt a RAM-ban, az Operációs Rendszer betöltötte a merevlemezrõl a rendszer-memóriába amire éppen szüksége volt. Ezen kívül a felsõ 2GB-ot úgy emlékszem nem is használta, a kompatibilitás miatt, ugyanis léteztek olyan processzorok, amik a 2GB feletti részt nem támogatták (DEC alpha)

 Természetesen nem volt olyan program, ami lefoglalt volna ilyen tetemes mennyiségû memóriát, így sosem volt kihasználva teljesen.

Mindezeket csak azért tudom, mert most tanulok Windows-NT-t programozni, és a memória lefoglalás esetén fontos, hogy átlássuk a mûködést.

Egyébként mindez a finomság arra jó, hogy párhuzamosan futhasson több alkalmazás anélkül, hogy egymást zavarnák.

Ezt rosszul tudod. Csak eppen mas fajta lapozas, nem ugyanaz nyilvan mint amit az EP a Dave-ben csinal A 386-os maga kozvetlenul meg tud(na) cimezni 4Gbyte memoriat igen, de az un virtualis cimtartomany ennel joval nagyobb, mivel egy lapot lehet jelolni nem letezonek is. Plusz, mivel 4Gbyte memoria ritkan volt azert 386-os rendszerben meg, eleve ezt csinaltak, ez az un swapping megvalositasanak a hw alapja, akkor egy nem letezonek jelolt lap hatasara kivetel generalodik, amit az OS lekezel, es pl a disk-rol betoltodik az aktualis lap. Nem tudom miert irod, hogy 386-oson nincs szukseg lapozasra: pont az a lenyege, minden modern OS, modern CPU-n lapozast hasznal! Csak eppen lehet, belekeveredtel a fogalmakba, mert - ahogy irtam - ez a lapozas _NEM_ az a lapozas, ami EP-ben van! Ez kis felreertesre adhat okot.

Itt jon a kepbe, hogy nem akartam azt mondani, hogy implementalni kene elsore egy "advanced MMU" (a "386-os ertelmeben vett" lapozassal egyutt) jelleget, azert mondtam, hogy mar az is elorelepes lenne, ha csak az EP ertelmben vett lapozasnal egy-egy 16K-s szeletre remondhatnad, hogy a CPU szamara az read-only, igy nem tudod felulirni veletlenul legalabb. Ettol persze ez teljesen mas jellegu dolog, mint 386-oson, ahol egy lapra azt mondod, hogy read-only, azon kivul, hogy a fogalom hasonlit, teljesen mas implementaciorol van szo, termeszeten!


Ez igy nem teljesen korrekt, nem epiti fel, csak hasznalja. Az kisse "draga" lenne, ha a laptablakat ujra kene epiteni minden context switch-nel
En pont errol beszeltem, hogy alapvetoen azert nem kene elsore egy uj 386-ost tervezni Z80 utasitaskeszlettel elsore az is jo, ha a meglevo dolgokat lehetne kisse "finomitani". Itt meg arrol van szo, hogy a Z80 alapvetoen 16 bites cimbusszal rendelkezik. Ha mindenaron - bar santito - analogiat akarunk allitani, mondhatjuk, hogy a fenti peldad igaz EP-re is: amit a Z80 lat pl a 0x3AE2 cimen, az lehet mindig mas, attol fugg, mi van oda "belapozva". Persze ismetelten: vigyazzunk ezzel a "lapozas" fogalommal, mert problema, hogy azert 386-oson ez nyilvan nem ugyanazt jelenti, mint EP-n (es persze tovabbi elteres, hogy 386-oson ez a CPU resze, EP-n pedig nem, a Z80 cimbusza 16 bites, csak epp a Dave "besegit" a hianyzo cimbusz bitek eloallitasaban).


Jah, win 2000 elotti dolgok azok vegulis DOS felett futo, protected mode "shell" voltakeppen nemi GUI-val Utana mar NT alapokon nyugvo rendszerrol van szo, amit erdendoen szerver OS-nek fejlesztettek, es maga a kernel nem is lenne rossz (pl VMS fejlesztok is reszt vettek benne). Csak epp annak amit tud, nagyon kis reszet hasznalja ki a windows-ban ami 'felette van' es kisse tonkrevagja a koncepciot ...


Nem kell elmagyarazni, irtam OS-t 386-osra mar, szoval tisztaban vagyok a mukodesevel Amit irtal, arrol irtam fentebb: egy lapot megjelolsz nem letezonek, ez ugy muxik. Amugy az most is gond akar pl Linux alatt is, ha 4Gbyte ram-od van, mert a cimtartomanyt fel kell osztani a kernel es a userspace kozott. Ilyenkor (vagy meg tobb ram eseten) jon a kepbe pl a PAE az ujabb x86-okon, ha mindenaron 32 bites rendszer kell, ami egy ujabb absztrakcios reteget jelent a cimlekepezesben valojaban.

 Természetesen nem volt olyan program, ami lefoglalt volna ilyen tetemes mennyiségû memóriát, így sosem volt kihasználva teljesen.


Vannak azert erdekes kerdesek minden OS eseten, pl memory overcommit stb, engedjunk-e tobb memoriat foglalni mint a fizikai rendelkezesre allo (hisz az valoszinu eleg durva swapolast - melleseleg szvop-nak kell ejteni, nem en irtam el, hehe) eredmenyezne kesobb.

Na bocsi, csak azert mentem bele ilyen reszleteseggel, mert ugy erzem, felreertettel, illetve osszemostad a "lapozas" fogalmat EP es 386 kozott. Remelem sikerult tisztazni, hogy mit is akartam mondani.

Az M1 az utasítások első byte-jának az olvasása közben (MREQ+M1), illetve megszakítás kérés elfogadásakor (IORQ+M1) aktív, a pontos időzítése megtalálható a Z80 dokumentációban. CBh, DDh, EDh, és FDh prefixes utasításoknál a prefix utáni utasítás byte olvasása közben is aktív az M1 (normál esetben, tehát ha nincs pl. több DDh prefix egymás után, legfeljebb 2 M1 memória művelet történik egy utasításban). Az ilyen típusú memória hozzáférésnek más az időzítése, és DRAM frissítést is végez. Ezt a fenti PDF file részletesen leírja.

Jelzi valami a Z80-nak, hogy fogadta/kitette az adatokat az adatbuszra?
 Csak azért kérdezem, mert ha késik a másik HW, akkor a Z80 rossz adatot olvas ki a memóriából, és kész a baj.

Imho egy orajelvezerelt digitalis rendszerben ez az idozitesen mulik (ez a szinkron - alias orajelvezerelt - megoldas, ha pedig kulon jel kell, hogy "kesz" az az aszinkron), es nem kell jelezni semmivel. Az mas kerdes, hogy esetleg egy lassu periferia alkalmazhat trukkoket pl "megallitja" a CPU-t egy idore, ha neki nem eleg a "normalisan jaro" ido, vagy hasonlo ...

Ezt csinálja a Dave, ha engedélyezve van neki.

Amúgy manapság már nem lehet olyan lassú cuccot kapni, amihez kéne