OldComp.cz

Čo takto? Ušetrí sa jeden bajt a robí to presne to isté ako pôvodne.

_________________
Oznamy o novom príspevku mi na mail chodia iba sporadicky, takže keď sa nehlásim v diskusii, tak je to tým. V 80% nepríde mail vôbec.

ld (PAMET),a ma 3 bajty, aj CALL ma 3 bajty. Ledazeby aj na inom mieste bolo ld (PAMET),a : ret a potom by sa na to dalo skakat pomocou JP co by usetrilo bajt. A ak by to bolo blizko a slo by JR tak hned dva bajty.

Inak co si ja vsimam cuzdie programy, obvykly zdroj neefektivity byva konstrukcia:

rut1:
...
call rut2
ret

Namiesto toho ide (obvykle) pouzit

rut1:
...
jr rut2 alebo jp rut2

a idealne je ak sa rut2 nachadza hned za rut1, to hned usetri rovno styri bajty:

rut1:
...
rut2:
...

_________________
Praxe znamená, že vše funguje, ale nevíme proč. Teorie znamená, že vše víme, ale nic nefunguje.
Někdy je teorie spojena s praxí. Znamená to, že nic nefunguje a nikdo neví proč ...

Pokud počítám dobře tak je to 1 byte delší, má to 20. Nebo se pletu? Můj měl 19. Potřeboval jsem 18.

edit: Jasně, chápu, poslední dvě instrukce nahrádím tím skokem JR někam . Pak ano, bude to mít 18

Tuhla na 18 bajtov:

Tak to je pecka! Jsem tušil, že něco brutálního vyplodíš. Jen ale přeci jen použiju to MilasPce řešení, protože se tam opravdu hodí lépe. To tvé je fakt bomba, ale obávám se, že za pár let až tam budu něco zase upravovat, tak bych si tady nad tím sakra lámal hlavu a ptal bych se co to vlastně má dělat
Ale fakt klobouk dolů

Jáj, som myslel že to LD (PAMET),A je jeden bajt, nedošlo mi že je to s adresou, teda tri bajty. Tak nič.

_________________
Oznamy o novom príspevku mi na mail chodia iba sporadicky, takže keď sa nehlásim v diskusii, tak je to tým. V 80% nepríde mail vôbec.

