Tak jistě, můj oblíbený séroš...

Tohle celé je nějaké divné. Pokud máš systém zastavený, nemělo by nic padat kvůli tomu, že "s tím Amiga pracuje snad i na pozadí". Pokud chceš, aby tvůj program udělal kompletní "system takeover", tak vřele doporučuji používat třeba Photonův MiniWrapper
http://coppershade.org/articles/Code...Dream_in_Code/

Stačí na začátek tvého zdrojáku dát (include) jeho MiniWrapper, ten všechno vypne, skočí do tvého kódu, a když se z něho vrátí, tak po sobě zase uklidí. Je to ověřené, používá to fůra lidí, případně si jiní naprogramovali něco, co je tomu stejně velmi podobné (ne-li identické).
Pokud tvůj program někdy funguje a někdy padá, tak si ověř, že na začátku je v registrech to, co očekáváš, resp. že jsou vynulovány. Systém je totiž nemaže, a tak když bys třeba udělal toto:
Taky je při programování zvykem, že rutiny nejdříve uloží obsah registrů které modifikují na zásobník a před návratem je zase vrátí do původního stavu:
Tím máš zajištěno, že ti zavolání tvé rutiny nenaruší chod zbytku programu.
Tvůj kód by rozhodně neměl zaseknout WinUAE tak, že ten pak nereaguje. Na reálné Amize to bylo naopak zcela běžné Tady bych spíš tipoval na nějaký problém ve tvém PC/Windows?

Ja je mám taky všechny, poslední čtvrtá série není nadabovaná. Někdy si to ještě pustím i teď, ale jako vše se to okouká. Ale já zbožňuji suchý anglický humor 🙂. A Moss je v některých aspektech takové mé druhé já 🙂

I když je český dabing na úrovni, tak já se raději koukám na origo s titulkama. Ono to nutí i naposlouchat a přiučit se anglině, i když to není ono. Občas si pouštím známé věci bez titulků.

Omlouvám se za

Nadabovány jsou samozřejmě všechny 4 série. Pátá série je jen jeden poslední díl a jde jen o "grandiózní finále" s titulkama Ajťáci: Přichází internet. To samozřejmě víme přece všichni

Defor měl si pravdu, jde o promazání registrů. Ještě to nemám zcela funkční. Ve smyčce, která hledá správné písmeno z napsaného textu jsem použil move.W místo move.B pro zápis čísla 39 které se v cyklu mění, písmeno se po tvé optimalizaci hledá od konce k začátku. To zlepšilo stabilitu, neseká se to, ale vypíše se všude stejný znak, který snad ani není z abecedy. Až budu mít více času, podívám se na to ještě. Díky za nesměrování!

A dnes ráno jsem vyřešil tu druhou chybu. Chyba začátečníka kdy jsem v A2 neobnovoval načtení adresy pro znaky potom co jsem A2 použil i pro načtení adresy na RAW obrázek.

Tedy program Textro je opět funkční i s úpravami aby běžel s mou hudební rutinou aniž by byl použitý zásobník. Tedy 2 programy v registrech D0-D7 a A0-A6. Registr A7 je zásobník.

Včera jsem program Textro zprovoznil v mé nehudební rutině. Dal jsem to v hudební rutině do velké smyčky a měl možnost vidět, jak tahle nízká frekvence smyčky pro práci s bitplanem na pro mně chtěné úrovni nepostačuje. Viděl jsem hezky, jak ta rychlost práce s bitplanem i kolíše. Dnes jsem Textro dal do krátké smyčky v mé hudební rutině. Tam vůči velké smyčce dokáži pracovat s až 32 násobní rychlostí. Tam to již litá o 106, asi to i zpomalím. Ono se to vše po chvíli chodu začne sypat, ale to je na tuhle fázi normální stav. Přišel jsem o pár taktů vůči umístění ve velké smyčce. V registry D2 mám pro pomocnou proměnnou již jen 2 byte místo 4, tedy jsem moveq vyměnil za move.w i kvůli instrukci DBF, které pracuje pouze s rozsahem Word a já musel mít vynulovaný v D2 i druhý byte. Ale DBF je fajn, na to že sníží proměnnou a udělá skok si vezme jen 4 takty, co mně mile překvapilo. Měl jsem zato, že je tahle instrukce pomalejší. Na to že si samotné move v rozsahu 1 byte vezme nepletuli se taky 4 takty. Na 2 takty se dostaneme až s instrukci moveq.

