Sajnos az ISA bus access latency miatt a fastloaderek nem nagyon fognak működni, mert a közel 1 us-os késleltetés miatt az időzítés rövid távon szétcsúszik. A handshake-s, illetve nem annyira időzítéskritikus loaderek működnek rajta.
Az időzítés így is kritikus; úgy van leprogramozva, hogy minél több port-access-t megspóroljunk: a CPU 0. fázisában olvassa a portot és csak a CTL regiszter változásakor írja. Ennek megfelelően kettő darab kompenzáló késleltetés van beleépítve: a port-access helyetti várakozás, illetve a cikluson belüli általános. Ezeket mindenkinek magának kell belőnie, mert a gép sebességétől függ, hogy mennyi idő marad szabadon a port hozzáférés, illetve a másik időzabáló - a getchar()
- mellett.
A program XE1541-es kábelt használ. Egyelőre csak Linux/x86-os verziók vannak, de ha igény van rá, akkor leforgathatom más UNIX-ra/processzorra is.
Update: A ROM-ot a home könyvtárba kell bemásolni ".e1541.rom" néven. A ROM file 16k-s kell, hogy legyen ($C000-$FFFF), tehát ha valakinek két db 8k-s image-ben van, akkor össze kell őket fűzni.
Update #2: Az időzítés pontosságának kiíratásakor volt egy apróbb bug, ami csak a 32-bites verziót érintette: a 64-bites eltérést %d-vel írattam ki, aminek köszönhetően a 32-bites paraméterek a printf()
-ben elcsúsztak. Ezt javítottam.
Letölthető itt:
Linux AMD64
Linux i386
Illetve, ha nem megy a letöltés, akkor itt:
http://oscomp.hu/depot/e1541-linux-amd64.zip
http://oscomp.hu/depot/e1541-linux-i386.zip
Várjuk a bugreportokat, ill. az ötleteket, hogy hogy lehetne életre lehelni a fastloadereket.
- TCH blogja
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
XE van, tesztelném is, de semmilyen browserrel nem működik a "letöltés" link. Értelmes downloadot pls
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
danke.
SIGFPE (K6/2, slackware 11)
wat do?
- A hozzászóláshoz be kell jelentkezni
Bitte.
Érdekes. Float művelet egyetlen egy helyen található az egész programban, ahol a timer pontosságát számolja: 1000000.0 van elosztva az 1000000 ciklus alatt eltelt idővel, viszont azt nem értem, hogy egymillió ciklus alatt hogy lehetne nulla az eltelt idő...
Próbáld meg ezt, ebben beraktam egy if
-et, hogy 0.0 esetén ne ossza el. Ha így már működik, akkor az időmérő valamiért nem jól működik nálad.
http://oscomp.hu/depot/e1541-test
- A hozzászóláshoz be kell jelentkezni
Fogtam és kihajítottam az egész számítgatós mókát, így egyáltalán nincs float a programban. Most nem azt írja ki, hogy hány ciklus egy usec, hanem azt írja ki, hogy 1 millió ciklus hány usec-ig tartott (megspóroltam az osztást); ezt kell úgy beszabályozni, hogy minél jobban megközelítse az egymilliót.
Itt a float-mentesített tesztverzió:
http://oscomp.hu/depot/e1541-nofloattest
- A hozzászóláshoz be kell jelentkezni
Float-mentesített és ROM elérés javított binárisok itt:
http://oscomp.hu/depot/e1541-linux-amd64.zip
http://oscomp.hu/depot/e1541-linux-i386.zip
- A hozzászóláshoz be kell jelentkezni
thx 4 da support
Unfortunately ez is ua. Unstripped exe kéne, vagy adok accot.
- A hozzászóláshoz be kell jelentkezni
Never mind.
Hát itt egy unstripped exe, de nem értem, hogy a strippelés hogy csinálhat SIGFPE-t. Pláne, hogy miért ad egy float-mentes program SIGFPE-t. Milyen accot? SSH accot a géphez?
http://oscomp.hu/depot/e1541-unstripped
Meg ki tudod próbálni ezt is?
http://oscomp.hu/depot/e1541-unstripped-noo
Ezen az optimalizációt is kikapcsoltam, hogy hátha beleforgat valami olyan utasítást a GCC, ami K6-on még nincs.
- A hozzászóláshoz be kell jelentkezni
gondolom erdekli, hogy pontosan honann jon az exception, valoszinuleg a forditod general bele valami olyan muveletet, amit nem tud a k6-2
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
Dehát ezt mondtam én is. Ezért adtam az optimalizálatlan verziót is.
- A hozzászóláshoz be kell jelentkezni
tenyleg :)
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
no 64-bit pls :)
- A hozzászóláshoz be kell jelentkezni
Tessék, 32-bites binárisok. Az első -O3
, unstripped, a második optimalizálatlan unstripped.
http://oscomp.hu/depot/e1541-32-unstripped
http://oscomp.hu/depot/e1541-32-unstripped-noo
Mondjuk nem tudom, hogy hogy fog menni nálad a K6-on, még ha el is indul, mert a két port access és a getchar()
(azaz kemény 3 sor) megzabálja a futásidő 95%-át, az emunak alig marad ideje futni még az én 2.4-es Athlonomon, meg a 3.5 GHz-es Piledriveremen is. Gondolom a te géped 450 MHz-es.
- A hozzászóláshoz be kell jelentkezni
nem látok a trace-ben symbolokat most se, -g opcióval lett fordítva?
450, de amúgy 1541emu 100-200mhz környékén már jól emulálja az 1541-et (DOS), linuxon inkább a non-realtime időzítéssel lesznek problémák várhatóan.
- A hozzászóláshoz be kell jelentkezni
Hopsz, de hülye vagyok. Csak nem strippeltem le a binárisokat, de a -g
kapcsoló elmaradt, sorry. Itt vannak újból:
http://oscomp.hu/depot/e1541-32-unstripped
http://oscomp.hu/depot/e1541-32-unstripped-noo
Igen, az időzítéssel. Azzal szenvedtem a legtöbbet. Kísérleteztem pl. azzal is, amit az 1541emu fejlesztői írtak, de hiába lockoltam a process-t, a 0. magra, meg hiába lockoltam az órajelet is, az RDTSC
majdhogynem random értékeket adott. (Nyilván nem random értékek voltak, de nem sikerült vele tick delayt mérni...) A többi mag letiltása sem segített. Kínomban már át akartam írni az egészet assemblyre (bár, akkor később írhatom újra az egészet, ha PPC-re, vagy Sparcra akarom portolni), de letettem róla, mert a mérések szerint az emu maga alig eszik valamit; 1 ciklus alatt valami pár tíz nanosec-et, így kb. semmit nem nyertem volna vele, viszont bukom a hordozhatóságot.
De, ha azt nézem, amit az 1541emu fejlesztői írtak, hogy multitaskos oprendszeren ezt kb. nem lehet megcsinálni, akkor már annak is örülök, hogy legalább annyit sikerült elérni, hogy egy gyorsabb gépen megy... Csak a fastloadereket sajnálom, dehát rövid távon egyszerűen képtelenség az 1 ciklus / 1 us-es időzítés, így a szinkronfutásos fastloaderek elpusztulnak.
Mondjuk még nem próbáltam, de a Jiffyvel elméletileg lehet gyorsítani, lévén ez nem protokoll emulátor, mint az Amigás, vagy DOS-os emuk többsége, így elvileg mennie kéne a Jiffynek is.
Viszont az 1541emu valami speciális kábelt használ, azt írják az X1541 kábelek túl lassúak volnának, lehet nekem is ezt a kábelt kéne használni, noha nem jött le a kapcsolási rajzból, hogy mitől lenne gyorsabb a type0, mint az XE1541, hiszen maga az ISA buszon ülő LPT port a lassú...
- A hozzászóláshoz be kell jelentkezni
nah így is üres, úgyhogy (még mindig) kapja be a linux, ennyi.
1541EMU amúgy elműködget (amikor sikerül elektronikailag megfelelő hardvert rakni alá), plus/4-es fastloaderekkel jól elvan (Borrowed Time-oztam vele), 64-es demoktól többnyire hanyattesik, gyakran programhiba miatt segfaulttal. mondjuk ulrich drepper is a készítői között van, szóval jó már nem lehet... a retro replay cartridge veszett gyors fastloadere érdekes módon tökéletesen megy vele.
- A hozzászóláshoz be kell jelentkezni
Az unoptimized verzió sem megy? Nem ír ki semmit, creditset se? Ha legalább azt lehetne tudni, hogy meddig jut el; nekem itt sajnos nincs K6-osom, nem tudom kipróbálni.
Demok szerintem ezen se nagyon fognak menni a fastloader miatt. Most pl. kipróbáltam az Artilleryt a Shape-től, de csak addig jutott el, hogy a zenét betöltse. (Az emulátor nem crashelt el, csak a kapcsolat szétesett.)
RR lehet, hogy nem szinkronfutásos fastloader, hanem valami mást csinál, így emulátorbarát.
- A hozzászóláshoz be kell jelentkezni
ez szerintem valami linux/gcc/glibc woe, egyébként athlon-on (k7) se jó
- A hozzászóláshoz be kell jelentkezni
Hát passzolom. Az első utasítás az printf()
, szóval, ha az sem fut le, akkor valami már a startup kódban sem jó; de nem értem, hogy minek pakol a GCC float utasításokat egy floatmentes program kódjába. Megpróbáljuk CLanggal? Az is fennt van.
- A hozzászóláshoz be kell jelentkezni
én mindenben benne vok. de még ott van a csodás binutils is pl...
egyébként 2.4 kernel.
- A hozzászóláshoz be kell jelentkezni
Oké, akkor itt van a két bináris CLanggal lefordítva. -g
kapcsolóval.
http://oscomp.hu/depot/e1541-32-unstripped
http://oscomp.hu/depot/e1541-32-unstripped-noo
Nálam 3.16-os kernel van, de nem tudom ez mennyire játszik közre.
- A hozzászóláshoz be kell jelentkezni
Lehet valami libc elteres. 2.4-es kernel alatt valami eszmeletlen regi glibc lehet, mert az ujabbaknak mar legalabb 2.6-os kernel kell, es emlekszem, hogy volt valami gebax glibc valtaskor, ha nem teljesen statikra forditottad a kodot volt egy verzio valtas, ami utan nem mukodtek a dinamikus ELF binarisok ha regebbi glibc-hez lettek forditva. De valamit (hibakiirast, coredumpot, barmit) kellene csinaljon, ez teny.
--
Blog | @hron84
Üzemeltető macik
- A hozzászóláshoz be kell jelentkezni
Ha a libc API tér el, akkor valami egyéb crashnek (hiányzó függvény, eltérő paraméterezés, etc.) kéne történnie, nem pedig SIGFPE-nek; az nem igazán API divergenciára vall...
- A hozzászóláshoz be kell jelentkezni
Na, ezt kipróbáljuk.
- A hozzászóláshoz be kell jelentkezni
Ép nincs kézközelben a C64-em, sem a drivom, de kifogom próbálni. Már nagyon kellet egy ilyen emu! :)
De nyugtass meg, hogy ehhez nem kell valami ezer éves gép LPT portal és megy egy modern PC-n is PCI-os LPT kártyával!?
- A hozzászóláshoz be kell jelentkezni
Megy modern gépen is. (Bár mi számít modernnek?) Én egy 2012-es AMD-s gépen fejlesztettem le PCIe-es LPT kártyával. (Először egy 2.4 GHz-es Athlon volt benne, most meg egy 3.5 GHz-es Piledriver van.)
A régi gépeken inkább necces, mert a getchar()
és a port access rengeteg időt megzabál, így az emunak alig marad idő. Nem tudom mekkora a minimum, amin már menni fog; nálam ment.
- A hozzászóláshoz be kell jelentkezni
Sajnos arról teljesen megfeledkeztem, hogy a ROM elérése be volt drótozva a futási könyvtár alatt "1541/dos15412.rom" néven. (A fejlesztés a home könyvtárból ment, de nyilván, ha valaki telepíti, akkor mindig be kéne lépni abba a könyvtárba, ahol a ROM van.)
Ezt most gyorsan javítottam; az új javított programokat feltettem a helyükre. Ebben már az a floattalanítás is benne van, amit Gabucinonak csináltam.
A ROM-ot ~/.e1541.rom útvonalon kell elhelyezni és a teljes 16k-s kép kell, tehát, ha valakinek két db 8k-sban van meg, akkor join.
http://oscomp.hu/depot/e1541-linux-amd64.zip
http://oscomp.hu/depot/e1541-linux-i386.zip
- A hozzászóláshoz be kell jelentkezni
Tipp: esetleg erdemes lehetne betartani az XDG ajanlasokat, es a ROM-ot a ~/.local/share/e1541/e1541.rom utvonalon is megnezni, akar beegetve is.
--
Blog | @hron84
Üzemeltető macik
- A hozzászóláshoz be kell jelentkezni
Miért, jobb úgy?
- A hozzászóláshoz be kell jelentkezni