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.
"Jo kerdes hogy mi tortenik ha a CPU irni akar, ha jol latom a kapcs rajzbol, akkor a WRT az negalt, tehat 0 ertek igy valoszinuleg sikerul is neki. Egyebkent ennek a kihasznalasaval lehetne oldal keretet bontani DMA soron is, bar elegge at kell gondolni azt a kodot :)) (ugye ertelmes is legyen, meg hat az is fog megjelenni a kepen mint character/color info... :)))
Ha megvan meg kuldjetek mar el ezeket a pelda progikat, erdekelne hogy nektek hogy jott elo, en amikor ebbe belefutottam, akkor nem $ff1e-t irtam. "
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.
(Bubis talán már tudja... :-) ).
L.
Ps. meséljétek már el, hogy' a bánatba' lehet idézni ezen a lapon!...
Bocsesz, hétvégén egy GSM-linken lógtam azaz nem tárcsáztam be ha nem volt életbevágó ;).
Crown:
Látom, ha a sorszinkron "rövid" vagy "hosszú", mert az öreg mittoménmilyen (vagy 20 éves) színes TV amit használok sokkal idegesebb (gondolom) vagy legalábbis elég ideges az ilyen poénokra. Ezért tudtam, hogy az 56 a helyes érték. A kikapcsolt képernyőről annyit, hogy direkt olyan rutint akartam ami hasraütésszerűen valahol kikap egy értéket $ff1e-ből, csinál vele valamit majd a _kezdőponthoz képest_ x ciklussal visszaírja (ezt asszem nehéz korrektül abszolválni felkapcsolt képernyővel). Ilyen alapon tehát az sem véletlen hogy "a vandorlo $ff1e pozicio irasok nem irtak olyan pozicioba, ahol gondot okozhattak". Ha okoztak volna, az épp annak a jele hogy rossz a ciklusszám (...azaz volt egy jól működő mutatóm, és végeredményben épp ezt akartam).
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.
Bubis: Mivel fejlesztesz PC-n pluszira?? Szeretnek kiprobalni par dolgot, de az emulatorban fejleszteshez nem nagyon van kedvem...
Csabo: nem igazan emlekszek olyanra, ami kimaradt volna, sot sok olyan volt, amire mar nem is emlekeztem :)) Egyebkent, ami pontatlansagot talaltam, azt megirtam mar Lavinanak.
Nem probaltam, de elhiszem, hogy megy! Meg meg kell neznem a sajat dolgaimat. Az egyiket mar megneztem, ott kepernyo teruleten ugy csinaltam stabil rasztert, hogy az elso ff1e-be valo irasnal #$7e-t tettem bele, azt amit ott olvasnek, es stabil maradt. Ez meg ha jol olvasom bele fer abban amit itt irtatok. Viszont amikor kepernyot szelesitettem akkor valahol a rasztersor elejen csinaltam ugyanezt, ott is azzal az ertekkel amit ott olvasnek es azt is stabil volt. Szoval lehet, hogy rosszul emlekszem, de ha nem (es a multkod is pont emiatt a pelda miatt mondtam) akkor megsem teljesen ugy vannak a dologk ahogy irjatok. Ma este megnezem. A magyarazat esetleg az lehet, hogy en nem kikapcsolt keretnel birizgaltam a $ff1e-t. Egyebkent annak adom a nagyobb valoszinuseget, hogy valamire rosszul emlekszem.
Hali,
Kimertem, ha double clock ciklus-ban irod az $ff1e-t akkor azonnal atirodik, mig ha single clock ciklusban akkor csak a kovetkezo ciklusban irodik felul. Ezert volt 56 ciklus.
Volt a Fillér utcaban (XIII. kerulet) egy szerviz, ahol meg par eve is javitottak Commodore-t. De mar akkoriban is azzal fenyegetozott a tulaj, hogy leallnak vele (nincs uzleti erzeke). Egy oreg bacsi volt ott az egyik szervizes, valami hihetetlen szeretettel bant minden regi 8-bites geppel, venni is lehetett mindenfelet: TVC, C16, C+4, 1541 drive, Enterprise, Amiga-k... Nem tudom mi lehet a bolttal, a bacsi privat telefonszamat meg elhagytam :-( Azota is verem a fejem a falba. EGyebkent a boltrol pont ebben a topicban hallottam eloszor, valamikor az eleje fele :-)
Hmm, kiprobaltam bekapcsolt kepernyovel is, 56 a jo ciklusszam. Az also biteket el is felejtettem, pedig beszeltunk errol a plus4 lev listan anno...
Latcheles lesz az a ket ciklus kozott, ha olvasaskor mar novelt lenne, akkor 1-el nagyobbat irnal be. De megnezzuk mindjart fast mode-ban, paros es paratlan cikluson is irva...
Fundamentalis hiba!!! :)) Eloszor is a single clock-os modban 2 ciklus-al korabban irod vissza nem 1-el (van ugye ott egy double clock-os ciklus is...)
Masreszt csereld le az utolso NOP-ot BIT $FF-re,
2 helyett 3 ciklus, es meg mindig mukodik :)))
Az 56 ciklusos kodod valoszinuleg 1 karaterrel kisebbre vette a kepet vizszintesen, ami meg tok meglepo modon de belefert a TV tureshataraba, viszont te nem lattal belole semmit (ugye keret nem nagyon lathato). Az viszont mar csak tenyleg tok veletlen, hogy a vandorlo $ff1e pozicio irasok nem irtak olyan pozicioba, ahol gondot okozhattak.
(58 es 59 ciklus is stabil volt) (60-nal mar ugrott a kep, de arra is ra tudott szinkronizalni...) Hmmm, ezzel adtal par otletet... :)))
Be kapcsolt kepernyonel teszteljel, sokkal tobbet lehet latni, persze bonyolultabb a kod is...)
sei
lda #$0b
sta $ff06 ;kép kikapcs
lda #$d2
sta $ff13 ;kétszeres óra tiltása
lda #$ff
l1: cmp $ff1d ;várunk, míg biztosan kikapcsolt képernyőn vagyunk ;-)
bne l1
l2: lda $ff1e ;let's get down to business...
eor #$ff
lsr dummy ;8*6 cycles
lsr dummy
lsr dummy
lsr dummy
lsr dummy
lsr dummy
lsr dummy
lsr dummy
nop
sta $ff1e ;Roast!
jmp l2 ;loop
A prog beolvassa $ff1e-t, invertálja az értéket, vár egy sort, majd az értéket visszaírja.
Ha a rutint futtatod, módosítatlan kikapcsolt képernyőt kapsz, azaz a kérdéses pillanatokban az írás ellenére a TED belső regiszterei nem változnak, azaz az egy sorral korábban kiolvasott és invertált érték beírva ugyanazt az értéket eredményezi mint ami az adott pillanatban a belső regiszterben is van.
Néhány komment és magyarázat. $ff1e kiolvasása az LDA utolsó ciklusára esik. A kiolvasás pillanatához képest az írás érvényre jutásának pillanata 56 ciklussal később van (és nem 57, mint a teljes sorhossz). Azaz egy ciklussal "korábban" kell beírni a kiolvasott és invertált értéket a kiolvasás pillanatához képest ahhoz, hogy a módosítás ellenére minden változatlan maradjon. Ennek a magyarázata szerintem belső szinkron-dolog lehet. Feltételezésem szerint a beírás némi időkésleltetéssel válik csak érvényessé a TED-ben. Az is lehet, hogy a kiolvasáskor az adott ciklusban már megtörténik a belső számláló növelése, és a CPU ezt a megnövelt értéket olvassa ki, az írás viszont még arra a pillanatra esik amikor az inkrement még nem indul el (tehát íráskor a ciklus végére a regiszterben levő érték ténylegesen a beírt + a növekmény lesz). ...Valahogy ki kellene próbálni hogy mi az igaz.
(Tettem egy kísérletet úgy, hogy nem tiltottam a kétszeres órajelet. Ugyanezt a viselkedést kaptam, azzal a különbséggel hogy 56 helyett 108 ciklust kellett az írás és az olvasás között -- ennyi, azaz az alapvető viselkedés nem változott. Az mindenesetre érdekes, hogy a gép nem rágott be az időnként single, időnként double clock ciklusokra eső olvasások és írások miatti pontatlanságra :-O. De ez valószínűleg a köv. dolog miatt van).
Íráskor a regiszter alsó két bitje redundáns, nincs bekötve, azaz nincs hatással a belső regiszterre. Ezt a köv. módosítással ellenőrizheted: az sta $ff1e előtti két utasítást cseréld ki erre:
sta dummy
and #$fc
ora #$00
Az ora paraméterének változtatása (0-3 között) semmilyen képernyő-változást nem okoz.
(Olvasáskor minimum egy bittel több érvényes, ill. lehet hogy mind be van kötve, csak a CPU nem tud olyan "sűrűn" olvasni hogy a legalsó bit változása is detektálható legyen).
Vegigolvastam a topicot, ra is ment par oram.
Nehany hozzaszolas:
Gaia (830)-as post
A tobbit meg emesztem (majd kuldd el a progit plz), de azt bizonyara tudod, hogy a dma bufferen belul is van egy indexvaltozo, ami szinten nem kezd addig noni, amig az elso bad line nem volt meg. Addig a TED vszleg az utoljara a buszon maradt erteket olvassa. Ha az FF06-ba $1F-et irsz Te is lathatod, hogy legfelul "bescrollozodik" egy -1. karaktersor, amiben mindig ugyanannak a karakternek ugyanaz a rasztersora latszodik.
Az stabilan a $ffff cimrol olvasodik be, semmi karakterhez nincs koze. Annyi tortenik, hogy a TED bitmap fetcher meg nem indult el, igy azokon a sorokon a TED a default allapotba rakja a cimbuszt ami $ffff. Ertelemszeruen ha ROM be van kapcsolva, akkor onnan jon az adat kulonben RAM-bol.
bubis (832)
Volt ami a kiserletezgetes soran egy kicsit meglepett. Ugy tunik, hogy $FF1A-$FF1B a karakter soron beluli 7 es 8-adik rasztersor kozott no 40-el. Tehat az utolso rasztersor elejen mar hozza van adva 40. En azt vartam volna, hogy csak a kov. karaktersor elejetol talalom ott a megnovelt ertekeket. Azt nem tudom megmondani egyebkent, hogy melyik ciklusnal frissul az erteke, en csak ugy mertem, hogy egy rasztermegszakitas elso utasitasa $FF1B-t olvasta.
A pontos ciklust megtalalod a plus4 lev lista archivumaban, annak idejen kimertem, (ha valakinek kell nekem megvan a teljes archiv 1998/05-tol 2002/01-ig) de ide is irom az infot. A regiszter noveles $92 es $96 kozott tortenik (Ezek $ff1e ertekek). Torles a $137 sorban $c0 es $c2 kozott tortenik. A torles-t at lehet lepni.
bubis (837), TLCCNS (843)
> Egyebkent amikor FF1E-t piszkaltam, neha olyasmi tortent, mint egy runstop+reset eseten, es a PC olyan helyre mutatott ahol nem is futott a kod, de nem tudtam rajonni, hogy hogyan all elo ez az ertek. :) Azt hiszem meg meg is vannek ezek a kodjaim.
Nekem is volt vele hasonló kalandom :-). Olyan volt, mintha a rutin néhány byte-ján "rejtélyesen" átszaladt volna a PC, anélkül hogy az ottani utasításokat a CPU valaha végrehajtotta volna :-). Sose' jöttem rá, hogyan csinálja. :-/
Ilyenkor valoszinuleg a kovetkezo tortenik (meg nem ellenoriztem le, csak teoria): sikerult rabirnotok a TED-et es a CPU-t hogy ugyanabban a ciklusban cimezzek a rendszerbuszt. A tenyleges cim ugy kepzodik, hogy ha barmelyikuk is 0-ra allitott egy cim vezeteket, akkor az 0 lesz, es csak akkor 1 ha mindketten 1-ben hagytak. A kiolvasott adatot mind a CPU mind a TED fel fogja hasznalni arra amit epp az adott ciklusban akart csinalni. Igy aztan nagy esely van arra hogy a CPU eppen olyan cimrol olvas opcode-t ahol BRK (0) van -> belepes Monitor-ba (Bubis), vagy eppen szerencsed volt es ertelmes kod volt ezert aztan ugy tunik hogy bizonyos kod resz nem hajtodott vegre (masik eset). Jo kerdes hogy mi tortenik ha a CPU irni akar, ha jol latom a kapcs rajzbol, akkor a WRT az negalt, tehat 0 ertek igy valoszinuleg sikerul is neki. Egyebkent ennek a kihasznalasaval lehetne oldal keretet bontani DMA soron is, bar elegge at kell gondolni azt a kodot :)) (ugye ertelmes is legyen, meg hat az is fog megjelenni a kepen mint character/color info... :)))
Ha megvan meg kuldjetek mar el ezeket a pelda progikat, erdekelne hogy nektek hogy jott elo, en amikor ebbe belefutottam, akkor nem $ff1e-t irtam.
