Enterprise Forever
:HUN => Programozás => Assembly => Topic started by: lgb on 2021.January.30. 12:50:29
-
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 ;)
-
Nekem úgy rémlik, hogy a videó RAM írása/olvasása olyan 3,5 MHz-es sebességnek felel meg, ha a kód nem ott fut,
Ha a videó memóriában fut a kód, nagyon változó, szerintem a 2,5 MHz alá is mehet.
Ha a kód a videó memóriában fut, akkor szerintem a BF port állítása mit sem jelent, azt nem tudom ,hogy Videó RAM írás/olvasásnál jelent-e valamit.
-
Kreáltam egy hiánypótló programot :D :D :D
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
[attach=1]
Eléggé siralmas látni, hogy az EP64-en milyen iszonyatos sebességgel száguldoznak a programok :D :D
-
Én ebből csak annyit értek, hogy POP, az is a zenei stílus miatt érthetőbb.
Annyira lassúak EP64-en a programok? Nem sokat próbáltam, csak tudom, hogy pl. a Catacomb pont arra lett írva. A programok nagy részénél érezhető a sebességkülönbség?
-
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)
-
Video RAM-nak mi számít? Szigorúan az FCh-FFh szegmensek, vagy csak azok a szegmensek/tárterület, amit az LPT alapján a Nick tényleg elér? Tehát pl. az FCh szegmensen akkor is lassabban fut a program, ha ott egyáltalán nincs video adat?
-
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.
-
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.
-
Kreáltam egy hiánypótló programot :D :D :D
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
(Attachment Link)
Eléggé siralmas látni, hogy az EP64-en milyen iszonyatos sebességgel száguldoznak a programok :D :D
durván belassul! :shock:
hülye kérdés: ZX speccin futhat vram-ban kód? értem, h szemét lesz a képernyőn, de van-e valami korlát, hogy a PC oda mutasson?
-
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
-
hülye kérdés: ZX speccin futhat vram-ban kód? értem, h szemét lesz a képernyőn, de van-e valami korlát, hogy a PC oda mutasson?
Egyrészt nincs ilyen korlát, anno egyes másoló programok ki is használták ezt, hogy maximális szabad memóriájuk legyen.
Amúgy meg az 5B00-7FFFh rész is a VRAM-ban fut, érvényes rá az ULA hozzáférés miatti lassulás.
128-as Spectrumon pedig nem csak a másik videószegmensre, hanem még két másik szegmensre is érvényes ez. Ráadásul a különböző 128-as típusoknál eltérő, hogy melyik ez a másik két lassú szegmens.
-
Az RV oszlop mit mutat?
-
az RV oszlop mutatja azt, ha az utasitas a normal RAM-ban fut, de az adatot a video RAM-bol veszi/ oda irja.
-
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?
-
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?
Én úgy tudom, hogy ha már a kód a VRAM-ban fut, akkor már mind1, hogy az adatot honnan kapja. A RAM-ban futó, VRAM-ot elérőt mutatja az RV oszlop.
-
Arra az esetre gondoltam, amikor két byte-os az opkód. A VVR mintázat nem lehet, hogy el fog térni az RRV-től?
-
Na ezt nem értem, az op kód mind a két darabja ugyanúgy ugyanabban a RAM-ban van.
-
Nyilván. Csak hipotetikusan az egyik esetben két memória hozzáférésnél lesz nyújtva az órajel ciklus, míg fordítva meg egynél. VVR = két nyújtott meg egy sima, RRV = két sima meg egy nyújtott.
-
bit x,(hl) pl 2 op kódos, az add a,(hl) 1, meg lehet nézni a táblázatban, hogy mi a stájsz (emulátoron :D )
-
Mondjuk az ilyen "fixen ennyi órajel" becsléseknek túl sok értelme nincsen :oops:
Valóságban a 14.2375362676056338 MHz-es Nick (IstvánV számolta ki: 4433618.75 / 568 * 2 * 57 * 16 ), és a 4/6/10 MHz-es Z80 aktuális viszonyát kell kiszámolni, fél órajel pontossággal (ugye az utasítás olvasás fél órajellel rövidebb mint a normál RAM művelet).
A Nick fix időzítéssel adja a hozzáférési ablakokat, amit vagy ki tud használni a Z80, vagy vár, és addig szünetel az órajele, amely szünet aztán Nick órajelekben számolható ki.
Errefelé (https://enterpriseforever.com/kijelzo/nick/msg32717/#msg32717) raktam be szkópos méréseket, amin látszik, pl, hogy NOP (vagy más azonos ideig tartó utasítás) esetén 4MHz-en nem is tudja az összes hozzáférési ablakot kihasználni a Z80, míg 6MHz-en már igen.
Bonyolultabb kódoknál is sokat számíthat az utasítások sorrendje, IstvánV már sokszor tett javaslatokat különböző program kódokhoz, hogyha fel van cserélve pár utasítás, akkor gyorsabb lesz, mivel jobban elkapja a Nick hozzáférési ablakokat.
Turbosítással sem biztos, hogy lineárisan változik a program sebessége, ha ugyanannyi vagy nem sokkal több ablakot tud elkapni a kód, akkor nem gyorsul nagyon, míg olyan proci sebességnél ahol már mondjuk kétszer annyi ablakot kap el, akkor hirtelen meglódul a program.
-
Errefelé (https://enterpriseforever.com/kijelzo/nick/msg32717/#msg32717) raktam be szkópos méréseket
Ha minden igaz, ilyenről loptam a profilképem egy részét.
-
Mondjuk az ilyen "fixen ennyi órajel" becsléseknek túl sok értelme nincsen :oops:
Valóságban a 14.2375362676056338 MHz-es Nick (IstvánV számolta ki: 4433618.75 / 568 * 2 * 57 * 16 ), és a 4/6/10 MHz-es Z80 aktuális viszonyát kell kiszámolni, fél órajel pontossággal (ugye az utasítás olvasás fél órajellel rövidebb mint a normál RAM művelet).
A Nick fix időzítéssel adja a hozzáférési ablakokat, amit vagy ki tud használni a Z80, vagy vár, és addig szünetel az órajele, amely szünet aztán Nick órajelekben számolható ki.
Errefelé (https://enterpriseforever.com/kijelzo/nick/msg32717/#msg32717) raktam be szkópos méréseket, amin látszik, pl, hogy NOP (vagy más azonos ideig tartó utasítás) esetén 4MHz-en nem is tudja az összes hozzáférési ablakot kihasználni a Z80, míg 6MHz-en már igen.
Bonyolultabb kódoknál is sokat számíthat az utasítások sorrendje, IstvánV már sokszor tett javaslatokat különböző program kódokhoz, hogyha fel van cserélve pár utasítás, akkor gyorsabb lesz, mivel jobban elkapja a Nick hozzáférési ablakokat.
Turbosítással sem biztos, hogy lineárisan változik a program sebessége, ha ugyanannyi vagy nem sokkal több ablakot tud elkapni a kód, akkor nem gyorsul nagyon, míg olyan proci sebességnél ahol már mondjuk kétszer annyi ablakot kap el, akkor hirtelen meglódul a program.
Jogos, erről megfeledkeztem