flat assembler
Message board for the users of flat assembler.

Index > Main > Seeking alternate methods...

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
bitshifter



Joined: 04 Dec 2007
Posts: 764
Location: Massachusetts, USA
bitshifter
Hello bitRAKE
The code i was using is same as above post: 04 May 2009, 11:52
and with revolutions snippet added just below the org 0x100

As for understanding segment:offset i am just learning to use.
If you look at the code you see what i know about this is limited.

Is there easy way to get segment:offset of g_buffer variable?
Maybe if you can show me some code to calculate i learn faster...
I am terribly frustrated with myself for not being able to solve this. Crying or Very sad

_________________
Coding a 3D game engine with fasm is like trying to eat an elephant,
you just have to keep focused and take it one 'byte' at a time.
Post 05 May 2009, 17:28
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17484
Location: In your JS exploiting you and your system
revolution
Make g_buffer=0, and es as per the code I posted previously.

When copying the es buffer to the screen RAM you also need to set ds to the proper segment value as the source location.
Post 05 May 2009, 17:32
View user's profile Send private message Visit poster's website Reply with quote
bitshifter



Joined: 04 Dec 2007
Posts: 764
Location: Massachusetts, USA
bitshifter
Could you please modify the code as you say and post it?
I having a hard time understanding words, code is better...
Post 05 May 2009, 17:37
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2942
Location: vpcmipstrm
bitRAKE
Note: I don't have an environment to run 8-bit code, atm. Does this work?
Code:
org $100

mov ax,cs ; all segments are the same at start
add ax,$1000 ; +64k
mov es,ax ; DS would work better, imho

cld ; all string access is forward

        mov     ax,0x0013
        int     0x10

    mloop:

mov al,0x07 ; color
mov cx,320 * 200
mov di,0 ; buffer starts at segment start
rep stosb ; stores bytes AL into ES:DI and increments DI

        mov     al,0x01     ; bk-fg pixel color
        mov     di,1        ; x position (column)
        mov     cx,1        ; y position (row)
;        call    SetPixel
imul bx,cx,320
mov [es:di+bx],al ; could use DS as it's the default segment

        mov     dx,0x03DA
    vend:
        in      al,dx
        test    al,0x08
        jz      vend
    vres:
        in      al,dx
        test    al,0x08
        jnz     vres

; source = gbuff:$0000
push es
pop ds
xor si,si
; dest = $A000:$0000
push $A000 ; video memory segment
pop es
xor di,di

mov cx,320 * 200
rep movsb
push ds
pop es

        mov     ah,0x01
        int     0x16
        jz      mloop

        mov     ax,0x0003
        int     0x10

        int     0x20
        ret    
For this example, using DS would work and it's the default segment (no prefix needed), but I've used ES to keep with the previous posts. What is your execution environment?
Post 05 May 2009, 22:51
View user's profile Send private message Visit poster's website Reply with quote
bitshifter



Joined: 04 Dec 2007
Posts: 764
Location: Massachusetts, USA
bitshifter
Hello bitRAKE
Thanks for the code! Razz *dances in circles*
Its works just as it supposed to.
I tested it in Win32-xp2 with cmd.exe
I spent 3 days trying to figure out what people are talking about
but after looking at the code i understand it in less than ten seconds.

Three quick easy questions:

1) The code can now grow to 64k safely but shares with stack?

2) Say i had a 3 byte variable right before the g_buffer then i would need to
adjust the zero based DI register up three bytes to get to the buffer, right?

3) Should i set ES and DS to this segment and leave them there
thus saving us from having all this pushing and popping.
Relating to your comment: mov es,ax ; DS would work better, imho
Or does other stuff besides string instructions use these?

_________________
Coding a 3D game engine with fasm is like trying to eat an elephant,
you just have to keep focused and take it one 'byte' at a time.
Post 06 May 2009, 01:10
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2942
Location: vpcmipstrm
bitRAKE
1) Your understanding is correct. Stack can be moved:
Code:
org $100
...some initialization code
  mov sp,MainLoop
MainLoop:
...    
...now the stack uses the space below the program proper. Very Happy Don't really need a lot of stack usually, but it could be given the 64k above the screen buffer, too. Can't end with a RET if the stack is moved. Eh, worry about this when you get there.

