LDOS....

Ke dnešnímu postu jen dopíšu, ze jsem nahral do ADFka pouze ten 88 KB MOD a porad to potrebuje 1 MB CHIP RAM. Tyhle naroky (1 MB CHIP RAM místo 512 KB CHIP RAM + 512 KB dalsí ram) jsou tedy neni zpusobeny LDOSem... .

LDOS...

Tak dalsi uspech / neuspech... info.

Hral jsem se s pameti, snazil se nacist data pomoci LDOS postupne po 1 MODe z bezne pameti - treba slow do CHIP RAM. Uvedomil si, ze kdyz nepouzivam PC relativni adresaci na pointer v pameti, ktery ukazuje na zacatek MODu, musim si tohle misto v pameti asi pamatovat, tak jsem si ho ulozil do volneho registru, aby po nacteni dat do CHIP jsem se mohl vratit na misto v pameti, kde mi tenhle MOD zacina a zacit ho z CHIP RAM hrat. To se mi nakonec povedlo, ale ne zcela spravne. MOD se mi nepovedlo pomoci LDOSu spravne indexovat. Ve vysledku jsem musel mit v pameti pred hranym MODem jeste nejake dalsi data, klidne jiny MOD. A problem nebyl jen v indexaci, to jsme si potvrdil. Privedlo mne to k myslence, ze by jsem s tim co jsem zjistil jak LDOS funguje, z toho co jsem zatim vedel zkusil samotny MOD zabalit do souboru LDOS - BIN. Ale nepovedlo se mi MOD spustit. Jak jsem si to vse co jsem vedel daval do hromady a s faktem, ktery jsem si uvedomil, ze je vlastne spravne, kdyz pri kompilaci LDOSu se mi data nezobrazuji v pameti CHIP, co je vlastne chtena vec, protoze je chci az pak do ni nacist, tedy jeden MOD, ktery chci hrat, jsem se vratil na "zacatek" a uvedomil si, ze LDOS mi konkretni MOD do CHIP RAM vlastne nakpiruje sam, aniz bych to musel delat v kodu ja, A ze to, co bude v pameti CHIP by mohla urcovat jen indexace pomoci direktivy
LDOS_LOAD_BINARY_BLOB
Pred touto direktivou se uvadi v registru D0 index souboru, ktery si LDOS načte ze souboru "script.txt" a tim ze mam program v CHIP RAM, tedy do pameti CHIP. Takhle mi to zda se funguje spravne. Nepovedlo se mi jen program rozbehat na nejnizsi konfiguraci co LDOS podporuje a to je 512 KB CHIP RAM + 512 KB dalsi pameti. Povedlo se mi to rozbehat na 1 MB CHIP RAM. Spusteni MODu na 512 KB CHIP RAM se mi nepovedlo, ani kdyz jsem nacetl jiny mensi 88 KB MOD. Doposud jsem spoustel nejmene 150 KB MOD. Na druhou stranu, pokud jsem dal na disketu data, ktere maji celkem kolem 1,3 MB. LDOS je pakuje a ve vysledku se na 1 disketu vejdou. Pokud jsem spoustel MOD, spustil se mi porad na konfiguraci 1 MB CHIP RAM bez jakekoliv dalsi pridavne RAM.

Mozna si budu muset lepe odridit praci s pameti v mem hlavnim programu, ale jiz narocnost 1 MB CHIP RAM pro mne zacia byt zajimava, Tedy ve vysledku LDOS v ramci toho, s cim jsem doposud mel moznost pracovat - ruzne packere je pro mne nejvetsim prinosem, pokud se nechci zalamovat s tim, ze si takovou vec musim naprogramovat, co prozatim fakt nechci a jsme rad ze nemusim

Soundy mi psal, že Leonard pracuje na verzi LDOSu, u které se již ty pasáže nebudou muset načítat pouze za sebou. Já potřebuji skladby načítat různě, ne pouze jak jsou za sebou a v kombinací snížení paměťové náročnosti a tedy aby jsem měl vždy načteny v paměti Chip pouze jeden MOD mne nenapadá jiná alternativa, než to načítat přímo z kódu. Ono způsob, o kterém Soundy píše, že bych s každý MOD měl k sobě pribalenou i hudebni rutinu - chci použít svou, to mne napadlo ještě před tím, nez mi to psal. To je ta první možnost od něj.

