Mohl bych prohodit u MiniWrapperu od Photona u podprogramu návěstí WaitRaster s WaitEOF? Kdyby to šlo, nemusel bych použít podprogram WaitEOF0. V A6 je $dff000. Před spuštěním mého programu používám podprogram WaitEOF0, po ukončení mého programu podprogram WaitEOF.

Podprogram AllOff0 již používám jak u vstupu tak u výstupu z mého programu, tedy podprogram AllOff dám do komentáře. Nicméně předpokládám, že jinak by výměna návěstí AllOff s IntReqD2 asi nebyla problém, kde bych pak nepoužil již podprogram AllOff0, protože bych jej volal napřímo tím, že bych měl prohozená ty 2 návěstí a nuloval jen INTREQ dva krát po sobě.

V obrázku je část kódu od Photona s mou úpravou a přidáním návěstí WaitEOF0 a AllOff0.

Tak dnes jsem se opět hrál s kódem od Photona, který vypíná systém a pak jej obnovuje v mém kódu. Ještě jednou jsem se zaměřil na u mně problémové části kódu a snažil se najít alespoň u mně nejlepší konfiguraci problémových části kódu (jsou jen 2 hlavní). Jednou jsem se rozhodl na základě tohoto, že se mi povedlo uvést můj program po několikátém spuštění do chyby, kdy již nešel vůbec spustit a má změna v kódu od Photona umožnila opětovné spuštění kódu 🙂. Mezi tím se mi a já přesně pořád nevím proč začal opět správně zobrazovat text až ke krajům obrazovky (zobrazoval se mi s odstupem od krajů) a dokonce mi i zobrazuje poslední 2 pixely na pravé straně co být taky problém. Našel jsem nejoptimálnější nastavení kódu od Photona vše uložil. Vypnul jsem A1200 tak na 10 minut. Zapnul. Kód spustil z rozlišení HiRes a i Multiscan Productivity (640x480) Zobrazení bylo správné. Zkompiloval jsem kód do EXE. Spustil kód z HiRes a Multiscanu a zobrazení je správné.

Pokud se mi to ještě někdy rozjebe, udělám vše proto abych zůstal klidný ale to správné zobrazení textu ke krajům jsem dnes opravdu nečekal 🙂

Hele je rok 2022 a hlavní úkol mého PC je emulace Amigy

Nemyslím, že by se na AGA nadávalo. Na západě možná někteří v roce 1992 čekali víc? Ale to nedokážu posoudit. U nás byla realita určitě jiná. Zpětným pohledem je samozřejmě vidět, že AGA byl jen nutný upgrade. Díky rychlejším DRAM umožnilo fetch až osmi bitplanů (a to i při 35ns pixelech) a s tím související podpora až 256 barev (a HAM8 režimu atd.). Bohužel to bylo z grafického hlediska vše. Sběrnice zůstala stejně rychlá (nebo spíše pomalá) jako v roce 1985, Copper zůstal stejný, Blitter zůstal stejný, i sprajty v podstatě zůstaly stejné (horizontální velikost se zvyšila taky jen díky 4x fetch módu). Navíc 4x fetch mód přinesl i různá omezení (problém s horizontálním scrollingem, se sprajty, ...). Je škoda že tohle nepřišlo aspoň o rok dříve -- snad by pak bylo pro AGA více programů (rozuměj her ). A mohlo to trochu víc konkurovat Genesis, SNESu a snad i tomu PC (?). No to je už jedno...

Tak to je dost slušná výhoda u AGA, možná největší jak na ni hodně lidí nadává

To platí jen pro ECS, AGA už toto omezení nemá (díky 4x fetch módu).
Commodore oficiálně zveřejnil jen dokumentaci k OCS a ECS. Myslím, že k AGA nic podobného nedal.

Ujisti se, že mažeš nebo správně nastavuješ všechny hodnoty registrů souvisejících s generováním obrazu. Nezapomeň například na vynulování horizontal scroll v BPLCON1. Na AGA je nutné nastavit správný fetch mode ($1fc) -- kvůli zpětné kompatibilitě s OCS/ECS je třeba ho vynulovat (i když to by asi mělo dělat už LoadView). Jinak mne nic nenapadá, proč by měl být obraz nějak posunutý, pokud používáš (víceméně) standardní hodnoty pro DIWSTRT/DIWSTOP (a s nimi související DDFSTRT/DDFSTOP).