2) That would work, or you could put them after the 64000 byte screen buffer (1536 free bytes of course). Might be good to note that X and Y are zero based, [0,319] and [0,199], respectively.
Code:
virtual at 320*200
  MyData db ?
  MoreData dw ?
  ...
end virtual

mov ax,[MoreData] ; using DS for screen buffer    
3) DS is the default for most memory MOVs. Could use the stack for data storage instead of DS - also have FS and GS to consider. There are many solutions. An easy one would be just to use GS throughout - I've seen this done before - fewer headaches juggling. You'll find your own style in time.
Post 06 May 2009, 03:15
View user's profile Send private message Visit poster's website Reply with quote
bitshifter



Joined: 04 Dec 2007
Posts: 764
Location: Massachusetts, USA
bitshifter
Just to clarify question #2...
If my buffer starts at cs+0x1000:0000 and uses up to cs+0x1000:FA00
then to initialize a string right after the buffer i would use this?
Code:
virtual at 0xFA00
  g_hello db 'hello world',0x00 
end virtual    

And to get pointer (offset) to string i could use this?
Code:
mov si,g_hello    


As for which segment to use, i will have to check the Intel
book and see what instructions rely on what segments.
I will choose the one which requires the least bit of housekeeping.

PS: Thanks for helping me in such a timely and respectable manner.

_________________
Coding a 3D game engine with fasm is like trying to eat an elephant,
you just have to keep focused and take it one 'byte' at a time.
Post 06 May 2009, 04:04
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17484
Location: In your JS exploiting you and your system
revolution
Virtual does not place any data or code into the binary image. It is used only to define pointers and constants. So the above will not put the string 'hello world' into your program, it will only define the value for g_buffer.
Post 06 May 2009, 04:17
View user's profile Send private message Visit poster's website Reply with quote
bitshifter



Joined: 04 Dec 2007
Posts: 764
Location: Massachusetts, USA
bitshifter
So virtual is only used for visualizing uninitialized data?

_________________
Coding a 3D game engine with fasm is like trying to eat an elephant,
you just have to keep focused and take it one 'byte' at a time.
Post 06 May 2009, 04:30
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17484
Location: In your JS exploiting you and your system
revolution
Post 06 May 2009, 04:33
View user's profile Send private message Visit poster's website Reply with quote
bitshifter



Joined: 04 Dec 2007
Posts: 764
Location: Massachusetts, USA
bitshifter
Ok, i get it.
Thanks revolution, you have been very helpfull.
(I now understand everything you said after seeing bitRAKE's code)
I go RTFM more...
Post 06 May 2009, 04:40
View user's profile Send private message Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
Code:
mov si,g_hello    
will only get you the address to an uninitialized location. It is called 'virtual' because it doesn't exist, it only exists as address REFERENCES.

For example:
Code:
virtual at $
  lol db 'LOL',0x00
end virtual

wtf db 'WTF',0x00    
And if you do this:
Code:
push lol
call print    
it will print "WTF" because that's what is put at '$' (current address, back then). 'lol' is only a reference to that LOCATION, but the VALUE "LOL" is not written.

this would be the exact same thing:
Code:
push wtf
call print    
Post 06 May 2009, 21:06
View user's profile Send private message Reply with quote
bitshifter



Joined: 04 Dec 2007
Posts: 764
Location: Massachusetts, USA
bitshifter
So the only way to put initialized data way down there
is to padd my code up to that point with 'times n db 0'?

_________________
Coding a 3D game engine with fasm is like trying to eat an elephant,
you just have to keep focused and take it one 'byte' at a time.
Post 07 May 2009, 02:02
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2942
Location: vpcmipstrm
bitRAKE
Only $FF00 bytes are loaded of a COM file. I haven't tested it, but it seems logical.
Post 07 May 2009, 02:49
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
bitshifter wrote:
So the only way to put initialized data way down there
is to padd my code up to that point with 'times n db 0'?
Yes. I mean, otherwise, Fasm gives you the choice to fill it with whatever you want.

Either that or DYNAMICALLY allocate those values in that memory space. No need to statically put it in the application file.

_________________
Previously known as The_Grey_Beast
Post 07 May 2009, 22:17
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< 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-2020, Tomasz Grysztar. Also on YouTube, Twitter.

Website powered by rwasa.