Ten kdo sleduje Oldcomp ví,ze krome assembleru se v posledni dobe hraju i s programovanim v C#. Tenhle programovaci jazyk vyssi urovne jsem pouzil pro udelani prevodniku z hudebniho formatu MOD na muj hudebni format. Technicky jsem byl skoro hotov. Jen jsem si pak uvedomil, ze pokud bych chtel s hudbou delat i nadale, kazda dalsi tvorba by byla kazdou dalsi praci zbytecneho prizpusobovani skladeb na muj hudebni format a to i za stavu, ze by znacnou cast udelal samotny prevodnik. Rekl jsem si ze je na case otocit list a zacal jsem pracovat s myslenkou, ze bych presel na zpracovani samotneho formatu MOD, ktery je konstrukcne na tom preci jen lepe nez muj hudebni format.

Jen pripomenu hlavni duvod, proc jsem zacal delat hudebni rutinu s mym hudebnim formatem. Jednoduse jsem to vnimal jako moc novych informaci, aby jsem se zacal ucit assembler, se kterym jsem nemel zadne zkusenosti a jeste u toho studovat hudebni format MOD, ktery jsem taky neznal stejne jako jsem nemel zkusenost s nacitanim dat z nejakeho externiho souboru, z MODu.

Chtel jsem si nejdrive z MODu vzit pouze data k samotne skladbe v ramci patternu ze skladby a ze si ostatni udelam po svem. Tak jsem vytvoril novy soubor a dal jsem si do nej casovac CIA, pointre na sample do sladby a udelal prvni kod, kde se mi zpracuji data zatim jen z patternu, tedy z casti dat z MODu ktere jsou urcena pro hrani tonu jednotlive skladby. Zatim jen cisti kod, ktery nemel ani pouzite HW registre. Nejmin mi sedelo zpracovani dat pro hrajici sampel, kde je 1 bajt rozdeleny na 2 casti, jen jsem premyslel, jak to zpracovat alepson trochu elegantne = co nejstrožeji. Já bych treba Lower four bits of sample number prohodil s Effect command a pak bych udelal rotaci doleva o 4 bity v 4 bajtech s tim ze bych jeste Lower four bits prohodil s Upper four bits of sample number, ale ok. Ve formátu MOD maji bity pro Effect command vetsi prioritu nez bity pro cislo hrajiciho samplu.

Struktura formatu MOD pro data z patternu:





Pek jsem ale zacal resit, jak lepe zpracovat pocet pointrů na jednotlive sample, pokud by jsem to delal sam a nebral tyhle data primo z MODu, protoze zatim u mne mel kazdy sampel skladby svuj vlastni pointer, neboli ukazatel na misto v pameti, kde se sampel nachazi a odkud jej číst. Pri vicero skladbach by to jiz slo do poctu, ktery se mi moc nelibil hlavne kdyby meli skladby vetší počty samplů. Tedy maúriklad 7 skladeb po 20 samplech by bylo 140 pointru v pameti na jednotlive sample a to se mi moc nelibi. Tyhle pointre by museli byt zvlast zadany primo v kodu a to samostatne, neboli zatim neznam zpusob, jak to udelat jinak a zatim se domnivam, ze bych to musel rešit nejakou komunikaci pomoci systemu, co je pro mne vyšší divčí (je to na mně moc). Nepovedlo se mi v kodu...

incdir "DH1:MOD T02X3/"
incbin "T02X3.MOD"

nacist samotny MOD jinak nez takhle. Chtel jsem u "incbin" mit moznost zadat retezec textu s nazvem modu treba z datoveho registru, nebo z pointru v pameti, kde by byl tenhle retezec textu s nazev souboru, tedy MODu. Tedy se mi soubor podarilo nacist jen s primym zadanim: incbin "T02X3.MOD"

Počet pointrů na sampel bych snizil, kdyby jsem mel sample nahrane za sebou a pro vsechny sample ve skladbe bych tedy mel celkem 4 pointre v pameti (4 hudebni kanaly). To by byl jiz stav lepsi a pro mne prijatelny.

To mne nakonec dovedlo k zaveru, ze tohle vse je jiz v samotnem MODu a ze bude nejlepsi nacist rovnou cely MOD a z neho si konretni sample nacist, co by celou situaci rešilo. Tedy jsem zkušebne zadal:

incbin "DH1:MOD T02X3/T02X3.MOD"

a navýšill pointer (ukazatel) v pameti na tenhle MOD o 1084 bajtu, co je misto, kde v MODu zacinaji data patternu MODu a porovnal tyhle data s datami z meho programku v C# kde mam taky jen data z patternu. Ty 4 bajty byly shodné... .

Tak fajn, budu tedy načítat celý MOD





​

Ano dá. Netroufám si tvrdit, jestli jsou mé znalosti úplné (a nebo správné). Napíšu v krátkost jen to, co teď vím a co si vybavuju.
Je velký rozdíl mezi A500 s CPU 68000 a A1200 s 68020. Nejdřív A500+68000, protože 68020 (a částečně i AGA) věci poněkud komplikuje.

