O: AmigaDOS

Tak od načtení fontu jsem se dál nehnul, hned jsem zkusil načíst paletu berev pomocí PALETTE, co mi z HDD funguje, ale z DF0 zatím ne, něco tomu chybí a já nevím, kde je přesně problém. PALETTE mám v DF0 v adresáři C. Mám danou cestu k souboru s příponou PRE: "palette FROM dh0refs/presets/demopcb3.pre USE". Viděl jsem i syntaxi bez FROM.

Hodí mi to hlášku:
Requires colorwheel.gadget V39

Tak jsem našel soubor v:
DH0:Classes/Gadgets/colorwheel.gadget

tak jsem ho s tou samou cestou dal i na DF0 ale nepomohlo a pořád mi to píše tu samou hlášku. Po delším zkoušení jsem si řekl že mi nebude fungovat ani načtení SCREENMODE:
screenmode FROM dh0refs/presets/demos.pre USE

a konečně se zadařilo, opravdu to nefunguje . S tímhle nastavením jsem se nehrál tak jako s PALETTE. Samotné nastavení SCREENMODE provádím ještě před nastavením PALETTE, ale nejdříve jsem chtěl rozběhat PALETTE, proto jsem to začal dříve řešit. Když chci načíst pomocí SCREENMODE soubor DEMOS.PRE, hodí mi to hlášku:

Error accesing file ENV:Sys/screenmode.prefs, object not found

Tohle vypadá být na nastavení v startup sekvenci, ale možná se pletu.

Jinak neexistuje nejaká utilita, která sleduje soubory, na které OS "hrabe", tedy které se OS snaží otevřít, aby jsem alespoň věděl, jestli mám problém hledat v absenci nejakého souboru/špatným souborem=starší nefunkční verze, nebo je v nastavení samotné startup sekvenci?

O: AmigaDOS

SnoopDos

O: AmigaDOS

SnoopDos me jiz nekolikrat zachranil pred infarktem myokardu. Velmi velmi uzitecny program.

O: AmigaDOS

Procesy PALETTE spušteného z Pythonu z HDD, kde načtení jiné palety pro WB funguje:
(zatím neradit, ja si kdyby něco řeknu)

O: AmigaDOS

Díky popisu startup-sequence na portály, knihy o AmigaDOSe (která by bez Probera asi neuzřela světlo světa ani v PDF podobě) a samozřejmě SnoopDOSu jsem to dal dohromady .

O: AmigaDOS

Tak jo, rozběhání načtení barev viz výše bylo u čistého příkazu PALETTE, pak jsem to dal do svého programu a nastal problém. Opět mi přestalo fungovat správné načtení fontu a i jeho zvětšení pomocí SCALE. Tak se znova začal kolotoč hledání chyby. Samotný program SnoopDOS byl taď krátký, odkazoval mne na neexistující knihovnu (asi spíše pouze na název procedury konkrétní knihovny nebo co já vím co). Při tom mém laborování jsem si asi časem zanesl do adresáře DF0 špatnou verzi SetFONTu (cca 5 kB) a ta byla načtena ještě před tou správnou, kterou jsem měl v DF0:C (cca 1 kB). Opět jsem se nechal napálit načtením špatné verze souboru, tak jsem měl o zábavu na pár hodin postaráno. Mi to připomíná začátky laborování se samotným PYTHONem.

O: AmigaDOS

Tak mám další problém, SCREENMODE a PALETTE mám z DF0 načtené, ale PALETTE si má brát ze SCREENMODE informaci o tom, na kolik barev je dán WB a když pracuji s DF0, přepínač v PALETTE je pořád v režimu 4 barev a to i v případě, že když spustím program SCREENMODE z DF0, tak je WB nastaven na 8 barev, co potřebuji. Přepínání přepínače v PALETTE na režim MULTICOLOR a pak daní volby USE nepomáhá, co je ale normální, takhle se to chová i když pracuji s HDD. Ale na HDD to funguje správně, tedy dle toho, jestli mám v SCREENMODE nastaveno 4, nebo 8 barev se automaticky přepínač v PALETTE nastaví na 4 barvy, nebo multicolor.