Sice jsem assembler motoroly už dávno zapoměla, tak tomu nerozumím. Ale slovo kolíše je úžasné, děkuji.

Poznámka k těm CPU taktům: Na základní MC68000 neexistuje instrukce, která by trvala jen 2 takty. To není možné, protože načtení wordu po sběrnici vždy trvá 2 takty. Nejrychlejší instrukce tak trvají minimálně 4 takty (instruction fetch + execution). To je taky důvod, proč má CPU povolen přístup na sběrnici vždy jen v lichých bus taktech - sudé by nevyužil. Systém Amigy byl nastaven pro MC68000 a jeho časování instrukcí. A frekvence CPU je nastavena podle frekvence sběrnice, a ta je zase nastavena podle frekvence generování obrazového signálu... Je to velmi vyladěný (ale taky uzavřený) systém.

Nedá mi to, tak tady napíšu spíš takový mikro tutorial. O tom, jak se to má se synchronizováním (časováním) u nesystémového programování.

Pokud vám vaše rutina má běžet opakovaně, tedy nějak časovaná a nejspíše synchronizovaná s časováním generování obrazu, máte několik možností.
1. Použít vertical blank interrupt, který Denise vždy generuje (i když je generování obrazu vypnuto)
2. Použít SOFT interrupt nebo COPPER interrupt (první je obvykle generován copperem, pak musí být povolen běh copperu)
3. Testovat pozici elektronového paprsku (Denise vždy nastavuje)
4. Použít některý z CIA (CIAA nebo CIAB) časovačů a jejich generované přerušení
Ten nejhorší způsob by bylo udělat jen nějakou CPU smyčku o známé délce a počítat s tím, že náš program pojede pouze a jedině na tom jednom jediném přesně daném CPU... Tuhle možnost tedy hned pusťme z hlavy.
Z výše uvedených možností bych spíše zavrhl tu čtvrtou, protože je obvykle zbytečná a hlavně CIA časovače bychom spíše mohli využít pro kratší časové intervaly (než je 1/50 resp. 1/60 sekundy). Třetí varianta se často využívá u různých rychlých ukázek a krátkých programů. Testovat ve smyčce hodnotu v registru VHPOSR je jednoduché, ale není to spolehlivé. Pokud je náš program náročnější (časově delší), snadno se nám stane, že paprsek "ulítne" a test na pozici nikdy nemusí vyjít správně.
Takže nám v praxi zůstávají jen interrupty.
Nejčastěji se používají dva: VERTB a SOFT. COPPER interrupt se moc nevyužívá, protože je na stejné prioritě jako VERTB a tedy používá i stejný odskokový vektor ($6C).

Jak se to má s přerušeními na Amize: Chipset (nebo CPU) nastaví do registru INTREQ (interrupt request) patřičný bit, Paula hodnotu porovná s maskou v INTENA (interrupt enabled) a pokud je výsledek 1 a hodnota se změnila (v INTREQ byla před tím nula), tak se na CPU vyvolá patřičné přerušení. CPU má různé priority přerušení, tzn. že pokud je CPU zrovna v ošetření přerušení, tak bude přerušeno, pokud přijde požadavek o přerušení s vyšší prioritou. U ošetření přerušení procesor vždy jde do supervisor módu (má jiný stack-pointer a může provádět "privileged" instrukce navíc), ze kterého se odchází instrukcí "RTE".

