flat assembler
Message board for the users of flat assembler.

Index > DOS > mode 13h

Author
Thread Post new topic Reply to topic
kb_08h



Joined: 03 Nov 2005
Posts: 12
Location: Ukraine
kb_08h 23 Jun 2007, 13:30
Hi, guys. Can you explain me please, how can i realize this algorythm in fasm? Confused

Code:
Program Fractal;
Uses Graph, Crt;
Var
   x, y, z  : Integer;
   gd, gm   : Integer;
   mx, my   : Integer;
Begin
   gd := Detect;
   InitGraph(gd,gm,'e:\bp\bgi');
   mx:=GetMaxX div 2;
   my:=GetMaxY div 2;
   For y:=-my to my do
      For x:=-mx to mx do Begin
        z:=trunc(0.1*(sqr(x)+sqr(y)));
        PutPixel(mx + x,my + y,z mod 16);
      End;
   Readkey;
   CloseGraph;
end.
    


I'll be apreciative for any suggest.

_________________
{D is for demoscene}
Post 23 Jun 2007, 13:30
View user's profile Send private message ICQ Number Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1903
DOS386 23 Jun 2007, 23:15
Quote:
how can i realize this algorythm in fasm


algorythm -> algorithm Shocked

Does the "TURBO"-PASCAL code work for you ?

Suspiciously simple Confused And the integers ... Confused

If YES, post screenshot or compiled EXE, please Wink

Code:
   gd := Detect;
   InitGraph(gd,gm,'e:\bp\bgi');
    


BGI is crap Sad As you found out, the easiest way to do is the VGA $13
mode. Wink Just execute INT $10 with AX=$13

Resolution is 320x200, "LFB" is at $A0000, 8bpp palettized

Code:
        PutPixel(mx + x,my + y,z mod 16);
    


Just poke it into the LFB ...

Code:
   CloseGraph;
    


INT $10/AX=3

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug
Post 23 Jun 2007, 23:15
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4624
Location: Argentina
LocoDelAssembly 24 Jun 2007, 02:57
If sqr means square root then I think this code cannot go nowhere. The square root of a negative number lacks of a real number solution. I think you need to handle complex numbers or not use negative numbers at all.

Can you link us to some info about this particular fractal?
Post 24 Jun 2007, 02:57
View user's profile Send private message Reply with quote
kb_08h



Joined: 03 Nov 2005
Posts: 12
Location: Ukraine
kb_08h 24 Jun 2007, 15:09
Quote:
algorythm -> algorithm Shocked

thx, sorry for my weak english Embarassed

Quote:
Does the "TURBO"-PASCAL code work for you ?

You're right. This "suspicious" code compiling with FPC with no errors but failing on execution.

I found this algorithm on this russian site
http://fractalworld.xaoc.ru/article/frcircl.html

screenshot is also there

i just want to write some fractal in fasm (dos mode 13), this one from fasm_dos examples is very good, but without any comments on FPU, is there any good FPU tutorial?

thank u all, guys for your replies...

_________________
{D is for demoscene}
Post 24 Jun 2007, 15:09
View user's profile Send private message ICQ Number Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4624
Location: Argentina
LocoDelAssembly 24 Jun 2007, 16:56
Sorry, my supposition about sqr was wrong since it squares the number instead of square rooting it.

Here is my unoptimized code
Code:
org $100
mov     ax, 13h ; AH = 0; AL = 13h 
int     $10 

; Set ES to $A000 to get access to the video memory 
mov     ax, $A000 
mov     es, ax 

xor     bx, bx 
mov     ecx, 50

yRes = 200 
xRes = 320 

; di = Y; si = X 
mov di, -yRes/2 

yLoop: 
  mov si, -xRes/2 

  xLoop: 
    ; z = (Sqr(di) + Sqr(si))/10 
    movsx   eax, si
    movsx   edx, di

    imul    eax, eax ; Sqr(si)
    imul    edx, edx ; Sqr(di)

    add     eax, edx ; Sqr(si) + Sqr(di)

    ; (Sqr(di) + Sqr(si))/10
    xor     edx, edx
    div     ecx

    ; PutPixel
    and     al, $F ; [(Sqr(di) + Sqr(si))/10] mod 16
    mov     [es:bx], al ; Writes the pixel

    inc     bx ; Increments pixel pointer 

    inc     si 
    cmp     si, xRes/2 
    jne     xLoop 

  inc     di 
  cmp     di, yRes/2 
  jne     yLoop 