Zde je mé načtení SCREENMODE a PALETTE z DF0. Pár věcí jsem vyzkoušel, ale nepomohlo. Třeba i načtení všeho přímo ze STARTUP sekvence, protože SCREENMODE potřebuje při změně resetovat otevřené okná, tak jsem to načetl ještě před samotným otevřením okna/spuštěním Pythonu, jinak si vše nastavuji kromě toho nejnutnejšího přímo z PYTHONu. Přišel jsem na to co je chyba v neexistující knihovně "bsdsocket.library" o které jsem psal výše. To je známá chyba, jen jsem nevěděl, že se takhle projevuje, když jsem nepoužíval SNOOPDOS. Je to nepodporovaná práce se znakmi mimo ASCII tabulku. Lépe řečeno Python řve, že neni deklarované kódóvání znakové sady (co se dělá přímo v něm) a asi má s tím pak problém i WB. Když jsem použil čisté ASCII, chyba se neprojevila. Práce s diakritikou na Amize ale i tak funguje. Je to jen klasický proces PRINTu, ale i s chybou.

Nějaká rada, jak dostat WB na 8 barev i když se bootuje z DF0?

O: AmigaDOS

Tak jsem včera, dnes nebo kdy to bylo přišel na to, že se musí použit v STARTUP SEKVENCI volba IPREFS. To musím použít pro to, abych dal WB na 8 barev. Tahle volba ale potřebuje REFRESH všech oken, tedy se musí zavřít. Pokud ale pak nenastartuju WB, tak se s Amigou nedá nic dělat (všechny okna jsou zavřeny) a musí se restartovat. Tedy bootování Amigy se 4 barvami WB je OK, ale na 8 barev již potřebuji i start WB. Tedy současný stav je, že se nabootuje z diskety, načte se správná paleta barev, font a jeho velikost, přepne se WB do 8 barev a nastartuje se WB. Z WB se pak již samotná disketa spustí. To je nic moc řešení, ale lepší než drátem do oka. Po vyndání diskety a resetu Amigy je WB na původním nastavení. Samozřejmě tohle znásilňovaní WB pak vyřeší použití knihoven v C (pokud k tomu někdy dojde).

O: AmigaDOS

OK,

vypadá to tak, že správné načtení barev budu dělat pouze, pokud se restartuje WB. Mohl by jsem je načíst i bez restartu, ale změna by se projevila, až by se zavřeli všechny spuštěné programy (i ten Pythoní) a to se mi nelíbí. Program by se musel spustit na dvakrát, aby byly v programu barvy z WB OK. Pokud si někdo spustí program bez restartu Amigy, program mu pobeží v původních barvách které má na WB nastavené. Jak jsem psal, dočasné lamerské řešení. Ale kvůli tomu nepíšu, to já jen tak na začátek. Ale ještě další úvaha... .

V mým pozvání na RESETkání dělám 3 procesy současně pak je pauza v délce 0,04 vteřiny. To je celkem snad použitelná rychlost s kterou se již dá něco dělat. 5 procesů mám odzkoušeno, že to A4000 (v rámci A4000 nějaká slabší konfihurace) nedá. 4 procesy jsem ještě nezkoušel. Já ale můžu krokovat po 0,02 vteřině. Tedy počet možných procesů násobím číslem 2. Tedy A4000 dá 6 procesů a možná i 8 celkem použitelnou rychlostí. Je otázný, s jak velkými a složitými objekty v rámci těchhle procesů dokážu pracovat. A teď to nejdůležitější, proč píšu .

V mým pozvání na RESETkání se v jednom procesu a to v úplně horním, kde se zobrazuje RESETkání zobrazuje i vozík (kurzor) co je rušivé. Předpokládal jsem, že to neni o Pythonu, nebo hlavní problém neni v něm, ale že i WB má v horní části obrazovky (nebo norma PAL) horší zobrazovací schopnosti. Pomalost Pythonu pak přispěje k tomu, že je tuhle vlastnost i vidět. Ja rušivý vliv minimalizoval tím, že jsem text RESETKání zobrazil v 2. řádku (1. řádek byl ještě horší). Teď jsem si chtěl dokázat, že je mé tvrzení pravdivé a přes to vše co se teď povedlo mu pořád veřím, ale může to být samozřejmě i jinak. Rušivý vliv se mi povedlo odstranit! V původní verzi se zobrazuje text horního RESETkání jako 2. proces. Když jsem tenhle porces dal jako poslední, tedy jako třetí, rušivý vliv zmizel. Mám alespoň v emulaci Amigy čistý celý obraz! Zkusil jsem ještě horní text RESETkání dát jako 1. proces a opět rušivý vliv. Zatím to tedy vypadá tak, že horní část obrazu je třeba zobrazovat jako poslední, aby byl obraz čistý.

