A Configure - Memory részben, ahol a szegmensekre lehet a romokat betenni, milyen configuration file-t lehet betölteni? Ha a configuration file melletti gombra kattintok, nincsenek olyan kiterjesztésű fájlok. Ha a kiterjesztést átállítom univerzálisra, akkor pedig nem tölthetők be a talált kiterjesztésűek.

Még egy Linux probléma, amit most vettem észre az előbbi hiba tesztelése közben: lenyomva tartott billentyűnél az ismétlés felváltva küld FL_KEYDOWN/FL_KEYUP eseményeket, Windowson viszont csak az FL_KEYDOWN ismétlődik, ami előnyösebb az emulátor számára. Bár az érintkezési hibás billentyűzet emulációja Linuxon akár "feature" is lehet. Nem tudom, ez az FLTK 1.1-ben is ilyen volt-e, mert nem emlékszem hogy régen ilyen probléma lett volna. Legalább most már tudom, miért akadozik a billentyűzet például a :FILE használatakor, már csak az a kérdés, hogyan lehetne javítani.

Találtam megoldást erre, az FLTK forráskódjából (src/Fl_x.cxx):
     // Stupid X sends fake key-up events when a repeating key is held
      // down, probably due to some back compatibility problem. Fortunately
      // we can detect this because the repeating KeyPress event is in
      // the queue, get it and execute it instead:

      // Bool XkbSetDetectableAutoRepeat ( display, detectable, supported_rtrn )
      // Display * display ;
      // Bool detectable ;
      // Bool * supported_rtrn ;
      // ...would be the easy way to correct this issue. Unfortunately, this call is also
      // broken on many Unix distros including Ubuntu and Solaris (as of Dec 2009)Az XkbSetDetectableAutoRepeat használata valóban javítja a billentyűismétlést, bár állítólag nem működik bizonyos disztribúciókon. De ha ez 7 évvel ezelőtt volt így, akkor talán nem nagy probléma. Esetleg csak akkor használnám, ha az FLTK nem túl régi verzió (pl. >= 1.3.2), ez remélhetőleg kiszűrné az elavult disztribúciókat is. Érdekes, hogy a kód további része az Fl_x.cxx-ben próbálja javítani a hibát más módon, de ez jelenleg nem működik, talán az X verziójától függhet?

Ez érdekes: (gúgli az ember barátja, na nem mindig ) Az nem lehet, hogy verziólemaradásom okozhat problémát ? Az FLTK 1.1.10-es pl

Egy újabb disztribúció valószínűleg nem ártana, a glibc 2.12 2010-es, a 2.15 pedig 2012-ben jelent meg. Bár a disztribúció frissítése sok munkával jár, csak az emulátor miatt nem érné meg.

A Configure - Memory részben, ahol a szegmensekre lehet a romokat betenni, milyen configuration file-t lehet betölteni? Ha a configuration file melletti gombra kattintok, nincsenek olyan kiterjesztésű fájlok. Ha a kiterjesztést átállítom univerzálisra, akkor pedig nem tölthetők be a talált kiterjesztésűek.

A memória konfigurációs file-ok használatára csak ritkán van szükség, "egzotikus" konfigurációk létrehozására, például az 576K-ra bővített EP64 "lyukas" RAM kiosztásának az emulálásához.

Elég régi disztró lehet.

UHU-2.2 glibc_2.11.2 2010.09.03
UHU-3 glibc_2.19 2014.07.09
UHU-UBK1 2.23 2016 10.17
És ezek mind 32 bitesek, talán lesz 64 bites is.

Olvasd el a readme.txt, 542. sorától kezdődően a "Memory configuration files" szakaszt. (Hiába, olvasott embernek nincs párja. )

Abszolút nem érdekel a véleményed, se az RTFM. Hogy finoman fejezzem ki magam. Ezzel a stílussal pont az ellenkezőjét éred el annak, amit szeretnél, mert még inkább meg fogom utálni az utánaolvasgatást.

Egyébként a File - Configuration menüben betölthető fájlokkal kevertem hirtelen össze ezt, és csodálkoztam, hogy nem működik, most jöttem rá.

Direkt takarja el a teljes képernyős emulátor a Windows tálcát? Nem tudom, az előző verzióban is így volt-e. Másik programra váltáshoz mindig vissza kell állítanom az emu méretét. Nem lehetne olyan módot is teljes képernyőn, ahol a tálca megmarad?

Biztos en benazom el, de most jutottam csak el addig, hogy kiprobaljam az ep128emu uj lehetosegeit (most SDext), es hat nem jutok vele sokra Most konkretan git-bol, mert az a tuti Az a baj, hogy SDext-el barmit probalok fekete kepernyot ad, es annyi. Eleve az sem vilagos, hogy a memoria szegmensek configjanal miert van kulon sd rom image, de aztan a 4-7 szegmensre is tolthetem. Probaltam mindenfele kombinaciot, de ugyanaz az eredmeny EXOS memteszt lefut, zold villanas, utana jon a fekete kepernyo marmint.
Mondjuk ami nem tudom mire jo, az a Machine configure-n belul az "Enable SD card". Mar csak azert sem vilagos, mert a File I/O "keretben" van, nem teljesen ertem, mi a ketto kozott az osszefugges. Ha azt kikapcsolom, megy az emu, de SD kartya sincs :-/ Hol rontom el az eletem? Persze disk confignal az sd image file be van allitva. Ami ROM image-t probalok, az az, amit a Xep128 is megeszik, EXDOS1.4/ISDOS (32K) + 16K filler (ide lehetne vmi) + 16K SDEXT 0.5 osszefuzve, hogy 64K-ra jojjon ki.

Ha a kész SD-s konfigot betöltöd, az nem jó?

Van olyan? Ilyesmit sose hasznaltam, mindig magam csinalom Lathatoan pont ez a baj, hehe.

Amúgy a külön ROM helyre kell betölteni egy SDEXT ROM-ot, ez azért külön mert meg van a lapozható rész is a 7-es szegmensen. Ezért ez így külön 64K ROM.
Ha SD engedélyezve van, akkor ez él a 7-es szegmensre, plusz az SD hardver, a fenti 7-es szegmens nem játszik.
ÉS ezen kívül kell egy EXDOS a normál részen.

Ja. hat az vili. Foleg, mivel mintha irtam volna SDext-et emulatorba, csak ugy tunik nagyon megszoktam a sajat cuccom De koszi, igy mar osszeraktam magamban a dolgot, es muxik is