Jen dodám že to, co mi u MiniWrapperu od Photona umožňuje spustit kód z grafického režimu Multiscan Productivity je u Graphics Library použití offsetu -222 LoadView(). Toho už jsem si vědom.

Jinak v dokumentacích jsem se dočetl že v grafickém režimu Multiscan Productivity lze použít pouze 4 barvy, ale mě reální A1200 s 4 MB Fast RAM pouští snad i na 256 barev. Hmm. Mám se ještě co učit.

Tak jsem si včera ráno chtěl spustit pro radost můj program kombinující hudbu v mém formátu a práci s textem a nefungoval, aniž bych v něm udělal změnu. Kód se mi po menší úpravě Photonovho MiniWrapperu povedlo rozběhat ale již ne tak jak jsem si to pamatoval a možná jsem si to pamatoval špatně. Hrál jsem se s tím včera celý den a taky si četl a hledal možné řešení..

Program se mi spouští vždy v rozlišení pro grafický režim Multiscan Productivity, tedy v 640 na 480. Alespoň se to tak jeví, protože mám text odsazen od krajů obrazovky jak levého tak pravého a je více posunutý doprava. Navíc a tohle již může být chybou mého LCD monitoru je posunutý obraz asi o 5 pixelů dolů. To posunutí dolů se mi projevuje jen na A1200 a LCD monitoru, který to může zobrazovat špatně. Pod emulací tohle posunutí dolů není, ale posunutí doprava a nedokreslení textu na kraje zůstává i v emulaci.

No a právě zjišťuji, že v emulací mi ani ta verze co mi obraz u real A1200ky posouvá doprava a nedokresluje ho na levou a pravou stranu monitoru, že se mi to v emulaci takhle nechová, pokud jsem v režimu Windowed nebo Full-window. V emulaci je obraz posunutý pouze v režimu Fullscreen (všechny 3 režimy jsou nastavením WinUAE) Nicméně v režimu Fullscreen mi WinUAE posouvá obraz i bez kódu MiniWrapperu od Photona. Tedy možná naháním duchy a i samotné posunutí obrazu na stranu bez dokreslení ke krajům a taky asi o 5 pixelů dolů u reální A1200 je jen tím, že si můj LCD monitor s tím neporadí.

Vypadá to tedy ale, že bych pod WinUAE režimu Windowed a Full-window mohl věřit. Tam mám obraz na střed. Nevidím pouze pár nejkrajnějších řádků nahoře a dolů, ale to je detail.

Má někdo taky zkušenost s tím že má pod WinUAE posunutý obraz u režimu Fullscreen na stranu?

No nic, aby mi nehrálo víc, než je současný stav, jdu dělat na chvíli opět něco jiného.

Jo a Probere s tou fází jsem napsal blbost, hlavně když se dle všeho asi jedná o část za trafem.

Tak jsem to přibrzdil takovým možná dočasným řešením, které jsem již měl hotové. Jsou to ty horní 2ky. Každá 2ka je 5 cyklů v hlavní smyčce programu. Je to časovač který mám určen na něco jiného, ale zatím jej používám i na to přibrzdění​​​​​​​. Těch dvojek by tam stačilo mít tak 18, já to přibrzdil více a je jich tam 45. Na foto je, jak vypadá můj formát pro práci s textem. Asi jsem to jsem již pár krát dával, ale mám z toho radost.

Dělal jsem si legraci, že když teď přenesu můj program z A1200 do PC, tak mi to pro jistotu zase nebude chodit v emulací, ale nestalo se tak

Tedy snad vyřešeny 2 problémy:
-Správné spuštění programu již i z grafického režimu Multiscan: Productivity.
​​​​​​​-Neusekáváni posledních 2 pixelů vpravo ani na reálné Amize.

​​​​​

Problém MiniWrapperu od Photona má mé Textro+hudební rutina s nulování bitů u DMACON a INTENA co je v návěstí AllOff a to jen u BSR (skoku na návěstí AllOff) před mým programem. Proto jsem si přidal návěstí / podprogram AllOff0, kde u daných registrů bity nenuluji, nuluji bity jen v registru INTREQ 2 krát po sobě pro kompatibilitu s Amigou 4000.
Po mém programu, kdy je návrat do systému již nuluji bity beze změny původního kódu, tedy ve všech 3 zde uvedených HW registrech.

