LPT-s 1541 emulátor

 ( TCH | 2017. május 20., szombat - 18:42 )

Elkészült az LPT-s 1541 emulátor, amin balagesszel már jóideje dolgozunk. A program az 1541-es emulációjának 100%-os pontosságára törekszik, nem IEC command emu, hanem ténylegesen emulálva van benne a 6502, a 6522-esek, a lemezvezérlés/mozgás és a soros kommunikáció.

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

XE van, tesztelném is, de semmilyen browserrel nem működik a "letöltés" link. Értelmes downloadot pls

danke.

SIGFPE (K6/2, slackware 11)

wat do?

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

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

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

thx 4 da support

Unfortunately ez is ua. Unstripped exe kéne, vagy adok accot.

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.

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

Dehát ezt mondtam én is. Ezért adtam az optimalizálatlan verziót is.

tenyleg :)

--
NetBSD - Simplicity is prerequisite for reliability

no 64-bit pls :)

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.

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.

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ú...

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.

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.

ez szerintem valami linux/gcc/glibc woe, egyébként athlon-on (k7) se jó

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.

én mindenben benne vok. de még ott van a csodás binutils is pl...
egyébként 2.4 kernel.

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.

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

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...

Na, ezt kipróbáljuk.

É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!?

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.

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

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

Miért, jobb úgy?