V pondělí a v úterý jsem se vrhl na předělání logiky v mém programu tak, aby práce grafiky nastoupila až po nějaké chvíli po tom co hraje skladba. Přemýšlel jsem jak to udělám a napadlo mně na to použít část kódu, která umí na začátku každé skladby udělat některé věci za můj hudební formát (ten to umí taky) ale je to tam pro případ, když by se třeba potřeboval nahrát sampl do kanálu a už by se třeba nemusel změnit. Tedy aby mi tahle situace zbytečně nezabírala "slot" pro 1 nástroj v rámci mého formátu v hlavní smyčce programu. Tohle se vykonává před touhle smyčkou. Tedy jsem před tuhle hlavní smyčku hodil vše podstatné pro práci s grafikou, co jí aktivuje, tedy načtení bitplanů a tak. Příhodný moment asi ve 4 řádku patternu hlavní smyčku v programu opouštím, načtu bitplany a jiné a vracím se zpět na hlavní smyčku. Zároveň vyblokuji v hlavní programové smyčce ostatní práci s grafikou pomocí mého formátu pro práci s textem na přibližně stejný čas, tedy na asi 4 řádky patternu. To vše můj program vlastně uměl, jen jsem musel trochu upravit u toho všeho logiku a vše si taky uvědomit jak by co mělo být. Například jsem psal, že čas potřebný pro spuštění podprogramu z grafické knihovny (offset -222) je rovný přibližně 20 řádkům patternu, to není pravda. Neuvědomil jsem si, že za čas 1 hlavní smyčky programu zpracuji přibližně 5 písmen v textu a ne pouze 1 písmeno. Tedy na 1 řádek patternu je asi 5 písmen a ne 1 písmeno. Vše to pak pěkně fungovalo. Chvíli ze startu hrála pouze skladba s prostředím Workbenchu a pak se přešlo na grafiku, neboli zobrazování textu. Aby tam tu chvíli nebyl Workbench to bych pak upravil ale... .

Mé předpoklady že podprogram s offsetem -222 potřebuje více času a že s textem musím začít pracovat později čím bych vyřešil to, že se mi text přestane někdy zobrazovat pouze asi do 12 písmena ze 40. Stalo se to, že při téhle úpravě programu se mi text ne jenom někdy zobrazoval do asi 12 znaků, ale vždy se zobrazoval do 12 znaků. Ani jedno spuštění programu tedy nebylo správné.

Jak byl u spuštění programu nachvíli ještě podržený Workbench, hezky jsem viděl otevření okna posunutého vlevo mimo celou obrazovku, tedy jsem viděl pouze jeho přibližně pravou půlku. A pak se mi začal text psát správně zleva od začátku ale jen do rozsahu posunutého okna Workenche doleva, tedy do jeho pravé půlky.

tadáaa standardní situace u mně. Martině máš to obráceně

Dobře, tak někdy se podprogram s offsetem -222 ukončí tak rychle že se práce s textem nestihne správně "chytnout".

Část programu co jsem načítal pro práci s textem dodatečně jsem dal do MiniWrapperu od Photona před podprogram s offsetem -222. Nepomohlo. Přichází na řadu časovač CIA nastavený na maximální hodnotu hexadecimálně FFFF. Dal jsem jej do programu mezi. Tedy před ním byla práce s grafikou, za ním -222ka. Samozřejmě vše s návratem na mou původní verzí programu před všemi změnami v logice. Teď jsem viděl jak opožděně začne podprogram s offsetem -222 pracovat. Tenhle podprogram grafické knihovny mi umožňuje celý program spustit i z rozlišení Multiscan Productivity, tedy z rozlišení 640 na 480. Jinak se vám program spustí tak, že to není použitelné. Absolutní bordel v obraze i ve zvuku. No a jak se -222ka po časovači CIA na hodnotě FFFF hexadecimálně spustí opožděně, tak nejdříve je bordel v obraze, je to chvilka a pak se obraz spraví (díky -222ce). Co jsem zatím zkoušel spustit celý program, zobrazování textu v pořádku na celou šířku obrazovky. Další krok. Vrácení práce s grafikou/textem nazpět mimo MiniWrapper od Photona. Před -222kou jsem nechal pouze časovač CIA nastavený na maximální zpoždění. Zobrazování je v pořádku.

Zatím jsem nezaznamenal nesprávné (useknuté) zobrazování textu do asi 12.znaku.

Jen napíšu, že časovač bylo to první, co jsem nasadil do Photonovho MiniWrapperu, který kompletně odstavuje systém, ale možná jsem u toho ještě Amigu 1200 i nevypinal. Její pouhý reset nepostačoval na to aby se vše u Amigy vrátilo do normálu a u Amigy se může vyskytovat pořád již stará chyba, tedy chybné chování a program můžete mít dobře.

Ještě pošteluji nějaké věci ale CIA časovač před -222kou nechávám na maxime.

U jakékoliv změny programu po běžném testování nastalo běžné testování po několikaminutovém vypnutí Amigy 1200. Pár desítek vypnutí to bylo.

Když se mi ta chyba ještě někdy projeví, nebo se prokáže, že vše je věc náhody a chyba nebude tímhle vyřešena, možná mně jebne

A tohle je definice vesmírného pirátství

A abych zde neměl jen blbý kecy tak pár postřehů, ale budu to tak nějak tahat z hlavy, nejsem nastaven na to čumět jakkoliv do kódu.

