Oznámení

Sbalit
Aktuálně žádná oznámení.

Assembler - všeobecná logika

Sbalit
X
 
  • Filtr
  • Čas
  • Zobrazit
Vymazat vše
new posts

  • Lisiak4
    odpověděl
    Ještě to píšu a zapomněl jsem zeditoval tenhle příspěvek tak smůla a je to níže 🙂
    Naposledy upravil Lisiak4; 27.01.2022, 14:26:25.

    Vložit komentář:


  • Lisiak4
    odpověděl
    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 🙂

    Vložit komentář:


  • Lisiak4
    odpověděl
    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.

    Vložit komentář:


  • Defor
    odpověděl
    Autorem citovaného textu je Lisiak4 Přejít na původní příspěvek
    Naskýtá se dotaz, proč adresy dffxxx nejsou nějak logicky za sebou jak se to vyžaduje.
    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, ...).

    Vložit komentář:


  • Defor
    odpověděl
    Autorem citovaného textu je Lisiak4 Přejít na původní příspěvek
    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í?
    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.

    Autorem citovaného textu je Lisiak4 Přejít na původní příspěvek
    Dnes jsem si zkusit v Copper listu prohodit zapisy do registrů dle jejich pořadí...
    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.
    Naposledy upravil Defor; 08.01.2022, 17:21:55.

    Vložit komentář:


  • Lisiak4
    odpověděl
    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 🙂

    Vložit komentář:


  • Lisiak4
    odpověděl
    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.
    Přiložené soubory
    Naposledy upravil Lisiak4; 03.01.2022, 23:16:54.

    Vložit komentář:


  • Lisiak4
    odpověděl
    Textro 20.zip Klikni pro plné zobrazení obrázku

Jméno: Textro 20 OBRAZEK.png
Počet zobrazení: 276
Velikost: 8,0 KB
ID: 154044

    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)

    Vložit komentář:


  • Lisiak4
    odpověděl
    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 🙂

    Vložit komentář:


  • Lisiak4
    odpověděl
    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?

    Vložit komentář:


  • Defor
    odpověděl
    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).

    Vložit komentář:


  • Defor
    odpověděl
    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ě.
    Naposledy upravil Defor; 13.12.2021, 10:38:01.

    Vložit komentář:


  • Lisiak4
    odpověděl
    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.

    Vložit komentář:


  • Lisiak4
    odpověděl
    Ok, díky za rady. To kopírování Longu místo Wordu jsem zatím vůbec neřešil, ale díky za upozornění. Makra jsou u mně ještě není v pořadí. Já jsem se zatím jen prohrabával tím principem toho kódu a udělal drobné změny. V rámci logiky jsem třeba udělal test 1, tedy konec řádku před 0, tedy konec celého textu. Původně se 0 testovala před 1, co už tedy vadilo i mně v i tak zatím rozdělaném kódu. Restore systému, možná se na to podívám, ale taky to teď není hlavní problém, každopádně dobré o tom vědět.
    Mně by třeba zajímalo, v Amiga Review se píše, že se má Cooper odstartovat zapsáním nějaké hodnoty na register dff088, nebo dff08a. V programu, ani v původní verzi se tohle nedělá. Není to tedy nutné a co Copper odstartuje, pokud ho odstartovat je třeba?

    Vložit komentář:


  • Defor
    odpověděl
    Asi by to chtělo dát tam i exáč, ať si to člověk nemusí buildovat sám.

    Pár poznámek ke code (si nemůžu pomoct, co?):
    - Nejsem si jistý, jestli se dá spoléhat na to, že se po povolení multitaskingu na konci programu vždy správně automaticky nastaví původní screen. Asi to obvykle zafunguje, ale i tak se doporučuje zavolat LoadView() s uloženým původním View. Problémy jsou údajně s RTG. Aby se zbytečně nevynalézalo kolo, tak doporučuji z netu stáhnout například Photonův MiniWrapper, který dělá shutdown/restore systému (ale pozor: ruší VBL přerušení, takže to ani tak nemusí vše v systému přežít bez úhony).
    - Není to sice u tak krátkého programu vůbec důležité, ale i tak to uvedu: Na některých místech se tam zbytečně dělá aritmetická operace s long-wordem, i když by stačil jen word -- add.l #40,a2 se dá zcela nahradit za add.w #40,a2, protože 680x0 všechny aritmetické operace s adresovými registry automaticky rozšiřuje na 32 bitů. Totéž také platí pro add.l d1,a3, kde stačí použít add.w d1,a3, pokud máme v d1 jen max šestnáctibitové číslo se znaménkem. Obecně platí, že když pracujeme jen s číselnými rozsahy, které se vlezou do 16ti bitů, je zbytečné používat operace nad long-wordy, které jsou vždy pomalejší.
    - A toto už vůbec není důležité, ale je to taková obecná rada, jak dělat na staré dobré Amize o něco rychlejší kód: Rozvinout smyčky (loop unroll). Pokud dopředu vím, kolikrát se něco má ve smyčce udělat (nebo mám nějaký rozumný odhad) a vnitřek smyčky je malý (pár instrukcí), je režie odskoku na začátek smyčky (bxx,b nebo dbxx.b) velká. Klidně i desítky procent v případě krátkých smyček. Je tedy lepší ty instrukce zkopírovat za sebe (vhodná jsou pro to makra). Sice to bude zabírat více paměti, ale bude to rychlejší.

    Naposledy upravil Defor; 12.12.2021, 19:37:15.

    Vložit komentář:

Zpracovávám...
X