Je to způsobeno tím, že horizontální čítač s hodnotou nula neznamená začátek řádku. Ano, zní to divně a je to divné, ale je to tak. Amiga čipset obsahuje mnoho podivností. Takže do WAIT (a SKIP) copper instrukce se musí dát o něco vyšší horizontální hodnota, aby bylo zajištěno, že MOVE se provede na začátku zadaného řádku. Např.
nezapne bílou barvu pozadí na začátku řádku $3e, ale už na konci $3d. Lépe to dopadne s tímto:

Diky za info,

MOVE.L An,Dn - použiju.

Já si pár registru pred programem pro praci s textem dam do zasobniku. Uvolnene registre pouzivam pro promenne, ktere mi staci pro 1 cyklus programu s textem. Neco pak pro program s textem davam do registru, ktery nedavam do zasobniku, tenhle registr je tedy spolecny jak pro hudebni rutinu tak pro text.

Jen co jsem premyslel nad tim zasobnikem, pokud bych chtel dat do nej i nejaky registr z programu pro text a pred tim bych do nej dal registr z hudebni rutiny, tak bych pak dle vseho ze zasobniku mohl vytahnout data v opacnem poradi, nez by se mi hodilo. Tedy do zasobiku data z hudebni rutiny, pak data z programu pro text a jako prvni bych mel k dispozici opet data pro text... .

Myslim ze jsem prisel na to jak urychlit to psani mezery v ramci textu, tak jsem dnes zacal program prepisovat opet od zacatku (uprava byla jiz na mne moc slozita). Hlavni cast mam hotovou, zatim jen klasicke zobrazovani textu, priste budu pokracovat. Celkove je ale nove psany kod podstatne kratsi a jednodussi snad na 1/2, nebo minimalne o 1/3 puvodni delky posledni verze.

DOTAZ:
Lze nějak Copperu říci, ať nevykresluje čáru až na kraj obrazovky?
V emulaci pri full-screen zobrazeni jsou na pravem konci vydět takove přehupy. Některe Amigy s velkym rosahem zobrazeni obrazu na sirku tyhle kraje dle vseho zobrazuji. Poustel jsem si dnes intro "Mindsurfin" a ty prehupy to tam zobrazuje taky. Nicméně 1 obrazek delany dle vseho taky Copperem ty prehupy nema. Tam ale Copperem kopirujes obrazek mensi sirky, tedy je v nem na kraji cerna barva. Co je asi reseni, jak ty prehupy v obraze nemit. Ale pokud se dela cista cara pouze Copperem, tak se tomu asi neda vyhnout. Prekryt ten konec cary znakem mezery nemuzu, az tak na kraj mi bitplan nedosahne. Za situace, kdy s tou carou nechci hybat se priklanim k reseni, ze ji vypisu spise pomoci znaku, cim se tomuhle prehupu v grafice vyhnu.

Obrázek s přehupem (v červeném rámečku) v čáře na pravé straně s použitím Copperu (full-screen zobrazení u emulace):

Instrukce TST neumožňuje testovat hodnotu v adresovém registru. Viz. dokumentace

Místo CMP.L #0,An bych spíš použil MOVE.L An,Dn, pokud máš k dispozici nějaký volný datový registr. Je to výrazně rychlejší a menší. A nebo CMP.L Dn,An, pokud můžeš mít v Dn nulu.

Tak vcerejsek se nesl v duchu zkušení vykreslovani urychlit, když je v textu mezera, to se ale nepovedlo. Kdyz jsem na mezere vynechal ze zpracovani tak pulku kodu a ani ji nezapisoval pomoci Copperu, tak se urychleni nekonalo. To bude kombinace toho, jak text vykresluji, jak pracuje program v Amize zamerne pomalu a 50 Hz zobrazovanim asi. Tak jsem se s rychlesji praci zobrazeni, kdyz je v textu mezera rozloučil. To ale neni az takovy průser.

