Jednou se mi seklo WinUAE tak, že nešlo zavřít ani přes křížek. Až po tak 4 minutách se PC vzpamatovalo v době kdy jsem se jo již chystal restartovat. To taky pobavilo. Chudák PC 😁

Hodil jsem si program textro k mé hudební rutině, přízpusobil registre a snažil se to s nima držet na podlaze, aby jich bylo potřeba co nejméně vždy v daný moment. Bylo to nestabilní, tak jsem si program s úpravami hodil samostatně, i tak to bylo nestabilní dá se říci nefunkční. Začal jsem laborovat kde je problem. Hrálo se to na moc věcí s různou stabilitou. Postupně čím dál více zpřesňoval místo chyby, pracoval jsem již i s možností více chyb. Nakonec to byl register kde je pointer na obrázek. Dle všeho s tím Amiga pracuje snad i na pozadí a když do něj dám něco jiného tak se program sekne/guru/nezobrazí správně grafiku anebo třeba i zobrazí ale jen při prvním spuštění a sekne se to při druhém spuštění. Tak mám opět program stabilní a příště jej zkusím hodit k mé hudební rutině opět. Dnes jsem šel spát ve 4 ráno, ale dorazil jsem to až po spánku, co více si přát 🙂

Ještě to píšu a zapomněl jsem zeditoval tenhle příspěvek tak smůla a je to níže 🙂

Beru zpět, chová se to stejně jako DMA na Paule. Jednoduše mi Copper běžel v ASM-pro a pak se již EXE správně nepustilo 🙂

Já jen prohodil řádky programu pouze v Copper listu nic víc, chtěl jsem si je seřadit dle hodnot samotných registrů opět zdůrazňuji pouze v rozsahu programu pro Copper. Jakmile jsem tak učinil, přestal mi program zobrazovat text.

Nevím, jak to přesně myslíš. Registry jsou v čipsetu umístěny logicky. Tabulka http://amigadev.elowar.com/read/ADCD.../node0060.html
ukazuje, že od $000 do $03E jsou umístěny registry, ke kterým se nesmí dostat Copper. Od adresy $040 do $07e jsou umístěny registry, kam se Copper dostane pokud mu to CPU povolí. A na vyšších adresách je vše vždy Copperu dostupné. Od toho se odvíjí logika umístění. Registry v rámci možností tvoří skupiny podle své funkčnosti (kontrola generování obrazu, bitplány, sprajty, blitter, audio, barevná paleta, ...).

Vím, že u nejstarších revizí (nebo jen té úplně první veřejné?) byla chyba v Agnus, kdy se špatně nastavoval příznak ukončení práce Blitteru. Ale detaily si už nepamatuju. Určitě se to dá dohledat na EAB (hledal bych něco jako "bugs in early revisions" a tak podobně). Myslím, že různých chyb v čipsetu bylo hodně, ale tato byla v běžné praxi asi jedna z těch závažnějších. Ale co si tak vybavuju, tak se tahle chyba stejně moc neřešila. Těch starých Agnus čipů asi v oběhu nebylo tak moc, aby to stálo tvůrcům nesystémových věcí za pozornost.

