OldComp.cz

No ten úvodní screen je právě těch 600 bytes plánovaných pro tu devastaci. Takže jeho odstranění je tak jako tak nevyhnutelné.


To demo s písmem v borderi se mi líbilo víc a neskutečně mě to pobavilo. Ano, budeme psát demo na chybu v romce, která by se vlastně nikdy nikomu na funkční mašině neměla objevit...

Pokud nemáte kdo do čeho (koho) píchnout, tak jen nekecejte a něco vytvořte. Schválně kdo to bude mít hezčí a na méně bajtů !! Každopádně hodnotu kontrolního součtu dám samozřejmě i pod LIST*

Také můžeme udělat anketu jakou barvu má mít PAPER a BORDER při resetu (když tedy zmizí ten úvodní divide screen). Červený předem vylučuju, protože ho má org. MDOS1 i 2. PVL mdos měl tuším fialový. Co dát nějaký multicolor efekt?

Pro inspiraci

Nie až taká hlúpa, viď ďalej.
Kašli na demo, daj tam nejakú hru (pingpong, tetris, batty).
som zvedavý, či potom nebudú všetci používať poškodenú romku aby sa im zobrazovalo to demo.

Ale vážne, ten error môžeš vlastne vypísať aj s použitím atribútov (ako má TFCOPY spravené počítadlo, alebo MRPACK2 keď nie je pripojená D80ka), prípadne ho skrolovať v strednej tretine a pridať aj nejaké výstražné efekty.

_________________
Didaktik Gama | ZX Spectrum 128 | ZX Diskface Quick A | BetaDisk 128C Interface | D40 & D80 | divIDE | Interface M/P | Multiface 128 (GOTDJ) | Gama Breaker | D80mini

"Kvalita a stabilita Windows XP se Microsoftu nevyplatila, stal se takovou temnou připomínkou toho, co se stane, když odvedete svou práci moc dobře."

Abychom to nezamluvili... Dá-li někdo rozumný nápad pro PEEK# (rozuměj funkční kód), který příliš nenabourá kompatibilitu s mdos1/2, tak to určitě vyzkouším a dám do Mdos 2.2
Podle mě jsou jen tři cesty:
1. rozšířit syntab a kód pro poke# posunout jinam (hrozí jisté riziko u programů, které kódu využívají, o žádném však nevím...)
2. změnit začátek tabulky syntab a zkrátit text hlášení "File is too long" o 8 bajtů
3. vyprdnout se na syntab a napíchnout se pro vyhodnocení příkazu v mdosu jinam, tj. asi nejlepší ale také nejdelší (počtem potřebných bajtů) řešení. Nejlépe asi využít volného prostoru #021d až #0265

Nejvíc se mi líbí řešení 1.
Nejméně destruktivní, tabulka příkazů zůstane tam, kde ji každý očekává, kód povelu POKE# na původních adresách není důvod využívat (buď volám z Basic ROM, pak neovlivním, o jakou adresu jde, nebo mám nastránkovanou DROM/DRAM a můžu do DRAM ukládat hodnoty rovnou).

Tieto dve riesenia su zial nepouzitelne, pretoze tabulka RSTTAB je urcena len na rozsirovanie prikazov - okrem navratovej hodnoty RST #08 testuje TADDR co je pointer na polozky do syntaxnej tabulky prikazov v ZX romke na adrese #1A7A.
Kdezto v pripade PEEK # sa nejedna o basicovy prikaz alebo jeho rozsirenie, ale o funkciu, ktora sa pouziva vo vyrazoch. A vyhodnocovanie vyrazov nema nic spolocne s TADDR.
Toto bude pre MDOS jedine schodne riesenie.

V obsluznej rutinke RST #08 (napr. na adrese #0266) bude treba otestovat ci navratova adresa je #1C8B (tam sa generuje error aj pri PEEK #) a ci CHADD ukazuje na znak '#' ktory tento error sposobil, a ci pred tymto znakom je nas PEEK (ktory moze byt od znaku este oddeleny nejakymi bielymi znami). A az ked toto vsetko bude splnene, mozeme pokracovat vo vyhodnocovani PEEK #. Hodnota TADDR sa kontrolovat nema, pretoze ta zavisi od konkretneho prikazu, v ktorom je vyraz obsahujuci PEEK # pouzity a preto to moze byt v podstate cokolvek.

Díky za objasnění. Využil bych tedy k tomu #021D až #0265. To místo je perfektně situované (ještě před vyhodnocováním SYNTAB) a je tam kód, který se nikdy neprovádí (zapomenutá debugovací rutina). Pochopil jsem, co jsi napsal, ale přeci jen se s tím budu trápit, protože zx rom zase tak zmáknutou nemám. Nechceš přiložit rovnou ten kód?
Já mám nyní toto (což je špatně, protože to rovnou tiskne na obrazovku, my však chceme jen předat hodnotu zpět basicu):

Ja sa skor divim preco tam vobec davali ten offset #3E00 a nenechali adresy pre POKE v ich nativnom rozsahu 14336..16383. Ale asi sa rozhodli ze staci len poslednych 512 bajtov a chceli lahsie zapametatelny rozsah 0..512.

Napadli ma hned styri riesenia ako na to:

