Tak jsem to přibrzdil takovým možná dočasným řešením, které jsem již měl hotové. Jsou to ty horní 2ky. Každá 2ka je 5 cyklů v hlavní smyčce programu. Je to časovač který mám určen na něco jiného, ale zatím jej používám i na to přibrzdění​​​​​​​. Těch dvojek by tam stačilo mít tak 18, já to přibrzdil více a je jich tam 45. Na foto je, jak vypadá můj formát pro práci s textem. Asi jsem to jsem již pár krát dával, ale mám z toho radost.

Dělal jsem si legraci, že když teď přenesu můj program z A1200 do PC, tak mi to pro jistotu zase nebude chodit v emulací, ale nestalo se tak

Tedy snad vyřešeny 2 problémy:
-Správné spuštění programu již i z grafického režimu Multiscan: Productivity.
​​​​​​​-Neusekáváni posledních 2 pixelů vpravo ani na reálné Amize.

​​​​​

Problém MiniWrapperu od Photona má mé Textro+hudební rutina s nulování bitů u DMACON a INTENA co je v návěstí AllOff a to jen u BSR (skoku na návěstí AllOff) před mým programem. Proto jsem si přidal návěstí / podprogram AllOff0, kde u daných registrů bity nenuluji, nuluji bity jen v registru INTREQ 2 krát po sobě pro kompatibilitu s Amigou 4000.
Po mém programu, kdy je návrat do systému již nuluji bity beze změny původního kódu, tedy ve všech 3 zde uvedených HW registrech.

Všechny zde teď uvedené časy a počty uvedu přibližně. Správná práce s vypisováním písma v mém programu po zavedení MiniWrapperu začíná někde na 100 cyklu velké smyčky v mém programu. Tedy chvíli mu trvá než se to vše správně chytne. Časově se jedná asi o 1 vteřinu. Asi tedy u textra udělám jednu malou obrazovku s asi 20 mezerami, než začnu pracovat s vypisováním textu.

Přibrzdění v kódu pomocí CIA nějak nepomohlo, že bych tomu MiniWrapperu dal vice času. Tak mi 1 malá krátká obrazovka naprázdno přijde zatím nejrozumnější, že nebudu muset do mé hlavní smyčky v kódu přidat nějakou další instrukci.
​​​

Defor, @ALL:​​

Tak dle předpokladu se mi kód z rozlišení Multiscan Productivity opravdu nepouštěl kvůli nedostatečnému stopnutí Workbenchu. Použil jsem MiniWrapper od Photona o kterém zde píšeš a zdá se to již být ok. Drobatko mi něco v tom kódu haprovalo a to tak nějak vím kde je problém. Nejdříve jsem měl rozběhly kód pod emulací, ale když jsem to spustil na A1200, tak jsem to vlastně nespustil. Dnes jsem se k tomu opět dostal a hodil do poznámky celý kód MiniWrapperu a postupně jsem jednotlivé části aktivoval již přímo na A1200 (odpoznamkoval kód) až na jednu dle všeho zatím problémovou část a dorazil na BSR odkud volám můj kód a řekl si, tohle zatím bude stačit. Přepnul jsem si v ASM-Pro screen mode na Multiscan a pustil jsem kód a běželo to. Celý kód jsem hodil zpět do poznámky, aby nebyl aktivní a řekl jsem něco ve smyslu tak a teď se to doufám posere a spustil jsem to a ono se to opravdu posralo. Ještě se s tím příště pohraju, ale boží, na hlavní problém to zabírá. A navíc MiniWrapper od Photona mi odstraňuje dle všeho další chybu a to, že už mi to ani na A1200 neusekává z obrazu poslední 2 pixely vpravo. Doposud to bylo ok jen v emulaci.

Ještě budu i testovat, ale vypadá to dobře.

Jen pro zajímavost, nejdříve se mi do tohohle nechtělo, chtěl jsem v asm dělat něco jiného, ale jak jsem.v nejbližší době zapnul ASM-Pro, začal jsem hněd dělat na tom, na čem jsem dělat nechtěl, protože v ten moment jsem si řekl, že je to pro mně to nejzajímavější. Jednoduše jsem otočil v rámci mého názoru o 180 stupňů, čím se dostáváme k závěru, že ani já sám někdy nevím, co můžu od sebe očekávat

