Prioritní je teď pro mně vědět na jaké rychlosti se bude hrát druhá krátká melodie. Když ji budu znát a bude to situace umožňovat, budu moci třeba zvýšit pracovní frekvencí programu i se současným časovačem v rozsahu 5 bitů, kde se současná skladba hraje pouze na rychlosti 4 (0-31). Proto jsem dělal ty manévry s rychlostmi... .

Tak vypisování a mazání textu za mně již svižné. Tím že hraju skladbu rychlostí 5 jsem si odrovnal funkci volume slide, protože u ní dělím číslem 4 pomocí rotace bitů a po technické stránce je tedy volume slide přístupné pouze pro hraní skladby s rychlostí násobku čísla 4, ale asi vím o úpravě a možná hodně jednoduché, jak tenhle efekt zpřístupnit i pro ostatní rychlosti třeba i 5. Teď jsem dělal hlavně to svižnější mazání textů a i drobnou optimalizaci kódu.

Teď jsem přemýšlel co s tím občasným "zakopáváním" ve zvuku. Já vím, jak bych to spravil, zvýšil bych vnitřně rychlost hraní rutiny. To bych již šel do násobku té současné rychlosti, aby jsem se dostal i na rychlosti se kterými pracuje i klasický formát MOD. A dokonce by ta úprava ani nebyla nějak složitá, ale asi se mi to nechce dělat z důvodu, že s tím nemám nějaký problém. Mně to tam vždy spíše pobaví a tak asi napíšu v textu že jsem si toho vědom a hudební rutinu nechávám i tak na nižší frekvenci.

Chvíli jsem se bavil na tom, jestli se zeptám na názor hudebníka, ale pak jsem si uvědomil, že již o něm vím, že má efekt zakopnutí ve skladbě rád, i když jeho efekt je řízený a je na stejném místě ve skladbě a ten můj náhodný, ale ano, když si řekne ať to odstraním, odstraním to, ale předpokládám že s tím nebude mít asi taky problém 🙂

Již se nějakou dobu těším ještě na 1 režim zobrazování textu a myslím, že je již na to hudební rutina celkem předchystaná, jen řeším standardně věci se kterými jsem nepočítal 🙂

Samozřejmě efekt zakopnutí kickbasu ve zvuku se projeví pouze, pokud píšu text v režimu více písmen naráz. Je to jednoduše již moc cyklů kým program pustím dál. Tam by pomohlo zvýšení frekvence pracování samotného programu, jak jsem již psal, protože moment ve kterém se samply hrají by byl přesnější.

Hlavní časovač v hudební rutině CIA mám na hodnotě 2f56 hexa 🙂

​​​​​​​Čím větší je tahle hodnota tím rychlejší je hudební rutina, protože zaplňujete pomocí CIA čas, a každý čas, co se takhle musí zaplnit je čas v kódu který se dá využít i jinak 🙂
​​​

....tak a teď si konečně můžu s programátorma, co mají hudební rutinu s CIA časováním porovnávat pinďoura na kolik kdo má nastavený časovač CIA.

Začal jsem si klást dotaz a co když budu chtít zahrát jinou skladbu jiným tempem? Tím že jsem časovač používal v plném rozsahu bylo nejpomalejší tempo hraní skladby právě dané. Pomaleji by to již nešlo. Podíval jsem se tedy do dokumentace Octamedu jak to dělá s tempem on. Základní rozsah má od 1 do 20 hexa. Já mám rozsah od 0 do 1F hexa. Tedy stejný jen posunutý o jedničku. Prosím já nic nekopíroval to sám! 🙂 Jednou jsem přidal časovači 1 bit, tedy jsem přešel z 4 na 5 bitů. Původní MOD hraje na rychlosti 5. Já tedy nastavil rychlost 4 a došteoval jsem hlavní časovač přímo v rutině (ne tenhle 5 bitový), ale CIA tak aby mi skladba hrála stejnou rychlostí jako originální MOD. Tím že mi vnitřně program jel 6 krát pomaleji z rychlosti 31 na 4 (0-31) tím jsem začal bojovat s rychlostí programu píšící text. Udělal jsem drobné úpravy, dal vše na maximální rychlost a celkem se povedlo. Jediné co se mi nelíbí je takový můj žertík jak mažu text a asi ho nepoužiju a udělám to jinak (chtělo by to alespoň dvojnásobní rychlost).
Teď bych měl mít moji rutinu rychlostně nastavenou stejně jako u hraní MODu když se používá tempo v rozsahu 1 až 20 hexa na Octamedu a asi i jinde, pokud je nárůst tempa lineární.