Pro synchronizaci je důležité to, že požadavek o vertical-blank interrupt se generuje vždy na začátku generování obrazu. Tedy u obvyklého nastavení je to každých 1/50 (PAL) nebo 1/60 (NTSC) sekundy. Vždy. SOFT interrupt si můžeme vyvolávat sami obvykle v copper-listu. Takže se nám pak generuje přerušení (resp. jeho request) tam, kde chceme, a jak často chceme (na daném řádku obrazu, nebo řádcích).
Dále máme na výběr, jak s přerušením naložíme. Obvykle se přerušení povoluje (INTENA) a nastaví se patřičný odskokový vektor ($6C pro level3, $64 pro level1 -- pozor na VBR registr u procesorů 010 a vyšších!). CPU nám pak skočí do naší rutiny, ve které si můžeme udělat vše potřebné, smazat request bit (je nutné, jinak by se přerušení znovu nevyvolalo, viz. výše) a vrátit se zpět (RTE).
Ale nemusíme to tak dělat. Klidně můžeme nechat přerušení zakázané a ve smyčce testovat hodnotu request bitu. Ten vždy nastaví buď hardware (VERTB) nebo náš copper-list (SOFT). Pokud je request nastaven, provedeme naši rutinu, smažeme request bit, a vrátíme se (RTS). Je to podobné, ale nejdeme do přerušení. Má to své výhody i nevýhody.
Je tu ale i další varianta: Povolíme přerušení, v něm si třeba jen inkrementujeme counter (frame-counter, který se může vždy hodit) a v hlavní smyčce testujeme jeho změnu.
Prostě fantazii se meze nekladou.

Ok, asi tedy ke správnému počtu taktů se dostanu, když připočtu 2 takty k tomu co mi ukazuje debugger v ASM-pro. Tedy při použití instrukce se z údaju v debuggeru dá odsledovat o kolik byte se posune adresa. Podle tohohle údaju se zatím rozhoduji která instrukce je jak rychlá.

K tomu časování, nijak samozřejmě neoponuji, není jsem padlý na hlavu, jako jsem ale v jiném aspektu. V mé hudební rutině používám CIA, stejně jako některé další hudební rutiny. Dává to více prostoru pracovat se zvukem přesněji. Možná je tam i kombinace s tím interuptem Copperu, protože program Textro je již součástí menší smyčky v mé hudební rutině. Ono ta menší smyčka není až tak malá, jsou v ní všechny efekty. Menší smyčku můžu provést 1 až 32 krát. Tím se nastavuje i rychlost hraní skladby. Pak se provede velká smyčka. V ní se můžou nastavit v skladbě věci, které se nastavují každý řádek patternu a jde se opět na menší smyčku.

S CIA časováním můžu být přesnější hlavně při práci s 5 samply ve 4 hudebních kanálech v rozsahu 1 řádku patternu. Tedy v 1 řádku patternu a v 1 hudebním kanálu můžu prostřídat 2 sample. Zde je celkem důležitá přesnost s rychlostí. S CIA se tohohle dosáhne lépe. Tohle byl asi hlavní důvod, proč jsem se rozhodl pro časovač CIA.

Učím se vše postupně 🙂

Každopádně Defor je supr že si zde, na tom se shodneme snad všichni 🙂

ASM-pro neznám, proto nemohu posoudit, jaké informace při debuggingu (nebo při editaci) poskytuje.
Kolik wordů instrukce zabírá v paměti sice může poskytnou hrubý odhad její rychlosti, ale rozhodně to není dostatečná informace. Je mnoho instrukcí, které mají ve svém instrukčním slově zakódováno vše potřebné (cílové a zdrojové operandy), mají všechny jen 2 bajty, ale jejich rychlost se diametrálně liší. Ale jistě platí, že musí-li CPU pro svůj chod načíst po instrukčním slově další údaje (immediate value, address offset, absolute address, ...), tak je instrukce samozřejmě pomalejší než její krátká (2 bajty dlouhá) verze.