Ha német EP-n nöttél volna fel, akkor nem zavarna a magyar kiosztás sem
Amúgy én, ahogy megtaláltam az első ékezetes karaktereket, már igyekeztem használni őket. Késöbb PC-n ALT+számos módszerrel, amíg el nem terjedt a magyar kiosztás.

En sose De mint irtam ez maganvelemeny Marmint ettol persze nem mondom, hogy "hulye" aki normalisan ir, valojaban en vagyok a "hulye" ha szigoruan nezzuk Dehat ez van.

Ami viszont ezzel nincs osszefuggesben, az az, hogy nem azert nem megy webes Xep128-ban mert szandekosan teszek azokra, akik mas kiosztast hasznalnanak hanem a fent leirt dolgok miatt Sajna ugy tunik a sok retegen valahol elcsuszik a dolog ... :-/

Ez egyébként szerintem azért hülyeség (mármint, hogy emiatt egyesek utáják a Chrome-ot), merthogy ugyebár a RAM az egy erőforrás. Ha ugyanis ott a 4-8 GB RAM a gépben, akkor miért ne töltse ki az adott sw, ha van rá lehetősége?

Ez olyan, mint egy extrásított EP progi. Ha kell, elfut 128k-s alapgépen is, de ha van bőven RAM, akkor kihasznnálja, és betöltődik az extra digi zene, meg az extra szuper grafika is Vagy éppenséggel 32kB-nál nagyobb forrásfájlt is be lehet tölteni (pl. a HEASS-ban).

Az, hogy valami sok RAM-ot használ, nem feltétlenül jelenti azt, hogy rosszul van megírva, vagy rosszul gazdálkodik a RAM-mal, és teleszemeteli... Hanem éppenséggel jelentheti azt is, hogy ha már ott van a gépben, akkor miért ne használja fel arra, hogy szebb / jobb / biztonságosabb legyen?

Jo, hat persze igazad vagyon, csak sok forumon is olvastam hogy firefox user kb "amint a firefox is ezt csinalja, bongeszot valtok" Nekem ez nem gond, legalabbis nem erzelmi alapu gond de teny, hogy nekem is ez a bajom a chrome-al: van az hulye szokasom (tudom, ez az en bajom ...), hogy neha 60 bongeszo tab-om is van Namost mivel 4G RAM van a gepemben, ez mar firefoxnal is kezd problemas lenni, chrome-nal meg konkretan katasztrofa Ugyanakkor persze multi-process model mellett nagyobb a biztonsag, jobb az egesz bongeszo "reszponzivitasa" vagy hogy hijjak' ezt es nem all le minden egy pillanatra, mert egyik tab eppen refresh-t jatszik pl EP forum Na meg tudom, vegyek RAM-ot, olcso az Mondjuk tenyleg akarok is, most ezen ne muljon.

Na én ezt nem értettem meg soha, hogy ez mire jó

Nem kell erteni, kinek mi jon be, en neha azt se ertem, mas mit eszik egy non, mas meg azt nem, hogy en mit

Erre ugyan van egyszerű megoldás: az emulátor funkciók hívására használt (eredetileg érvénytelen) utasítás kódjába beépíthető a funkció száma, a paraméterek pedig a Z80 regiszterekben adhatók át. Én 0xED 0xFE 0xFE N-t használok az epfileio.rom-ban, ami a kód speciális értelmezése nélkül NOP, NOP, CP N lenne. A 0xED 0xFE 0xFE 0x05 például az EXOS 5 hívásnak felel meg, és a használata is azonos (bemenet: A = csatornaszám, kimenet: B = olvasott karakter, A = állapot). Ha a ROM fel van készítve arra, hogy ezek az utasítások hatástalanok is lehetnek, akkor a másik emulátorban való betöltés nem okoz különösebb problémát, bár a speciális funkciók természetesen nem működnek.

Igazabol en nagyon okos akartam lenni anno Az volt az alapelkepzelesem, hogy en nem akarom nyilvantartani, hogy milyen funkciora milyen "ED trap"-et hasznalok, hanem szimbolum nevekkel operalok, es igy az "trap" _cime_ szamit ... Ez amugy tenyleg kenyelmes, es jobban latszik (legalabbis szamomra ...) az egeszben, hogy mi mihez tartozik (es kulon "konyvelni" sem kell), amde megvan az a karos hatasa, hogy igy persze egy byte-nyi kod hozzaadasaval "elmaszik" a XEP ROM-ban minden mogotte levo cim, akkor azt ugye egy masik Xep128 mas verzioval mar nem fogja felismerni, mert masok a trap-ek cimei. Persze, amikor ezt alkottam, nem volt meg olyan otletem, hogy pl snapshot-ot akarnek valaha is, orultem, ha _barmit_ csinal szerencsetlen emulator, nem voltak meg ilyen "advanced" elkepzeleseim

