Kezdem kapizsgálni a PC-s világ Pentium nevû termékeit.

A következõ érdekességet találtam: Pentium 3 processzornál az adatbusz 64 bites. Az SD-RAM memóriafoglalaton 8 (vagy 16db) chip található. Egy órajelciklus alatt (mondjuk legyen a memória busz 133Mhz-es) ezzel a processzor 8Byte-ot képes kiolvasni a saját cache (gyorsító) memóriájába.

 Emiatt hiányzik is a címbusz alsó három bitje. Emiatt van az, hogy kivételt generál az, ha mondjuk egy utasítás nem 0h vagy 8h címen kezdõdik és nincs benne a gyorsítótárban, tehát a memóriából kell kiolvasni, mert akkor mind a 8 byte-ot ki kell hozzá olvasni. Emiatt a gépi kódú rutinokat optimalizálni kell, tehát ha lehet folytonos legyen az adatok elhelyezése. Ugráskor szintén be kell tartani a 0h vagy 8h-ra végzõdõ címet. Ezzel igaz, hogy memóriát lehet veszíteni, de jelentõs gyorsulást lehet tapasztalni.

 Arra gondoltam, hogy az EP 2.0-nál ezt a technikát, miszerint az adatbusz mondjuk 32 bites, alkalmazhatnánk, mert akkor a memóriaelérési idõ drasztikusan lecsökkenhetne, így a processzor sebessége növekedhetne.
 Még mindig fontosnak tartom a belsõ gyorsítótár (cache) létrehozását, hogy a perifériák közvetlen memóriahozzáférése jóvoltából tovább gyorsulna a rendszer.
 Képzeljetek csak el egy 32 bites regiszterekkel ellátott 400Mhz-es Z80 kompatibilis processzort, mely bonyolult matematikai mûveleteket is képes elvégezni a beépített matematikai processzorával...

"Kedvenc" peldam a C64DTV hasznal ki egy erdekesseget: ugye az egesz egy ASIC-ban van implementalva, SDRAM-ot hasznal (2Mbyte), memoriavezerlo minden ASIC-ban integralva, abbol mar RAS/CAS jel jon ki, stb (kulon "jon ki" a flash fele a cim, ha a keres arra vonatkozik). Ott ugy van pl, hogy "burst" uzemmodot ha engedelyezed (persze akkor innentol timing az nem C64 compatible erosen) akkor kihasznalja azt a feature-t, hogy 32 bitet olvas egyszerre (4 byte), es ha ebbe pl belefer tobb opcode, akkor nem is kell kulon byte-onkent olvasnia: gyorsabb. Sot, ha a skip-cycle uzemmodot engedelyezed, akkor egy orajel ciklus alatt elmleletben vegre tudja hajtani az osszes utasitast ami belefer abba a 4 byte-ba, felteve persze ha mas memoria I/O nem kell ehhez. Na persze az "egy orajel ciklus alatt" az kisse megteveszto ott, mivel az ASIC maga ott AFAIK 32MHz-en ketyeg, csupan ugye az "emulalt" CPU-ra jon ki a kb 1MHz "orajel" (mivel kozben mas is van, blitter/DMA, VIC-II/SID emulacio stb stb). Vegulis ez is "cache" (code cache) bar igen kicsi, 4 byte Viszont lehet a kodot optimalizalni, hogy pl 4 byte hatarra essen a cucc, stb.

István kilépésével a EP128 emulátor napjai meg vannak számlálva.

Az emulátor fejlesztését és karbantartását is befejezte amikor a fórumot itt hagyta?

Miért is, amikor nyílt forráskódú, platformfüggetlen? Azóta is többen fordították pl MAC-re, meg Rasberryre is.

Szerintem Tuby128 arra gondolt, hogy nem lesz senki akinek kedve, ideje lesz arra, hogy karbantartsa.

Gondolkodtam kicsit hogyan lehetne kicsit fejleszteni az EP-n.
 Nagyon szeretem a Basic nyelvet, mert ha elrontok valamit, akkor kapok egy hibaüzenetet és megáll a végrehajtás. Ilyenkor le lehet kérni a változókat, és megvizsgálni a hibát.
 Nagyon szeretem az Asmon programot, szeretek a memóriában turkálni, főleg a video lapokat változtatni, de sajnos vagy visszaír mindent az asmon, vagy pedig elszál a kép, és nem látok semmit.

 Kellene nekem egy virtuális tér, ahol megváltoztathatok mindent, és úgy is marad. A Nick 2.0 témában már írtam róla, hogy a beépített Nick és a Nick 2.0 tudnának egymás mellett élni, így akár 2 képernyőn megjeleníteni.
 
 Ami még nagyon kellemes lenne, ha a Z80 nem csak 16kB-os lapokkal dolgozna, hanem ennek többszörösével, hogy ne kelljen a lap határ miatt aggódni.

 Hogy ezeket a dolgokat egyszerre teljesíthessem, arra gondoltam, hogy a Z80 kapna egy társprocesszort a buszra saját memóriával. Így akkor az egyik Z80 (a fizikai EP) a fejlesztő környezetért felelne, a másik (FPGA EP) pedig a Nick 2.0-át szolgálná ki. Debug és breakpoint lehetőségekkel.
 Végzetes hiba esetén pedig visszaállítaná a kiindulási állapotot.