Igen nekem is ez a masik modszerem. Az fli-nel asszem igy csinalom. Igyenkor viszont dupla megszak kell, azaz lassabb a dolog. Es a kitudja hany nop miatt nem is feltetlenul rovidebb.
single clock uzemmodba kapcsol a TED a rasztersor vege fele
Ennek ket oka lehet, vagy letiltottad explicite a double clock-ot (FF13, bit #1) vagy bizonyara a DRAM refresh-re gondolsz, ahol 5 ciklusban single clock-kal megy a proci...
Ja es van egy olyan sideeffektje a kododnak, hogy a double speed-es burst resz a sor vegen nem indul el, ott is single clockban megy a proci, ezert kell annyit irnod a masodik $ff1e-be amennyit irsz.
Na akkor meseld el, hogy ez mi! Mert tenyleg allitanom kellett masodik irast, hogy stabil legyen.
Na nekem is el kellene mar olvasnom a doksikat amik fellelhetok, nem csak mindig kiserletezni! :)
Egyebkent az miert van, hogy meg kikapcsolt kepernyonel is ugy tunik, hogy single clock uzemmodba kapcsol a TED a rasztersor vege fele.
Ha igazad van, akkor: a fenebe! :) Marpedig valszeg igazad van, mert eddig tenyleg nem sikerult semmit rakni oda. :( (Egyebkent az eor #$ff-el kapcs igazatok volt.)
A five magic-ban egyebkent tulkeppen mi van? Meg nem sikerult megneznem.
Ja es van egy olyan sideeffektje a kododnak, hogy a double speed-es burst resz a sor vegen nem indul el, ott is single clockban megy a proci, ezert kell annyit irnod a masodik $ff1e-be amennyit irsz.
Ha biztositja az ember, hogy az interrupt NOP-okon tortenjen ami eleg egyszeru, akkor egy sokkal rovidebb kodreszlettel lehet stabilizalni.
De az is megcsinalhato, hogy meg az interrupt elott stabilizalod ezen NOP-ok es az interrupt egymashoz viszonyitott fazisat, es akkor az interruptban mar nincs szukseg semmilyen szinkronizalasra, mar a kivaltas is stabil helyen tortenik.
Bubis meg este megneztem a kododat, csak aztan a UPC megallt, ugyhogy most mondom a kommenteket.
Ez amit irtal gyakorlatilag ugyanaz mintha 38/40 valtassal szedned le a keretet, tehat az extra helyeken csak a hatterszint latod semmi mast. Ha lecsereled a ket $ff1e irast $ff07 irasra, mukodik is rendesen (persze az A es X erteket updateld). A $9a ciklusban van az elso $ff1e iras, ez a ciklus ugye 2 cpu altal hasznalhato ciklussal van a DMA vege utan, es pont az utolso megjelenitett karakter elso feleben fut, ezert meg a latchelesbe belefer a keret inditas kesleltetese, de mivel a bitmap fetcheles mar regen leallt es mar az elozo ciklusban RAM refresh ment, ezert nem is fog a TED semmi megjelenitheto informaciot beolvasni ezekre a teruletekre.
Szinte szóról-szóra ugyanezt a módszert használtam, azzal a különbséggel hogy nem jutott eszembe a cmp #$c9-es poén ;-), ezért a 2x ciklussal NOP-okkal, a maradék 0+1 ciklussal pedig egy feltételesen végre- vagy végre-nem hajtódó bcs *+1 -gyel bántam el :-).
Ami engem illet, a kov. TED-es dolog amit meg szeretnek csinalni az a DMA delay. Bar nem az, csak hasonlo, de mind1. :) Termeszetesen annak a forrasat is kozre adom majd.
Heh, nyilvantartanak :-) Nyilvan tartanak tolem ( (C) Kontroll Csoport? ) :-) A problemat Luca jelezte. Ha kiprobalsz olyan zeneket, mint pl. ami a Treasure Island-ben van akkor hallhato... Az utolso pillanatban attertem a Te pwm tablad hasznalatara a regi helyett, es abban faltol-falig ertekek voltak (0-65535). Ezt ugyan normaltam 0-255-re, mert 8-bites a buffer, amit hasznalok, am a regi tablamban 0-127 kozotti ertekek voltak. Na most ha ketszolamban mindket csatorna ugyanazon frekin jatszik akkor interferencia helyett ilyen recsegesfele lesz belole (ezt hallhatod is a 0.46-ban, sajnos). A filternek nincs ra hatasa... Ezt egyelore ugy oldottam meg, hogy 0-255 helyett 0-127-re normaltam a tablazatot. Van ezzel meg mas gondom is, de majd talan jobb ezt privatban ;-)
Jut szembe: mit szoltok Bionic/Synergy "talalmanyahoz"? Nagyon erdekelte a noise sample, elkuldtem neki is, es erre masnap meglepett a shift regiszter feltetelezett rajzaval... :-)
Hasonlo tema: kozben probaltam atirni a DirectSound kodomat, mert neha betorzit (olyankor gyors oda-vissza kell kapcsolni mas alkalmazas es a Yape kozott). Sikerult is egy szepen jatszo kodot csinalni, de ez most meg neha akar egy mp kesesbe kerul az emuhoz kepest. A hajamat teptem :-( Mindegy, ennek majd igyekszem utanajarni, amennyire idom engedi, es akkor majd kicserelem a DSound kodot az ujra.
Tenyleg! Latjatok, hogy hogyan stabilizalom ki a raszter megszakot. Ha nem lenne vilagos ff1e alapjan a bpl-el beleugrok egy kodba (sok cmp, vegen nop) aminek az a jo tulajdonsaga, hogy ha barhol egy byte-al kesobb ugrassz bele, akkor egy ciklussal gyorsabban hajtodik vegre. Igy meg ugyanazon a rasztersoron ahol a megszak tortent stabilizalni lehet. A kereten egy kicsit modusul a kod, ez screenen jo, ahol nincs badline.
A kerdesem az, hogy milyen stabil raszter eloallitasokat ismertek meg!
Igen, annyi. Illetve mintha meg lenne 4 pixel pluszban (Levente irta ezt anno a listara), de ezzel mar nem foglalkoztam... A Funet-en (is) fenn levo TED doksi ha jol emlekszem viszont meg mintha 4-4 karakter szeles keretet jelezne (a hblank helyek alapjan). A vege az lett, hogy megneztem a TV-kartyamon, es ott hatarozottan 3-3 latszik :-)
Congrats a keret-magichez ;-). Most nem tudom kipróbálni mert melóban vagyok, majd este kísérletezek.
A keret tényleg kisebb mint 64-en. Úgy számolhatsz, hogy C64-en (emlékeim szerint) 63 ciklus van egy sorban, Plus/4-en pedig 57 (mivel más az órajelnél az osztásviszony). Ennyi számú ciklusból 40 a karakteres mező, + x (konstans) a vízszintes visszafutás ideje, a maradék pedig keret. Ezért Plus/4-en a keret "jóval" (kb. 2-3 karakterrel oldalanként) kisebb, ill. kicsit más ("szélesebb") a karakteres mező aspect ratio-ja.
Attila, közben figyelem hogy történések vannak hanggenerátor-téren ;-), ma igyekszem kipróbálni az ötletemet a szűrésre ill. közben elmondhatnád, mi az amit ténylegesen sikerült kijavítani tegnap este (amiről Luca beszélt :-) ).
Most ugrott be, annakidején süldő basic guru koromban írtam egy kis proggit, aminek az volt a lényege, hogy ha megnyomtam a tekerés gombot a magnón, akkor a + , - gombokkal lehetett szabályozni a sebességet, hogy milyen gyorsan tekerjen. Egész lassú is volt, kb a play sebesség 10-ed részétől full speedig lehetett állítani... Jó móka volt.
Ennél kicsit durvább, amit egy nyíregyházi srác csinált, ő lelassította a motort hardveresen fele sebességre, hogy kétszer annyi cucc férjen el a kazettán. Arra már nem emlékszem, hogy működött-e, de volt egy kis kapcsoló kivezetve, ami sebességet váltott, sőt, egy kis hangszóró is volt beépítve, hogy lehessen prg. elejét keresni gyorsan.
Tényleg, Nyíregyháza szinte az egyetlen város, ahol nem tudok pluszis csapatról, kóderről, hogy volt-e valaki egyáltalán... Any info?
Más: végre szóra bírtam az OCEAN drive-omat a PC-hez kötve x1541 kábellel, hála egy WINBOND ISA-s I/O kártyának. Úgy tudtam bejumperolni, hogy találtam egy fotót interneten egy ugyanolyan kártya hátoldaláról, azzal a különbséggel, hogy arra rá volt szitázva a jumer settings tables. :DDDD
Szóval ha valakinek Debrecen környékén át kell pakolni cuccost PC-re, akkor mostantól jöhet. (csak sört kell hozni cserébe...) :)
Ez a tolto erdekelne... El tudod kuldeni vagy ilyesmi? Az konnyen kideritheto, hogy gyorstolto-e. Ha a drive cpu PC-je $0000 es $0800 kozott kovalyog, akkor legalabbis nem a ROM rutinokat hasznalja, es mivel lassabb toltot minek irna valaki a ROM-nal (nehez is lenne! :-) ), valoszinuleg gyorstolto.
Milyen jó, hogy ezeket írtad. Köszi! A 3 db 0-ra emlékeztem, de nem ellenőriztem le.
Most megnéztem, a hiba abból adódik, hogy amikor NEM MONITORBÓL töltöm be, akkor az $1001,$1002-n levő cím nem nullára mutat. (MONITOR-ból töltve jó.) Ez már csak azért is érdekes, mert más tömörítőkkel nem jártam így. De ezzel mindig. Pedig sokféleképpen kipróbáltam.
Kérdés:
Nincs valakinek olyan loader-je, amit emu alatt is lehet használni? Találtam egy csomó régi loadert, de sajna egy se megy, pedig szerintem ezek nem gyorstöltők. Lehet, hogy be is szúrok majd ide egy asm forrást, mert igazán nem sok, pár byte az egész.