A címek helyett funkciókódok használata nem jelentene különösebb nehezítést, és elkerüli a ROM címek emulátorba építésével járó problémákat:

Code: [Select]

xepsym_fileio_open_channel      equ     1
xepsym_fileio_create_channel    equ     2
xepsym_fileio_close_channel     equ     3
xepsym_fileio_destroy_channel   equ     4
xepsym_fileio_read_character    equ     5
;...

MACRO   TRAP sym
        DB 0xBF, 0xED, xepsym_ed_trap_opcode, 0x20, sym
        JP NC, error_noemu
sym = $
ENDMACROAz xep_rom_syms.h pedig ugyanúgy generálható, ha fontos, hogy a fenti táblázat csak egy helyen legyen tárolva. Ez a makró egyben azt is ellenőrzi, hogy a funkció valóban támogatott-e, ha igen, akkor az emulátornak be kell állítania a C jelzőbitet, egyébként (mivel a CP A (0xBF) utasítás mindig C=0,Z=1-et állít be) a ROM hibát jelez.

Persze, hogy at lehetne irni, csak meseltem, miert lett ilyen Mondjuk addig lenyeges problemat nem okoz, amig nem akar snapshot-ot menteni, amit valami be is toltene

Szia LGB
WOS-on merült fel pár kérdés XEP128-cal kapcsolatban :

Fejleszted még az emulátort ?
Bináris XEP128 fellelhető-e Raspberryre?
A kérdező úgy értette valamelyik postot olvasva, de lehet gúgli translate elnavigálta, hogy érdekel téged vagy a XEP128, vagy egy másik emulátor ARM hardverbe való ültetése.

Itt az eredeti, hátha én is elnavigáltam valamit:
"Out of curiosity, I read somewhere that the Xep128 emulator can in theory be compiled to a Raspberry Pi... Some old YouTube videos seem to confirm that... Do you know whether this emulator is still in development or whether binaries can be found anywhere for the Raspberry pi?... Im guessing compiling for a Rasberry Pi is a complex job, and probably beyond my ability - just wondered if pre-compiled binaries for raspberry pi's exist anywhere?...

I also think I read somewhere a forum entry that suggested that the Xep author had interest in creating either that emulator or another to run native on ARM hardware, as a bare metal emulator - is that correct, or did I miss read the google-translation?..."

Ehm Na szoval, a "bare metal" programming igen, elvileg azt jelenti, hogy nincs OS egyaltalan, tehat kozvetlenul a hw (a "vas", "metal") folott vagy. Ez azert nem olyan trivialis dolog, mert akkor tenyleg mindent neked kell csinalni, amit ugye altalaban az OS megold (file access-tol kezdve minden, ami OS alatt nyilvan ugy szokas h meghivunk csak egy file open/read stb funkciot, amit az OS rendelkezesre bocsajt - ugyanez "bare metal" stilusban az, hogy eloszor kell irnod sajat drivert az SD-kartya/hdd/ami van eleresehez, aztan a file rendszer kezelesehez stb stb!!!!). Elvileg persze lehetne ilyet barmilyen sw-vel csinalni, Xep128-al, massal is, de azert ehhez jocskan meg kell dolgozni a dolog jellege miatt. Legyen a "vas" rapsberry pi, vagy akar PC is stb (regen PC-re is voltak jatekok amit bootolni kellett, azaz nem kellett ala OS voltakeppen, bar igaz, hogy pl DOS-ra keszult cuccok egy resze amugy is felig kozvetlenul hw-t hasznal mert DOS nem igazan egy "igazi" operacios rendszer amugy sem). Ilyesmit a Xep128 jelenleg nyilvan nem tud.

A kerdes masik resze, hogy Raspberry Pi alatt futtathato-e a Xep128 (marmint OS-sel most). Az persze, elevegre az "alap" OS ala egy Linux, tehat voltakeppen nem igazan kulonbozik attol a szitu, hogy mas Linux (pl PC-n futo Linux) ala forditja az ember. De amugy itt egy eleg vacak, regi, stb videom errol:

https://www.youtube.com/watch?v=n-qYMUGZaAs

