LPT-s 1541 emulátor

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ások

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

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

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.

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.

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.

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

É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