Ještě jednou díky všem. Jelikož vidím, že Vás to baví a rádi přemýšlíte, tak výzva č.2 :
Cílem je vizualně informovat uživatele a problémech s načítáním/ukládáním sektorů. Půjde o součást debug módu, takže není třeba to mít nějaké hogofogo. Místo už není, takže čím kratší, tím lepší. Bude se to volat z adresy #238E (na té adrese je nyní v MDOSu 2.0 call RWTRAN, já tam už mám vlastní RWTRANX, ale potřebuji ho doplnit o ten debug mód).
Na vstupu je tedy pouze reg. E, který obsahuje hodnotu 1-5, což je klíčová hodnota pro zobrazení uživateli. Dále lze vytáhnout i další důležité hodnoty z paměti:
číslo fyzické stopy LD A,(#3EF9)
číslo fyzického sektoru LD A,(#3EFA) sektor
číslo fyzické hlavy LD A,(#3EEB)
Pozor, že hlava může nabývat hodnot 0,1,2, přičemž 1 a 2 je jedno a to samé (jde o to, že diskety formátované pod MDOS1 tam mohou mít hodnotu 2 a MDOS2 hodnotu 1)!!

Na výstupu musí být všechno (registry) jako bylo na vstupu! A zásobník není žádoucí příliš zatížit, mohlo by to dělat paseku!

Uvažoval jsem, že k tomu využiju obrazovku, resp. nějaký kousek atributové části. Na začátku to vyčistím na hodnotu (8*7+7), tj bílý podklad i inkoust. Teoretický počet sektorů je 1705, což je hodně (atributová část má jen 768), tak jsem z požadavku slevil a zobrazoval bych stopu jako celek a na sektory se vyprdnul. Stop bude max. 94 (pořád musíme počítat s MDOS3 formátem...), tzn. že by mi stačilo do 200 bajtů atributů (94 pro jednu stranu diskety, 94 pro druhou stranu diskety - disketa má dvě hlavy/strany). Jeden byte s atributové části by tedy odpovídal jedné stopě a straně diskety. Logiku rozložení kde přesně to v obrazovce bude je celkem šumafuk. Plánoval jsem, že vyzvednu byte z obrazovky (ten který odpovídá dané stopě a hlavě), porovnám jeho barvu (tj. pouze bity 0,1,2 = inkoust) s registrem E. Pokud bude číslo v reg E menší, než je inkoust v obrazovce, tak do obrazovky vložím hodnotu z E (ovšem tak, aby i papír byl stejné barvy = bity 0,1,2 nakopíru i do bitů 3,4,5). Tímto by se mi na obrazovce hezky rozzářily všechny čtené/ukládáné stopy. Cílem debugu je zjistit kde má řadič problémy - problém by se hezky ukázal na obrazovce v podobě jiné než bledě modré (5) barvy. Na počátku je totiž v reg E hodnota 5 a s každým pokusem se snižuje (0 tam ale nebude, poslední číslo, se kterým by se pracovalo je 1). Čím menší číslo tím je to pro debug (uživatele) zajímavější (proto ten test, zda hodnota v obrazovce je menší/vetší než aktuálně reg. E). Cílem je vždy najít to minimum E pro každý sektor (resp. stopu, když sektory najednou do obrazovky bohužel nevejdou).

Jako je mi jasné, že obrazovka není zrovna vhodné místo kde to ukládat, protože to může být přepsáno klidně nahráváním obrázku z diskety. Ale je to opravdu debug mod, který standardně nebude zapnutý. A rozhodně se nebráním nějakému jinému řešení. Za mě nejkratší řešení ideálně tak na několik desítek bajtů vyhrává Mělo by to být user-friendly, není hezké to ukládat někam do paměti a potom nutit uživatele tam nahlížet devastací apod.

Nevím jak u Vás, ale u nás zase prší, takže tedy vykopávám
(na textové zadání se očividně nehrnete, tak kus kódu snad bude zajímavější...)

Ponecháno jak mne to napadlo, neoptimalizoval jsem. Vyzkoušeno a funguje. Každopádně zabírá to moc, používá to příliš mnoho registrů (a není splněna důležitá podmínka, že na výstupu musí být všechny registry jako na vstupu). Inicializace se zdá být delší jak hlavní kód Zatím tedy nic moc

Tak hlásím, že dnes ve 13 hodin a 13 minut se narodil MDOS 2.2
Věřím, že bude stabilní a hoden provozu

Pokec je v ZIPku. Interně je to test verze č.152 a takto se i po LIST* bude hlásit. Je to verze na hraní a testování, určitě není určena např. k zálohování vašich celoživotních programů ! Také není určená do kompaktů - chybí zapisování instrukce RST 0 na adresu #66 po každém resetu. Pokud by ji někdo chtěl, tak napište. Příp. si můžete patchnout i tuto verzi - stačí přidat na adresu 14189 instrukci ld (#66),a (nyní tam jsou tři NOPy)

Už jsem nevěřil, že tam nacpu všechno potřebné, protože jsem opravdu hodně bojoval s místem, ale povedlo se. O5 se potvrdilo pravidlo, že program bude tak dlouhý jak maximálně dlouhý může být. Zůstal tam nyní 1 bajt volného místa a to jsem byl opravdu asi 50 bajtů dlouho v mínusu. Ale povedlo se mi vždy najít něco, co uvolnilo místo. Ale je to vyčerpávající (a vyplývá z toho, že když se chce, tak se VŽDY podaří místo najít a potřebný kód tam nějak vecpat )

Takže zde pravděpodobně už oficiální release (pořadové číslo nese 156), který zanedlouho pověsím i na svůj web. Budu rád když vyzkoušíte. Problém pomalosti načítání u disket s deseti sektory na stopu vyřešen jiným uspořádáním sektorů už při formátovaní. Opravdu to způsobuje jen ta malá GAP3 (mezisektorová) mezera. Podle mého názoru řadič na MDOS1 čte o něco pomaleji než na MDOSu2 a tak mu ta mezera nevadí a stíhá.



Více info v txt v ZIPu. Zde malý výcuc ohledně toho rozložení sektorů:

Formátování a rozložení sektorů

Standardně má MDOS rozložené sektory na stopě tak, aby je dokázal načíst na jedinou
otáčku, konkrétně sudé stopy 1-2-3-4-5-6-7-8-9, liché stopy 5-6-7-8-9-1-2-3-4. Takto
to bylo v MDOSu 1 i 2 odjakživa. Řadič na MDOSu 2 má však s načítaním MDOS1 disket problém
a často dochází k ujíždění sektorů hlavě a ta je tak načítá s velkým zpožděním. Je do díky
GAP3 mezeře mezi sektory. MDOS1 ji při formátování má 40 bajtů, kdežto MDOS2 formátování má
80 bajtů (při deseti sektorech na stopu dokonce jen 35 bajtů). Jinými slovy diskety formátované
na MDOS1 (anebo i cokoliv s 10 sektory na stopu formátované na MDOS2) budou působit značně
přbržděným dojmem. Řešením je jedině diskety přeformátovat.

S formátem 9 sektorů na stopu na MDOS2 žádné problémy nejsou, protože GAP3 je dostatečně velká
na to, aby se vše stihlo. U deseti sektorů na stopu se GAP3 musí zmenšit na 35, a tak MDOS 2.2
ukládá při formátu stopy sektory takto 1-6-2-7-3-8-4-9-5-10. Tento fígl způsobí přečtení
všech sektorů na stopě na dvě otáčky (namísto deseti otáček, což způsobuje to citelné zpomalení)

Je možné aktivovat debug mód, upravit GAP3 mezeru a rovnež formáty s devíti sektory na stopě
si poskládat jako 1-6-2-7-3-8-4-9-5 (snadradně to MDOS 2.2 proloží opravdu jen u deseti
sektorů na stopu, u devíti ne!). Docílíte toho těmito příkazy:

Kód:

LIST @
POKE#96,128+64      ;musí být aktivní i bit6 na DEBUGu což LIST@ neudělá!
POKE#253,10      ;GPL
POKE#252,35      ;GAP3
FORMAT "a:80x09.B"

Co dělá ono POKE je vysvětleno výše. Klíčové je mít aktivní debug mód a to POKE#252,
které říká jak velká ta GAP3 mezera má být. Teoreticky je možné, že s takto naformátovanou
disketou bude MDOS2.x pracovat ve standardních BASIC operacích rychleji než s normálně
naformátovanou disketou s velkou mezerou a všemi sektory za sebou Dokonce bych se nebál
GAP3 snížit na nějakých 20 bajtů (POKE#252,20). Chce to ale vyzkoušet... Proto jsem ponechal
možnost debug mód s možností měnit GAP3 dle libosti.

Inak celkom nechapem preco autori MDOSu 1.0 medzi znacku a data sektora dali tak zbytocne velky gap az 37 bajtov, ked podla oficialneho datasheetu radic WD2797 tam ma mat 22 bajtov. Pri formatovani diskiet v BSDOSe tam davam tych predpisanych 22 bajtov a nikdy s tym nebol problem.

Intelacky radic pouzity pri MDOS 2.0 az tak dobre nepoznam, ale podla mna by tiez mal v pohode stihat tych 22 bajtov, aspon podobne radice na PeCiach s tym tiez absolutne nemaju problem (diskety naformatovane v BSDOSe dokazu PCdla na low-level sektorovej urovni citat uplne v pohode.

Toto říká komentovaný výpis MDOSu a datasheet:


U MDOSu 2.x ten úvod dle datasheetu značí GAP4(80xFF), SYNC(12x00), IAM(3xC1,1xFC). Jestli je něco takového i u řadiče MDOSu 1, nevím, když tak mne prosím doplňte. Také příkaz format track u MDOSu 2.x dovoluje poslat (tj. nastavit si dle libosti) mezeru GAP3, všechno ostatní má řadič nějak v sobě interně dané. Což je velký rozdíl oproti MDOSu 1. Možná to je ten důvod 36bajtové (ty jsi sice napsal 37, ale pokud počítám dobře, tak mi vychází 36) mezery mezi značkou a daty sektoru. Třeba už u MDOSu 1 věděli, že v nových řadičích to nelze měnit a chtěli ať to je stejně...

Je zajímavé, že téměř všechny hodnoty předepsaných bajtů se liší (MDOS1 vs. MDOS2), ale řadičům to očividně nevadí a navzájem to po sobě přečtou...

Ale ja pisem o gape medzi znackou sektora a datami sektora, a nie o gapoch na zaciatku stopy a medzi samotnymi sektormi.
To urcite nie, pretoze:
- MDOS vychadza zo SINDOSu a vtedy boli vsade v osembitovom svete radice WDxxxx
- Potom by aj uvodny gap po indexe dali rovnaky aky ho davaju (a zial aj nutne vyzaduju) intelacke radice
- A treti dovod si napisal sam:
Takze ja naozaj nevidim ziadny dovod preco mat tak velky gap medzi znackou sektora a datami.

Tak přeci jen to ještě není tak úplně bezchybné jak jsem si naivně myslel...
Pokud Vás to zajímá, můžete sledovat buglist na https://mts.speccy.cz/mdos21_bug.txt

Původně jsem zamýšlel, že narozdíl od MDOSu 2.1 tady u 2.2 udělám vždy dvě verze, jednu standardní a druhou pouze pro Didaktik Kompakt, který vyžaduje při každém resetu zapsat instrukci "rst 0" na adresu #0066, kde nemá ROMku, ale RAMku. Ale teď mi to přijde zbytečné, vždyť on by ten zápis do ROM neměl žádnému zařízení škodit... Nebo se pletu?