Sem tam mi moje rutina hudebně "zakopne" ale je to v místě kde vypisuji text jinak, ale je to třeba jednou za 10 minut a třeba se to ještě zlepší. Přeci jen stylem jakým vypisují text, že měním 2 způsoby na 1 obrazovce, to dělat nebudu. Uvidím vše testuji.

Musel jsem doladit v mém formátu ve skladbě 1 místo, které mi začalo po úpravách dělat ve zvuku puknutí. Již to bylo na hraně a po úpravách se to projevilo. Tak jsem sampl ztlumil o 1 moment dříve.

Zapracoval jsem i na části kódu píšící text v jeden moment. Ale není hotovo, mně teď zajímalo hlavně to tempo hraní skladby.

Samozřejmě možnosti je víc jak zrychlit vnitřní rychlost mého programu. Zatím zůstávám u časovače na 5 bitech na rychlosti hraní skladby 4... .

Tak první verze psaní textu vícero písmen naráz v mém jednoduchém textovém enginu hotova. Vypsal jsem 3 řádky naráz a zvuk se u toho neškubl, vše zatím v pohodě. Celkově můj engine teď pracuje se 3 rychlostmi psaní textu. Druhá rychlost je vnitřně v programu nastavitelná, tedy má svůj vlastní časovač.

Poslední chybu jsem odstránil tak, že jsem ji již neměl chuť hledat, pustil jsem si film Mortal Kombat 2, hned jsem ho vypnul, pustil jsem vývojové prostředí a chybu za chvíli našel, uložil verzi a pustil opět film MK2 který mi teď běží, jen tak na pozadí...

Tak snad problém vyřešen, testoval jsem poslední bit v Longu místo posledního bitu ve Wordu. Jsem byl již zblblej s tím, že u registru D4 pracuji s posledním byte ale v rámci čtení dat z formátu kde bit testuji pracuji jen s Wordem, tedy se 2 byte.

Tak hledám chybu v kódu a měl jsem za to že již mám problém vyřešen v závěru jsem jen zapomněl obnovit 1 registr tak jsem ho obnovil a chyba se opět začala projevovat. Tak jsem na zálohu 1 registru použil na test registr jiný, který se v části kódu ve kterém se hrabu vůbec nepoužívá aby jsem měl jistotu. Chyba se projevila. To jsem si řekl, to není možný. Šel jsem na kód, kde daný bit do registru dávám a byl jsem přesvědčen, že se ale nemá důvod prozatím vykonat a on se opravdu někdy vykoná. Jednoduše si mou chybou při ne zcela odšéfovaném kódu tam ten 1 bit do registru D4 vrazím hluboce přesvědčen že při daném stavu ho tam ale nedávám a pak se divím že ho tam mám a začnu hledat všude kolem co se děje, proč ho tam mám když tam ještě nemá být. Jak jsem si dal to poznámky jenom tu instrukci OR kterou tam ten 1 bit dávám tak začal být celý kód stabilní. Tak se na tu část kódu ještě musím podívat.

Jak jsem si ten registr jen obnovil a chyba se projevila s čím jsem nepočítal a měl jsem za to že mám problém vyřešený malém mně omylo.

