trebao si da posaljes kompletan tasm kod sa direktivama!!

------------------------------------------------

;smesta 13h u al, sto znaci da je ah=0
;ovo znaci zeli se funkcija 0 interapta 10h a to je
;postavljanje ekrana u zeljeni video mod koji se specifiran
;u al registru a to je 13h a to je VGA/MCGA 320x200 pixela u 256 boja

mov al, 13h

;poziv prekida

int 10h

;instrukcija koja ucitava 32 bitni pointer iz memorije u
;registar bp i es registre, e sad u bp ide offset a u es segment adrese, znaci 32bit = 4 BYTES = 2 WORDS
;prvi word ide u bp a drugi u es
;ovde je memorija vrednost koja se nalazi u bx
;registru a to je u ovom slucaju 0, posto bx nije menjan on je pri startovanju programa 0
;a sta je na 0 toj adresi? kod .com fajlova koji pocinju sa offseta 100h prvih
;100h bajtova je rezervisano za PSP tj program segment prefix
;na offsetu 0 nalazi se "int 20h" i to su prva 2 bajta, to u hex vrednostima predstavlja "CD 20" i ta
;vrednost ce biti ubacena u bp, ali to je ono sto nas neinteresuje, ono sto nam zaista treba je da u ES segmentu
;bude adresa video buffera a ona je A000h, a to se dobija iz sledeca 2 bajta na offsetu 0004h tj posle "int
;20h", a to su "A000" bas ono sto nam treba, dakle posle ove instrukcije bp ce sadrzati "20 CD" a es "A000", bp
;je potpuno nevazan i moga se koristiti i neki drugi registar koji nam netreba a ono sto je vazno je da es sadrzi
;segment video buffera koji nam treba kod sledece instrukcije
;(inace vrlo zanimljivo koriscenje instrukcije, prakticno covek je morao da gleda hex vrednosti na 0000
;ofsetu i da posle poveze to sa ovom instrukcijom ..ovo sve je mogao da odradi prostim
;mov ax,a000h
;xchg ax,es
;ali nije i time je dobio mozda 2 bajta manji program)

les bp, [bx]

;ova instrukcija je skracenica za store string byte i ona ce da smesti vrednost iz ax registra tj u ovom slucaju
;posto se radi o bajtu onda samo donji deo registra ax tj al u memoriju na koju pokazuje es:di
;es je segment video buffera
di je offset
;znaci ako je di = 0 onda ce stosb da smesti vrednost iz al na gornju levu tacku naseg monitora, ovde vrednost u
;al predstavlja boju posto sam rekao na pocetku da se radi o video modu sa 256 boja a al = byte, svi znamo da byte
;moze da predstavlja 256 razlicitih brojeva a to su u ovom slucaju boje


stosb

;sledeca instrukcija ce inkrementirati ax registar ako je CF flag postavljen, cilj ovoga je da poveca vrednost
;broja koji predstavlja boju, kako bi se ta boja sledeca iscrtala u tacki na ekranu pored one prethodne

adc ax, di

;sledeca instrukcija mi nije jasna, ne znam sta je fs
;nikad nisam radio sa tasm ali moguce da fs
;predstavlja neki od segmenata

adc ax, fs[046C]

;ovo je unconditional jmp i skace na 106 offset tj na stsob instrukciju, i time stvara endless loop kako bi se tackice stalno iscrtavale

jmp 0106
------------------------------------------------

dakle u osnovi program predstavlja beskrajnu petlju koja u svakom koraki iscrta po jednu tacku na ekranu na sledecem mestu sa sledecom bojom u spektru, posto su racunari jako brzi to sto mi vidimo na ekranu je jako brzo iscrtavanje tackica u raznim bojama i zato nam izgleda da kazem lepo

a zasto?



fs je segmentni registar, i on ne ovisi o tome koji asembler koristis. Zanimalo me zasto se on ovdje koristi jer sam jako malo radio u asembleru za DOS-u (DOS16asm, hehehehe) i tamo nikad nisam vidio da ga netko koristi. U win32asm se fs:[0] koristi za postavljanje SEH frame-a da bi se izbjeglo GPF ili neki drugi exception. Ako jednostavno maknes ovu instrukciju dobijes isto nesto slicno. Mozda ima neke veze sa onim CONTEXT-ima thread-ova pod win32? Ali me uostalom sada bas briga.

Sto se tice les bp, [bx], u mene nakon toga es ima 9FD6. a ne 9A00. Kako to objasnjavas?

pa zato sto direktive i te kako mogu da uticu na kod, ali ok ovde mislim da nisu potrebne, to sam rekao na prvi pogled


[/quote]