; ReadKey 
xor     ax, ax 
int     $16 

; Set video mode back to text mode 
mov     ax, 3 
int     $10 

; Return to DOS 
int     $20    


I haven't used any FPU code because actually the Pascal code doesn't need it. The trunc is used because of the multiplication with 0.1 but since dividing by 10 is the same I used integer-only code.

However, the resulting plot is not the same as in the screenshot of that page so I probably did something wrong Sad (note that the mine draws circles too, but in a different disposition).

[edit] Changed DX to DL in the PutPixel part [/edit]
[edit2] Now use 32 bits arithmetic [/edit2]


Last edited by LocoDelAssembly on 24 Jun 2007, 18:49; edited 2 times in total
Post 24 Jun 2007, 16:56
View user's profile Send private message Reply with quote
kb_08h



Joined: 03 Nov 2005
Posts: 12
Location: Ukraine
kb_08h 24 Jun 2007, 17:06
LocoDelAssembly
Cool! Exclamation

thanks for the comments! they're very usefull!...[/b]

_________________
{D is for demoscene}
Post 24 Jun 2007, 17:06
View user's profile Send private message ICQ Number Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4624
Location: Argentina
LocoDelAssembly 24 Jun 2007, 18:55
I did some changes. Now uses normal division and divides by 50 instead of 10. The reason for changing the divisor was that with 50 the plot is much nearest to the screenshot though the colors keeps different (maybe because BGI uses another pallete).

Oh, and the most important modification is that now uses 32 bit arithmetic. I not realized that many of the iterations handles values greater than 2^16 Razz . The plot didn't change much with the 32 bit arithmetic actually but some noise has been dissapeared.
Post 24 Jun 2007, 18:55
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1903
DOS386 24 Jun 2007, 23:34
> Program Fractal;

This is NOT a fractal program Shocked

> Here is my unoptimized code

COOL Smile

> maybe because BGI uses another pallete

Seems to be more than a palette difference Confused

WARNING this post comes with 2 screenshots - but they might be invisible for guests Sad


Description: Shot of Loco's code
Filesize: 7 KB
Viewed: 13710 Time(s)

CIRCLES.PNG