Všechny zde teď uvedené časy a počty uvedu přibližně. Správná práce s vypisováním písma v mém programu po zavedení MiniWrapperu začíná někde na 100 cyklu velké smyčky v mém programu. Tedy chvíli mu trvá než se to vše správně chytne. Časově se jedná asi o 1 vteřinu. Asi tedy u textra udělám jednu malou obrazovku s asi 20 mezerami, než začnu pracovat s vypisováním textu.

Přibrzdění v kódu pomocí CIA nějak nepomohlo, že bych tomu MiniWrapperu dal vice času. Tak mi 1 malá krátká obrazovka naprázdno přijde zatím nejrozumnější, že nebudu muset do mé hlavní smyčky v kódu přidat nějakou další instrukci.
​​​

Defor, @ALL:​​

Tak dle předpokladu se mi kód z rozlišení Multiscan Productivity opravdu nepouštěl kvůli nedostatečnému stopnutí Workbenchu. Použil jsem MiniWrapper od Photona o kterém zde píšeš a zdá se to již být ok. Drobatko mi něco v tom kódu haprovalo a to tak nějak vím kde je problém. Nejdříve jsem měl rozběhly kód pod emulací, ale když jsem to spustil na A1200, tak jsem to vlastně nespustil. Dnes jsem se k tomu opět dostal a hodil do poznámky celý kód MiniWrapperu a postupně jsem jednotlivé části aktivoval již přímo na A1200 (odpoznamkoval kód) až na jednu dle všeho zatím problémovou část a dorazil na BSR odkud volám můj kód a řekl si, tohle zatím bude stačit. Přepnul jsem si v ASM-Pro screen mode na Multiscan a pustil jsem kód a běželo to. Celý kód jsem hodil zpět do poznámky, aby nebyl aktivní a řekl jsem něco ve smyslu tak a teď se to doufám posere a spustil jsem to a ono se to opravdu posralo. Ještě se s tím příště pohraju, ale boží, na hlavní problém to zabírá. A navíc MiniWrapper od Photona mi odstraňuje dle všeho další chybu a to, že už mi to ani na A1200 neusekává z obrazu poslední 2 pixely vpravo. Doposud to bylo ok jen v emulaci.

Ještě budu i testovat, ale vypadá to dobře.

Jen pro zajímavost, nejdříve se mi do tohohle nechtělo, chtěl jsem v asm dělat něco jiného, ale jak jsem.v nejbližší době zapnul ASM-Pro, začal jsem hněd dělat na tom, na čem jsem dělat nechtěl, protože v ten moment jsem si řekl, že je to pro mně to nejzajímavější. Jednoduše jsem otočil v rámci mého názoru o 180 stupňů, čím se dostáváme k závěru, že ani já sám někdy nevím, co můžu od sebe očekávat

@Defor: Díky za nasměrování na ten MiniWrapper

Dnes jsem se s tím celkem hrál, pořád stejný výsledek. Zkusil jsem další 2 kódy, italský a polský se stejným výsledkem. V emulaci fungují, na A1200 nefungují. Myslím že to nejvíce vystihuje tenhle obrázek, když zobrazuji pouze 1 bitplane.

ok,

včera jsem to vše tedy hudební rutinu, testovací melodií a program pro práci s textem spustit. Pod emulací funguje, na reální A1200 nefunguje. Obraz je rozhozený, možná si o tom právě psal výše. Zatím jsem vše neměl čas zkoumat.

Vím ale:
-poslední verze mé hudební rutiny bez práce s textem funguje na reální A1200.
-ani původní neupravený kód jen programu pro psaní textu nefunguje na reální A1200.
-vlastně žádný program co mám (mám ještě další 2 z AmigaReview) nefunguje na reální A1200. Obraz je rozhozený, ale v emulaci programy fungují.
-zatim vycházím z předpokladu, že pokud se zprovozní původní program pro práci s textem na reální Amize, bude stejná chyba i v mé hudební rutině kde pracují i s textem a bitplany. Ale může tam být samozřejmě i více problémů.
-jak budu mít čas, najdu si nějaký funkční příklad zobrazení obrázku pomocí bitplanů (raw souboru).

Původní program bez mých úprav ze kterého pak vycházím i v mé hudební rutině je v příloze. Program funguje v emulaci, ale nefunguje na reální A1200.

