Az Exdos parancs egyszerüsítve a következõ lépéseket végzi: Nyit egy videó csatornát, display utasítással kiteszi, ez EXOS hivással történik és a videó sorokat az lpt-ben átcímzi. Kilépésnél bezárja a videó csatornát.
Tehát a képernyõ helyreállítás egyik módja, hogy végrehajtunk egy display hívást. Amikor nem használjuk az operációs rendszer videó csatornáját, vagyis valami direkt video memória kezelést alkalmazunk, akkor két lehetõség van. Ha tudjuk a videó soraink címeit, csak vissza cimezzük az lpt-sorokat. Amikor virtuális, tehát pl. görgetés miatt kiszámíthatatlanná vált a videócím, akkor célszerû lementeni az exdos parancs elötti lpt-t, és visszatéréskor vissza lehet irni.

Ilyet most látok életemben elöször!


Szerintem egyetértés van, legalábbis én EP-n meg egyébként is csak egyfajtát láttam, azt amit a hivatalos Zilog leírásokban is látni. Éppen ezért döbbentem meg az extrém elvadult példádon, hogy ki lehet olyan örült, hogy ilyet kitalál

Naja. De ha pl vki C nyelven akar fejleszteni, akkor Z80 eseten az sdcc az jo valasztas lehet, ami viszont ilyen asm output-ot keszit, tehat attol hogy neked (nekem se amugy!) nem tetszik ezzel is foglalkozni kell ;-( Legalabbis en igy erzem.

Masodsorban pedig IGENIS izles kerdese, mert ha van egy olyan cucc ami _ILYEN es OLYAN_ formatumot ad, akkor hiaba nem hivatalos az, hiaba nem tetszik stb stb, kenytelen vagy vele egyutt elni ha hasznalni akarod, ez ilyen egyszeru Most nem mondthatom meg az sdcc (meg az as-z80) keszitoinek hogy "hulyek vagytok szar a syntaxis" attol valszeg nem lesznek meghatva kulonoskeppen max azt valaszolnak hogy nem kotelezo hasznalni ha nem tetszik. De nekem pont az, hogy szuksegem lenne ra ...

Amugy ez mar eleve nem olyan egyszeru pl x86-on sem, mint ismert ott is ket fo formatum van, az Initel es az AT&T syntaxis, mely utobbit hasznalja pl a gas/gcc is, es elso latasra eleg durva, eleve forditva van a ket operandus, hogy masrol ne is beszeljek):

 __asm__ __volatile__(        
              "1:      mov" "b" " %2,%" "b" "1\n"        
              "2:\n"        
              ".section .fixup,\"ax\"\n"        
              "3:      movl %3,%0\n"        
              "        xor" "b" " %" "b" "1,%" "b" "1\n"        
              "        jmp 2b\n"        
              ".section __ex_table,\"a\"\n"        
              "        .align 4\n"        
              "        .long 1b,3b\n"        
              ".text"        : "=r"(__gu_err), "=q" (__gu_val): "m"((*(struct __large_struct *)
                            (   __gu_addr   )) ), "i"(- 14 ), "0"(  __gu_err  )) ;
              break;      