Jak jsem dal ten OR dal do poznámky (přesvědčený že se ještě nemá vykonat) a začal být kód stabilní tak jsem sprostě řekl. Ty kurva jedná proč se vykonáš?

Jeden z mých vypetejších momentů v rámci programování. Tep již mám opět v normálu.

To vypadá že si datový registr můžete vyblokovat i v případě, že jej v dané části kódu zrovna nepoužíváte, provedete v téhle zrovna nepoužívané části kódu rotaci, v druhé větvi programu rotaci se stejným registrem neprovedete a máte smůlu. Obě větve programu se sice vykonávají přibližně ve stejný čas, ale vždy jen jedna z daných dvou programových větví. Tímhle způsobem si vlastně můžete znepřístupnit správná data v obouch programových větvích.

Pokud tomu všemu dobře rozumím. Asi mám další zkušenost za sebou o tom co dělat, aby jsem si data v registry sám nevyblokoval a měl přístup ke správným datům.

No nic, budu to muset hodit do jediné programové větve.

Ještě bych tu rotaci bitů mohl zohlednit v části programu kde ji nevykonávám. To bych se ke správným datům snad dostal. Nazval bych to lišákovo programování pomocí zrcadlového efektu.

Tak kvůli nekonečnému cyklování úseku skladby v mé rutině jsem ten kód včera opět celý předělal. Ta funkce s logikou kódu zamíchala více, než jsem čekal. Tempo hraní skladby je od posledního nastavení vpořadku. Testoval jsem na nekonečném cyklování dokud mně to bavilo poslouchat a zároveň hlídat s tempem u originálního MODu, tedy pár minut. V tom zatím 1 ze 2 patternů jsem dnes zoptimalizoval kanál 0 a 3. Ještě pak tedy 1 a 2.
Taky jsem trochu "naháněl duchy" když jsem se snažil přijít na příčinu praskání ve zvuku. Já si to již v minulosti uvědomil, ale tak trochu na to zapomněl a zároveň s tímhle nespojil, ale jsem opět moudřejší. To když se ve zvukovém kanálu mění hlasitost ve větším rozsahu, třeba jí dáte z úrovně 10 na 50 dekadicky, tak vám ve zvuku lupne. Nenapadlo mně a zatím jsem nevěděl, že tohle lupnuti se projeví i když máte DMA přenos daného kanálu přerušený. Tedy nic nehraje, ale lupnuti je přesto slyšet. To jsem nevěděl. Ve 2.kanálu se mění hlasitost skoro pořád snad co 3 řádek patternu a ve velikém rozsahu, tedy lupání ve zvuku je průběžné. Naštěstí kanál s bubny je tak výrazný, že lupání vůbec není slyšet.

Například takový Octamed a snad i jiné s tímhle problém nemá. Je to z toho důvodu, že Octamed nemění hlasitost nástrojů přes HW registr, tam je nastavena konstantní hlasitost, ale mění hlasitost softverově pomocí velikostí amplitudy daného nástroje. Proto u přehrávání MODu není žádné lupání v tomhle případě slyšet a nemusíte mít puštěný ani kanál kde jsou nějaké bubny, hajtky, kick-bass 🙂
​​​

Již nějaký ten den mám v mé hudební rutině zeditovaný 1 pattern ze 2 z nové melodie z MODu do mého hudebního formátu. Ta editace je provedena nahrubo, ještě tam budu něco dodělávat a zpřesňovat. Nemohl jsem jít v přesnější editaci v tom jednom patternu dál, musel a ještě pořád musím nastavit správnou rychlost hraní skladby. Dá se říci že mám možná hotovo ale ještě... . Mám takovou myšlenku v rámci té skladby a potřeboval jsem funkci u mé hudební rutiny aby jsem věděl opustit úsek skladby, pokud ho více krát opakuji a pokračoval v hraní skladby dál. Doposud jsem uměl jen nastavit nekonečný cyklus. Tak jsem tuhle vlastnost do mé rutiny přidal. Časovači pro tohle opakování jsem dal zatím 4 bity a 2 stavy mají svou funkci. Stav Fh (1111) zabezpečí nekonečné opakování. To ještě dodělám. Stav Eh (1110) jsem použil jako info, že se jedná o úplně první (nultý) cyklus opakujícího se úseku skladby. Eh pak vyměním za správný počet a tuhle informaci obsahuje můj hudební formát. I samotná 0 v časovači mi určuje, že se úsek skladby bude jednou opakovat. Tedy celkový možný počet opakování úseku skladby je teď od 1 do 14 opakování, pokud chci úsek hrané skladby opustit, nebo nekonečné opakování.