Základem všeho je chip sběrnice a její taktování. A taky způsob její arbitráže, tedy kdy se povoluje přístup k čtení a zápisu na sběrnici jednotlivým HW částem Amigy. Ve tvém případě tě zajímá, jak ke sběrnici může přistupovat CPU. Arbitr sběrnice je v Agnus. Ta umožňuje přístup CPU ke sběrnici maximálně jen každý její druhý takt. To je hardwired, nejde to změnit a má to svůj důvod: Z časování instrukcí 68000 je zřejmé, že CPU potřebuje přistupovat ke sběrnici vždy jen v její liché takty. Např. nejjednodušší instrukce MOVE.W Dn,Dn trvá 4 takty, z toho v prvním a druhém taktu je třeba přistoupit je sběrnici (instruction fetch) a další dva takty trvá provedení. V A500 je CPU taktováno 2x rychleji než sběrnice, takže první dva takty CPU pokrývají jeden takt sběrnice. Další dva takty se sběrnice nevyužije. Pokud by instrukce četla z paměti operand, toto čtení se provede v taktech 5 a 6, a pokud by dělala i zápis, tak ten by se provedl v taktech 9 a 10. Tak je patrné, že přístup ke sběrnici se prokládá s takty, kdy se provádí interní operace a sběrnice pro CPU není zapotřebí. Proto je pro Agnus zbytečné, aby CPU dávala k dispozici každý takt sběrnice.

Rozdíl ve fast-ram (a myslím skutečnou fast-ram a ne expanzní 512kB paměť pro A500, která se připojuje na chip sběrnici - tzv. fake fast-ram, nebo též slow-ram) je v tom, že zde řadič (velmi primitivní) umožňuje přístup k RAM CPU v libovolném jeho taktu. Ale jak je z výše uvedeného snad patrné, je to vlastně zbytečné, protože CPU to stejně nevyužije.
Upozorňuju, že vše popsané platí jen pokud se bavíme o standardní A500, kdy je takt CPU dvojnásobek taktu chip sběrnice!

Jak je tedy možné, že fast-ram má i v A500 zrychlující efekt? To, že Agnus může dát sběrnici k dispozici CPU každý druhý takt, neznamená, že ji má k dispozici, a že ten přístup CPU skutečné dá. CPU má totiž v systému nejnižší prioritu ze všech zařízení (DMA kanálů). Pokud se toho na sběrnici děje hodně (fetchuje se příliš moc bitplane dat, copper jede na plné pecky, blitter kopíruje jak divý, do toho jsou zapnuté sprajty, ...), klidně se stane, že CPU se ke sběrnici nedostane po celou dobu generování obrazu. Tedy vždy, když paprsek na TV něco vykresluje, je sběrnice obsazená. CPU může načíst instrukci nebo načíst a zapsat operandy jen mimo tento čas (horizontal nebo vertical blank). To ale neplatí, když má CPU instrukce a data k dispozici ve fast-ram. Tam ho nic nebrzdí. A to je ten jediný rozdíl. Zjednodušeně se dá napsat, že pokud se na screenu Amigy nic moc neděje (lo-res max v 16 barvách, copper se fláká, blitter stojí, ...), nemá fast-ram oproti chip-ram žádný efekt.
Z chování chip sběrnice vůči CPU vyplývá i to, že nemá příliš velký význam 68000 přetaktovávat, pokud není k dispozici fast-ram. Je fajn, že se hodně instrukci _interně_ provede rychleji (určitě se velmi zrychlí provádění náročných instrukcí jako MUL, DIV nebo bitové posuny a rotace), ale CPU stejně musí čekat na chip sběrnici, třeba jen k tomu, aby načetlo kód další instrukce.

U A1200 se situace komplikuje tím, že je v ní 68020. A ta má interní instrukční cache. Už jen kvůli ní je možné načíst kód instrukce a začít ji zpracovávat bez ohledu na dostupnost chip-sběrnice. Ale má to svá velká omezení. Cache je jen pro instrukce, takže se stále musí číst a zapisovat do chip, pokud jsou operandy v paměti (a ne pouhé registry). 68020 je však obecně rychlejší. Nejen že byla taktována 2x rychleji než 68000 u A500, ale je i plně 32bitová, takže operace nad 4 bajty trvají už jen jeden takt. Chip sběrnice je u AGA pro CPU 32bitová - takže dvakrát rychlejší než u OCS, i když její takt je stejný. (Tady ještě uvedu, že AGA umožňuje fast-page mód u chip sběrnice, kdy se v jednom taktu může načíst až 8 bajtů dat. Bohužel ten je k dispozici jen mezi Alicí a Lisou k načítání bitplane a sprite dat.). Fast-ram má u A1200 obdobný efekt jako u A500, tedy že sběrnice synchronní s CPU může poskytovat data kdykoliv je potřeba. A protože má 68020 instrukční cache, lepší (úspornější) časování instrukcí a v jednom taktu čte/zapisuje celé 4 bajty, využije se to mnohem častěji. Proto je efekt fast-ram v A1200 dramatičtější než v A500.

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.