Kiprobaltam a VICE plus/4 emujat nehany EVS demoval. :-) A Virtually yours introja sajnos kifagy, igy reszenkent kellett betolteni, de a gigantikus raszterbugoktol eltekintve (a TED emulacio meg igencsak nem tokeletes :) egesz turhetoen futott. Nem is tudom hany eve nem lattam mar azt a demot... :-))) A Megadreams viszont pld. vegig lefutott, bar TED bugok voltak minden partban dogivel... :( Az Infinity a legelejen kiakadt, na jo, mondjuk az huzos darab. :-)
Ha jol vettem ki a doksibol, a YAPE-nak egyelore nincs semmilyen 1541-es tamogatasa, igaz? Ez nagy elony a VICE mellett... :-) De majd megnezem a YAPE-t es a MESS-t is... de most meg dolgozni kene egy keveset, ma nem sokat haladtam a projekttel... :-))
Van egyébként az xmame projectnek egy xmess nevû testvérkéje ami egy rakás gépet emulál, egyebek közt XT-t, TRS-80-at, Amigát, Apple II-t és C64-et meg Plus4-et is.
a mess ottlapja az xmame/xmess ottlapja Elég régen próbáltam de akkor mûködött a plus4 emu. Hogy mennyire jó azt persze nem tudom.
Hja, en meg sosem nyitogattam Plus/4-en a keretet; siratom elveszett gyermekkorom ;-) Szomoru hogy mostanaban az assembly csak GBC osszefuggesben jut eszembe, ott meg keret sincs. ;-) Ejj de kiprobalnam valamikor ezt az $FF1E trukkot...
Nagyon kivancsi lennek hogy milyen jatekokat irtok 1K-ba! En inkabb csak abban jeleskedtem mindig hogy 64k-ba mi mindent bele tudtam suriteni, ugye Edhellon? ;-)
TLC: Szia! Crown tényleg megírt egy nyitott oldalkeretes rutint. Ez a GOTU MegaDisk II-n van, a Five Magics demo 3-ik részében. Letölthető tőlünk. 42 karakter szélesre csinálta a képernyőt.
A zenelejátszód, amit tavaly írtál nagyon király (elküldted nekem). Nem adod ki? Ha már a lejátszó kész, csak a demo kell hozzá és kész is... ;-)
SJP: A Genetic Faulty-ban amit Murphy írt még nem volt 4x4-es effect. Volt benne elég sok más dolog, ami a Plus/4-es demók nagyon állat :-) Lehet te is azokra a ki nem adott partokra gondolsz amit én lentebb említettem. úgy látszik elég sok mindenki látta őket.
ATI: Megkaptam a leveled, válaszoltam is. Nem kaptad meg? írj megint, vagy dumáljuk a Plus4World forumon.
Közben én meg itt ülök 3 plusival (2 PAL, 1 NTSC) és még az XE1541 kábelem is megjött, csak nincs időm (meg helyem) otthon összerakni mindent... Na jó, ne panaszkodjak. Üdv mindenkinek!
Ezt ugy erted hogy 4 soronkent 1 badlinet 80x50-es uzemmodban? Ez engem is erdekelne, de szerintem a lenti allasfoglalas miatt nem lehet megcsinalni... :\
Arra gondolunk, hogy a 4x4 miatt csak egy plus badline legyen, tehat osszesen harom karakter soronkent.
Egyebkent ha mar itt tartunk, a normalisan a 0. sorban levo badline-t megsporolva grafikus modban talan lehet memoriat sporolni. Arra gondlolok, hogy ilyenkor a TED hatha (valszeg) mindig a bitmap elso karakter sortat jeleniti meg, es akkor a bitmap memoriajanak tobbi reszet lehetne hasznalni kodnak es tablazatoknak. :)
Ugye voltatok mar ugy C64-en, hogy azert csinaltatok karakteres 4x4-et, mert nem maradt eleg hely! :)
Emulator tema:
A YAPE-ig eljutottam, de meg nem volt erkezesem kiprobalni, talan ma. Lattam hogy a Linuxos valtozat sajnos joval a Win32 mogott kullog, igy annyira nem kapkodtam erte... :(
A VICE-ben nem leltem plus4-es reszt, pedig letoltottem a legujabb release forrasat, de lehet hogy en vagyok a bena. CVS-bol kell tolteni? Nem lattam CVS repository-t az oldalukon...
Hoppa, hogy meglodultunk, es meg Levente is elokerult... :-)
Hogy lehet-e csak egy badline-t előidézni?
Ezt ugy erted hogy 4 soronkent 1 badlinet 80x50-es uzemmodban? Ez engem is erdekelne, de szerintem a lenti allasfoglalas miatt nem lehet megcsinalni... :\
Ha megnézed a jó emlékű CNS FLI editor doksiját -- nos abban az editorban egy olyan FLI rutin van, ami soronként mindig ellépteti $ff06-ot. Ennek az a következménye, hogy a TED mindig azt hiszi, ugyanabban a fázisban van -- mindig szín-ramot olvas (bitmap módban vagyunk). Azaz, a képen a pixelek fényerejét az előző rasztersor színramja határozta meg =-).
Hat igen, en is kb. eddig jutottam a plus/4-es FLI-vel valo kiserleteimben a fene tudja hany evtizeddel ezelott. :) Itt feladtam, mert ugy gondoltam hogy mivel igy csinalja a TED, igazan jo editort nem lehet ra irni, illetve kepeket konvertalni nagyon nehez lenne, a grafikusok meg nem fogjak szeretni ezt a megoldast... :(
Azota se terjedt el az FLI hasznalata plus/4-en... :\
Murpy egyebkent mintha kiadott volna jopar 4x4-es rutint a Genetic Faulty (vagy hogy hivtak) demojaban par eve, erdemes rakeresni.
...Jól emlékszem: 64-en a "jobb" 80x50 rutinok CIA időzítő-megszakkal mennek? :-)
Igen. Ilyet hasznaltunk mi is pld. a Daze cimu demoban (ha jol remlik, epp Murphy irta a rutint :). Kesobb viszont nem tudtuk hasznalni, mert a Void-ban hasznalt joval gyorsabb loaderrel osszeakadt valamiert (neha elromlott az idozites, vagy 1-1 byte-al elcsuszott a loader, mar nem emlekszem pontosan) es mivel koztudottan lamerek vagyunk a VIC-II/TED programozashoz, nem is foglalkoztunk vele, hanem visszatertunk a 'dupla megszakitasos' regivagasu modszerhez, ami lassabb ugyan valamivel, de legalabb mukodott. :-)
De lehet hogy erre a mintára lehetne optimalizálni a 80x50 rutinod is. Kétesélyes...
Azt hiszem menni fog, mert gondolom ha a ket badline eroszakosan kovetkezne egymas utan, akkor a TED-et sem lehetne rakenyszeriteni, hogy minden sorban szinramot olvasson az FLI-nel.
Jól emlékszem: 64-en a "jobb" 80x50 rutinok CIA időzítő-megszakkal mennek? :-)
Nos, en meg csak ugy fel eve kodolok C64-re, szoval annyira nem ertek hozza. Nekem van egy raszteres 4x4-es rutinom es kesz. A "jobb" rutinokrol annyit tudok, hogy az 1-es idozitot beallitjak ugy, hogy valamilyen szinkronban legyen a raszter szamlaloval. Ez azert kell, mert C64-en egy ciklus pontossaggal vagy kenytelen idoziteni a mesterseges badline kikenyszeriteshez. Egyebkent lehet, hogy a megszakitas viszont nem idozitos, hanem raszteres es az idozito regisztereit csak olvassak a szinkronizalashoz (mindenkeppen kell olvasni). De eleg nagy a C64 scene, ugyhogy valoszinuleg van ilyen is olyan is.
Udv!
Andras
U.i.: Nagy orulok, hogy osszefutottunk itt a neten.
> Hat akkor te elobb jarsz mint en. Azt hittem en csinalom majd az elso oldalso keret leszedest, mert meg soha nem lattam ilyet. :)
Larry programja egy multicolor amerikai sast dobott fel a képernyőre (full screen, csak alul volt néhány üres sor ;-)), a pic konvertált, csak nem volt a prg stabil (nem volt még pontos időzítés :-/), ez kb, '96-os lehet? Asszem neki jött össze először.
> Egyebkent eppen oda jutottam (es asszem ezt le is irtem itt), hogy a $ff1e-t kellene megpiszkalni. No az viszont lehet, hogy nem jut eszembe, hogy a karakteres es bitkepes uzemmod kozott ilyen kulonbseg van, es feladom.
Nekem sem jutott eszembe; inkább "próba cseresznye" (mint minden más ezen a gépen). Bejött. Azt már korábban tudtam hogy a bitmapet viszonylag egyszerűen el lehet mozgatni regiszter-manipulációval (a karakterest -- azaz a szín-ramot nem :-( ), gondoltam akkor csak összejön valami hasonló itt is :-).
> Egyebkent honnan lehet valami pontosabbant tudni az idozitesekrol. Peldaul nagyon erdekelne, hogy egy badlinenal mikor fogja a TED a buszt hasonlok.
Pár éve készítettem egy diagot. Valahol megvan (keress a plus4@c64.rulez.org listaarchívban, hirtelen nem tudom hol lehet megtalálni de majd valaki tudja). Crown is foglalkozott a dologgal, az ő diagjai részletesebbek (egy csomó képgenerálás-esemény pontos pozícióját megkereste), ez is ott kell hogy legyen valahol az archívban.
Még egy kiegészítés. Attila már megtette, de kicsit bővebben: valóban, a TED a karakter-adatokat a karaktersor 0. rasztersorában olvassa. A színeket pedig az előző karaktersor utolsó rasztersorában.
Ez analóg a C64-gyel. A belső puffer feltöltése a VIC-II-nél az épp megjelenített karaktersor első rasztersorában történik (ez a bad line :-) ), közvetlenül a bitmaszkok olvasása előtti órajel-periódusokban. Plus/4-en annyiban más a helyzet hogy színt is kell olvasni külön -- nosza, a TED-nél betették ugyanezt a mechanizmust a megelőző sorba.
Hogy lehet-e csak egy badline-t előidézni?
Hmmm, talán.
Ha megnézed a jó emlékű CNS FLI editor doksiját -- nos abban az editorban egy olyan FLI rutin van, ami soronként mindig ellépteti $ff06-ot. Ennek az a következménye, hogy a TED mindig azt hiszi, ugyanabban a fázisban van -- mindig szín-ramot olvas (bitmap módban vagyunk). Azaz, a képen a pixelek fényerejét az előző rasztersor színramja határozta meg =-).
Elég trükkös volt. És pocsékul használható :-/. De lehet hogy erre a mintára lehetne optimalizálni a 80x50 rutinod is. Kétesélyes...
...Jól emlékszem: 64-en a "jobb" 80x50 rutinok CIA időzítő-megszakkal mennek? :-)
Hat akkor te elobb jarsz mint en. Azt hittem en csinalom majd az elso oldalso keret leszedest, mert meg soha nem lattam ilyet. :) Egyebkent eppen oda jutottam (es asszem ezt le is irtem itt), hogy a $ff1e-t kellene megpiszkalni. No az viszont lehet, hogy nem jut eszembe, hogy a karakteres es bitkepes uzemmod kozott ilyen kulonbseg van, es feladom.
Egyebkent honnan lehet valami pontosabbant tudni az idozitesekrol. Peldaul nagyon erdekelne, hogy egy badlinenal mikor fogja a TED a buszt, hasonlok. Persze mindezt kitartassal belulrol is fel lehet terkepezni, de ha meg lehetne ezt uszni, akkor nem probalgatassal irnek keret leszedo rutint. :)
> Orulok neki, hogy van meg egy ember, aki meg mindig kiserletezik ezzal a jo kis geppel! :)
Módjával... :-/
(Hogyan kell rendesen idézni ezzel a döggel?... Nem találtam autoindent :-( ).
>> A lehetőség Plus/4-en inkább $ff1e manipuláció, és ez is leginkább bitmap módban, mert ott >> nem kötött a soronkénti byte-ok száma.
> Ezt nem ertem. Miert nem kotott. Es mi is van $ff1e-n, a vizszintes raszter pozicio?
$ff1e igen, a vízszintes raszter pozíció (ill. annak felsőbb bitjei, kivéve a legfelsőt mert azt kihagyták a drágák :-/ ).
Ugyanúgy mint a függőleges raszter pozíció, $ff1d. Írható-olvasható a reg (bár annyi trükk van benne, hogy olvasásra nem a várt értékeket adja, másképp fogalmazva: valami meg van keverve a hardverben, mert egy ismert, magából a regiszterből előzőleg kiolvasott számot visszaírva (az időzítésre is ügyelve) elmászik a sor időzítése :-O.
Ha írod a regisztert, ugyanaz a helyzet mint a függőleges számlálóval: mivel a TED kép-felépítési műveletei ehhez szinkronizáltak, a kép "manipulálható" :-).
Kötött / nem kötött: amikor a keret leszedésével kísérleteztem, próbaképp "megnyújtottam" a kép karakteres mezőjét (ugyanúgy mint a függőleges keret-leszedésnél: visszaléptetve, majd előreléptetve a regisztert, a megfelelő időpontokban). Működött is :-) (bár nagyon labilis volt; ha elszámítottam valamit, borult az egész, memória-felülírás meg ilyenek :-/, valahogy úgy mint a késői C64-ek amelyek borulnak a durvább D011 trükkökre). Ezzel lehet nyerni vízszintesen néhány karakternyi plusz szöveges mezőt :-). Sokat nem, mert Plus/4-en (a lassabb dotclock miatt) eleve kisebb a keret.
A baj viszont az, hogy a karakter- és színmemória beolvasása továbbra is (a TED-be drótozottan) 40 byte-os per karaktersor :-/. Ahogy a TED felépít egy szöveges rasztersort, a sor elejétől folyamatosan olvassa a belső 40 byte-os karakterkód- és színpuffereit (azokat, amelyeket az utolsó bad line során töltött fel), ill. a karakterekhez tartozó bitmaszkokat. ...Aztán a 40-edik karakter után, "rájön" hogy nahát, még vissza lenne néhány karakter :-). Illetve nem jön rá, és ez a baj. A belső puffer valószínűleg fix 40 byte-os. Ezért a frissen kreált új pozíciókra normálisan nem lehet karaktereket tenni (mert a TED nem tudja hogy ott mi lenne), és a színmemóriával nem lehet befolyásolni a színüket :-(. (Hogy pontosan mi jelenik meg, már nem emlékszem).
A megoldás a bitmap mód. Ott a bitmap beolvasását önálló számlálók vezérlik. Kipróbáltam, és a karakteressel ellentétben, a bitmap móddal nincs baj. A soronkénti bitmap byte-ok száma nincs rögzítve, annyit olvas amennyit kell. Azaz, simán előfordulhat hogy egy bitmap sor hossza nem $140 hanem mondjuk $158 vagy $160 byte hosszú :-). Megcsinálja. Baj még mindig van, az új pozíciók színével -- de ez főleg multicolor módban már egy más súlyú probléma :-).
Asszem érdemes volna meghallgatni Crown-t mert ő mintha kódolt volna egy _valóban_ működő oldalkeret-leszedő rutint.
> Te egyebkent aktiv vagy?
Inkább úgy fogalmaznék hogy "áll az élet".
> Indulsz a mostani 16K compon vagy az 1K mini game compon?
Szinte kizárt.
A 16K compo-ra tavaly úgy gondoltam nevezek, el is készült egy TED zenelejátszó rutin meg némi teszt-zene (két ch négyszögjel mintállat =-) ). Aztán ebben maradtunk :-/.
Orulok neki, hogy van meg egy ember, aki meg mindig kiserletezik ezzal a jo kis geppel! :)
Az a függetlenül frissített szín- és fényerő infó amiről asszem András írt eléggé érdekes jelenség :-) (ha kéznél van a rutin, megnézném :-) ).
Na mostmar tenyleg reprodukalom a dolgot es holnap elkuldom. Egyebkent fene a pofamat, tegnap lett volna ra egy kis idom, csak elfelejtettem.
Zabálja az időt; viszont van független szín-és fényerő :-).
Es barhol elkezdheted a keretet az $ff1d megbutykolesevel, hogy CPU-t nyerj. :)
A lehetőség Plus/4-en inkább $ff1e manipuláció, és ez is leginkább bitmap módban, mert ott nem kötött a soronkénti byte-ok száma.
Ezt nem ertem. Miert nem kotott. Es mi is van $ff1e-n, a vizszintes raszter pozicio?
A másik, hogy $ff1d-t lehetőleg kettővel osztható számú sorral léptessétek odébb -- ha a váltás páratlan számú, az gáz mert a PAL színkódolás soronként inverz fázisú színsegédvivőt használ, és a váltás után a TED egyik pillanatról a másikra a várttal ellentétes fázisú színjelet fog generálni.
Hasznos info!
Te egyebkent aktiv vagy? Indulsz a mostani 16K compon vagy az 1K mini game compon?
Már két utalást kaptam hogy megy egy jó Plus/4-es fórum. Nem hagyhattam ki hogy be ne nézzek ;-).
Csabó: gratulálok a babához! :-). A képet meg küldöm, mihelyst kezembe akad egy digitális fényképező (rájöttem hogy nem is egyszerű normális képet találnom).
Volt egy-két dolog amit emlegettetek.
FLI, meg 80x50-es mód. FLI-t programoztam, 80x50-et nem. Eléggé sajátságos a dög. Észvesztő huncutságokra képes ha valami nem pontos. Ahogy írtátok, két "bad line" van egy karaktersorhoz -- azaz egy 80x50-nél 4 rasztersoronként kettő lesz. Zabálja az időt; viszont van független szín-és fényerő :-).
Egyébként minden csak pontos időzítésen múlik (a többi sima $ff06 magic :-) ). Épp mint 64-en.
Az a függetlenül frissített szín- és fényerő infó amiről asszem András írt eléggé érdekes jelenség :-) (ha kéznél van a rutin, megnézném :-) ). Lehet hogy olyasmi okozza, mint C64-en a DMA delay effectet, hirtelen ez ugrik be róla. Hogy tényleg mi, a szél tudja :-O. (A TED asszem nem fog az emulátor-írók kedvencei közé tartozni ;-) ).
Oldalkeret-bontás: A keretet el lehet tüntetni, pontosan úgy mint 64-en. Csak nincs mit a helyére rakni :-( (nincs sprite). A lehetőség Plus/4-en inkább $ff1e manipuláció, és ez is leginkább bitmap módban, mert ott nem kötött a soronkénti byte-ok száma. Larry írt egyszer egy oldalkeret-leszedő rutint, szintén bitmap módban ment. Én is kísérleteztem vele, de sosem lett tökéletes, viszont olyat néha csinált a TED manipuláció, hogy a proci néhány 10 byte beolvasásának idejéig nem 'látta' a memóriát ;-). Na itt adtam fel.
Képernyőkeret-leszedés meg ilyenek (asszem András írta hogy kísérletezett vele): nagyon jól manipulálható, csak arra vigyázzatok hogy a frame-enkénti sorok száma lehetőleg ne változzon. Ha kevesebb sor van, akkor nagyobb, ha több, kisebb a képfreki -- nem baj, de némelyik TV nem jeleníti meg. A másik, hogy $ff1d-t lehetőleg kettővel osztható számú sorral léptessétek odébb -- ha a váltás páratlan számú, az gáz mert a PAL színkódolás soronként inverz fázisú színsegédvivőt használ, és a váltás után a TED egyik pillanatról a másikra a várttal ellentétes fázisú színjelet fog generálni. Azaz a színek "ellenkezőre" váltanak (a YUV színtérben :-) ), amíg a PAL dekóder a TV-ben rá nem jön hogy mi újság :-).
Azt nem tudom, hogy ez a fázis-inverzió soron _belül_ is működik-e. Egy biztos, a következő sor színe már inverz.
(NTSC-ben lehet hogy nem, azzal nem kísérleteztem. Az NTSC más.)
"Igazi" interlace mód: Meg lehet csinálni :-). Kísérleteztem vele. Ugyanazzal van gáz, mint fent. A korrekt interlace módhoz a függőleges képvisszafutás-jelet (VSYNC) kell manipulálni (a néhány fekete-fehér sor a képernyő "alján", ami normálisan nem látszik). Eddig nem tudtam elérni hogy a VSYNC is jó legyen - és emellett a PAL színek ne kapjanak hülyét :-(. Ezzel utoljára tavaly foglalkoztam, akkor odáig mentem hogy egy digitális panellal bemértem egy Amiga laced és nem laced képjelét, aztán ugyanezt a Plus/4-en is. Aztán "eltérítettek". Mint mindig. B@sszuskulcs.
(Ha jól meggondolom, először valami tíz éve, '92 végén írtam fel egy papírra a szobám falára, hogy a C-16-nak sikerült 320x400-as felbontást produkálnia. ...Kicsit bosszant. Nem. Nagyon.)
Murphy (azaz Márta Krisztián a GSből) megírt egy pár ki nem adott demórészt pár éve, hozzám Atitól került el. De megkértek hogy ne adjam ki (azért persze most dumálok róla). Pedig irtó szépek, egy csomó 4x4-es "felbontásban" működő cucc.
Hat igen, ha egyszer megvan ez a rutin, akkor mindent ilyen cuccot egyszeruen at lehet emelni. Raadasul ezek egy resze nem is az egesz kepernyot hasznalja, es Plus/4-en ilyenkor az $ff1d piszkalasaval nyugodtan le lehet akkorara sovanyitani a kepernyot, amennyire szukseg van. Es ugye ilyenkor kapunk egy csomo CPU-t! :)
Ki fog az 1Ks minicompóra játékot írni? Én biztosan, nem is egyet.
Raallt az agyam egy resze a temara, ugyhogy ha jon valami jo otlet, akkor valoszinuleg en is indulok.
Rájöttem hogy hogy lehet futtatható kódot írni $1001-től, úgy hogy mégis Basicben elinduljon a program (csomó byte-ot spórolunk...)
Badline biztosan legalabb 2 lesz, hiszen karaktersoronkent ketszer (0. es 4. rasztersornal) kell a TED-nek frissitenie a fenyero/szin infot, a 4x4-es mod miatt. Sot, lehet hogy negy badline lesz, mert ha jol tudom, a TED-nek ket soraba telik amig frissiti mindket tablat (ezert is nem lehet 'normalis' FLI-t csinalni Plus/4-en sajnos) mivel egy sor a fenyero, es egy sor a szininfo frissitese.
No en az Attillatol ugy tudon, hogy az egyik badline a szineket, a masik a karakter/bitkepes adatokat firissiti. Ha az igy van, a jelenlegi 4x4-es rutinom general egy folosleges badlinet. Arra gondoltam, hogy egy idozitos megszakitassal a karaktersoron beluli 3-as rasztersor vegen megvaltoztatom az YScrollt es a szinmemoria helyet, megvarom mig elindul a badline, es rogton vissza is allitok mindent. Igy karaktersoronkent megsporolok egy megszakitast es egy badlinet is. Persze ez csak akkor muxik, ha a TED nem szakitja meg a badlinet a valtoztatas miatt, es nem tortenik meg meg igy is a kovetkezo badline.
En fogok! Jo Neked, hogy mar az a gondod, hogy beleferj 1k-ba, az enyem kabe 350 byte lett, es nagyon mas ertelmes mar nem is jutt hozza eszembe... Sose voltam valami kreativ :) El is kuldtem par napja mailben, megkaptad?
Ha mar itt tartunk. Hogy lehet, hogy a 4x4 mod nem terjedt el a Plus/4-en?
Igaza van SJPnek, addigra a Plus4 scene kihalt. Nem is csak hogy meg lehet csinálni, hanem meg is lett csinálva. Murphy (azaz Márta Krisztián a GSből) megírt egy pár ki nem adott demórészt pár éve, hozzám Atitól került el. De megkértek hogy ne adjam ki (azért persze most dumálok róla). Pedig irtó szépek, egy csomó 4x4-es "felbontásban" működő cucc. Visszafejtettem, nagyon egyszerűen az FF06 és az FF14 váltogatásával éri el a dolgot minden negyedik sorban.
Nem is hiszem el, hogy Plus/4-es kódolásról beszélünk, oda vagyok teljesen, JujjDeKlassz. Most 12 napos a kislányom így lemaradtam az elejéről...
Ki fog az 1Ks minicompóra játékot írni? Én biztosan, nem is egyet. Rájöttem hogy hogy lehet futtatható kódot írni $1001-től, úgy hogy mégis Basicben elinduljon a program (csomó byte-ot spórolunk...) Üdv minden Plusisnak!
Idozitessel valszeg menni fog karaktersoronkent egy megszakitassal es csak egy badlineal.
Meg lehet csinalni egy megszakitassal, azt a 4. karaktersorhoz kell elhelyezni, legalabbis C-64-en. :-) Badline biztosan legalabb 2 lesz, hiszen karaktersoronkent ketszer (0. es 4. rasztersornal) kell a TED-nek frissitenie a fenyero/szin infot, a 4x4-es mod miatt. Sot, lehet hogy negy badline lesz, mert ha jol tudom, a TED-nek ket soraba telik amig frissiti mindket tablat (ezert is nem lehet 'normalis' FLI-t csinalni Plus/4-en sajnos) mivel egy sor a fenyero, es egy sor a szininfo frissitese. Bovebb infoert olvasd el TLC FLI editoranak a doksijat. :-)
Nekem nem mukodott a java-s minus/4 emu, de lehet hogy a freeweb.hu hihetetlen kulfoldi savszelessege a ludas a dologban... De nem adom fel, majd valahogy letoltom oket es keresek egy emut.
