Gondolom a csapat egy része FLAG2002-n, aki nem az meg még (már :-) ) alszik :-). Néhány rövid reakció.
Hat ebbol a szempontbol csalodnom kellett. Nem hogy a Resouce nem volt ott, de mas csapatokbol sem sokan. Volt ket nemet srac, egy szabadkai, en es kb ennyi. Mi mindenesetre nagyon jol ereztuk magunkat. :)
Van itt azonban valami amin morfondírozok. Nem tudom, használható-e valamire. Kicsit talán túl "tömény" is, ha leírom...
Na ezt majd meg atragom. :)
>>Tegnap csak tanulmanyozasi cellal csinaltam egy
>>olyan keret leszedot, ami rendesen idozitve
>>van. Ezt mar valoszinuleg nem lesz nehez atirni
>>az $ff1d-s cuccra, csak arra kell figyelnem,
>>hogy a most kikiserletezett idozitest ne
>>rontsam el. "
>Na, működik már? :-)
Nem, meg nem, es most azt hiszem ezt egy kicsit felre teszem. Eloszor is be kene mar fejezni a 16K-t a Lucaval, es illene az Antiq-ra is csinalni valamit. Tisztra kiakadtam, hogy a Flag-en csak egy C64-es demo volt. Raadasul alig volt ott valaki a C64-es scenerol. Nehezen varhato el, hogy igy a partikon tamogassak ezeket a gepeket... Ennek ellenere volt egy 64-es demo vetites a javabol ami nagyon nagy siert aratott. A PC-s demokat nem tapsoltak meg ugy, mint ezeket, es ott valahogy senki nem kiabalta, hogy vissza! :)
Gondolom a csapat egy része FLAG2002-n, aki nem az meg még (már :-) ) alszik :-). Néhány rövid reakció.
Ed:
"Hoppa, hogy meglodultunk, es meg Levente is elokerult... :-) "
:-D
András:
"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. "
Szinte biztosan át lehet verni valami $ff06 / $ff1d / $ff1f magic-kel :-).
Van itt azonban valami amin morfondírozok. Nem tudom, használható-e valamire. Kicsit talán túl "tömény" is, ha leírom.
A TED-ben két, egyforma 40 byte-os puffer kell hogy legyen a karaktersorok szín- és karakterkód adatainak átmeneti tárolásához (egy karaktersor idejéig). Ezeket a tárakat tölti fel a TED a "bad line" alatt, és ezekből veszi ki az infót a karaktersor felépítése során. Bitmap módban, ezek a pufferek adják egy "karaktersor" szín- és fényerő byte-jait.
Azon gondolkodom, hogy ez az egész hogy működhet.
A FLI editorban használt FLI rutinnak mint mondtam az a tulajdonsága, hogy a soronkénti $ff06 léptetés miatt minden sorban van bad line, _és_ az adott sor színeihez a megelőző sor színei adják a fényerő-infót. Ez a viselkedés azt jelenti -- számomra -- hogy a két puffer "szerepe" nem rögzített, azaz az hogy a pufferben levő byte-ok mikor játsszák szín-, mikor fényerőbyte-ok szerepét, az nem a puffert feltöltő bad line alatt hanem a sor megjelenítésének kezdetén derül ki (ha a bad line elején már kiderülne, akkor az adott puffer a beolvasás után _vagy_ szín, _vagy_ fényerőinfó szerepét játszhatná, és sosem a másikat -- de mivel láttuk hogy az előbbi FLI rutinnál ezek a szerepek sorról sorra cserélődtek, anélkül hogy az infókat a TED _újra_ beolvasta volna, úgy néz ki hogy a helyzet nem ez).
Magyarul, két kérdés merül fel. 1. mi határozza meg hogy egy bad line során a ramból beolvasott byte-ok melyik pufferba kerülnek, és 2. mi határozza meg egy adott rasztersor pozícióján hogy melyik pufferből származik a szín- és melyikből a fényerő (vagy karakteres módra lefordítva: melyik puffer byte-jai lesznek karakterkódok, és melyek színek).
Fogas kérdés...
Visszatérve a "2+1" bad line-os 80x50-re: ha itt valami árulás van a TED-ben az esetleg bajt okozhat. Másik oldalról: kitűnő alkalom hogy fény derüljön rá, tényleg így van-e :-).
"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. :) "
Ezt szinte biztosan meg lehet csinálni. Ha minden bad line-nál kinullázod $ff1a/$ff1b-t (gyanúm szerint elég csak az alsó byte-ot), komoly esélyed van rá hogy a bitmap felépítése nem megy "előre", azaz a legelső sor bitmapja lesz minden sorban érvényes.
"Tegnap csak tanulmanyozasi cellal csinaltam egy olyan keret leszedot, ami rendesen idozitve van. Ezt mar valoszinuleg nem lesz nehez atirni az $ff1d-s cuccra, csak arra kell figyelnem, hogy a most kikiserletezett idozitest ne rontsam el. "
Na, működik már? :-)
Csabó:
"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. ..."
Jól emlékeztem...
"A zenelejátszód, amit tavaly írtál nagyon király (elküldted nekem). Nem adod ki?"
Miért ne? Ezer örömmel :-) Csak legyen aki zenél vele.
"Ha már a lejátszó kész, csak a demo kell hozzá és kész is... ;-) "
Valahogy így |-D.
Meg kellene (talán) fejelni valami digivel. Vagy mittudomén. Pont olyasfajta zenéket nem lehet (vagy csak én nem tudok) megszólaltatni az öreg palacsintasütőn amelyeket szeretek :-(.
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.
No akkor itt van az a 4x4 rutun, amit en csinaltam:
http://dotsch.freeweb.hu/plus4/4x4test.prg
es itt van egy olyan valtozata, ami a karaktersoron beluli 3-as rasztersorban valtja ki a badlinet es emiatt a TED nem frissit minden szint:
http://dotsch.freeweb.hu/plus4/4x4test_bad.prg
Sajnos nem tudtam pontosan reprodukalni amirol korabban meseltem. Itt nem pont a kepernyo kozepen van az elvalasztas, es ugy tunik a kepernyo bal felen a fenyero ertekek soha nem olvasodnak ujra csak a szinek, mig amit korabban csinaltam, ott azert minden rendes badline-al minden ujra olvasodott.
Tegnap csak tanulmanyozasi cellal csinaltam egy olyan keret leszedot, ami rendesen idozitve van. Ezt mar valoszinuleg nem lesz nehez atirni az $ff1d-s cuccra, csak arra kell figyelnem, hogy a most kikiserletezett idozitest ne rontsam el.
Egyebkent ert egy kis meglepetes! Megcsinaltam 8 rasztersorra a cuccot, aztan elso probakent 10-szer egymas utan irtam, gondolvan, hogy akkor most mar 10 sorban lesz leszedve a keret. A fenet! A 6. sor korul valamiert elcsuszik az idozites! Meg nem jartam utana.
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.