Description: Shot from Russian page (crap: truncated, JPG, bloated :-( )
Filesize: 18.3 KB
Viewed: 13710 Time(s)

S.JPG



_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug


Last edited by DOS386 on 25 Jun 2007, 08:43; edited 1 time in total
Post 24 Jun 2007, 23:34
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4624
Location: Argentina
LocoDelAssembly 25 Jun 2007, 03:51
Code:
Program Circle;
Uses Graph;
Var
   x, y, z  : LongInt;
   gd, gm   : Integer;
   mx, my   : LongInt;
Begin
   gd := Detect;
   gm := 0;
   InitGraph(gd,gm,'c:\tp\bgi');
   mx:=GetMaxX div 2;
   my:=GetMaxY div 2;
   For y:=-my to my do
      For x:=-mx to mx do Begin
        z:=Trunc(0.1*(sqr(x)+sqr(y)));
        PutPixel(mx + x,my + y,z mod 16);
      End;
   ReadLn;
   CloseGraph;
end.    


The code above worked for me on Turbo Pascal 7.0. The only difference with my assembly code is that this program has plotted at a 1024x768 resolution but with the same ugly colours and with the same pattern (when ECX is 10 on my code). I still can't reproduce exactly as the russian page screenshot so, perhaps it looks different due to the shrinking and the heavy loss of quality that JPEG produce over graphics?

PS: I tried with FreePascal for DOS but the program crashes even before reaching the main "begin" on both Windows and DOSBox 0.70.
Post 25 Jun 2007, 03:51
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1903
DOS386 25 Jun 2007, 08:38
> I tried with FreePascal for DOS

Version ?

> but the program crashes

Evil or Very Mad

> even before reaching the main "begin" on both Windows

It might be a good idea to use "windows" version of FPC when compiling to "windows" ...

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug
Post 25 Jun 2007, 08:38
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4624
Location: Argentina
LocoDelAssembly 25 Jun 2007, 14:17
> Version ?
2.0.4

>It might be a good idea to use "windows" version of FPC when compiling to "windows" ...

Surprisingly BGI works on Windows apps Surprised

Anyway, same ugly colours on a 1024x768 window. The differences between the original code and the mine is that I changed "'e:\bp\bgi" with "c:\tp\bgi" and I use LongInt instead of Integer. If I use integer the program crashes even if I disable the range checking... If I try to debug with the dissasembly view the IDE crashes aswell or closes without warning. You don't have an idea of how I hate this FreePascal, certainly TP7 works alot better but TP7 is a 16-bit DOS compiler!!

Image
Post 25 Jun 2007, 14:17
View user's profile Send private message Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1903
DOS386 25 Jun 2007, 23:05
> > Version ?

> 2.0.4

Voila ... the 2nd most broken one (after 2.0.0 - no DOS version at all Shocked )
- it's horribly buggy and unusable Crying or Very sad

the latest stable is always the best (R)

2.1.4 is reported to be better - very buggy only, this prog might be simple enough to work with it Confused

> Surprisingly BGI works on Windows apps

Compiled with FP to Windows target, BGI "emulated" ?

> If I try to debug with the dissasembly view the IDE crashes aswell

In DOS it does not even start Crying or Very sad

> don't have an idea of how I hate this FreePascal

I (see also my signature Laughing ) DO Confused

> certainly TP7 works alot better but TP7 is a 16-bit DOS compiler!!

NO. It has other horrible bugs ( Error 200 criminal division by 0 in CRT )
and is 16-bit only Crying or Very sad

_________________
Bug Nr.: 12345

Title: Hello World program compiles to 100 KB !!!

Status: Closed: NOT a Bug
Post 25 Jun 2007, 23:05
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4624
Location: Argentina
LocoDelAssembly 25 Jun 2007, 23:39
>NO. It has other horrible bugs ( Error 200 criminal division by 0 in CRT )

Well the bug is not in the entire compiler, just in the CRT unit that is not required to be used always. There are many unnoficial patches that fixes this problem with the initialization code for later use of Delay procedure. How many others? Everything I did on TurboPascal has worked great while on FreePascal sometimes I get compilation errors on things that actually are OK and the generated code is many times worst that the one a fasm macro can do.

About emulation, I didn't touch anything, just compiled and a PE Console executable has been generated. When the InitGraph proc gets executed a new window of 1024x768 pixels appears. I was surprised because I didn't know that such functions was available under Windows environment.

PS:
http://www.freepascal.org/download.var wrote:
The latest release is 2.0.4 .
Post 25 Jun 2007, 23:39
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo 26 Jun 2007, 02:14
LocoDelAssembly wrote:

PS: The latest release is 2.0.4.


FPC News wrote:

May 20, 2007 After years of development the new fpc version 2.2.0, version 2.1.4 aka 2.2.0-beta is released. The beta will be available for about two months whereafter 2.2.0 will be released. We ask all our users to test this release, and report bugs on the bug-tracker. If you want to know if your bug is already solved, you can look it up in mantis, or try one of the daily snapshots, based on the fixes_2_2 branch. So please help us make version 2.2.0 the most stable version of freepascal, until now. List of changes can be found here. The releasenotes are also available. Please note that there are some intentional incompatibilities with previous versions, for an overview click here.


BTW, if you don't like FPC for DOS, try GNU Pascal (w/ DJGPP / GCC 3.4.4) or Virtual Pascal (supposedly runs w/ HXRT).
Post 26 Jun 2007, 02:14
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4624
Location: Argentina
LocoDelAssembly 26 Jun 2007, 02:46
rugxulo, that quote was to show that I'm using the stable version, though, I revisited the page few seconds ago and I can't see where it says it is the stable release :S

Thanks for the suggestions, I'll give to them a try the next time I need to code in Pascal (hopefully never more!!Wink).
Post 26 Jun 2007, 02:46
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2341
Location: Usono (aka, USA)
rugxulo 26 Jun 2007, 03:43
Well, if you want a Pascal-ish language that isn't Pascal (heh), try XPL0. Worth a look just for the examples, IMO (e.g. Cubic). Very Happy
Post 26 Jun 2007, 03:43
View user's profile Send private message Visit poster's website Reply with quote
kb_08h



Joined: 03 Nov 2005
Posts: 12
Location: Ukraine
kb_08h 01 Jul 2007, 20:21
hi again, i'm trying to realize this algorithm:

Code:
for (y=0; y<199; y++)
{
   for (x=0; x<319; x++)
   {
        color=sin(x/25)*63+sin(y/25)*63;
        Putpixel (x,y,color);
    }
}
    


here's what i did

Code:
org     100h

;set vga 8bit 320x200 mode
mov     al,13h
int     10h

;set ES to $A000 to get access to the video memory
mov     ax, $A000
mov     es, ax


xor     si,si   ;xres
xor     di,di   ;yres

yloop:

   xloop:

        push    si
        push    di
        fild    dword [si]      ;st0 = xres
        fidiv   dword [25]      ;xres/25
        fsin                    ;sin(xres/25)
        fimul   dword [63]      ;sin(xres/25)*63
        fistp   dword [si]      ;si = sin(xres/25)*63

        fild    dword [di]      ;st0 = yres
        fidiv   dword [25]      ;yres/25
        fsin                    ;sin(yres)/25
        fimul   dword [63]      ;sin(yres)/25*63
        fistp   dword [di]      ;di = sin(yres/25)*63

        xor     ax,ax
        mov     ax,di
        add     ax,si           ;ax = sin(xres/25)*63 + sin(yres/25)*63

        pop     di
        pop     si
        mov     bx,di
        imul    bx,320          ;yres*320
        add     bx,si
        mov     [es:bx],ax

        inc     si
        cmp     si,319

   jne  xloop

inc     di
cmp     di,199
jne     yloop


;await keypress
_keypress:
mov      ah,00
int      16h

;terminate program
_end:

mov     ah,00
mov     al,03
int     10h
mov     ah,4ch
mov     al,00
int     21h


    


can u tell me please what's wrong with this code?
i think the problem is in FPU calculations, i use FPU for the first time... Confused

_________________
{D is for demoscene}


Last edited by kb_08h on 01 Jul 2007, 21:01; edited 2 times in total
Post 01 Jul 2007, 20:21
View user's profile Send private message ICQ Number Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4624
Location: Argentina
LocoDelAssembly 01 Jul 2007, 20:58
Code:
org     100h

;set vga 8bit 320x200 mode 
mov     ax,13h
int     10h 

;set ES to $A000 to get access to the video memory 
mov     ax, $A000 
mov     es, ax 

xor     di,di   ;yres

finit

yloop: 
  xor     si,si   ;xres

   xloop:
        push    si
        push    di
        mov     word  [aux], si
        fild    dword [aux]      ;st0 = xres
        fidiv   dword [c25]      ;xres/25
        fsin                    ;sin(xres/25)
        fimul   dword [c63]      ;sin(xres/25)*63
        fistp   dword [aux]      ;si = sin(xres/25)*63
        mov     si, word [aux]

        mov     word  [aux], di
        fild    dword [aux]      ;st0 = yres
        fidiv   dword [c25]      ;yres/25
        fsin                    ;sin(yres)/25
        fimul   dword [c63]      ;sin(yres)/25*63
        fistp   dword [aux]      ;di = sin(yres/25)*63
        mov     di, word [aux]

        xor     ax,ax 
        mov     ax,di 
        add     ax,si           ;ax = sin(xres/25)*63 + sin(yres/25)*63 

        pop     di 
        pop     si 
        mov     bx,di 
        imul    bx,320          ;yres*320 
        add     bx,si 
        mov     [es:bx],ax 

        inc     si 
        cmp     si,319 

   jne  xloop 

inc     di 
cmp     di,199 
jne     yloop 


;await keypress 
_keypress: 
mov      ax,00
int      16h 

;terminate program 
_end: 

mov     ah,00 
mov     al,03 
int     10h 
mov     ah,4ch 
mov     al,00 
int     21h

c25 dd 25
c63 dd 63

aux dd 0    

It's very extrange the output but doesn't crash now.

Sorry, no time to explain the modifications Sad
Post 01 Jul 2007, 20:58
View user's profile Send private message Reply with quote
kb_08h



Joined: 03 Nov 2005
Posts: 12
Location: Ukraine
kb_08h 01 Jul 2007, 21:08
Thx, LocoDelAssembly, i've get the clue.... but result is very... unexpected =\

can't get what's wrong...
Post 01 Jul 2007, 21:08
View user's profile Send private message ICQ Number Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.