Azert sem tul nehez leforditani, mert a Xep128 az kb majdnem "tiszta" SDL2 app, szoval amit SDL2 tamogat, azzal nincs gond. Az ep128emu-t szerintem nehezebb lenne pl, foleg, mivel vannak egyeb fuggosegei is (ezt most nem negativan mondtam, de a hordozhatosag szempontjabol kulonbozo platform-ok kozott ez jelenthet problemat). Bar azt is meg lehetne valahogy oldani, gondolom, ez ugyben nem nyilatkoznek Spec, a Xep128 azert is egyszeru, mert nem igazan van semmi egyeb menurendszer, UI elem stb benne, mint maga az emulator window (ami SDL2), igy tenyleg javareszt az SDL2-n mulik. Ilyen elven amugy elvileg Android-ra is lehetne viszonylag egyszeruen portolni, mivel az SDL2 tamogat ilyesmit.

Mondjuk amikor en utoljara probaltam raspberri pi-re, akkor egy a raspbian-ban nem levo SDL-t forditottam meg ala, es ugy mux, hogy GUI nem is kell hozza (tehat kozvetlenul text console-on kell elinditani). Ez kicsit kulonbozoik pl egy atlag PC-n futo Linux-tol, ahol X/Wayland/akarmi felett megy a cucc altalaban ugye. Oszinten, nem tudom hol tart a raspbian, pl hogy milyen SDL van benne verzioszamilag, regebben az volt a gond, hogy ami alapbol volt benne az egyszeruen tul regi volt mar a Xep128-nak ...

Tehát akkor félreértette

És ugye a XEP128 fejlesztését nem fejezted abba?

Nem nyilvanitom "abbafejezettnek" de az gondolom feltunt, hogy nem is vagyok tul aktiv benne mostanaban, mondhatni "szuneteltetve". Ez nem jelenti azt persze, hogy vegleg letettem rola, vagy barmi hasonlo ... De itt tobb dolog is van:

1. Az ep128emu-bol hianyoltam par dolgot, pl SD-kartya, eger, ilyesmik, amit en abba beletenni nehezen tudtam volna (C++, stb), IstvanV meg akkoriban annyira nem akarta mar fejleszteni ahogy lejott ez nekem, ezert inkabb megcsinaltam magam a Xep128-ban. Azota viszont az ep128emu is tud kb mindent amit a Xep128 vagy ugyanugy, vagy inkabb jobban, tehat kerdeses hogy mennyi ertelme van (semmi negativ erzesem nincs itt mielott vki felreerti, ezek csak tenyek ). Van amiben viszont a Xep128 latvanyosan le van maradva (vagy javareszt ertekelheto modon nincs is benne), pl hang.

2. Ennek ellenere en mindig elveztem a Xep128-al valo munkat, mert alapvetoen a kihivas/hobby stb jellege erdekes szamomra, meg akkor is, ha nem feltetlen versenytarsa az ep128emu-nak (ismet, emogott nincs semmi erzelemi toltet).

3. Mostanaban mar jo ideje igazabol idom sem lenne ra nagyon

4. Nem is igazan erkezett feedback, hogy sok embernek hianyozni. Nem, ettol nem fogok sirogorcsot kapni tenyleg csak megjegyeztem. Oszinten, en magam is orulok, hogy ep128emu-ba bekerult egy csomo dolog, ami regebben hianyzott, en is gyakran hasznaltam/hasznalom, gyakrabban idonkent mint a sajat Xep128-amat, hogy bevaljam

5. Mas temaban (Commodore 65, Commodore LCD, Mega 65 emulaciok) az Xemu projectben vagyok erdekelt egy ideje igazan, ahol nincs is igazan mas hasznalhato emulator egyaltalan szo szerint. Ennek kapcsan az "Xemu" nevu cuccot "talaltam ki" es fejlesztgetem, ami elvileg amolyan multi-platform, multi-emulator framework/API stb lenne egyszer, ha majd felno szep nagyra Ennek keretein belul vannak az emlitett emulaciok, illetve ebbe beletoltam mar viszonylag regebben a Xep128 kodbazisat is (miert fejlesztenek tok redundansan hasonlo emulator "alapot" tobbet is?). De oszinten, azota sok minden nem tortent vele, es igazan integralva sincs az "Xemu framework"-kel ...

6. Amugy is nyitott vagyok barmire, ami erdekes, otletes, elgondolkodtato, stb stb, az egyetlen objektiv problema nalam az idom hianya szokott sajnos lenni, meg ha amugy erdekelne is a dolog