EP128emu

[lgb]

Most vagy en nem ertem, vagy te - de inkabb en nem Mindenesetre nekem ez igy sehogy sem all ossze. Pont az a baj (nem csak Xep128-nal, pl Xemu-ban a C65 meg az M65 emulatorommal is) hogy barmi disk emunal nagyon durvan elszall a CPU hasznalat. Az oka az, hogy bar az emulalt CPU szempontjabol eltelt annyi orajelciklus amit igenybe vesz a kerdeses muvelet elkuldese a hw fele (ami ha opcode szintjen nezzuk, akkor maga az opcode vegrehajtasi ideje, ha viszont "sub opcode szinten" akkor kvazi nulla, mert ha a kerdeses opcode pl memoriat irna akkor is ugyanannyi lenne), ugyanakkor jelentos overhead van ehhez kepest, mivel van egy-ket libc/syscall is kozben. Viszont ugye az emulator idozitese azt szamolja, hogy hany emulalt orajelciklus telt el. Ha most mondjuk egy viszonylag szuk ciklusban csinalgat ilyeneket, akkor akar minden X.-edik opcode-nal is a PC jelentos hatranyban van az EP-hez kepest, mert ugye ott a szokasos hw emulaciohoz kepest meg ott az is, hogy file I/O-t is kell csinalnia. Na, a lenyeg az, hogy Xep128-ba es Xemu-ban tobb kulonbozo emulatoromban is ez komoly gond. Pl M65 emulator ezert nem is mukodik, mert az I/O total lefogja (3.5Mhz emulalt 65CE02 eseten ugy 30-40% SD-vel valo bizeralas, 10% ha nem, marmint a CPU hasznalat a futtato Linux-on - ha szendekosan lentebb viszem az emulalt CPU orajelet akkor kvazi alig lesz kulonbseg, mert tobb iro marad mindenre). Ha kikapcsolom akkor jo Ott valoszinu megis tobbszalas lesz, vagy valami emulalt busy-val lesz megoldva, hogy ne flood-olja ugymond az emulatort (igaz, az M65 gyorsabb mint az EP, szoval ez azert nem teljesen ugyanaz a tema).

Xep128/EP eseten amugy a dolog nem annyira veszes, de pl pont ep128emu kapcsan, amikor csinaltam a ganyolast, ott nagyon lefogta, amig fread()-et hasznaltam, toredekere esett a cpu fogyasztas, ahogy attertem a read()re ... Ha jol remlik windows verzio alatt (IGAZ, a windows verziot wine-al tudtam csak kiprobalni). Azert erdemes lenne megnezni, hogy valtozik az emulator CPU fogyasztasa intenziv image emulalt I/O eseten, ep128emu-t (a fenti halvany emleken kivul) nem neztem, Xep128 es Xemu eseten is eleg jelentos elteres van/volt.

A debug printf az nem emlekszem hol/mikor volt, es mikor nem de alapbol mintha nem lenne engedelyezve, de lehet, hogy tevedek (ha ugy felejtettem a DEBUG_SDEXT-et akkor tenyleg volt, de amikor neztem en, akkor persze kikapcsoltam, mert az tenyleg zavaro, foleg, ha kozben ugye szegeny gep CPU ideje arra megy el, hogy a kismillio printf output-jat a terminal ablakba szeeeeep fontokkal lerenderelje ...).

[Zozosoft]

Most kipróbáltam (i5-ös Lenovo X220), 10MHz-es EP, SymbOS 2 videó lejátszás egyszerre (ez ugye folyamatosan SD-t olvas, rakás LDI-vel), kb 2-3 CPU%, így lesz összesen kb 5-6

[IstvanV]

Most kipróbáltam (i5-ös Lenovo X220), 10MHz-es EP, SymbOS 2 videó lejátszás egyszerre (ez ugye folyamatosan SD-t olvas, rakás LDI-vel), kb 2-3 CPU%, így lesz összesen kb 5-6

A magas CPU fogyasztásnak nem is nagyon lenne értelme, a korábban említett tesztben egy 900 MB-os file olvasása kb. 1.8 millió puffereletlen 512 byte-os fread() hívással 2 másodperc volt, és ez egy 1.65 GHz-es AMD E450 laptop CPU-n. Tehát egy egész szektor beolvasása (a tényleges lemezműveletet nem számítva, mert a file-t már cache-elte a rendszer, de itt egyébként is csak a read()/fread() különbség a lényeges) átlagosan alig több mint 1 us, és erre természetesen csak minden 512. byte (512 * 16 / 10 = 819.2 us 10 MHz-es Z80 CPU-n 512 LDI utasítás) után van szükség.

Az Xep128 esetében valamilyen más probléma lehetett, talán a Wine vagy a már említett debug printf()-ek miatt (az biztosan lassítja az emulátort ha a lemezműveletek közben több ezer üzenetet kell kiírni a konzolra).