Myslím že jsem konečně narazil na příčinu, proč se mi můj program pomocí kódu od Photona co odstaví systém chová někdy při spuštění nestandardně.

Popis chování, které se projeví ze začátku někdy při spuštění a při třeba tak 5 spuštěním po sobě již méně často​​​​​ co je tak jednou za 20 až 50 spuštění.

Zobrazování textu jen u prvních 12 písmen že 40.
Nezobrazení textu, hraje pouze skladba a funguje Copper.
Nereagovani ukončení programu pomocí klávesy space, pomocí tlačítka na myši program ukončit lze.

Co mně zmátlo je skutečnost že se program při hledání chyby chová jinak pod prostředím a jinak když je zkompilovaný. Tedy to že přijdete na vodítko které by vás nasměrovalo na to čeho se chytit a které vám funguje pod vývojovým prostředím většinou nefungovalo u kompilovaného programu.

Problém by dle všeho měl být u podprogramu s offsetem -222 z grafické knihovny. Je to zjištění ze dnes, ještě budu testovat ale kód byl zatím u EXE stabilní, když jsem tenhle offset/podprogram u kódu od Photona nepoužil. Ják bude čas budu hrát na to, že tento podprogram se vykonává dlouze a můj program díky němu začne pracovat bez chyby tak na jeho 20 cyklu. Tenhle podprogram zabezpečuje spuštění mého programu i z grafického módu Multiscan Productivity, tedy se to pokusím dát nějak dohromady 🙂

Hm, tak ono to vypadá jako by restart A1200 nestačil po tom co spustíš program s ne zrovna ideálním nastavením DMA přenosů. Pomohlo až vypnutí a zapnutí A1200 aby se program začal chovat korektně, když jsou i DMA přenosy nastaveny správně.

Opět díky moc za nasměrování. To nastavení bitů pro práci s bitplany a copperem nebylo ani součástí původního kódu pro práci s textem, který jsem převzal a upravil. Je pravdou že Copper jsem přidal já i když s ním dělám pouze jednoduchou čáru. Nějak jsem si to vše nedal dohromady. To jsem celý já.

Správně fungování původního podprogramu WaitEOF bylo podmíněno správným nastavením DMA přenosu v DMACON ($dff096), tedy tohle již taky funguje.

Tak tohle jsou ty přerušení, já to jen používám. Tedy doposud hlavně u Pauly, teď již i u Bitplanu a Copperu.

Vím že jsem se již jednou ptal na 9.bit DMAEN u DMACON co je hlavní povolení DMA. Má zkušenost je taková. Že pokud jsem pracoval čistě jen s Paulou bez obrazu, nepotřeboval jsem ho nastavovat, ale jakmile již k tomu přidám i práci Bitplanu, nebo Copperu, již potřebuji mít tenhle 9.bit nastaven, jinak mi ani Paula nic nehraje. Tenhle 9.bit (DMAEN) hlavní povolení DMA vnímám jako nějakou komunikaci mezi právě probíhajícími DMA přenosy.

Právě zjišťuji že teď mám problém ještě s podprogramem AllOff který se provádí až za mým programem, tedy při návratu do systému. Za to ale již snad já nemůžu? Ono tedy někdy se to spustí dobře a někdy mi to zobrazuje jen asi prvních 10 znaků ze 40 a většinou se to spustí správně bez téhle chyby. Jednou se mi to spustilo i s odstupem textu od kraje obrazovky. Taky se mi to i jednou z EXE nespustilo, ale pak jsem udělal další kompilaci. Zdá se mi nevynulování registrů DMACON a INTENA za mým programem jako stabilnější ale ještě to budu testovat. Nulování těchto 2 registrů před mým programem již provádím.

​​​​​
​​​​

Nerad to píšu, ale tvé AllOff0 nedělá nic, co je účelem původního AllOff -- tedy zakázání DMA a přerušení. #$7fff nuluje vše ve dvou registrech k tomu určených: DMACON a INTENA. Zápis této hodnoty do INTREQ je jen zajištění, aby se nevyvolalo žádné přerušení, o které už bylo systémem (Paulou) požádáno (INTerrupt REQuest). Nevím, jestli je to úplně nutné, ale věřil bych Photonovi, který tohle určitě převzal z jiných starších rutin, a nechal bych to tam. Každopádně tvé AllOff0 DMACON ani INTENA nemažou a tudíž ti na pozadí stále běží ošetření všech dříve povolených přerušení (a stále ti běží všechny DMA kanály).
Pokud ti tvůj program normálně po AllOff nejede, je to nejspíš tím, že pak přerušení, která používáš, nezapneš. Nezapomeň nastavit i bity INTEN a DMAEN, protože ty byly taky smazány!
Tvoje rutina WaitEOF0 taky nic nedělá. Teda dělá jen to, že počká až přestane pracovat blitter (WaitBlitter). Úkolem té rutiny je vrátit se v okamžiku, kdy je obrazový paprsek za vykreslováním posledního řádku obrazu (tedy začne docházet k vertical-blank). Proč Photon pro jistotu čeká i na blitter netuším -- asi další příklad velké opatrnosti. Tvoje rutina ale na paprsek nečeká - netestuje jeho pozici. (Mimochodem ta rutina nefunguje, pokud by tvůj program běžel na NTSC systému. Tam je nejvyšší vertikální pozice el. paprsku jen $106.)

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.
​​​