ok ali ja taj gore kod nisam mogao da kompajliram sa A86 jer nije prepoznao sta je to FS.. mada ok mislim da je to jedno od ogranicenja ovog kompajlera u sharware verziji

adc ax, fs[046C]
adc instrukcija znaci addition with carry
pa ovo gore predstavlja sledece
ax = ax + [fs:46C] + CarryFlag

dakle na ax vrednost dodaje word koji se nalazi na adresi fs:46C a ja isto imam neki bezveze debuger koji mi ne prikazuje sadrzaj fs segmenta ali predpostavljam da on pokazuje na isti segment kao i cs, ds, i ss jer je rec o .com fajlu

pravo da ti kazem i ja se sa FS prvi put bavim sada




es treba da ima vrednost A000 a ne 9A000
i cim ti intro radi znaci da es zaista ima vrednost A000 a ne 9FD6
meni posle te instrukcije ima vrednost A000 a pre nje je imao vrednost istu kao i ss,cs i ds
proveri jos jednom da nisi procitao neki drugi registar

meni je es na 9FD6. Koristim Turbo Debugger, 16-bitnu verziju naravno.

Evo ti dump sa ds:

ds:0000 CD 20 D6 9F 00 9A F0 FE
ds:0008 1D F0 32 0B 85 10 0F 0C

Koji debugger koristis i kako u njemu izgleda ova memorija?

hm zanimljivo.. i kod mene u turbo debugeru se dobije isto sto i kod tebe ali u d86 debugeru koji dolazi uz a86 kompajler se dobije ono sto sam gore pisao, ali debug.com mi daje isto sto i d86
kucaj
debug.com intro.com
d cs:0

i dobices sadrzaj memorije, pogledaj 3 i 4 bajt videces da su 00 A0
znaci nesto nije u redu sa turbo debugerom, ili pogresno prikazuje ili ne znam sta
e sad probaj u td da promenis vrednost es registra na A000 i videces da ce da radi lepo

ok sad u cemu je fora? malo sam razmisljao i misim da sam provalio tj setih se adresiranja koje vazi u dosu

fizicka adresa u dosu gde je memorija segmentno raspodeljena se dobija na sledeci nacin
ADRESA = SEGMENT*16 + OFFSET
dakle do jedne adrese se moze doci na vise nacina
npr
0000:0010
je isto sto i
0001:0000

za prvi bice: 0000*10h + 10 = 0 + 10 = 10
za drugi: 0001*10h + 0000 = 10 + 0 = 10
16 = 10h

dakle ono sto se desava u nasem intru je da se istoj fizickoj adresi pristupalo preko 2 razlicita segmenta, zato je program radio i pod turbo debugerom i pod d86 i bez debugera, samo jos ostaje da se odgonetne zasto je kod turbo debugera 9FD6 na lokaciji cs:003 a kod debug.com i d86 A000, a to zaista ne znam, jedino sto mi pada na pamet je da mozda turbo debuger brljavi po PSP-u odnosno po tih prvih 100h bajtova rezervisanih za .com fajove i upisuje neke svoje podatke koje mu trebju za debug

Stara je tema... Ali ja sam je skoro procitao, i svidelo mi se. Ranije sam se
bavio DOS-om, pa cu pokusati da razjasnim do kraja...

mov al, 13h
int 10h ; - VIDEO -
les bp, [bx] ; u es ide word sa offset-a 2 iz PSP-a
; to je segment adresa poslednjeg paragrafa
; (1 paragraf = 16 bajtova) dodeljenog programu
; obicno .com programi dobiju celu raspolozivu
; memoriju, tako da je to adresa koja je dovoljno blizu
; A000, dok se di registar non-stop vrti od 0-64k i
; tako iscrtava sve ispocetka
stosb
adc ax, di
adc ax, fs[046C] ; fs = 0 na pocetku programa (u DOS-u fs nista ne znaci)
; 046C = 0040:006C - tajmer, BIOS inkrementuje ovaj
; word priblizno 18.2 puta u sekundi
jmp 0106; skace na stosb

E sad, kako je uspeo da nasteluje da crta krugove, pojma nemam... ;)

pa necrta krugove, to samo mozda izgleda zbog velike brzine
ja nisam primetio te krugove mada imam slabiji procesor

ma nisu to krugovi u pravom strogom matematickom smislu te rijeci, vec neki psihodelicni likovi koji izgledaju poput koncentricnih krugova. tako nekako. ja mislim da je autor ovoga programa testirao razlicite vrijednosti registara i tako je naisao na onu koja proizvodi graficki najefektniji efekt.

Da, zagledao sam pazljivije. Nisu krugovi, vec neki "krugoliki" pattern-i. Ali
u svakom slucaju, ima nekakvu formu, nisu to potpuno random nabacani pixeli.

BTW, probajte sbb ax, fs[046C]