Ez AT&T syntaxist hasznalno gcc inline assmbler betet volt eppen ;-> Lathato hogy allatira nem trivialis (google-el erdemes rakeresni arra hogy "black magic gcc assembly"

Amugy ez az AT&T syntaxis pl tobbe kevesbe kvazi standard UNIX vagy UNIX szeru rendszereken, tobbfele CPU-n is (max ofkoz maguk az opcode-ok masok).

Ezt most csak peldanak mondtam, hogy milyen nehez kerdes is az, hogy mi az "izles kerdese" meg mi nem ...

Raadasul, ha mar x86, az sem egyszeru kerdes, hogy kitalalja az assembler, eppen milyen cimzesmodot hasznalna szerencsetlen programozo, nezzunk egy peldat:

mov ax,label

Namost jo kerdes, hogy most az AX regiszterbe a label cimke cimen levo word-ot kell betolteni, vagy magat a cimet. Itt pl total keveredes van x86 assemblereknek. A NASM (Netwide Assembler) pl ezert ilyet nem is enged, es MEGKOVETELI, hogy a programozo egyertelmuen jelezze mit akar, ott pl a fenti forma a CIMRE vonatkozik, a [label] pedig a cimen levo ertekre. Pl 65xx cpu-kon mar eleve a "hivatalos" syntaxis is felkeszult erre, es # jelet hasznalja arra, hogy jelezze ez bizony egy konstans, es nem cim, azaz pl az "LDA #1" 1-es erteket tolti be az akkumlatorba, mig az "LDA 1" az az 1-es cimmel rendelkezo byte tartalmat ( hasonlo lenne az x86-os mov ax,label vagy mox ax,[label], ahol keveres is van mert nehol pl mov ax,offset label syntaxist is hasznalnak az "offset" szoval jelezve hogy a label offsetje kell, mint lathato minden CPU-n kurva nagy kavarodas van, sot assemblerenkent valtozik)!

Persze ez elvileg Z80 eseten is megvan, ahol ugye ilyesmire szokas hasznalni a (...) jeleket, viszont pl ezt se erzem mindenhol logikusnak. Valoszinuleg az scc/as-z80 keszitoi azert akartak egy EGYERTELMU es konnyeben ertelmezheto jelolesrendszert bevezetni (ami amugy nemikepp az 65xx szintaxisra hasonlit, ami azert is gyanus, mert amugy azt is tamogatja az 65xx procikat legalabbis ami a mellekelt assemblereket as-* illeti).

Globalisan pl. Hogy minden CPU-nak miert kell tok mas asm syntaxis, marmint nyilvan az opcode-ok jeloleset leszamitva? Pl az AT&T syntaxis egyik erdekessege hogy ugyanugy jeloli a cimzesmodokat kulonbozo CPU-n is, meg az egyes CPU gyartok altalaban valami sajat format talalnak ki tok hasonlo dolgokra is, pl MOS 65xx esten LDA #1, mig x86 eseten mov ax,1, az hagyjan hogy LDA !=MOV (mert eleve nem lehet egy cpu-n olyan opcode aminek nincs is kozvetlen megfeleltetese) de a cimzesmod jeloles stb is tok mas. Ezert szoktal valasztani hogy valami konnyebben parse-olhato es egysegsebb format hasznaljanak, hogy ne kelljen az embernek 1234943947db syntaxist megjegyeznie ha mondjuk tobb cpu-ra is programozik assembly-ben (a mar soXor emlitett AT&T szintaxis pl pont ezt akarja behozni, hogy nagyjabol hasonlo legyen meg teljesen kulonbozo CPU-k eseten is, es ne legyen tok mas assember/cpu fuggo).

Na ezzel _NEM_ azt akarom mondani hogy a Zilog altal specifikalt formatum ne lenne jo nekem, csak azt akartam bemutatni, hogy milyen indittatasbol vannak esetleg mas formatumok is, amit en azert akarok tamogatni, hogy mas tool-okkal egyutt tudjak mukodni Pont ezert kerdeztem, hogy talalkozott-e valaki mas "extrem" vagy kevesbe kozismert synataxisokkal amit esetleg megfontolas targyava lehetne tenni hogy tudjak "konvertalni" a mar vazolt modszerrel.

Igazabol a konkret esetre valo logikussag kerdese azert jott elo itt nalam, mert a Zilog prezentalt formatum kozel konzisztens, de ha tobb formatumot pl keverni akarod akkor nem az, ami problemakat vet fel, ha mindegyiket tamogatni akarom Ez persze nem a Zilog hibaja, nyilvan. Viszont az teny, hogy nekem valahogy meg kell kuzdenem vele, ami egy csomo heurisztikat igenyel emiatt a konverterem reszerol, tehat nem egy egyszeru nota ...

Köszi, sejtettem, hogy a dollárjel a fõszereplõ. Még egy kicsit így is magas, de ha átnézem, biztos megértem. Most viszont munka...

Az jó lenne!
Itt a Heass leírásban nincs szó ilyenrõl
A második használatánál a macronak már azt írja ki, hogy a szimbólum már létezik.

És a Heass 1.1.-ben benne lesz?