🔒 Locked

Linux Assembler int 10h

Started by ........................................ Jan 7, 2006 at 11:35 AM 9 replies 10k views

Original Post

........................................

Jan 7, 2006 at 11:35 AM

I want to get easy Pixel acces under linux, so I tried to use int 10h with xor ah,ah ;just to get shure mov ax,13h;setting graficsmode 13, 256 colors 320x200 int 10h ;bios video int I get a memory acces error. (even when running from one of the real terminals) Does someone know whats wrong about it? the whole code is:


section .data				;section declaration

msg     db      "O_o",0xa	;our dear string
len     equ     $ - msg ;length of our dear string


section .text				;section declaration
			;we must export the entry point to the ELF linker or
    global _start	;loader. They conventionally recognize _start as their
			;entry point. Use ld -e foo to override the default.

_start:

;write our string to stdout

        mov     edx,len ;third argument: message length
        mov     ecx,msg ;second argument: pointer to message to write
        mov     ebx,1   ;first argument: file handle (stdout)
        mov     eax,edx   ;system call number (sys_write)
        int     0x80	;call kernel

	xor	ah,ah
	mov	ax,13h
	int 	10h	

;and exit

	mov     eax,1 ;system call number (sys_exit)
	xor	ebx,ebx	;first syscall argument: exit code
        int     0x80	;call kernel

nmi

Jan 7, 2006 at 11:39 AM

Linux is an operating system working in the protected mode of x86 processors. This way it can ensure that each process is separated from another and may not harm the system (i.e. by directly writing to the hardware). As a result of this, direct calls to the bios are not allowed in the form they are in real mode.

To directly access graphics memory you can try to access the frame buffer device. A much easier alternative is to use a library, such as SDL.

bytecoder

Jan 7, 2006 at 11:42 AM

10h ~~is a DOS specific interrupt~~ doesn't work on pretty much anything other than DOS. If you want to do graphics programming in linux you either have to interface directly with the hardware through the kernel using the correct mechanism or use svgalib or X11. If you're running X11, there's a good chance that's what you want; I'm not sure if you can use svgalib (or do it manually) while X11 is running.

........................................

Jan 7, 2006 at 5:19 PM

Quote:
Original post by nmi
To directly access graphics memory you can try to access the frame buffer device. A much easier alternative is to use a library, such as SDL.

thanks for the information, but I SDL really avaible through assembler? I have used it with C/C++ but didnt knew it works with assembler...

Spoonbender

Jan 7, 2006 at 5:44 PM

In principle everything is available from assembly. It's not too difficult to call a function from asm that is implemented in some other language. As long as you know the calling convention it uses, that is.

Why does it have to be in asm though?

nmi

Jan 7, 2006 at 5:51 PM

Quote:
Original post by philipptr
thanks for the information, but I SDL really avaible through assembler? I have used it with C/C++ but didnt knew it works with assembler...

I you get a pointer to the frame buffer, you can use assembler to write to the memory. Have a look at SDL_Surface::pixels.

........................................

Jan 8, 2006 at 9:21 AM

Quote:
Original post by Spoonbender
Why does it have to be in asm though?

because I want to find the fastest way to get pixel on the screen (SDL with c++ is pretty slow)

bytecoder

Jan 8, 2006 at 9:23 AM

Quote:
Original post by philipptr
Quote:
Original post by Spoonbender
Why does it have to be in asm though?

because I want to find the fastest way to get pixel on the screen (SDL with c++ is pretty slow)

SDL with assembly would be no different. Why is it you think it's slow? Are you sure you have X11 (which I'm assume you're using) configured correctly?

........................................

Jan 8, 2006 at 9:26 AM

well I always used it uner windows, and Pixel acces was always quite slow, when redrawing an entire 800*600 I got quite bad fps, especially when thinking of the fact that I was trying it with 2,8ghz (old 2d games were drawing 640*480 on 90mhz)

rip-off

Jan 8, 2006 at 9:27 AM

Quote:
Original post by philipptr
Quote:
Original post by Spoonbender
Why does it have to be in asm though?

because I want to find the fastest way to get pixel on the screen (SDL with c++ is pretty slow)

SDL and c++ work grand for me. have you ensured you get a software SDL surface as your screen? because read/writes to hardware surfaces are going to be slow.

how experienced with asm are you?

Spoonbender

Jan 8, 2006 at 3:36 PM

Quote:
Original post by philipptr
Quote:
Original post by Spoonbender
Why does it have to be in asm though?

because I want to find the fastest way to get pixel on the screen (SDL with c++ is pretty slow)

Accessing individual pixels *is* slow. There's no way around that. That's why people don't usually draw their graphics one pixel at a time.
And don't assume that asm is neccesarily faster. Unless you *really* know what you're doing, it might very well end up being a lot slower than what you write in C++. The main difference is that in C++, the compiler is there to generate code based on its knowledge of the architecture of different cpu's, the latency of instructions, and hundreds of other optimization guidelines.

*If* you know more than the compiler about all this, it may be possible to outperform it by writing in ASM. Otherwise, you'll most likely end up with a much slower version.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.