Dal jsem kód do reální Amigy 1200. Vše hraje a funguje. Nejdříve jsem se ujistil že se v skoku na začátek opakovaného úseku skladby opravdu vracím na správné místo (dělám přímý skok v mém hudebním formátu) a to tak že jsem na úsek před správným místem skoku zahrál nějaký vysoký tón. Pak záměrně jsem provedl skok o 4 byte delší (4 byte = 1 řádek v patternu bez práce jakýchkoliv efektů / nastavení hlasitosti / nahrání samplů a jiných) a chtěl jsem aby se mi vysoký tón zahrál. Vrátil jsem skok na opakovaný úsek skladby, tedy snížil ho o dané 4 byte a nechtěl jsem, aby se mi tón zahrál. Vše v pořádku, skákal jsem na správné místo. Teď vlastně i z hlavy vím že můj 1 pattern má krásných rovných 700 byte. Zpřesnil jsem tempo hraní melodie na úrovní možných 14 opakování. Už mi tam stačí dát to nekonečné opakování a nechám to hrát pár minut jestli mi to uhne vůči hraní skladby u originálního MODu. Originální MOD hraju pod emulací WinUAE s Octamedem, můj formát hraju na Amize 1200 souběžně.

Vtipné momenty v programování:
Měl jsem za to že funkci opakování budu mít hotovou rychleji, nicméně jsem na to potřeboval v programování 4 dny. To ale není hlavní myšlenka. Tím je to, že jakmile jsem si uvědomil všechny souvislosti aby mi to v mém kódu fungovalo změnil jsem celou logiku během asi 10 minut (potřeboval jsem si stihnout jít zaběhat ještě za světla). Jak jsem se opět vrátil k programování jiný den, nastala kontrola kódu a taky ověření, že to dělám nejlépe jak umím. Prokázalo se, že varianta mnou rychle v programování naházena do počítače byla ta nejlepší a nedokázal jsem ji jakoukoliv jinou alternativou trumfnout. Na to aby jsem kód zkrátil o 1 nebo 2 instrukce jsem potřeboval 1 volný byte v datovém registru, nicméně jeden ze 2 mých pomocných registrů mám speciálně vyblokovaný, ponechávám v něm hodnotu velikosti snížení/zvýšení hlasitosti pro efekt volume slide. Tak smůla 1 nebo 2 instrukce navíc... .

Hodnotu časovače pro opakování skladby mám v adresovém registru v jeho 1.byte (0-3). Ale tím že se nejedná o datový registr, tak snad jsem udělal vše proto, aby jsem s tím pracoval nejefektivněji. V rámci volných byte mám ještě v daném adresovém registru volné 2 vyšší byte, mé poslední volné celé byte na případné něco, ještě nevím co. Sice mám časovač v adresovém registru a ještě ani ne v jeho 0.byte, ale časovač na opakování skladby je v důležitosti snad na jednom z posledních míst a dost v kódu využívám vlastnost, že mi stačí vědět, jestli vůbec nějaká informace v časovači je, aniž bych musel správně přečíst hodnotu jaká tam je. To mi celkem pomohlo udělat ten kód přiměřeně krátký.

