Dnes jsem konecne zkusil na emulaci WinUAE pod cistou ROM 1.3 / A500, kdy zkompilovane exe nakopiruji na disketu a udelam reset, jestli vse bezi rychlostne ok a tvari se to, ze ano.

Zkusil jsem emulaci pak jiz ve WB pod A1200 nastavit rychlostne pomoci SysInfa na rychlost A1200 a nejak se nezadarilo. Cycle-exact zaskrtnute, pamet na 1MB chip a porad jsem byl podle SysInfa rychlostne mezi A1200 a A2500. Pokud jsem u stejne konfiguraci presel z AGA na Full ECS (WB hlasil nejakou chybu, ale šlo to), tak již se rychlost dle grafu shodovala s rychlosti A600, ale jakmile jsem nastavil na emulaci AGA, rychlost byla opet mezi A1200 a A2500. Očekával bych rychlost A1200.

A ještě dotaz k rychlosti z mých zkušeností v rámci optimalizace kodu i pro A500. Může se zrychleni A1200 s 4 MB Fast RAM blížit až 4 násobku rychlosti holé A500?
Dá se nějak shrnout rychlostni rozdil A1200 s fast RAM, A1200 bez fast RAM, A500 s pridavnou RAM a A500 v základu? Pokud sehraje roli i A500+ vuči již zmíneným konfiguracim, tak klidne zahrnout. Jde mi tedy o rychlosti pouze s pridavnou RAM bez turbokarty

Díky za upozornění, chtěl jsem udělat za vypisovaným textem čtverec, ale ten text se postupně vypisuje docela rychle na to, aby se mi to s tím čtvercem líbilo, tak tam vypisuji prázdný znak. Tohle řešení je myslím míň rušivé, ale dostačující na to, aby jsem oddělil předchozí text od textu nově vypisovaného. Tohle řešení má pak i další výhodu, lze celkem dobře použít pro stav, kdy nebudu chtít na obrazovku z 2.zdroje textu chvíli nic vypisovat. 1.zdroj textu má na tohle svůj vlastní časovač.

NOP jsi asi nepoužil zcela správně. Na Z80 fungovala jako vycpávka - nedělala nic, jen zabrala cyklus. Ale na 68000 dělá něco jiného:
viz https://www.nxp.com/docs/en/referenc.../M68000PRM.pdf

Pri psani textu jsem v 1 pripade potreboval, aby se znak vypisoval opradu stabilne. Pouzivam CIA casovani a to mi umozmuje zpracovavat vypisovany znak na obrazovku i v case, kdy el.papsek neni na obrazovce, tedy asi v case preruseni. To nejak dle vseho nevadi, oko to nepostrehne. Zobrazovani textu se mi zda byt stabilni az na 1 pripad, kde v case, kdy se kona preruseni a ja chci vypisovat konkretni znak, ktery potrebuji vypsat opravdu stabilne to postrehnutelne opravdu je.

Dané nestabilni vypisovani konkretniho znaku se dalo kodem minimalizovat tim, ze jsem vykreslovaci smycku kodu pro znak minimalizoval, nicmene porad to nebylo ono.

Pripadne pouziti instrukce NOP (asi pseudo instrukce), nebo casovace CIA nechteny stav zmirnilo, ne vsak vyresilo.

Pak jsem si vzpomnel na pouziti kodu pro vyckani na konkretni radek el.paprsku pomoci casovani VBLANK. To, ze hudebni rutina potrebuje vice casu nez je pockani na vykresleni 1 konkretniho radku el.paprsku je mi jiz nejakou dobu znamo.

Podival jsem se na netu na kod a nejdrive jsem 1 hlavni smycku hudebni rutiny nechal hrat po vykresleni 1 el.paprsku, hudebni rutina nestihala, ale vykresleni potrebneho znaku bylo stabilni. Kod pro vyckani na el.paprsek jsem dal primo pred smycku na vykresleni konretniho znaku. Tak jsem vyckal na 2 paprsky, tedy 2 cykly hudebni rutiny pocas vykresleni 1 snimku, to jiz bylo skoro dobry, no tak jsem to dal na 3 cykly hudebni rutiny pocas 1 snimku obrazu a to jiz je OK a potrebny znak se na obrazovce zatim vykresluje stabilne.

Kdyz se tak vlastne nad tim zamyslim, tak se spise hraje 1 cyklus hudebni rutiny pocas vykresleni 1 obrazu, nicmene prevdepodobnost, kdy se ma hudebni rutina "dostane ke slovu" jsem asi ztrojnasobil. To nevylucuje alternativu, ze se muzou stihnout nekdy 2 cykly hudebni rutiny, nicmene pouze 1 cyklus hudebni rutiny za vykonani 1 obrazoveho snimku jí je casove malo.

Kód vypada ne zcela originálne, ale zatim funguje

Názvy navesti casem zvyknu dat na nejake srozumitelnejsi (vetsinou)

Asi to pak pujde dat lepe na třetiny než 80/160/240 radek s tim ze nejnizsi radek (ted 240) bude muset byt ponizen o vysku znaku (8 radku), aby se mi nizsi radky znaku nedostali mimo chteny cas pro vykreslovani.

Vse je teprve standardne v testovani.

Kód ktery ceka na konkretni radky el.paprsku a pak za navestim "lala21" vykresli konkretni znak a pak pousti "ke slovu" i hudebni rutinu zde, misto puvodni instrukce ASR jsem pouzil z meho pohledu prihodnejsi LSR. U toho ASR pak vse resi AND, ale i tak. Ja jsem se jiz pri pouziti ASR par krak celkem napalil.

Včera jsem dokončil program pro zpracovaní textu, který pracuje se 2 zdroji textu naráz. U vypisováni 2.textu jsem nemohl zcela použít program, co mi píše 1.zdroj textu, ale snažil jsem se to na něj napasovat a z původního kódu použít alespoň zobrazovací část. Ta je ale na počet instrukcí delší a na potřebnou rychlost zobrazení 2.textu, po tom, co jsem chtěl dosáhnout ještě 1 konkrétní věci to v závěru nestačilo a tak má celé vypisování 2.zdroju textu vůči 1.zdroju textu svůj vlastní kód.

Díky, zkusím.

info:
Nepovedlo se mi vypisovani mezery vůči běžnýmu textu urychlit. Ale to prepsani kodu nebylo uple marny. 2 promenne nemusim davat vuci predesle verzy do 1 adresoveho registru, co je fajn. Rozsiril jsem pocet radku na obrazovce z moznych 15 na vice (255). Ve skutecnosti mi 3 radky chybely.

Zavedl jsem v textu specialni znak, který trochu dorovnava to, ze se mi nepovedlo urychlit zobrazovani mezery a rika, odted co je dal v tomhle bloku textu te nezajima a preskoc to. Pokud se v danem bloku nenachazi zadny text, lze to pouzit a funguje to hezky.

Jdu si dat oraz

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