Na, ha mar igy belemelegedtem a forumozasba Egy kerdes. Nyilvan nem pontosan erdekelne. De, van valakinek hozzavetoleges szamadata, hogy "atlagosan" (oke, tudom fugg attol hogy milyen Z80 opcode-ok futnak stb stb) mennyivel lassabb az EP a standard 4Mhz + nem video RAM esethez kepest, ha:

* rengeteg video RAM iras/olvasas (nem video RAM iras/olvasas helyett), hogy a kod nem video RAM-ban van amugy
* ugyanaz, de ha a kod is video RAM-ban van
* BF port allitgatasa milyen hatassal van (vagy van-e?) a nem video RAM-os esetre, ha nem ott fut kod
* BF port allitgatasa milyen hatassal van, ha a fenti masodik eset van (minden a video RAM-ban van, kod is)

Ha valakit erdekel, azert kerdezem, mert lusta vagyok tesztelni De az erdekelne, hogy kb le lehet-e menni arra a szinte, hogy atlagosan legalab kb! 2.5MHz-es Z80-nak megfelelo sebesseget adjon ki. Oke, nem pontosan, meg tudom, mint irtam, fugg attol hogy epp mit csinal a kod. Csak ugy nagy atagban.

Sajna, az pl ki is ment a fejembol, hogy a BF portnak mintha nem lenne hatasa a videoram-ra egyaltalan amugy, de mar nem vagyok biztos

Gondolom, aki a 2.5MHz-en meglatta, talan van otlete, hogy miert pont az kene nekem

Kreáltam egy hiánypótló programot
Kiírja, hogy bizonyos utasítások normál RAM-ban futva, és ha olvasnak adatot, akkor onnan olvasva, RAM-ból futba, VRAM adatolvasás, és VRAM-ban futva, onnan olvasva milyen sebességgel hajtódnak végre.
A program 8MHz-ig működik, 9-cel már elment fagyizni
[ Guests cannot view attachments ]
Eléggé siralmas látni, hogy az EP64-en milyen iszonyatos sebességgel száguldoznak a programok

sajnos annyival lassabbak, eddig az volt a tippem, hogy az ep64-en a video ram kesleltetes miatt olyan, mintha 2,5 MHz-en futnanak, de ebbol a tablazatbol az jon le, hogy a helyzet rosszabb, kozelit a 2MHz-hez, igaz, csak emulatoron futtattam, de nem hinnem, hogy nagy lenne az elteres a vashoz kepest.
Amugy a szamok azt jelentik, hogy az adott utasitas hany T-state alatt hajtodik vegre, tehat egy 7 T-state-es utasitasbol 1 masodperc alatt 571428 hajthato vegre. Az RR oszlop jelzi, hogy egy sima 4 MHz-es EP-n milyen sebesseggel hajtodik vegre az utasitas (RR - normal RAM-ban fut a kod, es onnan is veszi az adatot, ha vesz) , a VV oszlop jelzi, hogy ugyanaz az utasitas hogy szaguld EP64-en. (VV - Video RAM-ban fut a kod, es az adat is onnan szarmazik)

Mindig, minden körülmények között az FCh-FFh szegmensek. Őrült komplexitást várnál el szegény NICK-től, hogy olyanokat tudjon. Nem biztos, hogy akár a mai processzorok is képesek erre, pedig azoknak barokkosan komplex virtuális memória alrendszerük van.

Akkor ezt jó fejben tartani, ha kell a sebesség.
Nagyobb komplexivitást nem várok, csak kíváncsi voltam, hogy azért lassú-e az a terület, mert ketten olvassák a procival, vagy egyszerűen az a négy szegmens mindig lassabb. Ha jól tudom, a Nick mind a 64K-t meg tudja címezni függetlenül attól, melyik szegmensek vannak belapozva, de csak azt a tartalmat olvassa ténylegesen, amit az LPT-ben megadunk neki.

Azért lassú, mert a NICK-nek és a Z80-nak is hozzá kell férnie, és a NICK-é az elsőbbség, plusz aszinkron a Z80 buszához. A NICK csak és kizárólag azt a négy szegmensnyi memóriát képes olvasni. Hogy ténylegesen mit olvas az értelmezés kérdése, mert ennek a memóriának a frissítését is a NICK végzi legjobb tudomásom szerint. Aztán persze tévedhetek is.

Siman tehetsz a Speccy Vramba is kodot, sot az attributumokkal ki is takarhatod, de az ott levo kodra is jon a bunti, gyanusan nem akkora, mint EP-n

Az RV oszlop mit mutat?

Pusztán teoretikus kérdés: lehet-e különbség a VRAM-ban futó és bővítő RAM-ot elérő, illetve a bővítő RAM-ban futó és VRAM-ot elérő azonos utasítások végrehajtási ideje között?