Deforovi ho nedám, nechci aby mi z toho udělal 2 řádky...

​​​​​


Jak jsem testoval na Amize hraní skladby, tak jsem mi ve zvuku začalo objevovat pukání. Říkal jsem si co zas. V hudebním formátu jsem odstavil práci s hlasitostí.... pukání, odstavil jsem efekt volume slide .... pukání, Tak aby jsem nenaháněl duchy vypnu vývojové prostředí ASMpro zapnu Octamed pustím MOD a bez pukání. Vypnu Octamed, nastartuji ASMpro, dám rutině zahrát krátký úsek aniž by mně napadala známá příčina proč mám ve zvuku pukání. Krátký úsek se zahraje čistě. Načtu celý kód odznovu a pustím skladbu bez omezení a hraje mi to zrazu čistě. No jo, vývojové prostředí zapnuté přes noc. Už toho bylo na něj moc...

V pondělí a v úterý jsem se vrhl na předělání logiky v mém programu tak, aby práce grafiky nastoupila až po nějaké chvíli po tom co hraje skladba. Přemýšlel jsem jak to udělám a napadlo mně na to použít část kódu, která umí na začátku každé skladby udělat některé věci za můj hudební formát (ten to umí taky) ale je to tam pro případ, když by se třeba potřeboval nahrát sampl do kanálu a už by se třeba nemusel změnit. Tedy aby mi tahle situace zbytečně nezabírala "slot" pro 1 nástroj v rámci mého formátu v hlavní smyčce programu. Tohle se vykonává před touhle smyčkou. Tedy jsem před tuhle hlavní smyčku hodil vše podstatné pro práci s grafikou, co jí aktivuje, tedy načtení bitplanů a tak. Příhodný moment asi ve 4 řádku patternu hlavní smyčku v programu opouštím, načtu bitplany a jiné a vracím se zpět na hlavní smyčku. Zároveň vyblokuji v hlavní programové smyčce ostatní práci s grafikou pomocí mého formátu pro práci s textem na přibližně stejný čas, tedy na asi 4 řádky patternu. To vše můj program vlastně uměl, jen jsem musel trochu upravit u toho všeho logiku a vše si taky uvědomit jak by co mělo být. Například jsem psal, že čas potřebný pro spuštění podprogramu z grafické knihovny (offset -222) je rovný přibližně 20 řádkům patternu, to není pravda. Neuvědomil jsem si, že za čas 1 hlavní smyčky programu zpracuji přibližně 5 písmen v textu a ne pouze 1 písmeno. Tedy na 1 řádek patternu je asi 5 písmen a ne 1 písmeno. Vše to pak pěkně fungovalo. Chvíli ze startu hrála pouze skladba s prostředím Workbenchu a pak se přešlo na grafiku, neboli zobrazování textu. Aby tam tu chvíli nebyl Workbench to bych pak upravil ale... .

Mé předpoklady že podprogram s offsetem -222 potřebuje více času a že s textem musím začít pracovat později čím bych vyřešil to, že se mi text přestane někdy zobrazovat pouze asi do 12 písmena ze 40. Stalo se to, že při téhle úpravě programu se mi text ne jenom někdy zobrazoval do asi 12 znaků, ale vždy se zobrazoval do 12 znaků. Ani jedno spuštění programu tedy nebylo správné.

Jak byl u spuštění programu nachvíli ještě podržený Workbench, hezky jsem viděl otevření okna posunutého vlevo mimo celou obrazovku, tedy jsem viděl pouze jeho přibližně pravou půlku. A pak se mi začal text psát správně zleva od začátku ale jen do rozsahu posunutého okna Workenche doleva, tedy do jeho pravé půlky.

tadáaa standardní situace u mně. Martině máš to obráceně

Dobře, tak někdy se podprogram s offsetem -222 ukončí tak rychle že se práce s textem nestihne správně "chytnout".