Pak jsem se zameril na praci s casovou pauzou u vypisovani textu. Po mych zkusenostech s urychlenim, kdyz je v textu mezera, jsem to neviděl moc dobře. Musim psat stejny text na jiz napsany text, nebo je to nejjednodussi reseni, jak zabezpecit u casove pauzy textu konstantni hrani skladby. Napadlo mne, ze muzu zobrazovat stejny text pouze jen 1 čáru (výška 1 pixel) z kazdeho pismena, to mi pomohlo nemit tak dlouhou casovou pauzu pri vypsani celeho textu na jiz vypsany stejny text. To jsem si pak jeste dal nastavil tak, aby mi nastaveni časovače v rozsahu 1 bajt umoznilo pouzit jak kratkou pauzu tak dlouhou. Ve vysledku zatim zobrazuji tedy 1 čáru z kazdych 2 poslednich pismen. To mi umoznuje udelat casovou pauzu u jiz vypsane obrazovky pri nastaveni casovace na hodnotu v rozsahu 1-255 v rozsahu cca 3 vteřin až 13 minut. Já to pak ještě časem nastavim lepe když budu potrebovat, hlavne kvuli mensi pauze než 3 vteřiny.

A dnes se mi opet neco povedlo. Vcera jsem zjistil, ze mi nova verze kodu pro psani textu nebezi pod ROM Amigy 500. Relativne rychle jsem prisel na to, ze byl problem v 1 instrukci. Kdyz jsem ji psal (možná poprvé s tímhle použitím), nemel jsem nejlepsi pocit, ale vyvojove prostredi mi chybu nehlasilo, tak jsem to pouzil. Amiga 1200 s tim problem nema, ale A500 již jo.

Je to instrukce testu vynulovaneho adresoveho registru v mem pripade A4.
Kde jsem zadal:
Ta mi fungovala pouze na Amize 1200

Tak jsem jí nahradil testem nul v adresovem registru:
A tohle řešení již funfuje jak na Amize 500, tak na Amize 1200

Programování zdar!

Tak vcera jsem dokoncil dalsi verzi programu pro praci s textem, tedy jeji hlavni cast pro zobrazovani textu. Mam ted dovolenou a nemel jsem zadny vyrazny motor pro mne nez je tohle, tak jsem jel od rana az kym jsem nepadl relativne nonstop. Po 8 dnech jsem se dostal do stavu preprogramovanosti co bylo vcera tak to beru volneji, nebo vysadim, uvidim. V zaveru vcerejska jsem jeste pridal zrychleni kodu s textem. Jak jsem psal posledne, ze si muzu dovolit pouze 1 cyklus prace s textem k 1 cyklu hudebni rutiny, neni to celkem pravda. Je to celkem 5 cyklu psani textu a 1 cyklus hudebni rutiny, pokud nechci pouzit dvě ruzne programove casovani pro A500 a A1200. Jinak by to samozrejme na obou pocitacich mohlo litat jako drak s konstantnim hranim skladby. S pouzitim 1 casovani pro oba pocitace ale pouze 5 cyklu psani textu. Dnes jsem jeste pridal praci s pauzou, uvidim jestli to takhle bude stacit, ale snad ano. Jak budu chtit pridam mazani textu a minimalne zaklad bude hotovy. Neplanuji do toho dalsi veci, pouze kdyz tak nutne rizeni pro program co budu potrebovat.

Jen pro zajimavost, pokud se misto 5 cyklu pro program s textem pouzije za stejny cas 10 cyklu, A500 bude hrat skladbu pri dane rychlosti 5 pro format MOD a muj format tuhle rychlost ma jako 4 (rozsah 0-31 a ne 1-32 jako u MODu) pri pouziti stejneho casovani pro oba pocitace pomaleji odhadem asi o 5 procent.

I kdyz vlastnim A500, zatim ji porad neprovozuji, testuji na emulaci. Ta se da dat i pod ROM 3.x na rychlost A500. To je ale pouze na hrubejsi nastaveni. Pod ROM 1.3 to jeste je treba casove vyladit. Tam je beh programu jeste o neco pomalejsi. Tomuhle nastaveni ROM 1.3 pod emulaci zatim verim, nicmene muzu pouzit i min cyklu pro program s textem nez je 5 jiz. Casovou rezervu tedy snad mam a pripadne nutne otestovani CPU to jisti

