flat assembler
Message board for the users of flat assembler.
Index
> DOS > mode 13h |
Author |
|
DOS386 23 Jun 2007, 23:15
Quote: how can i realize this algorythm in fasm algorythm -> algorithm Does the "TURBO"-PASCAL code work for you ? Suspiciously simple And the integers ... If YES, post screenshot or compiled EXE, please Code: gd := Detect; InitGraph(gd,gm,'e:\bp\bgi'); BGI is crap As you found out, the easiest way to do is the VGA $13 mode. 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 |
|||
23 Jun 2007, 23:15 |
|
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? |
|||
24 Jun 2007, 02:57 |
|
kb_08h 24 Jun 2007, 15:09
Quote: algorythm -> algorithm thx, sorry for my weak english 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} |
|||
24 Jun 2007, 15:09 |
|
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 (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 |
|||
24 Jun 2007, 16:56 |
|
kb_08h 24 Jun 2007, 17:06
LocoDelAssembly
Cool! thanks for the comments! they're very usefull!...[/b] _________________ {D is for demoscene} |
|||
24 Jun 2007, 17:06 |
|
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 . The plot didn't change much with the 32 bit arithmetic actually but some noise has been dissapeared. |
|||
24 Jun 2007, 18:55 |
|
DOS386 24 Jun 2007, 23:34
> Program Fractal;
This is NOT a fractal program > Here is my unoptimized code COOL > maybe because BGI uses another pallete Seems to be more than a palette difference WARNING this post comes with 2 screenshots - but they might be invisible for guests
_________________ 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 |
|||||||||||||||||||
24 Jun 2007, 23:34 |
|
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. |
|||
25 Jun 2007, 03:51 |
|
DOS386 25 Jun 2007, 08:38
> I tried with FreePascal for DOS
Version ? > but the program crashes > 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 |
|||
25 Jun 2007, 08:38 |
|
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 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!! |
|||
25 Jun 2007, 14:17 |
|
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 ) - it's horribly buggy and unusable 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 > 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 > don't have an idea of how I hate this FreePascal I (see also my signature ) DO > 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 _________________ Bug Nr.: 12345 Title: Hello World program compiles to 100 KB !!! Status: Closed: NOT a Bug |
|||
25 Jun 2007, 23:05 |
|
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 . |
|||
25 Jun 2007, 23:39 |
|
rugxulo 26 Jun 2007, 02:14
LocoDelAssembly wrote:
FPC News wrote:
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). |
|||
26 Jun 2007, 02:14 |
|
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!!). |
|||
26 Jun 2007, 02:46 |
|
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).
|
|||
26 Jun 2007, 03:43 |
|
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... _________________ {D is for demoscene} Last edited by kb_08h on 01 Jul 2007, 21:01; edited 2 times in total |
|||
01 Jul 2007, 20:21 |
|
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 |
|||
01 Jul 2007, 20:58 |
|
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... |
|||
01 Jul 2007, 21:08 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.