Sync, mint szinkronizalas Amire en gondolok, hogy mire jo: pl egyszerre akarod, hogy menjen a hang mondjuk ket csatornan. Ha egymas utan felprogamozod, nem pont egyszerre indul, mert nem nulla CPU ido, amig beirogatod sorba a regiszterekbe. De mivel a sync bitek egy porton vannak, azzal "tartod" hogy ne induljon el a counter, felprogramozod a megfelelo erteket, majd egyszerre inditod a sync bitek torlesevel, es igy tuti szinkronban futnak. Gondolom en, hogy erre jo

én is így tudtam, de ennek kb nulla értelme van, azért gondoltam hogy nem értem
(basic-ben van értelme ilyesminek, lásd a sync parancs a sound-ban, asm-ban semmi...)

Ha nem hang, hanem időzítés a célja, akkor van értelme, mert a sync bit törlése után pontosan a beállított időtartam után történik megszakítás.

Megfelelően időzítve hangnál is van értelme, ilyen effektust valódi analóg szintetizátorokban is használnak, illetve ha jól emlékszem, a SID is tudja, csak a DAVE esetében nem lehet automatikusan másik csatornával időzíteni, hanem szoftveresen kell újraindítani szabályos időközönként.

akkor van értelme ha a hullámformát szinkronizálja. vajon ez megtörténik?
mert pl basic sync-nél nem, ezért van az hogy két ugyanolyan hang random erősíti vagy gyengíti egymást, ami tök jó effekt lenne ha lehetne kontrollálni

Egyszerű sync példa:

(Attachment Link)

huh ez nem semmi. na pont erre gondoltam! és ezt én sose használtam hang meg zene kódolásban! tök jó

Egy másik lehetséges használata a csatornák fázisának a szinkronizálása. Ezzel és a felüláteresztő szűrő effektussal például megoldható a négyszögjel kitöltési tényezőjének a csökkentése.

na ez az! és épp ez az ami nekem tökre kimaradt, illetve valszeg próbálkoztam vele, de mivel nem értettem a működését, nem tudtam értelmes eredményt kihozni belőle...
és hát ügye ez az egész hiányzik az összes zeneszerkesztőből is, meg a játék vagy demó zenékből is...

ha basic-ben elérhető lett volna, akkor lehet hogy többen felfedezik és használják...

Találtam egy EP konfignyi cuccot itt bent a munkahelyen

4MHz-es valódi gépen az ep128emu értékeivel egyezik meg.

Miert nem lepodok meg, eleg pontos emulator az Majd jol kikapok IstvanV-tol hogy nem bizok benne, hogy jol csinalta Amugy egesz pontosan egyezett?

Turbóval az utolsó sor változik, 50/51 6MHz-en, 7EC 7.12-n.

Es a tobbi nem? Pedig elvileg tobb utasitas "fer el" ugyanannyi ido alatt, amit gondolom eppen ezert a kulso interrupt forras (VINT a Nick-tol) le is "fulelt". A Dave belso dolgai akkor azert nem valtoztak, mert a Dave orajelet is emli a turbo? En kicsit itt elvesztem, mert ugye elvileg van az 8/12Mhz oszto allitas, pont azert mert az EP tervezoi mar gondolhattak a 6MHz-es turbora? Akkor viszont nem teljesen vilagos, mert turoboval a teszt program nem ugyanazt irna ki, hiszen allitom a 8/12Mhz bitet is. Vagy bocs, ha hulyseget mondok, ez a turbositas meg mindig feher folt nekem, hogy most minek az orajelet emeljuk konkretan a CPU-n kivul persze, es o honnan kapja, es mas kap-e tobbet

Igen, ill. itt-ott van 1-1 értéknyi szórás, de az minden programfuttatáskor változik.

Az mondjuk nem csoda. Azert van, mert ugye attol fugg mikor valt pontosan szintet az adott int source "level" erteke a B4 portot olvasgatva. Elvileg pont az emlitett sync bittel a TG source-ok eseten lehetne ezt "stabilizalni" persze, csak akkor lehet pont az veszne el ami most gondolkodba ejtett: hogy mi a kulonbseg most a Xep128 es az ep128emu+igazi EP kozott, ami nyilvan valahol az en hibam, csak meg azt nem tudom pontosan, hogy hol Koszi a tesztet!

Az előbbi forráskód részletekben nem látni a hibát, talán máshol van. A teszt programban érdekesség, hogy a frekvencia értékek (7D00h és FA00h) nem ábrázolhatók 12 biten, de ennek elvileg nem kellene problémát okoznia, mert a TG megszakításra az effektusoknak nincs hatása, ezért a felső 4 bit itt figyelmen kívül hagyható.

Ez tenyleg igaz, latod erre nem is figyeltem De ahogy mondod is, elvileg hibat nem okoz, ugyan pl ep128emu-n (Xep128-ban azert nem, mert nincs implementalva hehe) a counter-ek felso byte-janak felso 4 bitje ugyan allit egy-ket dolgot, de nem kene, hogy az barmi problemat okozzon - mivel a tobbi hangkepzessel kapcsolatos bit, a TG interrupt TG0 meg TG1 forras eseten meg ugye is  - ha jol tudom - csak az oszcillator alapfrekvenciajat nezi. Azert atirtam ertelmesebb counter ertekekre most!

Egy másik kisebb "hiba" a programban az, hogy a VINT bemenet nem 50% kitöltési tényezőjű négyszögjel, ezért "véletlenszerűen" méri a VINT magas (rövid) vagy alacsony (hosszú) állapotát.

Igen, ezt tudom A VINT-et (INT1) csak otletszeruen tettem hozza, tisztaban vagyok vele, hogy igy van valoszinusege, hogy esetleg a rovidebb, de rendszerint a hosszabbat meri. De alapvetoen a teszt program nem erre keszult, azt csak ugy "poenbol" rakta hozzam, tul sok ertelme igy tenyleg nincs

Amugy most tanacstalan vagyok. Kicsit atstrukturaltam a test programot, elvileg pontosan ugyanazt csinalja mint eddig, csak kevesbe ronda a kod. Es most latszolag jol mukodik megis a Xep128-al is, kb +/- 1 teszt pont elteressel ugyanazt irja mint az ep128emu. Jajj, de utalom az olyan bug-okat, ami csak eltunik "magatol" es nem jovok ra, mi volt a hiba ...

Na mind1. Commitoltam az ujrabb test program forrast:

https://github.com/lgblgblgb/xep128/blob/master/doc/intfreq.asm

Ha mar szoba kerult a VINT probaltam nemi ganyolas aran (egyszerubb lenne a tesztben nem change-et nezni hanem fixen fel v le futo elt, de lusta voltam, meg ugye 1Hz interrupt miatt meg tovabb kene varni akkor) meri mindket "felet" a negyszognek. Igy igen erdekes, hogy ket a szam-"csoport" pont meg van cserelve Xep128 es ep128emu kozott, azaz lehet hibasan hasznalom a level szintet a VINT-nel Legalabb meg valami kiderult, hmmm. Alakul ...

Bocsanat a tema flood-olasaert, nem Dave specifikus dolgokat mar nem ide fogom loni persze.

Koszonom IstvanV es Zozo segitseget!!