Samozrejme ted je nejvetsim otaznikem pouziti skladby s rychlosti hrani nizsi nez je tahle skladba. Ale to je hodne pomale tempo a kdyz tak se pokusim testnou to CPU, ale to je jen takaova zaloha kterou si myslim nepouziji

Diky, ja zkusil napasovat mou hudebni rutinu na VBLANK misto CIA, jestli mi to nevyresi to, aby mi hrala melodie konstantni rychlosti jak na A500, tak na A1200, nicmene nevlezu se casove / rychlostne s 1 smyckou hudebni rutiny do 1 snimku VBLANK a i ten 1 snimek je dost pomaly na tohle, alespon u mne. Krome hlavniho casovace CIA, ktery jsem chtel nahradit VBLANK pouzivam CIA jeste napriklad pred nahranim vysky tonu do registru, protoze se nekdy do registru nenahral a tak to pribrzduji, ale tam mam CIA nastavene jen na 70 hexa u kazdeho hudebniho kanalu, tedy mohlo by pomoci kdyby jsem to zrusil, protoze ted jiz pracuji s frekvenci tonu naprimo a nehledam tu spravnou ze vsech v cyklu, co jsem takhle jeste nedavno delal. To jsem nezkusil a co jsem v minulosti zkousel, tak i samotne pouziti CIA nastavene se spozdenim na 0 ma celkem slusnou casovou rezii, ale ja jiz zacal cely kod co pracuje s textem opet prepisovat (mel a mam to jiz nove napsany a znovu predelavam). Myslim, ze spusob jak na to ted jdu bude stacit k tomu, aby stacil k 1 cyklus hudebni rutiny a pouze 1 cyklus pro psani textu cim pak dosahnu stejnmomerne rychlosti hrani skladby aniz bych musel detekovat CPU a dle toho pak pouzit jedno ze 2 nastaveni rychlosti prace programu. Prave jsem dohledal 1 chybu, kdy jsem pointer na text mel daleko v pameti pomoci PC relativniho adresovani, tak jsem to poresil jinak. Assembler mne opet vyskolil. Ono prekrocit to rozmezi dosahu PC relativni adresace neni opravdu az tak těžký... .

Jeste jsem nove CIA pouzil v hudebni rutine v mistech, kde se vynechavaji cele 4 bajty v hudebnim formatu, aby jsem to v techhle mistech pribrzdil, pomohlo to. Ono mi pomalu stacilo vyvolat pouze prazdny podprogram, tedy BSR, navesti a RTS, ale pridal jsem k tomu i CIA nastavene na nulu. Pomohlo to rovnomernejsimu hrani melodie pri stave, kdy k cyklu hudebni rutiny pridavam i cyklus pro praci s textem. Muj hudebni format nema konstantni sirku a rozdil takovych 3 Longů byl již na rytmu hrani skladby pri vetsim zatizenim hudebni rutiny (s programem pro psani textu) i znát.

Díky a zatím zdar

Určitě. Kvůli OCS/AGA rozdílům.

Všechno je možné (s rozdílnou přesností) zjistit. Velikost a typ paměti, typ procesoru, frekvenci. Myslím, že se nejvíc používá test na dostatek paměti, pokud se to tedy nenechá přímo na systému, a pak na čipset. Další testy (CPU, frekvence, ...) jsou asi méně časté a/nebo nutné.
Za jeden snímek se toho i na základní A500 dá stihnout dost. Nebo za dva snímky. Hodně her běžně jelo "jen" na 25fps.

Resi se nejak u hole Amigy 500/1200 jejich detekce v ramci programovani? Rozdily vykonu obou pocitacu jsou celkem znacne. Tedy pokud chceme provest neco na obrazovce a zabezpecit aby to stejne rychle delala i A500 znamena to hodne velike osekani celkovych moznosti, z meho pohledu dost radikalni osekani, protoze A1200 je vuci A500 opravdu celkem rychlik.

A taky casovani VBLANK mi pro holou A500 zatim pride hodne hrube. Tedy ze se za 1 snimek po programove strace u hole A500 toho neda moc stihnout. Ale samozrejme me prvni dojmy.

