Index
> Main > Seeking alternate methods...Goto page Previous 1, 2 |
| Author |
|
|
revolution 05 May 2009, 17:32
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. |
|||
05 May 2009, 17:32 |
|
|
bitshifter 05 May 2009, 17:37
Could you please modify the code as you say and post it?
I having a hard time understanding words, code is better... |
|||
|
05 May 2009, 17:37 |
|
|
bitRAKE 05 May 2009, 22:51
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 |
|||
|
05 May 2009, 22:51 |
|
|
bitshifter 06 May 2009, 01:10
Hello bitRAKE
Thanks for the code!  *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. |
|||
|
06 May 2009, 01:10 |
|
|
bitRAKE 06 May 2009, 03:15
1) Your understanding is correct. Stack can be moved:
Code: org $100 ...some initialization code mov sp,MainLoop MainLoop: ...  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 |
|||
|
06 May 2009, 03:15 |
|
|
bitshifter 06 May 2009, 04:04
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. |
|||
|
06 May 2009, 04:04 |
|
|
revolution 06 May 2009, 04:17
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.
|
|||
|
06 May 2009, 04:17 |
|
|
bitshifter 06 May 2009, 04:30
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. |
|||
|
06 May 2009, 04:30 |
|
|
revolution 06 May 2009, 04:33
|
|||
|
06 May 2009, 04:33 |
|
|
bitshifter 06 May 2009, 04:40
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... |
|||
|
06 May 2009, 04:40 |
|
|
Borsuc 06 May 2009, 21:06
Code: mov si,g_hello For example: Code: virtual at $ lol db 'LOL',0x00 end virtual wtf db 'WTF',0x00 Code: push lol call print this would be the exact same thing: Code: push wtf call print |
|||
|
06 May 2009, 21:06 |
|
|
bitshifter 07 May 2009, 02:02
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. |
|||
|
07 May 2009, 02:02 |
|
|
bitRAKE 07 May 2009, 02:49
Only $FF00 bytes are loaded of a COM file. I haven't tested it, but it seems logical.
|
|||
|
07 May 2009, 02:49 |
|
|
Borsuc 07 May 2009, 22:17
bitshifter wrote: So the only way to put initialized data way down there 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 |
|||
|
07 May 2009, 22:17 |
|
| Goto page Previous 1, 2 < Last Thread | Next Thread > |
Forum Rules:
|