Část programu co jsem načítal pro práci s textem dodatečně jsem dal do MiniWrapperu od Photona před podprogram s offsetem -222. Nepomohlo. Přichází na řadu časovač CIA nastavený na maximální hodnotu hexadecimálně FFFF. Dal jsem jej do programu mezi. Tedy před ním byla práce s grafikou, za ním -222ka. Samozřejmě vše s návratem na mou původní verzí programu před všemi změnami v logice. Teď jsem viděl jak opožděně začne podprogram s offsetem -222 pracovat. Tenhle podprogram grafické knihovny mi umožňuje celý program spustit i z rozlišení Multiscan Productivity, tedy z rozlišení 640 na 480. Jinak se vám program spustí tak, že to není použitelné. Absolutní bordel v obraze i ve zvuku. No a jak se -222ka po časovači CIA na hodnotě FFFF hexadecimálně spustí opožděně, tak nejdříve je bordel v obraze, je to chvilka a pak se obraz spraví (díky -222ce). Co jsem zatím zkoušel spustit celý program, zobrazování textu v pořádku na celou šířku obrazovky. Další krok. Vrácení práce s grafikou/textem nazpět mimo MiniWrapper od Photona. Před -222kou jsem nechal pouze časovač CIA nastavený na maximální zpoždění. Zobrazování je v pořádku.

Zatím jsem nezaznamenal nesprávné (useknuté) zobrazování textu do asi 12.znaku.

Jen napíšu, že časovač bylo to první, co jsem nasadil do Photonovho MiniWrapperu, který kompletně odstavuje systém, ale možná jsem u toho ještě Amigu 1200 i nevypinal. Její pouhý reset nepostačoval na to aby se vše u Amigy vrátilo do normálu a u Amigy se může vyskytovat pořád již stará chyba, tedy chybné chování a program můžete mít dobře.

Ještě pošteluji nějaké věci ale CIA časovač před -222kou nechávám na maxime.

U jakékoliv změny programu po běžném testování nastalo běžné testování po několikaminutovém vypnutí Amigy 1200. Pár desítek vypnutí to bylo.

Když se mi ta chyba ještě někdy projeví, nebo se prokáže, že vše je věc náhody a chyba nebude tímhle vyřešena, možná mně jebne

A tohle je definice vesmírného pirátství

A abych zde neměl jen blbý kecy tak pár postřehů, ale budu to tak nějak tahat z hlavy, nejsem nastaven na to čumět jakkoliv do kódu.

Myslím že jsem konečně narazil na příčinu, proč se mi můj program pomocí kódu od Photona co odstaví systém chová někdy při spuštění nestandardně.

Popis chování, které se projeví ze začátku někdy při spuštění a při třeba tak 5 spuštěním po sobě již méně často​​​​​ co je tak jednou za 20 až 50 spuštění.

Zobrazování textu jen u prvních 12 písmen že 40.
Nezobrazení textu, hraje pouze skladba a funguje Copper.
Nereagovani ukončení programu pomocí klávesy space, pomocí tlačítka na myši program ukončit lze.

Co mně zmátlo je skutečnost že se program při hledání chyby chová jinak pod prostředím a jinak když je zkompilovaný. Tedy to že přijdete na vodítko které by vás nasměrovalo na to čeho se chytit a které vám funguje pod vývojovým prostředím většinou nefungovalo u kompilovaného programu.

Problém by dle všeho měl být u podprogramu s offsetem -222 z grafické knihovny. Je to zjištění ze dnes, ještě budu testovat ale kód byl zatím u EXE stabilní, když jsem tenhle offset/podprogram u kódu od Photona nepoužil. Ják bude čas budu hrát na to, že tento podprogram se vykonává dlouze a můj program díky němu začne pracovat bez chyby tak na jeho 20 cyklu. Tenhle podprogram zabezpečuje spuštění mého programu i z grafického módu Multiscan Productivity, tedy se to pokusím dát nějak dohromady 🙂