Kdyby jsem nemusel resit u ASM vykon A500, ale pouze A1200 a vyssi, citim se podstatne lepe

Tak dnes taková drobnost, udělal jsem to prvně a to zvýšení 2 menších čítačů. Jeden v rozsahu 4 bitů (o hodnotu +1) a druhý v rozsahu 2 bajtů (ale jen těsně, horní hranice čísla se motá kolem 500 desítkově a tam je to o hodnotu +3) v jedné instrukci.

Alespoň mně to pobavilo

ADD.L #$30010, A1

Pokus rozběhani intra na A500+ s 2MB chip RAM. První problém je někde v miniwraperu od Photona co odstavuje systém, ten jsem zatím kompletně vyhodil. Další problém je v zobrazovací části textu.

Ale...
​​​​​​


​​​​​

Nedá mi to a zajímá mně jak šikovně by si řešil skutečnost, že při jiném režimu zobrazování textu (znaky 1 až 9 a A až F), vůči tomu standardnímu se ti začne na A1200 hudba v tempu zpomalovat a když dáš u CIA hodnotu o 1 menší máš tempo skladby moc rychlé. Jak by si to pak přibrzdil, aniž by si přidával co i jen 1 řádek dalšího kódu? Opět jen pro zajímavost, ve skutečnosti se hodnota nastavení CIA sníží o 5, protože se dělá celkem 5 cyklů (hraje se melodie rychlostí 5). Já mám rychlost i 0, tedy v MODu je nastavení 5 a u mně 4 🙂

...jen se s tebou bavím o tom co mně baví. Ono mně někdy ty řešení opravdu pobaví, minimálně v závěru.

​​​​​​

Díky, já LEA používám zatím jako PC relativní adresaci, vím že to byl příklad . Já řešil zacyklení celého intra a to je skok více než 2 byte. Jenže pokud chceš použít při odečtu i poslední bit ze 2 byte, jíž musíš pracovat s rozsahem Long, aby byl výsledek správný, co jsem si musel uvědomit. Na pro mně potřebný skok mi 2 byte nestačí. Tak si jen odchytnu poslední bit ze 2 byte a provedu skok přímo v kódu, aniž bych hodnotu zadával do textového enginu. Nižší hodnoty bez posledního bitu ze 2 bytu jsou již zpracovávány textovým enginem. Já si teď ověřuji, jestli mám ten skok správný. Ono nedělám skok na úplný začátek, to jen tak pro zajímavost. Kvůli tomu si ještě budu muset sesynchronizovat druhou smyčku programu s tou první.

Hodnota v adresovém registru je vždy v plném rozsahu 32 bitů. Adresové registry podporují pouze aritmetické operace v plném rozsahu 32 bitů.
V důsledku to znamená, že jakákoliv hodnota s menším počtem bitů (8 nebo 16) použitá jako vstupní operand je automaticky rozšířená na plný rozsah 32 bitů. Hodnota vstupního operandu se vždy bere, že je se znaménkem!
Z tvého popisu to vypadá, jako by nebylo možné mít v adresovém registru hodnotu $8000 aniž by nebyla rozšířená na 32 bitové číslo $FFFF8000. To samozřejmě není pravda. K nastavení nebo vynulování horních 16 bitů dojde pouze při přesunu nebo při aritmetické operaci.
v A0 bude hodnota #$FFFF8000.
Tady bude mít A0 normálně hodnotu $00008000.
bude mít stejný výsledek jako
Z toho vyplývají některé optimalizace. Např. je zbytečné dělat
stačí
Je zbytečné dělat
stačí
(assembler se zaplou optimalizací si toho ale asi všimne a udělá úpravu sám)
apod.

​​​​​​Předpokládám, že vlastnost, když máme v adresovém registru v rozsahu word nejvyšší bit na logické 1 = 8000h, se další 2 byte (druhý word z Longu nastaví na hodnotu FFFF = FFFF8000h) má opodstatnění o kterém zatím nevím... .

Edit: pokud do adresového registru dáváme hodnotu v rozsahu wordu...

Problém dle všeho vyřešen.