Ok, tonight Attila fixed TEDsound emulation right under our sight, and it seems to work pretty well! The same for the Hannes 256K emulation and the .tap creation.
While you still think about emulating sideborder, I wanna introduce another toopic to the Yape's ToDo topics: there is a demo effect that NEVER works on Yape, disregarding differences demo by demo, and exactly it is the LINE-MORPHING.
E.g., Synergy's Future World, or GOTU's 5 Magics, or (if it will works on yape once a day) Moldi's +4 Mania Forever...
Ja, HTML-tagkent ertelmezte... :-) Kiprobaltam a kodot, es tenyleg jobb szelen megnagyobbodott a kep, viszont nalam ez csak 3 karakter szeles, mivel utana mar hblank van, legalabbis a TV-kartyan :-)
Aztan mikor a keretre iras jott szoba, teljesen racsobbant a temara, hisz ilyen abban a formaban nem lehetseges C64-en. Bar bubis is tudna meselni, milyen feeling C64 utan plus/4-re kodolni, nem? :-)
Te, en alapvetoen pluszisz vagyok, nekem csak ugy egy eve van C64-em. :) Azert mentem 64-re, mert a pluszis scene elegge elhalalozottnak tunt.
De ha mar a keret bontasnal tartunk, egy kis friss ropogos. :) A kovetkezo kod ha minden igaz a 4-es rasztersorban ahol ugye badline van (!) megszelesiti a screent 4 karakterrel. :))))
sei
sta $ff3f
lda #$02
sta $ff0b
lda #$02
sta $ff0a
lda # sta $fffe
lda #>irq
sta $ffff
lda $ff09
sta $ff09
cli
jmp *
Nekem sem artana jo elore tudni, mert en is kulfoldon vagyok... Viszont egy jo kis partyert elutaznek akar Ausztraliaba is :-) Csak tudjam meg idoben, mert meg kell tervezni a szabdsagot :-(
Jol beszelt a Maugli, uff :-) En speciel a bad line-ok alapos kivesezesenek orulnek a legjobban. Ami a FAQ-ot illeti, tegnap az IRC-n fenn volt egy C64-es coder arc (TMR/Cosine) aki marhara megorult egy attekintheto TED regiszter referencianak (ezt kuldtem tovabb Mauglinak). Aztan mikor a keretre iras jott szoba, teljesen racsobbant a temara, hisz ilyen abban a formaban nem lehetseges C64-en. Bar bubis is tudna meselni, milyen feeling C64 utan plus/4-re kodolni, nem? :-)
jah, party, hát elég nehéz lesz összehozni, mert sokan jönnének rá. Mindenesetre lehet gondolkodni a kereteken.
Jönne pl TCFS, STEVE, akik alapból külföldön vannak, TCFS csak 3 hetente van itthol hétvégén, STEVE meg ha minden igaz, most megy ki a héten 3 hónapra.
Maugli: A democompo leírása a GOTU honlapon megtalálható, a lényeg az, hogy bővítetlen c16-on fusson, és lehetőleg ne használja a drive cpu-ját számításra. (ez Bubisnak különszabály...)
Mindenesetre mindkét módon kipróbáltam, és a TPSH packerrel tömöríttet proggi mindkét esetben rossz lett, a MC packeres meg mindkét esetben jó.
(mit értek az alatt, hogy rossz lett? : eleve amikor betöltöm, a list eredménye a sys ... -en felül egy zsák krixkrax szines "dzsuva". - persze monitorból töltve jó.)
Szerintem nézd meg egyszer a Basic indítósort monitorból. Az első dolog hogy a végén 3 db. 0-nak kell lennie. A másik hogy a Basic sor végét jelző pointernek (ami $1001-$1002-n van) erre a 3 db. nullára kell mutatnia. Ha ez megvan, a Basic elkönyveli hogy ennyi a Basic forrás és a többi memmel nem foglalkozik (azaz lehet az egy darab Basic sor mögött bináris adat, úgy hogy a Basic-et nem zavarja). Ha nincs a 3 nulla, ill. a pointer túlmutat rajta, akkor az interpreter megpróbálja a bináris adathalmazt Basic sorokként értelmezni, amiből eljut odáig hogy bumm a fejbe :-). ...Gondolom ez lehet a baja, ha más nem.
Király csávó lehet az az MC :)))
A regisztercsavargatáshoz én viszont nagyon hülye vagyok :) Anno sem értettem hozzá, most meg már azt is elfelejtettem :))
Kicsit megint fejlődött a FAQ, hála Atinak. (Thanx!) Próbáltam egy kicsit angolosítani is. Minden további ötlet welcome! :) Szeretném hangsúlyozni, hogy ez nem egy nagy FAQ akar lenni, amiből bármit meg lehet tudni, hanem egy icipici kedvcsináló, egy két proggival megtűzdelve.
Küzdöttem a TPSH packerral, sikertelenül. Mostmár majdnem biztos vagyok benne, hogy hibás verzió van nekem. MC packere megmentett, azzal jól ment minden. Már majdnem ide jöttem kérdezni, hogy mit cseszek el.
Mi is volt a gond?
Szóval, ha jól emléxem minden packer miután beállítottuk a 0x2b, 0x2d-n az a start-end-et lefuttattuk, ugyanzokba a 0x2b,0x2d -be állítja be, hogy mennyi lett a kész termék.
Ez logikus is, hiszen a BASIC innen tudja, hogy meddig kell menteni.
Itt kicsit elbizonytalanodtam, hogy mi is a különbség a MONITOR-ból mentett és a BASIC-ból mentett dolgok között.
Mindenesetre mindkét módon kipróbáltam, és a TPSH packerrel tömöríttet proggi mindkét esetben rossz lett, a MC packeres meg mindkét esetben jó.
(mit értek az alatt, hogy rossz lett? : eleve amikor betöltöm, a list eredménye a sys ... -en felül egy zsák krixkrax szines "dzsuva". - persze monitorból töltve jó.)
Na erről hirtelen ennyit. :)
Na és akkor ha jól értem egy c16-oson fog menni a demo?
El van már döntve, hogy hol lesz a party? Én nagyon szívesen megyek Debrecenbe is, ha ott lesz. (Persze Szegedet preferálom :)) )
Még valami: Azoknak, akik annyira gyűrik ezt a keretre-írás dolgot, szeretnék mély elismeréssel adózni. Úgy érzem bennetek van annyi tudás, hogy egy-egy emulátor hiányosságait, hibáit sokkal jobban észre tudjátok venni ezekben a mélységekben. Szerintem okos dolog lenne a tutibiztos dolgokat összegyűjteni. (mikor hogyan van badline, mi hanyadik ciklusban kezdődik, stb, stb..) Úgy érzem egy pontos leírásnak Ati nagy hasznát venné a Yape fejlesztéséhez.
A timereket megtalalod a plus4 levlistaban, anno azt is kimertem. Most igy
fejbol nem emlekszem az irasra, de az biztos hogy a csokkentes ott fix
fazisokban volt, raadasul ugy hogy a 2-es timer az nem ugyanabban a ciklusban
csokken mint az 1-es es a 3-as. Majd este megkeresem es bemasolom ide.
:-)
Egyebkent valoszinuleg a double clock ciklusban irt $ff1e is csak a
kovetkezoben updatelodik, de mivel az also ket bit nem irodik ezert ugy tunik
mintha azonnal tortenne. Sajna ezt nem is nagyon lehet kimerni, mert karakter
kozepen nincs semmi allapot valtozas amit befolyasolni lehetne...
Mibõl gondolod?
Kicsit mas a helyzet, ott 38/40 karakter valtassal csinaljak. Azonkivul ha a
STA 3 olvaso ciklusa meg a DMA elott befejezodik, akkor az iro ciklus is a DMA
elott lesz, (tudod az a 3 ciklus ahol csak irni tud a proci), ugyhogy ha az
irast a DMA utan akarod, akkor egy olvaso ciklusnak mindenkepp kell lennie a DMA
utan, es akkor mar az iras keso lehet. De meg ha az iras pont a keret elott van
akkor is a latcheles miatt valoszinuleg a keret bekapcsol.
Damn! De várjunk csak: emlékezetem szerint az írásnak C64-en arra a ciklusra
kell esnie, ahol épp vége a karakteres mezõnek (azaz arra a karakterre, ahol
normálisan nincs, 38 széles módban van keret). A másik amit tudok, hogy 64-en
_biztosan_ csináltak keretleszedést DMA-soron. Azaz _lehet_ ebben a ciklusban
írni. ...Ez azért érdekes, mert szerintem ez az elsõ vagy legfeljebb második
ciklus DMA után (inkább az elsõ?...).
Ki kell próbálni... Nincs más hátra.
Ja... A régi tesztprogram (a CPU + TED busz-ütközéssel) sajnos nincs meg. :-(
Valószínûleg ugyanúgy végezte, mint a többi hasonló kísérletem
(...memory-corruption + halál :-/ ).
[Lavina]
nem értem, miért olyan érdekes ez a keretleszedési probléma??? Persze, jó
poén, de miért olyan enthusiastic mindenki about it??? :D
Mert ez ($ff1e) egy eléggé felderítetlen része a TED-nek. Engem legalábbis ezért érdekel.
Na a Cc65-hoz es a DASM-hoz tettem fel ket kis progi forrast, ami egy
1024 sys 4109
basic sort general az adott forditokban, es a "main" cimkere ugrik, aminek a helye $100d. Egy kis segitseg az elindulashoz! :)
Latchelt működés: nem lehet, hogy a TED más regisztereire (pl. számlálókra) is működik valami ilyen? Gyanús, hogy ha egyszer megcsinálták a szinkronizálást, akkor miért pont erre az egy regiszterre használták és a többire nem.
A timereket megtalalod a plus4 levlistaban, anno azt is kimertem. Most igy fejbol nem emlekszem az irasra, de az biztos hogy a csokkentes ott fix fazisokban volt, raadasul ugy hogy a 2-es timer az nem ugyanabban a ciklusban csokken mint az 1-es es a 3-as. Majd este megkeresem es bemasolom ide. Egyebkent valoszinuleg a double clock ciklusban irt $ff1e is csak a kovetkezoben updatelodik, de mivel az also ket bit nem irodik ezert ugy tunik mintha azonnal tortenne. Sajna ezt nem is nagyon lehet kimerni, mert karakter kozepen nincs semmi allapot valtozas amit befolyasolni lehetne...
Morfondírozok valamin, mióta Bubis nekiállt oldalkeret-lebontani és szóbakerült a DMA-sor. 64-en emlékezetem szerint egy cikluson múlik, hogy az effektet meg lehet csinálni (azaz, a $D011-be írásnak épp a DMA-t közvetlenül követő ciklusra kell esnie ahhoz, hogy a keret eltűnjön, azaz az STA három olvasó ciklusának a DMA előtt be kell fejeződnie). Nem lehet-e véletlenül, hogy ugyanez pont elég ahhoz, hogy Plus/4-en a CPU beírhasson a $ff1e regiszterbe, és néhány ciklussal késleltesse a jobb oldali keret megjelenését? Ha a DMA előbb befejeződik mint a jobb oldalkeret megjelenése (márpedig emlékeim szerint előbb befejeződik) akkor a lehetőség szerintem adott. Vagy nem?... ...Ki kellene próbálni. Kicsit mas a helyzet, ott 38/40 karakter valtassal csinaljak. Azonkivul ha a STA 3 olvaso ciklusa meg a DMA elott befejezodik, akkor az iro ciklus is a DMA elott lesz, (tudod az a 3 ciklus ahol csak irni tud a proci), ugyhogy ha az irast a DMA utan akarod, akkor egy olvaso ciklusnak mindenkepp kell lennie a DMA utan, es akkor mar az iras keso lehet. De meg ha az iras pont a keret elott van akkor is a latcheles miatt valoszinuleg a keret bekapcsol.
Azt probalta mar valaki mi tortenik, ha az $FF1E-be iras (es negalas) utan $E4 es $FF kozotti ertek kerul? Valoszinuleg siman atporog 0-an keresztul.
Pontosabban dehogynem. A 38-40 karakteres uzemmod ($ff07-ben van?) valtogatasvbal badline-on is szedtem le keretet, csak nem tudtam semmit rakni oda. Megcsinaltam, hogy az egyesz kepernyo teruleten leszedtem a keretet, es ott pont ugy ment, hogy amikor a raszter a 40. karakternel tartott, ott kellett 40-rol 38-ra kapcsolni, hogy ne kezdodjon el a keret rajzolas.