1. Prve je velmi primitivne, staci odstranit kontrolu na rozsah do 512 na adrese #06E0 a tiez aj ADD #3E00 na adrese #06EA a cela D80 ram bude potom dostupna v spominanom rozsahu 14336..16383. Ale toto nie je zial spetne kompatibilne, take typicke POKE #247 pojde do romky a aplikacie s prepinanim cez RST #00 sa budu logicky resetovat.

2. Ako prve riesenie, ale ak je adresa v POKE mensia ako 511 tak iba vtedy pripocitat #3E00, cim sa zabezpeci spetna kompatibilita, ale zostanu funkcne aj nativne adresy, cez ktore bude mozne pristupovat do celej D80 ramky.

3. Toto zachovava kompatibilitu v rozsahu 0..511, ale pre zvysok ramky zavadza adresovy priestor 512..2047. Takze nemame kontinualny adresovy priestor 0..2047, ale tento priestor je "zlomeny" na dve na seba nenadvezujuce casti. Na toto uplne postaci #06E0 zmenit CP 2 na CP 8 a medzi ADD HL,BC a LD (HL),A este pridat test BIT 6,H a aj je tento bit nenulovy, potom k HL este navyse pripocitat hodnotu #F800. V podstate iba 7 bajtov navyse:
4. Pokial chceme "kontinualny" priestor s adresami -1536..+511, uprava bude o dost zlozitejsia. V tomto pripade totiz nemozeme pouzit univerzalnu romkovu rutinku #1E85 ktora prevezme prvy parameter 0..65535 a druhy -256..+255, ale musime si samostatne prevziat druhy jednobajtovy parameter s vlastnym osetrenim jeho znamienka (pri zapornom hodnotu znegovat), a potom prvy parameter pri ktorom si tiez musime osetrit jeho znamienko (a tiez pri zapornom znegovat) a otestovat ho na rozsah -1536..+511. A potom uz len pripocitat #3E00 a mame adresu pre POKE. Odhadujem ze bude treba pridat tak 20 az 30 bajtov kodu.

Cize obaja hlasujete pre moznost 2. To ma tesi, tato moznost sa najviac pozdava aj mne

(akurat teda PotPalo chce este navyse aby to pre rozsah 512..14335 vyhodilo chybu, co mi osobne pride zbytocne)

Ved tak to aj bude. Poke s adresami 16384 a viac pojde normalne do spektrackej ramky, takze tam bude jedno, ci uzivatel pouzije znak # v prikaze POKE alebo nie

Navrh na novu rutinku POKE# od adresy #06DE:

teda pani... celkom ma udivuje, akeho kockopsa dokazete s chladnou hlavou navrhnut/odsuhlasit...

tu sa nebavite o programe, ktory si nejaky Janko z Hornej Dolnej doma zbastlil v basicu a pacil sa mu, lebo tam bolo vela farieb a pipal...

ako k tomu pridu adresy #0000-#01ff, ze cez POKE#/PEEK# s nimi nemozno ratat, ale zato adresy #3e00-#3fff su viditelne hned dvakrat?

za mna, ak chcete zvacsit rozsah adries a chcete byt spatne kompatibilni (co samozrejme hodnotim pozitivne), tak nerobte z "POKE #" bastarda, radsej nechajte "POKE #" tak ako je a spravte nieco nove, napr. "POKE &", alebo "POKE '" (alebo nejaky iny vhodnejsi znak).

Každý máte svým způsobem pravdu.
V mdosu 2.2 já osobně upravím POKE# aby akceptoval pouze 0-511 a 14336-16383 ostatní vyhodí error out of range.
PEEK# bude stejně tak (pokud se mi to tedy podaří, protože tam bruslím na tenkém ledě a nepříjde mi to zrovna úplně snadné a Busy zatím mlčí

Vsetko beriem, akurat my sa teraz snazime o nejake jednoducho a rychlo spravitelne riesenie ktore nevyzaduje prilis velke zasahy do MDOS romky. Poziadavku na prevadzkovanie MDOSu v ramke s povolenym zapisom, vratane moznosti POKE do celych 16kB jeho priestoru, sme (zatial) neriesili.
Ale ja pisem o PEEK# ako protipol POKE#, nie PEEK vo vseobecnosti. To znamena, ze ho mozeme vymysliet ako uzname za vhodne, nemusi nutne splnat vsetky atributy systematickosti (ked ho uz ani samotne POKE# z principu nemoze splnit) My ho prave chceme spravit ako protipol POKE#, t.j. cez adresu, ktorou sa naPOKE#-uju data, sa budu dat tieto data aj PEEK#-ovat. Standartom je iba to ze adresy 0..511 zodpovedaju poslednym 512 bajtom MDOS ramky a snazime sa toto nejak rozsirit na zbytok tej 2kB ramky v MDOSe.
Ak niekto bude chciet mat plny PEEK/POKE pristup do celych 16kB, na toto by som pouzil iny znak nez #, tak ako si navrhoval vyssie.
Nemlcim ale spravit cez RST #08 obsluhu PEEK# pri vyhodnocovani obecneho vyrazu nie je az tak trivialne aby sa to dalo napisat len tak zfleku. Na to si musim najst cas a poriadne sa na to pozriet.

Jen takový nápad. Nezaložíme zcela novou tému s názvem "Vývoj MDOS 2.x" a nepřesuneme pár posledních stran tam?
Přeci jen toto stávající téma je spíše o HW a někoho to třebas vůbec nemusí zajímat....