[lgb]

Az Xep128 esetében valamilyen más probléma lehetett, talán a Wine vagy a már említett debug printf()-ek miatt (az biztosan lassítja az emulátort ha a lemezműveletek közben több ezer üzenetet kell kiírni a konzolra).

Akkor passz, nekem akkor sem jon ossze, es ep128emu-val _SE_ mint jeleztem megjegyzem. debug dolgok persze, mint mondtam, ki voltak akkor kapcsolva.

Bar nem az alapproblema resze, de amugy van meg egy helyzet, amikor ez viszont tenyleg gond: nem feltelen igaz, hogy cache-elve van, es a rendszer nem vegez I/O muveletet amugy,a mikor akar emeberi idoben merve is eltarthato valameddig a muvelet, na ez viszont meg gazabb. Nekem a fenti anomaliakon kivul ez akkor gond, amikor pl sshfs-en at mount-olok egy filerendszert, es ugy lassu, de az amugy is lassu, ha csak siman shell-bol probalod machinalni. Normalisabb megoldasnal ilyenkor pl SD kartya emulacio siman busy-t ad vissza mint normalisan is, egeszen addig amig nem sikerul az I/O. Am mivel itt blocking I/O van, addig all az egesz emulator (ezt meg ugy ertem, hogy ugye akkor tenyleg az egesz, meg szabalyosan kilepni sem tudsz, meg semmi nem mukodik, ha pl behal eppen a halozat). Oke, lehet en vagyok tul paranoid, de ez velem neha megesik, mert altalaban sshfs-en at tolok dolgokat

[lgb]