V README.md se píše
a taky o něco dále
Jednotlivé části (říká jim FX) by tedy měly být vytvořeny jako standardní Amiga EXE soubory. LDOS utilitka si to už přelouská a dá na disketu. Ale na disketu se mohou dát i obecná data (říká jim BLOB). Asi je třeba je dát až za EXE části, když se bohužel všechny načítají postupně za sebou (při RTS z tvého kódu zpátky do LDOSu).

Jsou na to postupy jak jsem psal viz soubor v odkazu (LDOS_User_Manual.pdf​):




Soundy, autor návodu mne pak ještě nasměroval:


Myslim, ze LDOSu je treba umet rici co a kdy se ma nacitat, nebo kdyz tak z meho pohledu je lepsi, kdyz se mu to muze rici a LDOS tohle umi.


Veskere prikazy, se kterymi se LDOS ridi primo v kodu jsou zde a sam Leonard, autor LDOSu je ve svych prikladech, ktere jsou soucasti LDOSu pouziva:

​Nevim jestli LDOS umi nejak sam rozdelovat. kdy ma co nacist, tedy jestli LDOS umi byt vice radoby samostatnejsi. Ono to neni slozite, jen ze zacatku pro slabsiho programatora a ne pro hardcore asm killera je obtiznejsi tomu hned porozumet. Z meho pohledu je k tomu nedostatecna dokumentace, ale jiz se do toho dostavam snad

Ja to vnimam jako vyhodu mit moznost si rici, kdy se ma co nacist do pameti. Jestli LDOS umi pracovat i s celym exe, tak co jsem ted v rychlosti koukal do toho navodu tak jsem neco takoveho nevycetl. Dle vseho je LDOS jednoduse pro programatory a tam se pocita, ze jsou k dispocici asi spise kody.

Myslel jsem, že LDOS jen vezme konfigurační soubor, který obsahuje cesty k binárním souborům, a vygeneruje obsah diskety (ADF). Soubory můžou být buď jakékoliv obecné binárky a nebo amigácké EXE soubory. LDOS umí obojí podle potřeby načíst při běhu (po nabootování z diskety) do paměti. Pokud jsou EXE soubory v pořádku, obsahují podporované HUNK sekce (viz. dokumentace k AmigaDOS), tak by je měl umět správně načíst -- tedy rozpoznat co je HUNK s kódem, co je HUNK s relokační tabulkou a co jsou HUNKy s daty nebo BSS (tedy jen s informací o alokaci paměti). Myslel jsem si, že by to mělo být celkem snadné k používání. Pokud chce uživatel načíst nějaká vlastní data (a tedy je nedávat do EXE), tak to LDOS myslím taky umožňuje. LDOS automacky všechna data na disketu zabalí ARJ7 kompresním algoritmem a dekomprese je "zadarmo", protože běží ve stejný čas, kdy se další data načítají z pomalé diskety.

Ve tvém případě by mělo stačit udělat si jeden exáč, ve kterém do datové sekce (section data_c) dáš svůj modul a do kódové sekce (section code) dáš jeho přehrávání. Prostě normální exáč. Akorát tam už nemusíš psát odstavování systému, protože to za tebe už předem udělá LDOS. Tento exáč dáš do konfiguračního souboru a vytvoříš LDOS utilitou disketu (ADF). Disketa bude mít LDOS boot-block, který asi načítá nějaký dodatečný LDOS kód (pokud se to autorovi celé nevlezlo do boot-blocku) a ten pak načte tvůj "exáč" a spustí. Mělo by to fungovat. Aspoň jsem si to myslel.
Ta "genialita" LDOSu podle mne spočívá právě v tom, že uživatel dělá normální Amiga exáče (v jakémkoliv assembleru, nebo klidně i v jiném programovacím jazyce) a ze svého kódu pak jen LDOSu říká, jaký exáč má načíst a spustit (když se produkce skládá z více částí).

LDOS - pouze info

Šlo mi o to, jestli se zpakovava MOD, pokud z nej nedelam LDOSacky BIN a zpakovava, Takhle nejak vypada kompilace, kde davam jeden MOD primo do CHIP RAM. Skladbu mi to da z nejakych 170 KB na 100 KB.

