Enterprise Forever
:HUN => Emulátorok => Topic started by: Zozosoft on 2008.July.26. 23:53:52
-
Elõszedtem a régi órajelmérõ programomat, és egy picit kibõvítettem, hogy részletesebb infót adjon.
A program lényege, hogy egy ciklusban számlál, azon ideig amíg a Nick megjeleníti a képernyõ egy részét. Mivel a Nick órajele fix, így a ciklus lefutásának számából ki lehet számolni a Z80 órajelét.
Ha a különbözõ memóriavárakozásokat engedélyezzük (191-es port), akkor látszik is a lassulás a kiszámított órajelekben.
A jelen verzió a 191-es port mind a hat féle beállítása mellett kijelzi az értékeket: a ciklus lefutásának számát, ill. az ebbõl számolt órajelet.
Itt vannak az eredmények, 4, 6 ill. 7.12 Mhz-es valódi gépen futtattva, ep128emu alatt, és EP32 alatt (itt 7.12 nincs, mert nem beállítható tört érték).
Ami kiderült: a "nincs várakozás" ill. "1 órajel várakozás minden utasításnál" üzemmódban ugyanazt hozza a két emu. A "1 órajel várakozás minden memóriahozzáférésnél" módot az EP32 nem emulálja.
"nincs várakozás" módban minden frekvencián picit lassabbak az emuk mint az igazi gép.
"1 órajel várakozás minden utasításnál" módban 4 Mhz-en picit lassabbak, viszont nagyobb órajelen jelentõsen gyorsabbak az igazinál!
"1 órajel várakozás minden memóriahozzáférésnél" módban az ep128emu 4 Mhz-en jó, nagyobb órajelen gyorsabb.
[attachthumb=1][attachthumb=2][attachthumb=3]
[attachthumb=4][attachthumb=5][attachthumb=6]
[attachthumb=7][attachthumb=8]
-
Ez tök izgi! :-) (EDC -t is rá kellene venni, hogy kicsit "hozza fel" az EP32-t... :-) ) Igen tanulságos képek!
-
"1 órajel várakozás minden utasításnál" módban 4 Mhz-en picit lassabbak, viszont nagyobb órajelen jelentõsen gyorsabbak az igazinál!
Feltételezem, hogy azért, mert a nagyobb órajel csak a Z80-ra érvényes, viszont a várakozásokat a DAVE generálja, amely ilyenkor kisebb frekvencián működik a Z80-hoz képest, és így a várakozások átlagosan hosszabbak 1 Z80 ciklusnál (az eredetileg 18 ciklus alatt végrehajtott INC HL/JR NC mindkét nagyobb órajelnél 22 illetve 24 ciklus lesz a várakozásokat engedélyezve, ami arra utalhat, hogy a várakozás egyszerűen felfelé kerekítődik 2 Z80 ciklusra, de ezt érdemes lenne más ciklussal is tesztelni). Ezt az emulátorok nem veszik figyelembe (ill. az ep128emu csak a video memória esetén).
Egyébként még az eredeti 4 MHz-es gép időzítését sem olyan egyszerű emulálni :) Érdemes lenne a tesztet lefuttatni más utasításokkal a ciklusban (pl. CB/DD/ED/FD prefixes utasításokkal is), I/O port művelettel (a NICK portoknál más az időzítés), és a video memóriában is különböző utasításokkal.
A kis eltéréseket (pl. 3.99 MHz 4 MHz helyett) az okozhatja, hogy a NICK frekvenciája nem pontosan annyi a Z80-hoz képest, mint amit az emulátorok feltételeznek; például az én gépemen ha a Z80 pontosan 4 MHz lenne, akkor a sorfrekvencia kb. 890100/57 Hz, és nem 890625/57 Hz, ami az ep128emu alapértelmezett beállítása (de ez megváltoztatható a konfigurációban).
-
Elöször is egy kis javítás: végig olvastam mégegyszer Tigrian Nick leírását, amiböl kiderül, hogy amikor a Nick órajelét használjuk rendszerórajelnek, akkor egész pontosan 7.125 Mhz lesz a Z80, csak mi nem mértünk ennyi tizedesre.
Ha ezt az értéket állítjuk be az ep128emu-ban, akkor a várakozás nélküli esetben megegyezik a visszakapott HL értéke a valódi gépen mérttel.
[attachthumb=1]
-
Feltételezem, hogy azért, mert a nagyobb órajel csak a Z80-ra érvényes, viszont a várakozásokat a DAVE generálja, amely ilyenkor kisebb frekvencián mûködik a Z80-hoz képest
Ajaj, itt akkor most találtunk egy nagy emulációs bakit!
A DAVE a rendszerórajellel mûködik (ennek a fele jut a Z80-nak), így amikor turbósítjuk a gépet, gyorsul a DAVE is, ami jól érzékelhetõ abból, hogy a generált hangok magasabbak lesznek! Na ez az amit az emulátorok nem tudnak!
Eleve készülhettek arra, hogy 6 Mhz-es gépet is kiadjanak, mivel beépítettek egy kapcsoló bitet a DAVE-be, amivel megadható, hogy 8 vagy 12 Mhz a rendszerórajel, így biztosítva a helyes hangfrekvenciát. Ez a bit mûködik is az emulátorokban, csak éppen a Dave nem gyorsul hozzá turbós konfigban.
Mint a programból kiderült, ennek a bitnek nincs hatása a Z80 várakozásokra, ezért megegyezik az elsõ három eredménysor a második hárommal.
És azért kell gyorsulnia a DAVE-nek, mert különben az A14-A21 címvezetékek nem mûködnének szinkronban a közvetlenül a Z80-ból jövõ A0-A13-al!
viszont a várakozásokat a DAVE generálja
Mivel ez még nem volt teljesen egyértelmû, végeztem egy kisérletet, ahol kikötöttem a Z80 összes olyan lábát, ahol le lehet fékezni :-)
[attachthumb=1]
A Videó RAM várakozások így is mûködnek, a kapcsolási rajzot megnézve egy megoldás maradt: a rendszerórajelet a Nick felezi meg a Z80 számára, és amikor éppen összevesznének a videómemórián, akkor szünetelteti a Z80 órajelét.
Viszont az egyéb beállítható várakozások így nem mûködnek, mint további kisérletezéssel kiderült, azok rendesen a WAIT lábat használva készülnek (Hopp itt akkor felmerül egy újabb turbó gomb lehetõsége :-) ). Ezeket tényleg a Dave készíti...
...de a hogyan az még rejtély. Én azt gondoltam volna, hogy egyszerüen 2 rendszerórajel ciklus és kész...
mindkét nagyobb órajelnél 22 illetve 24 ciklus lesz a várakozásokat engedélyezve, ami arra utalhat, hogy a várakozás egyszerûen felfelé kerekítõdik 2 Z80 ciklusra
Ami érdekes anomália, hiszen azt már tudjuk, hogy turbóval a Dave is gyorsul.
Lehet, hogy nem a rendszerórajelet használja? De miféle egyéb idõzítõt építettek belé?
Esetleg van a kapcsolási rajzon valami kondenzátoros cucc a Davere kötve, aminek nem tudni a szerepét, mivel nem tudni, hogy azok a lábak mit csinálnak...
Kieg: de nem, annak a kondinak zajszûréshez van köze, ha kiszedem, iszonyatosan zajos lesz a hang, ellenben a várakozások nem változnak :-)
-
Ajaj, itt akkor most találtunk egy nagy emulációs bakit!
A DAVE a rendszerórajellel mûködik (ennek a fele jut a Z80-nak), így amikor turbósítjuk a gépet, gyorsul a DAVE is, ami jól érzékelhetõ abból, hogy a generált hangok magasabbak lesznek! Na ez az amit az emulátorok nem tudnak!
A magasabb hang és időzítő frekvenciát valójában tudja emulálni az ep128emu, csak nem automatikusan, hanem a "Sound clock frequency"-t külön be kell állítani, 6 MHz-es Z80 esetén 750000-re, 7.125 MHz-nél pedig 890625-re (ami azonos a "Video clock frequency" értékével). Amit nem tud az az, hogy a várakozás ne csak 1 ciklus lehessen, mint a 4 MHz-es eredeti gépen, hanem 2 vagy esetleg több is.
A Videó RAM várakozások így is mûködnek, a kapcsolási rajzot megnézve egy megoldás maradt: a rendszerórajelet a Nick felezi meg a Z80 számára, és amikor éppen összevesznének a videómemórián, akkor szünetelteti a Z80 órajelét.
Ezt még érdemes lenne tesztelni, hogy a video memória várakozások mennyire pontosak az emulátorban különböző órajeleket használva.
-
A magasabb hang és idõzítõ frekvenciát valójában tudja emulálni az ep128emu, csak nem automatikusan, hanem a "Sound clock frequency"-t külön be kell állítani, 6 MHz-es Z80 esetén 750000-re, 7.125 MHz-nél pedig 890625-re (ami azonos a "Video clock frequency" értékével).
A következõ verzióban lehetne, hogyha átírjuk a Z80 frekit, akkor automatikusan álljon át a sound freki is? Végülis az igazin nem is lehet külön állítani.
a video memória várakozások mennyire pontosak az emulátorban különbözõ órajeleket használva.
Változatlan program, 64K módban futattva, azaz videómemóriában.
Van némi eltérés...
[attachthumb=1][attachthumb=2]
[attachthumb=3][attachthumb=4]
[attachthumb=5][attachthumb=6]
-
A kis eltéréseket (pl. 3.99 MHz 4 MHz helyett) az okozhatja, hogy a NICK frekvenciája nem pontosan annyi a Z80-hoz képest, mint amit az emulátorok feltételeznek; például az én gépemen ha a Z80 pontosan 4 MHz lenne
Bennem is felmerült, hogy esetleg az alkatrészek szórása miatt van eltérés, de több gépen nézve is azonosak az eredmények.
A 4 Mhz most kb 5 gépen volt nézve, a 6 és a 7.125 pedig 2-2 gépen. És korábban le is volt közölve az órajelmérõ program az Enterpressben, és senki nem panaszkodott, hogy nem kerek 4 Mhz jön ki neki :-)
Szóval lehet, hogy van eltérés ahhoz képest amit feltételezünk, de az minden gépben úgyanúgy ott van.
akkor a sorfrekvencia kb. 890100/57 Hz, és nem 890625/57 Hz, ami az ep128emu alapértelmezett beállítása (de ez megváltoztatható a konfigurációban)
Ha átírom kb 890450-re, akkor jó lesz a 4 és 6 Mhz-es várakozás nélküli érték, ekkor viszont 7123600 értéket kell használni 7125000 helyett harmadik sebességnek, hogy jó legyen.
Igazából kéne valaki, aki oszcilloszkóppal megmérné, hogy mennyi az annyi? Tigrian, hol vagy? :-)
-
A következõ verzióban lehetne, hogyha átírjuk a Z80 frekit, akkor automatikusan álljon át a sound freki is? Végülis az igazin nem is lehet külön állítani.
Ez megoldható, bár annak is van előnye, ha nem változik automatikusan, például egy 64 MHz-es Z80-at beállítva talán célszerűbb, ha nem lesz 4 oktávval magasabb a hang, még ha ez az eredeti gépen nem is így lenne (eltekintve attól, hogy ilyen nagy órajellel nem is működne a hardver :)).
Változatlan program, 64K módban futattva, azaz videómemóriában.
Van némi eltérés...
Ami nem túl meglepő, ugyanis a pontos emulációhoz az is fontos lenne, hogy a memória műveletek az utasításon belül melyik ciklusokban történnek, mivel a várakozás mértéke nem fix, hanem attól függ, hogy egy 890 kHz-es cikluson belül mikor próbál a memóriához hozzáférni a Z80. Bár az ep128emu ezt is emulálja valamennyire, de nem igazán pontosan, és rövid ciklusoknál nagy eltérés is lehet; nagyobb programrészeknél (pl. BASIC utasítások végrehajtása közben) az átlagos sebesség már pontosabb.
-
nagyobb programrészeknél (pl. BASIC utasítások végrehajtása közben) az átlagos sebesség már pontosabb.
Most csináltam egy BASIC tesztet:
10 PRINT TIME$
20 FOR I=1 to 2000
30 A=SQR(I)
40 NEXT
50 PRINT TIME$
60 PING
Az igazi gépen órakártya volt így turbóban is pontos az óra, ROM bõvítõk: ZT 1.8, EXDOS 1.3, BASIC 2.1, epemu alatt ugyanez. Epemunál turbó frekvenciáknál beállítottam a DAVE-t is megfelelõ sebességre.
Az elsõ idõ mindig a valódi gépen mért, a második az emus. Nyilván nem 100%-ig pontos mérés, de az jól látszik, hol vannak nagyobb eltérések.
A normál, minden utasításnál 1 várakozás mód:
4 Mhz: 5:53, 5:58
6 Mhz: 4:06, 3:35
7.125 Mhz: 3:22, 2:56
Nincs várakozás mód:
4 Mhz: 5:02, 5:01
6 Mhz: 3:07, 3:06
7.125 Mhz: 2:35, 2:34
Minden memóriamûveletnél várakozás:
4 Mhz: 6:32, 6:30
6 Mhz: 4:51, 3:57
7.125 Mhz: 3:58, 3:17
Video RAM (64K) mód:
4 Mhz: 7:04, 6:58
6 Mhz: 5:11, 4:40
7.125 Mhz: 4:41, 3:53
-
A normál, minden utasításnál 1 várakozás mód:
4 Mhz: 5:53, 5:58
6 Mhz: 4:06, 3:35
7.125 Mhz: 3:22, 2:56
Nincs várakozás mód:
4 Mhz: 5:02, 5:01
6 Mhz: 3:07, 3:06
7.125 Mhz: 2:35, 2:34
Ezek megfelelnek a korábbi tesztek alapján várható eredménynek, az eltérést az okozza, hogy az emulátor nem 2, hanem csak 1 ciklust vár a nagyobb frekvenciákon, bár a legelső sorban az 5:58/5:53 kevésbé érthető. Egyébként ugyanezt a programot futtatva (emulátoron) nekem lassabb volt, talán mert nem pontosan ugyanaz volt a konfiguráció.
Video RAM (64K) mód:
4 Mhz: 7:04, 6:58
6 Mhz: 5:11, 4:40
7.125 Mhz: 4:41, 3:53
Itt meglepő, hogy az emulátoron a sebesség gyakorlatilag lineárisan nő az órajellel, pedig nagyobb frekvencián elvileg átlagosan többet kéne várakozni, mert a NICK órajele nem változik. Lehet, hogy ez egy bug az emulátorban ?
-
nekem lassabb volt, talán mert nem pontosan ugyanaz volt a konfiguráció.
Igen azt én is tapasztaltam, ha több bõvítõ is van a rendszerben, akkor lassabb pár másodperccel, ezért a Zozotools RL NEW utasítással mindent likvidáltam ami nem feltétlenül szükséges (ZT az órakártya kezelés miatt maradt).
-
Ha átírom kb 890450-re, akkor jó lesz a 4 és 6 Mhz-es várakozás nélküli érték, ekkor viszont 7123600 értéket kell használni 7125000 helyett harmadik sebességnek, hogy jó legyen.
Igazából kéne valaki, aki oszcilloszkóppal megmérné, hogy mennyi az annyi? Tigrian, hol vagy? :-)
Ezzel kapcsolatban itt egy egyszerű teszt program:
[attachurl=#]
Ha a villogó csík nem mozdul el hosszabb idő után sem, akkor a feltételezett frekvencia pontos. Ha felfelé mozog, akkor a várakozást növelni kell, ha lefelé, akkor pedig csökkenteni.
-
Ha a villogó csík nem mozdul el hosszabb idõ után sem, akkor a feltételezett frekvencia pontos.
És a feltett program milyen frekvenciát feltételez? Mert nekem mindig fut a csík.
-
És a feltett program milyen frekvenciát feltételez? Mert nekem mindig fut a csík.
Ha igazi gépen nézted, és gyorsan fut, akkor úgy látszik, nem jó frekvenciát tételezett fel :oops: Mindenesetre az én gépemen a második program kb. pontos. Érdekes lenne megnézni néhány gépen, hogy mennyi üres ciklussal lesz stabil, bár ha nagy eltérések vannak, akkor talán nincs is igazán jelentősége :)
Kisebb fórum probléma: miért az "ep128emu 2.0.6" topicba kerülök vissza innen a hozzászólások elküldése után ? :eek:
-
ZT órát ki kell kapcsolni :oops: akkor egész jó, de érdekes, hogy nem egyforma minden gép.
Az enyémen a 2-es egész jó, az egyes lassan megy lefelé. Kurczu gépén a 2-es megy lefele, 1-es gyorsabban.
-
ZT órát ki kell kapcsolni :oops:
Ez igaz, már említettem, hogy a ZozoTools órája 313 sorra növeli az LPT méretét (bug ?), a teszt programok pedig az eredeti 312 sort tételezik fel :oops:
akkor egész jó, de érdekes, hogy nem egyforma minden gép.
Az enyémen a 2-es egész jó, az egyes lassan megy lefelé. Kurczu gépén a 2-es megy lefele, 1-es gyorsabban.
Tehát mindkét gépen a NICK a Z80-hoz képest valamivel gyorsabb a számítottnál. Olyan gép nincs, ahol az 1-es program felfelé fut :?:
-
Tehát mindkét gépen a NICK a Z80-hoz képest valamivel gyorsabb a számítottnál.
Akkor ez lehet az oka a korábban felvetett problémának? Mivel gondolom az emulátor az elméleti sebességgel futtatja a Nick-et.
Olyan gép nincs, ahol az 1-es program felfelé fut :?:
Megnéztem egy rakás gépet, de ilyet nem találtam! Az elöbb említett variációk fordulnak elõ, ill. egy gépen (az arab EP128) volt az, hogy az 1-es nagyon lassan futott lefelé, a 2-es pedig nagyon-nagyon-nagyon lassan felfelé (kb 20 másodperc alatt egy sor).
-
Akkor ez lehet az oka a korábban felvetett problémának? Mivel gondolom az emulátor az elméleti sebességgel futtatja a Nick-et.
Nem, az emulátorban eddig 890625 Hz volt az alapértelmezett beállítás (mert 890625 / 57 = 15625, azaz a szabványos PAL sorfrekvencia), viszont az első tesztprogram 889846 Hz-re, a második pedig 890042 Hz-re van beállítva.
Az itt (http://www.ep128.hu/Ep_Hardware/Pic/EP64-3.jpg) található kapcsolási rajz alsó részén látható áramkör állítja elő a Nick órajelét. A Nick "H/2" kimenetén a ~14 MHz-es órajel (14M) 1824-ed (= 16 * 57 * 2) része jelenik meg, a "PAL" bemenetre pedig az LM1889-ről 4433619 Hz frekvenciájú jel kerül. A "H2REF"-en pedig a "PAL" valamilyen mértékben leosztva jelenik meg. A "H/2" és a "H2REF" az U32-n keresztül vezérli a TR4/L2/C29 oszcillátort, és a két frekvenciának meg kell egyeznie.
Tehát ha jól értelmeztem a kapcsolási rajzot, akkor a "14M" órajel az pontosan 4433619 * 1824 / N Hz, de N még nem ismert :) Az első program szerint 568, mert ez az az egész szám, amely a legpontosabb eredményt adja. A második programban N=567.875 (az EP-n mért sebességből számított 567.87 1/8-ra kerekítve). Természetesen a 8 MHz és a 4.433619 MHz valójában nem egészen pontos, ezért szóródás van az egyes gépek között, és így továbbra is csak találgatni lehet :) :oops:
-
A "H/2" és a "H2REF" az U32-n keresztül vezérli a TR4/L2/C29 oszcillátort, és a két frekvenciának meg kell egyeznie.
Ráadásul az L2 még állítható is, ami nem tudom mit befolyásol a dologban...
-
Ráadásul az L2 még állítható is, ami nem tudom mit befolyásol a dologban...
Talán csak annyit, hogy az oszcillátor csak kis frekvencia tartományban tud működni, és egyébként az L2/C29 szórása miatt az áramkör (amely gyakorlatilag egy PLL) esetleg nem tudna beállni a pontos frekvenciára.
A "PAL" és a "H2REF" pontos arányát meg lehet állapítani olyan "turbós" géppel is, amely a Z80/DAVE órajelét a 8 MHz helyett 4.43 MHz-ből állítja elő (feltéve, hogy az alacsony frekvencia nem okoz valamilyen problémát), bár akkora jelentősége talán nincs ennek a kérdésnek, hogy ezért érdemes legyen gépet átalakítani :)
-
A "PAL" és a "H2REF" pontos arányát meg lehet állapítani olyan "turbós" géppel is, amely a Z80/DAVE órajelét a 8 MHz helyett 4.43 MHz-bõl állítja elõ (feltéve, hogy az alacsony frekvencia nem okoz valamilyen problémát), bár akkora jelentõsége talán nincs ennek a kérdésnek, hogy ezért érdemes legyen gépet átalakítani :)
Csak egy forrasztás kipróbálni :-) szerintem floppyt nem fog tudni majd így olvasni, mint ahogy a 16Mhz-en járó WD-hez is kevés a 4 Mhz Z80 (6Mhz-en megy ha a várakozási ciklusok le vannak tilva, vagy 7.12Mhz)
Akkor már csak egy aránymegállapító progi kéne :oops:
-
Csak egy forrasztás kipróbálni :-) szerintem floppyt nem fog tudni majd így olvasni, mint ahogy a 16Mhz-en járó WD-hez is kevés a 4 Mhz Z80 (6Mhz-en megy ha a várakozási ciklusok le vannak tilva, vagy 7.12Mhz)
Akkor már csak egy aránymegállapító progi kéne :oops:
Ez egyszerűen megoldható a fenti teszt program módosításával. Az üres ciklust és a NOP utasításokat be kell állítani, hogy a csík ne mozogjon, és akkor a ciklusok számából pontosan meghatározható az órajel.
-
Tesztprogramok 2.217 MHz-es Z80-hoz:
[attachurl=#]
[attachurl=#]
313 soros LPT-hez:
[attachurl=#]
[attachurl=#]
-
Mûködik! (Persze, ahogy várható volt, floppyt nem olvas.) Tulajdonképpen nem is rossz ötlet ez az anti turbo, pl a Tombs of Doom játszhatóságát határozottan javítja :ds_icon_cheesygrin:
A teszteredmény: az 1-es verzió masszívan áll, a 2-essel pedig lassan fut felfelé.
-
A teszteredmény: az 1-es verzió masszívan áll, a 2-essel pedig lassan fut felfelé.
Akkor ez alapján úgy látszik, mégis az első tippem volt helyes, azaz a PAL frekvencia pontosan 568-al van osztva, és a Nick "ideális" órajele (17734475 / 4 / 568) * (2 * 57 * 16) Hz, és ennek megfelelően az emulátor "Video clock frequency" beállításának 889846-nak kell lennie 890625 helyett. Meglepő viszont, hogy ennek ellenére 4 MHz-es Z80 frekvenciánál már a 890042-t feltételező tesztprogram működik jobban a gépek többségén; talán az alkatrészek több gépen hasonló mértékben pontatlanok (pl. mert ugyanabból a sorozatból vannak), vagy más oka lehet ?
Mindenesetre köszönöm a segítséget :)
-
talán az alkatrészek több gépen hasonló mértékben pontatlanok (pl. mert ugyanabból a sorozatból vannak)
Talán ha a gépek sorozatszáma mellé tesszük az eredményeket, ez kiderülhet. Gondolom legalábbis, bár ki tudja, lehet, hogy az egymáshoz közel esõ sorozatszámú gépekben nem ugyanabból a sorozatból vannak az alaktrészek... Bár minek tárolnának egy alkatrészt a polcon, hogy késõbb használják fel? :D
-
Video RAM (64K) mód:
4 Mhz: 7:04, 6:58
6 Mhz: 5:11, 4:40
7.125 Mhz: 4:41, 3:53
Itt a nagy eltéréseket elsősorban az okozta, hogy a várakozás turbós gépeken 1 helyett 2 ciklus, és így a BASIC interpreter - amely nem a video RAM-ban, hanem ROM-ban van - nem a megfelelő sebességgel futott. Azonban már sikerült megvalósítani a 2 ciklus várakozást (amely 5000000 Hz-nél magasabb Z80 frekvenciánál automatikusan bekapcsol - az igazi gépen nem tudom, hogy pontosan milyen határ felett vált 1-ről 2 ciklusra a DAVE :?:), tehát a 2.0.7 verzió pontosabb lesz. :)
A video RAM időzítésén is sikerült javítani; itt azonban most azt feltételezem, hogy a NICK nem csak 4 MHz-es, hanem 8 MHz ciklussal is tudja késleltetni a Z80 órajelét, azaz gyakorlatilag fél ciklus felbontással. Ezt nem tudom ellenőrizni, hogy valóban így van-e, mindenesetre a tesztprogramok pontosabb eredményt adnak. Még azt kell beállítani, hogy az egyes utasításokon belül pontosan mikor történnek a memória hozzáférések, és az időzítés remélhetőleg jobb lesz, mint a régebbi verziókban. Viszont a korábban felvett demo file-okat valószínűleg nem lehet majd megfelelően lejátszani :oops:
Az OJ.BAS (http://enterpriseforever.com/emulatorok/idozitesi_problemak_az_emulatorokban-t380.0.html;msg10174#msg10174) 64K-s konfigurációval futtatva és 889846 Hz video frekvenciát beállítva HL=1366 (néha 1367) eredményt ad 4 MHz Z80 órajelnél, és HL=1641-et 6 MHz-nél a módosított emulátorral (összehasonlításképpen az igazi gépen és régi emulátoron mért értékek itt (http://enterpriseforever.com/emulatorok/idozitesi_problemak_az_emulatorokban-t380.0.html;msg10183#msg10183) találhatók).
-
tehát a 2.0.7 verzió pontosabb lesz. :)
Ez jól hangzik!
-
HL=1366 (néha 1367) eredményt ad 4 MHz Z80 órajelnél, és HL=1641-et 6 MHz-nél a módosított emulátorral
A 7.12 MHz viszont nem jó, és a BASIC program sem pontos egyelőre. :(
Készítettem egy új tesztprogramot a video RAM időzítésének a tesztelésére:
[attachurl=#]
Ez egy a beépített joystick használatával változtatható ciklusban végez egy video RAM hozzáférést (így az utasításon belüli időzítés nem befolyásolja az eredményt), és kiírja a várakozás nélküli és a tényleges időtartamot Z80 ciklusokban. A mért érték stabilizálódására várni kell néhány másodpercet. A program módosítható memória írás, M1 olvasás, és NICK I/O port művelet tesztelésére is, bár nagy eltérések nincsenek: az írás időzítésében nincs változás, az M1 valamivel (max. 1-2 tized ciklus) gyorsabb, az I/O pedig szintén kis mértékben lassabb.
Eerdmények igazi gépen és emulátoron (4000000/889846/500000 Hz):
EP ep128emu ep128emu
2.0.7 2.0.6
-----------------------------
46: 49.44 49.45 49.45
47: 49.44 49.45 49.45
48: 49.44 49.46 50.31
49: 53.93 53.94 53.94
50: 53.93 53.94 53.94
51: 53.93 53.94 53.94
52: 53.93 53.94 53.94
53: 58.25 58.44 55.55
54: 58.43 58.44 58.44
55: 58.43 58.44 58.44
56: 58.43 58.44 58.44
57: 58.45 58.50 59.08
58: 62.92 62.93 62.93
59: 62.92 62.93 62.93
60: 62.92 62.93 62.93
61: 62.92 62.93 62.93
62: 67.34 67.43 64.60
63: 67.41 67.43 67.43
64: 67.42 67.43 67.43
65: 67.42 67.43 67.43
66: 67.50 67.60 68.59
67: 71.91 71.92 71.92
68: 71.91 71.92 71.92
69: 71.91 71.92 71.92
70: 71.91 71.93 71.93
71: 76.37 76.42 73.67
72: 76.40 76.42 76.42
73: 76.40 76.42 76.42
74: 76.40 76.42 76.42
75: 76.58 76.92 77.18
76: 80.89 80.91 80.91
77: 80.89 80.91 80.91
78: 80.89 80.91 80.91
79: 80.90 80.91 80.91
Érdemes lenne ezeket megnézni turbós gépeken is.
-
Érdekes, hogy a 4Mhz-en is van némi eltérés, gondolom a gépek szórása miatt.
Eddig egy gépet néztem, ott
53: 58.30-1
62: 67.36
63: 67.42
66: 67.49
71: 76.38-9
75: 76.54
76,77,78: 80.90
-
És megnéztem egy turbó és egy anti-turbó eredményt is:
4Mhz 2.217Mhz 6Mhz
-----------------------------
46: 49.44 47.33 53.74
47: 49.44 49.52-3 53.74
48: 49.44 49.83 53.74-5
49: 53.93 49.83 53.95
50: 53.93 52.32 53.95
51: 53.93 52.32 53.95
52: 53.93 54.65-6 55.55
53: 58.30-1 54.81 60.68-9
54: 58.43 54.81 60.68-9
55: 58.43 57.30 60.69
56: 58.43 57.30 60.69
57: 58.45 59.71-2 60.69
58: 62.92 59.79 60.69
59: 62.92 59.80 66.51-3
60: 62.92 62.28 67.43
61: 62.92 62.28 67.43
62: 67.36 64.76 67.43
63: 67.42 64.77 67.43
64: 67.42 64.84-5 67.43
65: 67.42 67.26 67.43
66: 67.50 67.26-7 74.17
67: 71.91 69.75-6 74.17
68: 71.91 69.76 74.17
69: 71.91 70.00-9 74.17
70: 71.91 72.25 74.18
71: 76.38-9 72.25 74.18
72: 76.40 74.74 74.18-9
73: 76.40 74.74 80.91
74: 76.40 74.92 80.91
75: 76.54 77.23 80.91
76: 80.90 77.23 80.91-2
77: 80.90 79.72 80.92
78: 80.90 79.72 80.92
79: 80.90 80.03 83.33
-
Érdekes, hogy a 4Mhz-en is van némi eltérés, gondolom a gépek szórása miatt.
Eddig egy gépet néztem, ott
53: 58.30-1
62: 67.36
63: 67.42
66: 67.49
71: 76.38-9
75: 76.54
76,77,78: 80.90
Ezek nagyon kis eltérések, csak századokkal különböznek attól, amit én mértem. Valójában még ugyanazon a gépen is változhat ilyen mértékben az eredmény pl. melegedés hatására. Az emulátornál jóval nagyobb a különbség, tehát még lenne mit javítani :oops:, de legalább jobb, mint a korábbi verziók.
-
És megnéztem egy turbó és egy anti-turbó eredményt is:
Ez hasznos információ :smt023 Érdekes lesz megnézni, hogyan változik az időzítés az órajellel, és remélhetőleg az emulátort is sikerül jobban beállítani.
-
Megnéztem egy kétturbós gépet is, itt viszont eltérõ értékek jöttek ki 6Mhz-re, is, sõt 4Mhz-en is minden eltér.
Tippem szerint az R12 ellenállás rövidrezárása okozhatta ezt, az valami idõzítést állíthat a Nicknél, ha nem bírja a turbót a videóram, akkor kell rövidrezárni. Emlékeim szerint 7.12-es gépekben mindenben így lett, de több 6-osnál is kellett alkalmazni.
4Mhz 6Mhz 7.12Mhz
-----------------------------
46: 49.42 53.91 56.00
47: 49.42 53.91 56.00
48: 49.51 53.91 56.00
49: 53.92 53.91 56.00
50: 53.92 53.91 56.00
51: 53.92 56.49 56.00
52: 53.92 60.65 56.00
53: 58.41 60.65 64.00
54: 58.41 60.65 64.00
55: 58.41 60.65 64.00
56: 58.41 60.65 64.00
57: 58.61 60.65 64.00
58: 62.90 60.65 64.00
59: 62.90 67.30 64.00
60: 62.90 67.38 64.00
61: 62.90 67.39 64.00
62: 67.39 67.30 71.99
63: 67.39 67.30 71.99
64: 67.39 67.30 72.00
65: 67.40 67.30 72.01
66: 67.70 74.12-3 72.00-1
67: 71.89 74.12-3 72.01
68: 71.89 74.13 72.01
69: 71.89 74.13 72.01
70: 71.89 74.13 80.00
71: 76.38 74.13 80.00
72: 76.38 74.39 80.00
73: 76.39 80.86-7 80.00
74: 76.39 80.87 80.00
75: 76.92 80.87 80.00
76: 80.88 80.87 80.00
77: 80.88 80.87 80.00
78: 80.88 80.87 87.99-88.00
79: 80.88 84.72 87.99-88.00
-
Érdemes lenne összehasonlítani az új beta verziót igazi géppel különböző órajeleken, például BASIC programot futtatva video memóriában, de más teszteket is meg lehetne nézni (OJ.BAS, stb.).
-
Valószínűleg már nem aktuális, de itt van még egy sebesség tesztelő program:
[attachurl=#]
Ez egy konvertált kép kicsomagolásának az idejét méri képkockákban (1/50s). 128K-s gépen (EXOS 2.1 + BASIC) alapértelmezett memória várakozással (OUT 191, 4), illetve az EP64.COM (http://enterpriseforever.com/hardver/ep64-t148.0.html;msg14582#msg14582) futtatása után ez lett az eredmény - az első az igazi gép:
EP128 2.0.7 2.0.7 2.0.7 2.0.6 2.0.6 2.0.6
4 MHz 4 MHz 6 MHz 7 MHz 4 MHz 6 MHz 7 MHz
128K 305 305 231 195 305 203 171
64K 514 514 324 324 529 319 315
-
128K-s gépen (EXOS 2.1 + BASIC)
Ha EXDOS is van, az baj?
-
Ha EXDOS is van, az baj?
Szerintem nem, mert letiltja a megszakításokat, illetve saját megszakítást használ. Azok a ZozoTools verziók jelenthetnek kisebb problémát, amelyek megváltoztatják az LPT hosszát. De ez a program lehet, hogy túl egyszerű, mert 6 és 7.12 MHz-es módban is ugyanannyi a futásidő 64K memóriával (legalábbis ha jó az emulátor) :)
-
4/6/7.12
128: 305, 227, 195
64: 514, 324, 320
-
4/6/7.12
128: 305, 227, 195
Meglepő, hogy a 6 MHz és a 7.12 MHz között nem lineáris a gyorsulás (6 * 227 / 195 ~= 6.985, de 6 * 231 / 195 ~= 7.108). :shock: Elvileg a normál RAM hozzáféréseken kívül csak 5000-6000 video port és nagyon kevés video memória művelet történik, de az nem elég a 4 képkocka eltéréshez.