Zápisy do registrů v copper-listu mohou být obvykle v libovolném pořadí. Samozřejmě se můžou naskytnou situace, kdy na pořadí záleží. Extrémním případem by mohlo být ovládání Blitteru přímo Copperem. Velikost manipulované oblasti (BLTSIZE) se musí zapisovat jako poslední, protože se tím Blitter odstartuje (před tím ale CPU musí povolit Copperu přístup k BLTxxx registrům). Také při manipulaci se sprajty do určité míry záleží na pořadí zápisu (více například zde: http://coppershade.org/articles/AMIG...e_Programming/). Ale to jsou hodně speciální případy. Takové to klasické nastavení adresy bitplánů BPLxPT, modula BPLxMOD, barevné palety, DMA fetch start/stop DDFSTR/DDFSTOP a umístění zobrazování pro Denisu DIWSTRT/DIWSTOP se mohou dělat v libovolném pořadí. Ale samozřejmě dostatečně včas před samotným zobrazováním. Obvykle se to dělá na začátku, hned po vertical blank. Dokonce se tyhle věci vůbec ani nemusejí nastavovat opakovaně. Vlastně je to zbytečné plýtvání často velmi cennými DMA sloty (přístupy na chip-ram sběrnici). Takže hodně věcí (BPLxMOD, BPLCONx, DDFSTRT/DDFSTOP. DIWSTRT/DIWSTOP, COLORxx) se daji nastavit jen jednou (v nějakém pomocném copper-listu, nebo pomocí CPU, když je jisté, že to něco nezmění), a pak přepnout na copper-list, který v každém frejmu nastavuje už jen potřebné věci (např. BPLxPT).
Takže tvůj problém asi bude v něčem jiném.

Dnes jsem si zkusit v Copper listu prohodit zapisy do registrů dle jejich pořadí dffxxx a celkem jsem narazil. V ASM-pro to bylo ok, ale EXE již nepracovalo, nejčastěji mi to hodilo jen čistě modrou obrazovku, co je jedna ze 2 barev se kterou pracuji. Ve výsledku jsem nepřesunul nic nikam a nechávám Copper list bez změn v pořadí. Naskýtá se dotaz, proč adresy dffxxx nejsou nějak logicky za sebou jak se to vyžaduje. Jediné co mně napadá je, že byly upřednostněny návaznosti spíše hardvérové než softvérové a to by bylo samozřejmě v pořádku 🙂

Další verze, asi předposlední. Dal jsem rozsahy u registrů na menší, když to umožňovala situace a nejednalo se o ADD Dx,Ax, kde jsem nechal Long. U ADD #x,Ax jsem použil Word. Nebyl jsem zvyklý používat rozsahy u podmínek BEQ a jiných ani u skoku BRA a dalších ale ok a ponechal jsem. Původně byly použité 2 různé adresové registry pro pointer na bitplan, to jsem sjednotil, nic mne to nestálo. Taky jsem použil D0 jako pomocnou proměnnou v jednom případě, čím je D0 použita na 2 místech a ničemu to nevadí, tedy jsem uvolnil D6. Původní kód myslím nejdříve nuloval D0 a nim se pak nuloval pomocí MOVE register D5 na 2 místech, to bylo i zavádějící, tak nuluji D5 přímo pomocí rychlejšího MOVEQ. Taky se báze execu načítala 2 krát i když jsme register kde ji máme nijak nepřepisovali, tak snad ničemu nevadí když jí dávám do D6 jen na začátku a nenacitam bázi execu i těsně před ukončením programu a jen program ukončím. Zpřesnil jsem některé komentáře. To tak v kostce co jsem posledně udělal. Ještě se pak podívám na ty registre na návěstí SPRADR. V italské verzi na assembler je o tom nějaký pokec. Snad registre pro sprity a taky ještě 2 registre něco s bitplany. A za mně bude hotovo. U změn v kódu jsem ponechal v poznámce i původní kód, ale to bude vidět i na stejných komentářech. Taková má záloha zatím radši.

Asi to pak vrazim do mé hudební rutiny, nahodim nějakou primitivní melodii i ručně než udělám převodník na můj hudební format.

Vím že se řešil nějaký příznak BOM kvůli A1000 nebo A500 nějaké první verze. Budu to potřebovat při nesystémovém programování aby byl můj program korektní?

Jen poznámka pro mne, ještě hlasitost do 2.byte v registrech

V příloze KÓD, EXE, jen přejmenovaný obrázek PNG, stručný popis v TXT co je v registrech, jak jsem v tom trochu dělal pořádek, a posledně jsem zapomněl přiložit soubor=obrázek RAW, ze kterého se načítají písmena na obrazovku pomocí Copperu, tak ten je již taky.

Textro 20.zip

Optimalizace kódu pro vypsání textu, obraz již stabilní vůči předešlé verzi. Ještě není vše ve finále ale hlavní snad hotovo. Přidáno návěstí TEXTLOOP2, kdy za stavu, kdy se nezobrazuje písmeno není nutné načíst již načtené 2 adresy. Doplněné komentáře u všeho kromě nově použitých registrů pro Copper a na to se ještě podívám. Taky není ideálně komentovaná část kolem načtení grafické knihovny zatím. Na práci s rozsahy B,W,L se taky asi ještě podívám. A ještě mně něco napadá ale až příště. Dole v kódu je malá legenda pro mé komentáře.

v příloze EXE, KÓD, OBRÁZEK (i zde)

Defor .
A když jsme u těch dotazů, tohle není tak nutný ale zeptám se když tě tady mám. Jak si načteme pointer na grafickou knihovnu a pak ji přes knihovnu OldOpenLibtary otevřeme, ta nám vrací posunuty pointer na grafickou knihovnu v D0, v D1 je původní pointer. Pracujeme ale dále s D0. Rozumím tomu správně, jedná se pořád o stejný pointer na grafickou knihovnu, jen je posunutý možná kvůli použití absolutního adresování aby jsme v našem programu věděli samotnou grafickou knihovnu načíst na správné adrese?

Když jsem vše napsal blbě tak pardon 🙂

Defor proč se prosím u tohohle dle všeho známého zápisu
move.l 38(A1),$dff080

používá offset 38?

našel jsem jen popis co to dělá, ale ne ten důvod proč se použije offset 38. V grafické knihovně nezačíná na tomhle offsetu funkce. Mám tomu rozumět tak, že se z dané funkce ne přímo na jejím začátku vemou data co se potřebuji?

Odstavení multitaskingu (nebo obecně systému) by mělo přijít až v okamžiku, kdy se začne manipulovat s hardwarem. V tomto případě s Copperem (nastavení adresy jeho programu do COP1LC registru). Kdyby se to udělalo později, je tu nebezpečí, že běžící systém/programy na pozadí by adresu přepsaly podle svých potřeb. To platí i o čemkoliv jiném (přerušení, audio, floppy, ...).
Systém se samozřejmě dá odstavit dřív. Někdy se to dělá proto, aby se zrychlila inicializace dat (decrunch, precomputation, ...). Příliš brzké odstavení ale například způsobovalo, že dos nestihl vypnout motor flopiny po načtení z diskety. Programy tak měly na začátku pauzu, nebo přes trackdisk.device motor samy vypnuly, nebo to prostě neřešily.
Vypnutí multitaskingu Forbid() není odstavení systému, jen task scheduler nepřepne kontext na jiný task a nezačne se provádět jeho program. Funkce Disable() zastaví i ošetřování přerušení (ty např. potřebují všechny devices) -- tohle vypnutí systému je důslednější. Nejdůslednější shození systému je zakázáním přerušení a/nebo přepsáním vektorů přerušení. Pozor, systém negarantuje správnou funkčnost svých součástí a zařízení po návratu do systému, i když se vše změněné vrátí do původního stavu. Některá zařízení podle dokumentace (síťové karty například?) vyžadují neustálé ošetřování přerušení (tedy provádění jejich kódu vyvolávaného přerušením).

Pár oprav a dodatků:
* Opravuji své tvrzení ohledně "add.w Dx,Ax "instrukce: I když obecně stále platí, že je u 68000 vhodnější pracovat pouze s šestnáctibitovými daty (pouze 16ti bitová datová sběrnice), výjimkou je instrukce add.w Dx,Ax, která je pomalejší (o dva takty) než add.l Dx,Ax. Důvodem je, že CPU musí šestnáctibitovou hodnotu v Dx registru nejdříve rozšířit na 32 bitů a pak teprve provést aritmetickou operaci.
* Rozvinutí smyček (loop unroll) je u CPU s cache vhodné dělat jen do takové míry, aby byl kód stále v instrukční cache. Nemá smysl rozvinout smyčku do kódu o délce stovek nebo tisíců bajtů, jestliže se pak nevleze do cache. To by bylo kontraproduktivní.

K tvým otázkám:

* "jsr d(a6)", kde d je -408 je skok do funkce OldOpenLibrary() v exec.library, která otevírá jinou knihovnu (ve tvém případě zřejmě graphics.library).
Obdobně -414 je ofset pro funkci CloseLibrary(), kterou se dříve otevřená knihovna zavírá.
U AmigaOS je zajištěno, že na adrese 4, je vždy uložena bázová adresa exec.library. Proto ve všech programech uvidíš něco jako "move.l 4.w,a6" -- systémové funkce vyžadují, aby báze knihovny, jejíž funkce se volá, byla uložena v registru a6.
Předpokládám, že tvůj program původně otevíral graphics.library, aby mohl zavolat její funkci LoadView (viz. můj předcházející příspěvek).

* $dff088 a $dff08a jsou adresy registrů COPJMP1 a COPJMP2. Jsou to tzv. "strobe" registry -- nezáleží, jaká hodnota se do nich zapíše, důležitý je jen proces zápisu. Pokud se do nich zapíše, tak Copper začne provádět instrukce od začátku copper-listu, tedy od adresy uložené v COP1LC nebo COP2LC. Tedy jinými slovy se vynutí, aby Copper skočil na adresu uloženou v těchto registrech a od této adresy začal načítat instrukce. Dá se to připodobnit k CPU instrukci "jmp". Osobně používání COPJMP1/2 registrů nedoporučuji. Není pro to ve většině případů důvod (ale existují výjimky a existence těchto registrů má své opodstatnění). Copper se totiž restartuje (začne provádět instrukce od začátku copper-listu) automaticky na začátku každého vertical-blank. Naopak vynucení skoku na danou adresu přes CPU může přijít v době, kdy je už elektronový parsek na libovolné pozici a v důsledku toho (záleží na tom, co se v copper-listu dělá) se může obraz v tomto frejmu generovat nesprávně.

Já tyhle verze dělám hlavně hlavně pro Stano
Proto z mé strany zatím jen ten přímý kód.

Zamýšlím pak balíček původní kód, zkompilovaný, zkrácený kód, zkompilovaný a můj amatérský výklad zkráceného kódu, kde třeba nepopíšu vše přesně ale princip bude obsažen. Ještě ale musím proběhnout ten Copper list, jak budu mít čas. Je pravdou že jsem 1 věc ohledně volání systému vůči původní verzi zrušil. Nechal jsem jenom ten multitasking. Na to se asi taky podívám. V kódu se celkem pozdě odstavuje multitasking. Má to nějaké opodstatnění, nebo se to může udělat i na začátku? V mé hudební rutině to mám na začátku. Offsety z původního kódu pro systém jsou i -408,-414, co je open/close library, ale teď v rychlosti k tomu nic dalšího nenacházím. Já jen čemu zatím nerozumím, ale pořádně jsem se ještě neměl čas podívat. Koukám že ty offsety se používají v závěru programu a mezi open a close se zapisuje pouze na registr dff080, po tomhle zápisu je ten offset -414, před zápisem na dff080 je offset -408 pak se pouští multitasking a je konec programu.