Windows-ácká kompilace LDOSu na ADF:

LDOS - pouze info

Tak poslední 3 dny jsem si nasel cas na LDOS a pred chvili jsem zaznamenal uspech. Jeden francouz, co sepsal strucny navod na LDOS mne nasmeroval spravnym smerem. V navode se neresi co jsem potreboval a i kdyz mi napsal vseobecny postup, tak jsem si na par veci prisel sam. Ono je to o tom, ze LDOS si dela svou vlastni kompilaci a clovek presne nevi co se tam deje a jak to pracuje a ze zdrojovych kodu jsem pro mne potrebne veci nevycetl, nebo je tam nenasel. Co byla moje prvni chyba bylo to, ze jsem si udelal potrebne struktury a pak se snazil MOD nacist jiz klasicky pomoci assembleru s tim ze pri kompilaci LDOSem se potrebne veci jiz udelaji. Chyba. Je treba pouzit dal specificky pristup LDOSu. Na to mne nasmeroval ten francouz co sepsal navod. I tak jsem mel problem zahrat MOD. Tak jsem samotny MOD nezpracoval LDOSem na soubor BIN, ale dal jsem ho do struktury primo (čistý MOD) s tim, ze jsem ho nacetl pomoci LDOSu. MOD se mi spustil. Zatim ho pro jednoduchost mam primo v CHIP RAM. Samotny nazev MODu uvadim tedy i v souborech LDOSu, ktere mi pouzite subory slinkuji. V zaveru jsem zkusil samotne nacteni MODu ani neuvest v kodu. I tohle funguje. Samotny LDOS ho pri slinkovani priradi do ADFka. Je tam nevyhoda, ze si nemuzete urcit, do jake pameti se MOD nakopiruje. Myslim, ze by to melo byt do te, se kterou se pracuje v kodu, kde se s LDOSem nacita samotny soubor.

Jak jsem koukal na kod LDOSu, tak jsem zatim nic lepsiho nevidel. Strasne "tvrdy kod". Skoda ze prace s LDOSem neni lepe popsana.

Mel bych jit spat....

Ještě dnes druhý příspěvek, pouze info.

Ještě předtím, než jsem zacal resit vyse popsany problem jsem resil 1 chybove hlaseni LDOSu. Bylo to neco jako, ze nemuze najit soubor s indexem 0001. Leonard popisuje pouze problem, pokud je pamět preplněna, jak se to pokusit resit. Ten problem mam taky, ale to jsem docasne vyresil tim, ze nacitavam zatim pouze 2 MODy. Ve vysledku se ten problem s indexem souboru 0001 vyresil tim, ze jsem odstavil / vymazal cely kod od Photona, co mi odstavuje system. Domnívám ze, ze LDOS ma takovyhle kod svuj. Asi mu nesedelo 2 krat po sobe odstavovat system, popripade neco z Photonova kodu, co odstavuje system. To je jen ma domnenka. Po odstaveni Photonova kodu se chybova hlaska prestala zobrazoat a ja i dle chovani predpokladal, ze se mi jiz spustil muj kod i kdyz v te dobe bez hudby a ja pokacoval v bádání dál

Kodér Leonard a pak popis 1 problému, co mám s LDOSem

Drobátko teď OT, ale standardně mně to pobavilo a myslím, že jsem nalezl jednu z možných příčin, proč mi tvůrce LDOSu zatím neodepsal

Info z Twitteru:



@leonard_coder

·

U LDOSu řeším ještě 1 věc. Nedaří se mi z hudby MOD udělat jeho BIN soubor, neboli ho udělám, ale kód ho nenačte a hudba tedy nehraje. Pokud do ADF zpracované LDOSem vložím klasický MOD, tak mi hudba hraje. Tedy pomocí LDOSu mám vše ok kromě toho MODu a já ten BIN potřebuji, aby se ty MODy načítali postupně a ne naraz, čím bych měl snžit pamětovou náročnost. Vytvoreny BIN soubor meho programu je ok. U MODu postupuji stejně. Já vlastně ten MOD jen zabalím do BIN. Ta spojitost v kodu je pak nasledovná:

načtu BIN do A1 (návěstí Mod0) a dole v kódu mám INCBIN:

ve druhém souboru mám (první řádek je direktiva LDOSU, ve druhém jen načítám samotný MOD):
Druhý soubor dle postupu zabalím do BIN souboru a soubor BIN se mi pak vytvoří. Soubor BIN pak načítám místo MODU, aby mi s ním LDOS uměl pracovat. Pak vytvorim BIN i z meho kodu soucasne s ADF souborem. Hudba mi vsak nezacne hrat.

Pokud pouziju v kodu
​
ModScr0 incbin "Mediev.MOD"
místo:
ModScr0 incbin "ModMediev.bin"

a použiju LDOS, který mi vytbori BIN soubor z meho kodu a soubezne se mi vytvori ADF, ktereho je BIN z meho kodu soucasti, hudba z takhle vytvoreneho ADF mi hraje a vse je ok.

Tak za chvíli se vraci koder LDOSu Leonard z Japonka, třeba prohodíme pár vět, pokud se to nevyřeší...

LDOS - pouze mé postřehy

Postupne se prokousavam tim LDOSem. Vypada to zatim dobre, jen si to je treba osahat. Jo, vyslednim ADF nebude klasicky amiga format, tedy to z diskety pujde spustit, ale jinak se nebude dat nacist tak, aby jsme viděli na ni klasicke soubory. LDOS by mel mit minimalni naroky 512 KB CHIP RAM + 512 nejake dalsi RAM. Ja se zatim zameruji na disketu, ale mel by mit i zavadec na HDD. LDOS obsahuje i hudebni prehravac. Je reprezentovany jako nejrychlejsi hudebni prehravac na Amize co by mohlo byt, ale neco za neco. Neprehrava klasicke MODy. Hudebni MOD si LDOS prevede do nejakeho sveho specifickeho formatu, Pri spravnem nastaveni by se tohle melo udelat automaticky, ten prevod pri vytvareni ADF / HDD verze. Ja tohle obejdu a dnes se mi povedlo udelat format LDOSu BIN. Jsou v nem binarni data, se kterym vas zdrojovy kod v assembleru pracuje. Ja si jako tyhle data urcil samotny MOD. Kazda skladba bude jeden BIN, tim docilim toho ze se budou MODy nacitavat do pameti postupne, Jako BIN muzete mit i jina data se kterymi potrebuje pracovat. Na to aby jste BIN mohli vytvorit potrebujete mit v adresari krome zdrojoveho kodu a MODu taky soubory LDOSu "M" a "VC". V souboru M si pomoci editace urcite cestu a nazev zdrojoveho kodu v ASM a nazev samotneho BIN, ktery se vam jeste jen vytvori. Ja mam ve zdrojovem kodu pouze INCBIN na konkretni MOD. Kazdy zdrojovy kod musi jeste nelepe někde na zacatku obsahovat i direktivu INCLUDE "kernel.inc". To je soubor LDOSu. Pokud je vse OK a spustite soubor M, LDOS vam vytvori soubor BIN. Ten si pak jiz nactete ve zdrojovem kodu. Tedy priprava ADFka by se dle vseho mela delat na dvakrat. Pripravite si BINy, ktere uvedete ve zdrojovem kodu a pak samotne vytvoreni ADFka. Dle vseho az tim krokem, jak se bude vytvaret ADF / HDD by se mela ucinit i samotna komprimace, kterou LDOS podporuje a tedy na disketu date vice dat. LDOS je dle vseho dost komplexni system, jde tam hodne veci nastavovat. Lze napriklad nastavit, aby se po nacitani dat a spusteni programu zacali nacitat hned dalsi data ktere jsou potreba. Tohle se muze a nemusi vyuzit dle potreby. Programator Leonard je jeden z dalsich expertu v ramci programovani. Jednoduse Oxygene . Ja v jednu dobu dost šlapal na hudebnim disku Amigatari, ktereho je koder Leonard a pouziva LDOS. System LDOS obsahuje i navod, ja pouzivam navod v kombinaci s ukazkovym kodem / soubory pro ADF. Samotny navod by mi nestacil, ale v kombinaci to zatim celkem jde. Tak zatim jen takove me postrehy a snad se zadaří

Zrejme si autor aktualizácie povedal že ak nie je podporovaný iný rozsah ako .W, tak to bude hlásiť ako chybu (v syntaxe alebo podobne).
A možno ťa len nemá rád a chce ťa nasrať. Zaspomínaj či si ho niekedy nenasral ty.