Hm, tak ono to vypadá jako by restart A1200 nestačil po tom co spustíš program s ne zrovna ideálním nastavením DMA přenosů. Pomohlo až vypnutí a zapnutí A1200 aby se program začal chovat korektně, když jsou i DMA přenosy nastaveny správně.

Opět díky moc za nasměrování. To nastavení bitů pro práci s bitplany a copperem nebylo ani součástí původního kódu pro práci s textem, který jsem převzal a upravil. Je pravdou že Copper jsem přidal já i když s ním dělám pouze jednoduchou čáru. Nějak jsem si to vše nedal dohromady. To jsem celý já.

Správně fungování původního podprogramu WaitEOF bylo podmíněno správným nastavením DMA přenosu v DMACON ($dff096), tedy tohle již taky funguje.

Tak tohle jsou ty přerušení, já to jen používám. Tedy doposud hlavně u Pauly, teď již i u Bitplanu a Copperu.

Vím že jsem se již jednou ptal na 9.bit DMAEN u DMACON co je hlavní povolení DMA. Má zkušenost je taková. Že pokud jsem pracoval čistě jen s Paulou bez obrazu, nepotřeboval jsem ho nastavovat, ale jakmile již k tomu přidám i práci Bitplanu, nebo Copperu, již potřebuji mít tenhle 9.bit nastaven, jinak mi ani Paula nic nehraje. Tenhle 9.bit (DMAEN) hlavní povolení DMA vnímám jako nějakou komunikaci mezi právě probíhajícími DMA přenosy.

Právě zjišťuji že teď mám problém ještě s podprogramem AllOff který se provádí až za mým programem, tedy při návratu do systému. Za to ale již snad já nemůžu? Ono tedy někdy se to spustí dobře a někdy mi to zobrazuje jen asi prvních 10 znaků ze 40 a většinou se to spustí správně bez téhle chyby. Jednou se mi to spustilo i s odstupem textu od kraje obrazovky. Taky se mi to i jednou z EXE nespustilo, ale pak jsem udělal další kompilaci. Zdá se mi nevynulování registrů DMACON a INTENA za mým programem jako stabilnější ale ještě to budu testovat. Nulování těchto 2 registrů před mým programem již provádím.

​​​​​
​​​​

Nerad to píšu, ale tvé AllOff0 nedělá nic, co je účelem původního AllOff -- tedy zakázání DMA a přerušení. #$7fff nuluje vše ve dvou registrech k tomu určených: DMACON a INTENA. Zápis této hodnoty do INTREQ je jen zajištění, aby se nevyvolalo žádné přerušení, o které už bylo systémem (Paulou) požádáno (INTerrupt REQuest). Nevím, jestli je to úplně nutné, ale věřil bych Photonovi, který tohle určitě převzal z jiných starších rutin, a nechal bych to tam. Každopádně tvé AllOff0 DMACON ani INTENA nemažou a tudíž ti na pozadí stále běží ošetření všech dříve povolených přerušení (a stále ti běží všechny DMA kanály).
Pokud ti tvůj program normálně po AllOff nejede, je to nejspíš tím, že pak přerušení, která používáš, nezapneš. Nezapomeň nastavit i bity INTEN a DMAEN, protože ty byly taky smazány!
Tvoje rutina WaitEOF0 taky nic nedělá. Teda dělá jen to, že počká až přestane pracovat blitter (WaitBlitter). Úkolem té rutiny je vrátit se v okamžiku, kdy je obrazový paprsek za vykreslováním posledního řádku obrazu (tedy začne docházet k vertical-blank). Proč Photon pro jistotu čeká i na blitter netuším -- asi další příklad velké opatrnosti. Tvoje rutina ale na paprsek nečeká - netestuje jeho pozici. (Mimochodem ta rutina nefunguje, pokud by tvůj program běžel na NTSC systému. Tam je nejvyšší vertikální pozice el. paprsku jen $106.)