Udvozlok mindenkit, en csak a flag-en tudtam meg a Bubis-tol, hogy van ez a jo kis forum, es most latom csak, hogy mennyi ismerossel lehet itt osszefutni...
Az utobbi idoben feldobott raszteres temaval kapcsolatban nehany hozzafuznivalo.
Az FLI-ben a mar fentebb emlitett problemak miatt 2 sorban erdemes gondolkodni, de ugy viszont minden problema nelkul, egyszer csinaltam is egy 2 soros fli editort, ami azutan sajnos felbemaradt, es volt nehany egyszeru effektem is ami ezt hasznalta... Egyebkent a Corpse-nek volt olyan kepkonvertere pc-n, ami ezt is tamogatta...
Ami csak alom volt, hogy ezt x iranyban interlacelve nagyon szep kepeket lehetne csinalni... Es ugye ez also felso keret bontassal is kepes egyuttmukodni... 320x256 121 szinnel, eleg jol hangzik...
Ha jol emlekszem a 40x32-karaktert sikerult osszehoznom, anno meg egy karaktereditorhoz, de termeszetesen ez se lett releaselve, mondjuk ez nem egy komoly fegyverteny...
Meg erdekes rasteres effektem volt, az amigas Kefrens bar-okra tett probalkozasom 33 karakter szeles teruleten tudott mukodni, es mivel egy rastersort ismetelgetett ff1d felulirassal, gyakorlatilag magatol tudta a keretre irast... ez a sinus update rutin miatt, csak olyan 245-6 rastersor magas volt, mondjuk szerintem ez is eleg tekintelyes...
Az bitmap ismetelgetes 4x4 modban nekem is megvolt, az ati-nak elkuldott tolcser effekt is ezzel mukodik emuk alatt eleg furcsan is fest, mondjuk nekem 2 karaktersornyi bitmap-el sikerult ezt elerni, de lehet, hogy optimalizalhato.
Az Oswald-al kiagyaltuk, hogy elvileg 64-en is lehet hasonlot trukkozni, mondjuk ott tobb mint fel kepernyonyi bitmap kell, de megsem egesz, de hogy gyakorlatban hogyan kellene azt most fejbol nem tudom megmondani...
Hmmm, nem tudom. 60Hz-es IFLI nezot csinalt C128-ra, de mas hasonlorol nem tudok. Azert annyira nem ismerem a C64-es scenet.
Ja. Ez lehet pozitív vagy negatív kicsengésű, de a puszta tény az az hogy AntIQ-n mindenképp ott leszek ;-) (ha lesz).
Ugy tudom, hogy lesz. Az EstFM-ben egy hete volt egy musor, ami alapjan ez biztosnak tunik. En nem biztos, hogy megyek, de egy kisebb demot szerintem lehet, hogy kuldok. Egyebkent www.antiq.hu.
A PC scene úgy látom mélyponton van (nem véletlenül ritkultak meg a nagy party-k... :-/). Kiégett, kifutotta magát. Ehhez képest, 8-bites gépre demót írni úgy tűnik megint kihívás :-).
Marha nagy kihivas! En atneztem kb 94-tol a jelentosabb partyk anyagait, hogy tudjam mit csinaltak mar meg, es hogy tanuljak. Hat dobbenet! Aztan kitalaltam nehany dolgot, amirol ugy tunt, hogy meg nem csinalta meg senki. Hat ezek tobbsegerol kiderult, hogy bizony megcsinaltak! Most a Flag-en peldaul a demovetites kozben kellet rajonnom, hogy korbefordulos tunel (amit talan mar mutattam) is van mar C64-en. Igaz, hogy nem sotetedik el az alagut vege (fog, azaz kod), de van ilyen. Szoval csak azt mondhatom el, hogy tovabbfejlesztettem. Na jo, mondjuk nalam van fog is, es a tunel nem csak egy tengely korul forog, hanem teljesen szabadon, de akkor is. :) Szoval ez a gep igazi kihivas! Itt aztan meg lehet mutatni az embernek, hogy mit tud! Nincs izomgep, ami mindent kiszamol!
"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. :) "
Olvastam a c64 rulez levlistán a rövid party reportot :-).
Ninja nem az a tag véletlenül, aki (asszem egyik Coma Light-ban) elsütötte azt a 26 karakteres képernyő + VIC "túlmelegedés" + VIC hőfokmérő poént? ;-D
Ja. Ez lehet pozitív vagy negatív kicsengésű, de a puszta tény az az hogy AntIQ-n mindenképp ott leszek ;-) (ha lesz).
"Na ezt majd meg atragom. :) "
Én is. Valahogy sehogy nem jön ki "egyszerűen" (pedig az biztos hogy a Commodore egyszerű megoldást választott ;-) ). Tegnap kísérleteztem (egy pillanatig még a sorrendben is kételkedtem); annyi biztos hogy a 0.-1 rasztersorokban mindig szín-, a 0. rasztersorokban mindig karaktermemória-olvasás történik.
"...A PC-s demokat nem tapsoltak meg ugy, mint ezeket, es ott valahogy senki nem kiabalta, hogy vissza! :) "
A PC scene úgy látom mélyponton van (nem véletlenül ritkultak meg a nagy party-k... :-/). Kiégett, kifutotta magát. Ehhez képest, 8-bites gépre demót írni úgy tűnik megint kihívás :-).
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 :-/.