Kto vie.

Mňa teraz zase trápi chovanie ASM-Pro (1.18 aj 1.20) s RTG. Možno to ani nemá čo robiť s RTG ale keď používam KS vyšší ako 3.1.4 tak po kompilácii a spustení programu nasleduje GURU. A pomôže len reset.

Testujem to už asi tretí deň. Najprv som mal podozrenie na PiStorm ale robí to aj vo WinUAE. Až dnes ma napadlo zmeniť KS, používal som KS 3.2.
Zajtra to musím skúsiť na A1200 s PiStorm. Keby tu bol ešte niekto ochotný vyskúšať toto chovanie s posledným KS 3.2.1 by bolo super.

OK, s tym DBF jsem to myslel tak, ze jiz nelze napsat ve verzi 1.20 DBF.W, protoze ti to napise chybu a to ve verzi 1.18 fungovalo a slo napsat DBF.W. Je hezky, ze lze instrukce psat i bez W, ale rozhodne by pri pouziti spravneho rozsahu nemel kompiler hazet chybu co 1.20 dela a 1.18 nedela. Tohle je pro mne zatim chyba, ktera ve verzi 1.20 pribyla. Ja vim, ze kde nemusis rozsahy nepouzivas, pamatuji si to z nasich starsich komunikaci, ze to takhle máš.

Já si rikal, ze ti budu vysvetlovat neco, co te asi ani nebude srát, protoze to nepouzivas...

Verziu 1.20 zatiaľ len skúšam.

Pokiaľ ide o DBF (DBRA) tak mne sa zdá že u nej je dĺžka skoku len W size. Potom chyba je skôr vo verzii 1.18.
Možno u vyšších cpu aj L ale nie som si istý. Ja to nechávam na assembler nech si to skompiluje ako sa mu páči

Skús si napísať krátky program, spusti debug (AD) a krokuj.
V spodnom riadku budeš vidieť inštrukciu aj v HEX. Niečo takéto:

$51C8xxxx

Kde XXXX je dĺžka skoku v bytes. Takže W size. Pri .B bude XX a pri .L bude XXXXXXXX. Ale pochybujem

Potom môžeš skúsiť meniť B,W,L a tam uvidíš či je zmena pri trasovaní vo 1.18 verzii.


To s Include poznám, ja dávam reštart asmpro príkazom !R.


Rozdiel medzi systemovým Load a Save je len veľmi malí. Neskôr ti sem hodím lepší príklad.

ObiWanKen všiml jsem si ze pouzivas ASM-PRO 1.20, ktera vysla v prosinci. Tak jsem ji dnes taky nahodil. Mam u tehle nove verze vuci stavajici 1.18 jedno horsi chovani. U instrukce DBF pokud se u ni pouzije jakykoliv rozsah, tedy se za tecku da W, co jsem u par mel, rozsah B je pro tuhle instrukci nedostacujici, pokud si to dobre pamatuji. Nicmene verze 1.20 haze chybu "illegal address size", co je z meho pohledu chybne chovani. Rozhodne se rozsah W / L musi pouzivat. Tahle chyba neni hlasena jen v pripade, kdyz se instrukce DBF napise bez rozsahu, co lze taky samozrejme, ale i tak by rozsah, pokud je spravny mel jit napsat, co ted u DBF nejde a to vnimam jako chybu.

Problem s INCLUDE, kdy musim zdrojak, ktery INCLUDE nacitavam pokud jej zmenim, tak ASM-PRO ukoncit a opet nastartovat, aby se mi zmena v kodu projevila u kompilace pomoci "a" zustal zachovany i u verze 1.20

Zatim jsem tvuj kod co zde vyse uvadis uplne nestudoval, ale tak nejak se mi jevi, ze v nem data spise zapisujes, nez nacitavas. Ja ted resim postupne nacitavani dat.

Defor ohledem Track-loaderu se rozkoukavam, ta myslenka s tim pridanim dát do ADF je super, skoda, ze takova data pak musi byt nezpakovane, neboli v mem pripade zatim ano. Asi by mne stacilo nakopnout jak je to s pouzitim toho kodu od Photona, ktery jsem uvedl vyse, ale celkove se rozkoukavam...