@Defor: Díky za nasměrování na ten MiniWrapper

Dnes jsem se s tím celkem hrál, pořád stejný výsledek. Zkusil jsem další 2 kódy, italský a polský se stejným výsledkem. V emulaci fungují, na A1200 nefungují. Myslím že to nejvíce vystihuje tenhle obrázek, když zobrazuji pouze 1 bitplane.

ok,

včera jsem to vše tedy hudební rutinu, testovací melodií a program pro práci s textem spustit. Pod emulací funguje, na reální A1200 nefunguje. Obraz je rozhozený, možná si o tom právě psal výše. Zatím jsem vše neměl čas zkoumat.

Vím ale:
-poslední verze mé hudební rutiny bez práce s textem funguje na reální A1200.
-ani původní neupravený kód jen programu pro psaní textu nefunguje na reální A1200.
-vlastně žádný program co mám (mám ještě další 2 z AmigaReview) nefunguje na reální A1200. Obraz je rozhozený, ale v emulaci programy fungují.
-zatim vycházím z předpokladu, že pokud se zprovozní původní program pro práci s textem na reální Amize, bude stejná chyba i v mé hudební rutině kde pracují i s textem a bitplany. Ale může tam být samozřejmě i více problémů.
-jak budu mít čas, najdu si nějaký funkční příklad zobrazení obrázku pomocí bitplanů (raw souboru).

Původní program bez mých úprav ze kterého pak vycházím i v mé hudební rutině je v příloze. Program funguje v emulaci, ale nefunguje na reální A1200.

Miluji programování

DMAEN bit (podobný je INTEN bit v INTENA registru) povoluje nebo zakazuje (podle toho jestli se nastavuje nebo maže) všechny DMA procesy. Tedy pokud bys potřeboval z nějakého důvodu zakázat všechny DMA, nemusíš mazat jednotlivé bity, ale stačí smazat jen DMAEN. Pro opětovné povolení jej stačí jen zpátky nastavit. Je to "master enable/disable bit". Nemusíš ho nastavovat, pokud máš jistotu, že už je nastavený. Pokud ji nemáš, tak neuškodí ho nastavit

Vypnutí DMA pro sprajty se skutečně udělá zápisem $20 do DMACON ($96) registru. Jen bych dodal dvě poznámky: 1. Je vlastně zbytečné to dělat v každém snímku (tedy v copper-listu, který se provádí každý snímek). Stačí to udělat ve správný čas jen jednou. 2. Je nutné si pohlídat, aby DMA sprajtů nebylo vypnuto v okamžiku, kdy už došlo k zápisu dat do kontrolního registru SPRxCTL a do datavého registru SPRxDATA. K tomu prvnímu dochází někdy krátce po VBLANK (přesný počet řádků z hlavy nevím), k tomu druhému pak podle toho, jaký sprite byl právě zobrazován. Kdyby bylo DMA vypnuto "v blbém okamžiku", může se to projevit slavným vertikálním pruhem přes obrazovku. Je to důsledek toho, že zobrazování sprite dat Denisou stále pokračuje. DMA je záležitost Agnus - ta sice přestane Denisu krmit novými daty, ale ty staré v Denise (SPRxDATA, SPRxDATB) stále zůstávají a horizontální komparátor je při tom stále aktivní (deaktivuje jej zápis do SPRxCTL). Denisa tak na každém řádku zobrazuje stále stejná data. Ale o tom všem se dočteš v HRM: http://amigadev.elowar.com/read/ADCD.../node00AE.html

$8E a $90 jsou DIWSTRT a DIWSTOP (display window start / stop). Denisa je používá k tomu, aby věděla, kdy má generovat obraz z načtených dat bitplánů (BPLxDAT). Musí se to nastavit aspoň jednou. Opět platí, že je to vlastně zbytečné nastavovat v copper-listu každý snímek, ale pro zjednodušení se to tak obvykle dělá.

Nerozumím co myslíš tím "stabilní pro statický obrázek". Ty hodnoty, co tam máš, jsou zřejmě pro obraz o něco širší než klasických 320 pixelů.
Viz. http://amigadev.elowar.com/read/ADCD.../node0071.html
Obvykle se používají hodnoty $2C81 a $2CC1.
Samozřejmě je možno použít i HiRes. OCS podporuje i generování 70ns (hires) pixelů -- tedy "640" bodů horizontálně (nebo víc, nebo míň...). Stačí to zapnout, správně nastavit DDFSTRT, DDFSTOP, DIWSTRT, DIWSTOP, a samozřejmě i BPLxMOD.