A aby toho nebylo málo perlička na závěr.
Již verze co jsem nahrál na YouTube používá snad můj první hack (?)
Pokud je kurzor WB barevně stejný s pozadím WB, kurzor WB jde automaticky do jiné barvy, aby byl vidět. Tuhle vlastnost se mi povedlo odstranit. Je otázné, jaký veliký výkon bych potřeboval na Amize, aby jsem takhle problikující kurzor "schoval". Tohle ale již řešit nemusím. Mám ve WB určené 1 místo, kde je tahle vlastnost (měnění barvy kurzoru) ve WB nefunkční. Před zalomením řádku (změna zobrazení celého obrazu) jedu kurzorem WB na tohle místo a tam řádek zalomím čím mi kurzor a pozadí WB zůstane i nadále v černé barvě.

O: AmigaDOS

hmm a co takhle si otevrit novy screen, s nezavislym nastavenim rozliseni a poctu barev, na screenu do ktereho jsi nabootoval?

O: AmigaDOS

Máš na mysli pomocí AmigaDOSu, nebo pomoci utility? U mne jedna utilita pohořela. Nedokázala vyčistit kompletně obrazovku ve WB co je u mne důležité. Čistě pomocí AmigaDOSu nevím o tom, že by to šlo, když načtení barev potřebuje IPREFS a to potřebuje mít všechny CLI zavřené, na to aby načetlo nové nastavení WB. Možná by pomohlo dát otevření CLI do WBStartup ve WB. Od toho jsem ale upustil, aby jsem nikomu nic do WB nekpíroval, ale to mne nenapadlo, že to je WB na disketě a né u někoho na HDD. Teď jsem si to pustil přímo z ROM 3.1, tu mi ale nenačte v emulaci s JIT, tak jsem JIT vypnul a další bordel v rámci obrazu v místě kde zalamuji řádek. Menší, než v horní části textu RESETKání, ale je tam. Hned mám v hlavě 2 řešení.

1. zalamovat řádek budu za horním textem RESETkání, čím nastane malá optimalizace, kde nebudu skákat na konkrétní místo, ale samotné zalomení v konkrétním místě je určené vypsaním posledního písmene v slově RESETkání, které se teď vypisuje jako poslední.

2. Teď to vtipnější řešení. Přeformátuji font Topaz-L2 na proporcionální, stejnou šířku písmen nastavím stejným parametrem u každého písmena v editaci fontu a nastavím ve fontu šířku fontu 1 pixel, čím šířku vozíka dám na 1 pixel, čím asi hodně zmenším samotný rušivý vliv vozíku na obrazovce, když bude tak malý . Jen upravým program, který i tak polohu každého písmene určuje zvlášť.

EDIT: Tedy ve 2. řešení ani nebudu muset určovat šířku každého písmene v editaci fontu, protože nikdy nenapíšu 2 písmena za sebou pomocí 1 polohy prvního písmena, ale každé písmeno je zobrazeno pomocí konkrétní souřadnice a tam tenhle parametr udán být nemusí.

O: AmigaDOS

OK,

1. řešení nepomohlo. Jak bude čas, dám alespoň vozík na 1 pixel.

JIT je otázkou pouze emulace, nebo to má například i A4000?

O: AmigaDOS

JIT je metoda emulace. V pripade UAE podstatne rychlejsi nez klasicka ("interpretivni") emulace CPU.

O: AmigaDOS

OK, já snižoval výkon na A4000 v emulaci pomocí CPU speedu. Výkonově stejného snížení dosáhnu i s vyplou JIT (měřeno v SYSINFU), ale zobrazovaní je s vyplou JIT pomalejší.

O: AmigaDOS

Ked bootujes, tak nemas otvorene ziadne okno, takze nevidim problem s pouzitim iprefs a zatvaranim okien.

Neviem, preco by WB alebo norma PAL mala mat v hornej casti obrazovky horsie zobrazovacie schopnostii, to je blbost !

Rychlost emulacie sa nerovna rychlosti realnej masiny...

Ako ti pise Exie, otvor si novy screen s vlastnym nastavenim,atd...