Miluji programování

DMAEN bit (podobný je INTEN bit v INTENA registru) povoluje nebo zakazuje (podle toho jestli se nastavuje nebo maže) všechny DMA procesy. Tedy pokud bys potřeboval z nějakého důvodu zakázat všechny DMA, nemusíš mazat jednotlivé bity, ale stačí smazat jen DMAEN. Pro opětovné povolení jej stačí jen zpátky nastavit. Je to "master enable/disable bit". Nemusíš ho nastavovat, pokud máš jistotu, že už je nastavený. Pokud ji nemáš, tak neuškodí ho nastavit

Vypnutí DMA pro sprajty se skutečně udělá zápisem $20 do DMACON ($96) registru. Jen bych dodal dvě poznámky: 1. Je vlastně zbytečné to dělat v každém snímku (tedy v copper-listu, který se provádí každý snímek). Stačí to udělat ve správný čas jen jednou. 2. Je nutné si pohlídat, aby DMA sprajtů nebylo vypnuto v okamžiku, kdy už došlo k zápisu dat do kontrolního registru SPRxCTL a do datavého registru SPRxDATA. K tomu prvnímu dochází někdy krátce po VBLANK (přesný počet řádků z hlavy nevím), k tomu druhému pak podle toho, jaký sprite byl právě zobrazován. Kdyby bylo DMA vypnuto "v blbém okamžiku", může se to projevit slavným vertikálním pruhem přes obrazovku. Je to důsledek toho, že zobrazování sprite dat Denisou stále pokračuje. DMA je záležitost Agnus - ta sice přestane Denisu krmit novými daty, ale ty staré v Denise (SPRxDATA, SPRxDATB) stále zůstávají a horizontální komparátor je při tom stále aktivní (deaktivuje jej zápis do SPRxCTL). Denisa tak na každém řádku zobrazuje stále stejná data. Ale o tom všem se dočteš v HRM: http://amigadev.elowar.com/read/ADCD.../node00AE.html

$8E a $90 jsou DIWSTRT a DIWSTOP (display window start / stop). Denisa je používá k tomu, aby věděla, kdy má generovat obraz z načtených dat bitplánů (BPLxDAT). Musí se to nastavit aspoň jednou. Opět platí, že je to vlastně zbytečné nastavovat v copper-listu každý snímek, ale pro zjednodušení se to tak obvykle dělá.

Nerozumím co myslíš tím "stabilní pro statický obrázek". Ty hodnoty, co tam máš, jsou zřejmě pro obraz o něco širší než klasických 320 pixelů.
Viz. http://amigadev.elowar.com/read/ADCD.../node0071.html
Obvykle se používají hodnoty $2C81 a $2CC1.
Samozřejmě je možno použít i HiRes. OCS podporuje i generování 70ns (hires) pixelů -- tedy "640" bodů horizontálně (nebo víc, nebo míň...). Stačí to zapnout, správně nastavit DDFSTRT, DDFSTOP, DIWSTRT, DIWSTOP, a samozřejmě i BPLxMOD.

Koukám na program co vloží obrázek pomocí bitplanů.

Je tam pár registrů které se zatím na nic netváří, netvrdím že jsou navíc, ale radši se ujišťuji.

Je třeba nastavovat $dff096? Je tam třeba mít aktivovaný 9.bit DMAEN? Na Paulu používám bit 0 až 3 a 15 samozřejmě. Ale to jsem jen odskočil od tématu a bavím se zde o obrázku. Jak by tenhle registr měl být nastaven pro použití zobrazení statického obrázku? Pokud jej vůbec musíme nastavovat?

V Cooperlistu se ještě na $dff096 zakazuje sprite.
DC.W $0096, $20

Tyhle 2 instrukce by měli v Cooperlistu nastavit velikost zobrazení okna.
DC.W $008E, $2C75
DC.W $0090, $2CC5

Ostatnímu v kódu rozumím a vím že ty věci tam mají být použity, u instrukcí zde napsaných mi zobrazení obrázku funguje i bez jejich použití, tak mne to zajímá, jestli by to tam opravdu mělo být použito.

Jaký maximální grafický režim je stabilní pro statický obrázek v LoRes aby to šlapalo na všech Amigách? Nebo lze použít i HiRes?

Díky