Koukám na program co vloží obrázek pomocí bitplanů.

Je tam pár registrů které se zatím na nic netváří, netvrdím že jsou navíc, ale radši se ujišťuji.

Je třeba nastavovat $dff096? Je tam třeba mít aktivovaný 9.bit DMAEN? Na Paulu používám bit 0 až 3 a 15 samozřejmě. Ale to jsem jen odskočil od tématu a bavím se zde o obrázku. Jak by tenhle registr měl být nastaven pro použití zobrazení statického obrázku? Pokud jej vůbec musíme nastavovat?

V Cooperlistu se ještě na $dff096 zakazuje sprite.
DC.W $0096, $20

Tyhle 2 instrukce by měli v Cooperlistu nastavit velikost zobrazení okna.
DC.W $008E, $2C75
DC.W $0090, $2CC5

Ostatnímu v kódu rozumím a vím že ty věci tam mají být použity, u instrukcí zde napsaných mi zobrazení obrázku funguje i bez jejich použití, tak mne to zajímá, jestli by to tam opravdu mělo být použito.

Jaký maximální grafický režim je stabilní pro statický obrázek v LoRes aby to šlapalo na všech Amigách? Nebo lze použít i HiRes?

Díky

Včera mne pobavil jeden můj komentář k instrukci AND, nakonec jsem to řešil jinak ale bylo to něco ve smyslu:

AND.L #$10ffffff,D2 ;zanechavam bit pro vibrato, ta 1 vlevo

Další věc co mne v minulosti pobavila bylo když jsem text z textra měl v paměti až za samply. ASM-pro na mně po tom, co jsem se snažil načíst adresu na které byl text uložený řvát že je text mimo rozsah 16 bitů, tedy pro PC relativní adresování moc daleko v paměti, kdy jsem zkonstatoval, že ten text dám radši před sample 🙂

Posledně jsem v mé hudební rutině dodělal poslední souvislosti se kterými mi již Textro běží v pohodě. Dnes jsem udělal v rámci Textra takovou drobnost. Mezera mezi písmeny se původně řešila odskokem od písmene a já potřeboval mezeru zpracovat stejně jako písmeno, tedy vykreslit ji po řádcích od shora dolů. Nejdříve jsem zkusil na slepo vykreslovat pozici za posledním písmenem z RAW obrázku. To mi neprošlo. Tak jsem si raw obrázek s písmeny zobrazil. Poslední písmeno končilo vpravo na kraji obrazovky. Pak mně napadla varianta ke které se vrátím, více se mi líbila 3.myšlenka a to vykreslit písmeno stejnou barvou jako je pozadí. Samozřejmě měnil jsem barvy ostatním písmenům tedy blbost. Tak jsem se vrátil k 2.nápadu. Zopakovat 7 krát nejhornější prázdnou pozici u znaků kde to tak je. To jsou 3 znaky a já si vybral tečku. Tedy načtu 7 krát horní pozici ze znaku "." a tu odshora dolů vykreslim na obrazovce. Pokud bych úpravu chtěl dát do původního kódu kreslícího i znaky, potřeboval jsem další 4.promennou v rozsahu 2 byte (Word). Já tomu chtěl obětovat pouze 1 byte. Ale nenašel jsem takovou kombinaci, aby mi stačil, tak jsem udělal rozvětvení a zjednodušenou verzí programu pro kreslení znaků pouze i pro mezeru. 12 řádků. Tak celkem fajn. Program je delší ale při kreslení mezery rychlejší. Funguje. Tak fajn 🙂

Ano, CIA časovače se používají v hudebních přehrávacích rutinách. Možná se používají i při čtení klávesnice (pro potvrzení sériového přenosu). A určitě i pro další aplikace. Jsou přesné i pro krátké časové intervaly. CIAB časovač vyvolává maskovatelné přerušení s nejvyšší prioritou, což je často k užitku (např. právě u té hudby), ale může to být na obtíž (když bychom v přerušení chtěli dělat i něco delšího). Tohle téma je určitě zajímavé a obsáhlejší.

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.

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 🙂

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á.

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.

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.