De amugy megnyugtattal, hogy te sem szofisztikaltad agyon ep128emu-ban ezek szerint az image kezelest, hanem ott is "inline" (vagy hogy mondjam) blocking I/O van szepen, semmi egyeb. Ha jol ertem. Azert en pl SD kartya sebesseget csak megneznem egyszer, hogy valojaban milyen gyors Az biztos, hogy az SPI busz sebessege az SD cartridge-n ugy van megvalasztva, hogy elvileg Z80-al nem tudod "megelozni" (azt hiszem ezt egyszer szamoltam/neztem, talan meg turbo-s gepen sincs gond, bar 12MHz kornyeken ilyen POP/PUSH jellegu trukkel mar lehet gond, de ez nem is a fenti problema ugye, hanem mas jellegu). A masik resze, hogy milyen gyorsan valaszol adattal pl egy block read-re, azert lenne lenyeges, mert van ahol ez fontos, pl az SD audio playeremnel ez nagyon nem mindegy, igy lehet mas eredmeny egy valodi gepen es egy emulatorban ... Xep128-ban mindig egy $FF jon az $FE data token elott mint mondtam, ezt mondjuk le lehetne tesztelni, hogy a valosagban mennyi (bar ez nyilvan fugg kartya tipustol, sot meg lehet az adott block helyzetetol is, hogy flash-en hol van, mittomen' nem igazan ertek a flash technikahoz melyebben, hogy uniform-e az access time). Linear olvasasnal biztos nem lesz lassu foleg egy EP-nek de random hozzaferesnel erdekes lehet.

[IstvanV]

Írható SD kártya:
[ Guests cannot view attachments ]

[lgb]

Írható SD kártya:
(Attachment Link)

Ebben mennyire tertel el az en kodomtol? Neztem, elsore most tul faradt vagyok hogy a melyere nezzek, de erdekel amugy

[lgb]

Kozben a Xep128 github-os repo-ba felnyomtam ezeket, amit itt is kuldtem C forras, mert eddig csak local-ban volt meg ...................

[Zozosoft]

Jól veszem észre, hogy az SD hardver akkor kapcsol be, ha a secondary slave-be be van rakva a VHD, egyébként normál szegmens a 7-es?
Szerintem végleges verzióba kéne a Machine configuration-ba egy opció, hogy Enable SD interface emulation, amihez tartozna konfig fájl bejegyzés, ahogy a virtual fileIO-hoz is. A lemez kiválasztón meg vagy lenne külön fülecske az SD-hez, vagy a secondary két vinyó válthatna át két SD-vé.

Magánál az emulációnál még a kártyaméret kiszámolás hiányzik, ami elvileg az Lgb féle friss forrásban már benne van.

[lgb]

Jól veszem észre, hogy az SD hardver akkor kapcsol be, ha a secondary slave-be be van rakva a VHD, egyébként normál szegmens a 7-es?

Ez Xep128-ban ugy van, hogy megnezi milyen rom van ott, ha EXOS_ROM es SDEXT kifejezest megtalalja a szegmensen akkor "feltetelezi" hogy SDEXT ROM van ott es engedelyezi. Ez nem tudom mennyire jo megoldas mondjuk

Magánál az emulációnál még a kártyaméret kiszámolás hiányzik, ami elvileg az Lgb féle friss forrásban már benne van.

Ami elvileg mar xep128 github-on is van amugy. Max ott tele van pakolva figyelemezteto ablakokkal ugye az image meret "noveles" miatt ha nem jonne ki "SD-compatible" meretre.

[IstvanV]

Jól veszem észre, hogy az SD hardver akkor kapcsol be, ha a secondary slave-be be van rakva a VHD, egyébként normál szegmens a 7-es?

Ezt a GitHub-on már módosítottam, most egyelőre nem konfigurálható a grafikus felületen, ezért szöveges formátumú konfigurációs file-t kell betölteni (Alt+Q), illetve ugyanezek megadhatók a parancssorban is:

Code: [Select]

sdext.imageFile "C:\\Program Files\\ep128emu2\\sdcard.img"
sdext.romFile "C:\\Program Files\\ep128emu2\\sdcard1.rom"
sdext.enabled Yes
memory.rom.04.file "C:\\Program Files\\ep128emu2\\sdcard0.rom"
memory.rom.04.offset 0
memory.rom.05.file "C:\\Program Files\\ep128emu2\\sdcard0.rom"
memory.rom.05.offset 16384
memory.rom.06.file "C:\\Program Files\\ep128emu2\\sdcard0.rom"
memory.rom.06.offset 32768
memory.rom.07.file "C:\\Program Files\\ep128emu2\\sdcard0.rom"
memory.rom.07.offset 49152Ezen kívül már emulált a 64K flash ROM, és írható is, de csak a lapozható része, a 04-06h szegmensen normál ROM található. A ROM írás használhatóságát még nem tudtam tesztelni, tehát nem biztos, hogy működik. A flash ROM emuláció hátránya, hogy már nem használja a 07h szegmenst, és ez a ROM nem kerül snapshotba, illetve jelenleg a 7K SRAM sem.
[ Guests cannot view attachments ]
[ Guests cannot view attachments ]

Magánál az emulációnál még a kártyaméret kiszámolás hiányzik, ami elvileg az Lgb féle friss forrásban már benne van.

A VHD támogatás és az image méret számítása/ellenőrzése már a forráskódban van, a tegnap fordított verizóban is megtalálható (ha nem hibás).

Újdonság lesz még a tömörített formátumú snapshotok (illetve demo és egyéb ep128emu fejlécű bináris file) támogatása, ilyenek egyelőre csak az epcompress segítségével készíthetők, az emulátor csak tölteni tudja ezeket:
epcompress -1 snapshot.ep128s snapshot.ep128s                       (lassú)
epcompress -raw -9 -maxoffs 262144 snapshot.ep128s snapshot.ep128s  (max. tömörítés, nagyon lassú)
Ha később beépítem a mentést is, akkor az valószínűleg egyszerűbb, kevésbé hatékonyan tömörítő, és lényegesen gyorsabb kódot használna.

[IstvanV]

A fent említett változtatásokon kívül a debuggerben az SD kártya I/O területének az olvasása nem zavarja az adatátvitelt (azaz egy memory dump nem számít LDI utasításoknak ), és az egyébként csak írható regiszterek is olvashatók.
[ Guests cannot view attachments ]

Tömörített snapshot/demo file-ra példa, az eredeti itt található:
[ Guests cannot view attachments ]

Ebben mennyire tertel el az en kodomtol? Neztem, elsore most tul faradt vagyok hogy a melyere nezzek, de erdekel amugy

Lényeges eltérés nincsen az írás működésében, az esetleges új bugoktól eltekintve.

[lgb]

Lényeges eltérés nincsen az írás működésében, az esetleges új bugoktól eltekintve.

az irassal amugy ovatosan, elvileg ez "testing" fazisban volt nalam is csak ...

[lgb]

Nem tartozik szorosan a temahoz, de:

http://c65.lgb.hu/web-xemu/xc65.html

Ez az Xemu project-embol a Commodore 65 emulator, "webes" verzioja. Ellentetben az jsep-vel, ez nativ C kod, csak az emscripten nevu forditoval kvazi le van forditva javascript-re (az jsep az "kezzel" irt javascript kod volt). Ezt elvileg meg lehetne tenni persze az Xep128-al is (es akkor kvazi jsep-szeruseg lesz belole ...). Sot, elvileg az ep128emu-val is, azert irtam ebbe a topic-ba Csak ugye a gond azzal az, hogy az emscripten kepes SDL2-t "emulalni", de az ep128emu nem igazan azt hasznal (bar amugy emscripten GL-t is tud valahogy a SDL2-n at, ahogy nativan is tud ilyet az SDL2, amikoris WebGL lesz belole valahogy a forditas soran).

[Zozosoft]

az irassal amugy ovatosan, elvileg ez "testing" fazisban volt nalam is csak ...

Szedjem elő a pszeudo véletlenszámos írástesztelőmet, amivel anno az igazi SD tesztelésénél kibukott az EXDOS bug?