Recent Posts

1

Programming with NASM / Re: how to switch video modes (switching to VESA video modes too) in protected mode

« Last post by fredericopissarra on May 17, 2019, 12:29:30 PM »

I read it, and it seems to that it can work properly, but can you please tell me how to do it in C language?

I could, but I thought this forum was about assembly language, isn't it?

2

Programming with NASM / Re: how to switch video modes (switching to VESA video modes too) in protected mode

« Last post by lukassevc on May 16, 2019, 03:58:44 PM »

http://www.petesqbsite.com/sections/tutorials/tuts/vbe3.pdf

See "Obtaining the Protected Mode Entry Point", page 21 -- this is NOT available in all implementations and I was never been able to make it work properly...

I read it, and it seems to that it can work properly, but can you please tell me how to do it in C language?
Thanks!

3

Programming with NASM / Re: how to switch video modes (switching to VESA video modes too) in protected mode

« Last post by fredericopissarra on May 16, 2019, 11:43:33 AM »

http://www.petesqbsite.com/sections/tutorials/tuts/vbe3.pdf

See "Obtaining the Protected Mode Entry Point", page 21 -- this is NOT available in all implementations and I was never been able to make it work properly...

4

Programming with NASM / how to switch video modes (switching to VESA video modes too) in protected mode

« Last post by lukassevc on May 16, 2019, 06:23:51 AM »

Hi, I am Lukas,
and I am writing my operating system but I have problem with switching video modes ( switching to VESA modes too ) because I don't know how to do it and I don't found any tutorial on it so I need help. I know that in real mode it can by done by using ah = 0x00 and with interruption 0x10, but I am in protected mode so I don't know how to do it. Can someone help me please?
Thanks for any help!

5

Summer of Code Ideas / Re: Nasm is still quite stupid enough

« Last post by Frank Kotler on May 10, 2019, 11:58:46 PM »

Hi uncle Richard,

Welcome to the forum.

I am terribly sorry you had trouble with Nasm.

Best,
Frank

6

Summer of Code Ideas / Re: Nasm is still quite stupid enough

« Last post by uncle Richard on May 10, 2019, 09:32:56 AM »

Three days have passed. But H. Peter Anvin, Cyrill Gorcunov, Chang Seok Bae, Jim Kukunas, Frank B. Kotler are silent. So. The main problem with Nasm is that it does not have a linker. And if it is not needed in Linux, in Windows it is absolutely necessary. TCC is a C compiler and a satisfactory linker for the elf format, simultaneously. But no one can guarantee on how correct this TCC is.

A bunch of Gcc+Yasm+TCC brings a result of 87, too. Thus, Gcc and TCC can be defective, and Nasm can be normal. The earlier Nasm will acquire its own linker and IDE, the better. Fasm popularity is the best proof of this.

It should be only one regret. MSVC, GCC, TCC, DmC, Pelle C, PCC, NASM, FASM, YASM, GOASM, UASM, MASM are excellent compilers, each in its own way. And this is good. The bad thing is that they are completely incompatible with each other. Even at the 'Hello World' level. And they will not.

Pelle C is closest to me. I wrote a small converter Pelle -> NASM + TCC. Everything works, except comm variables. Even Agner Fog does not know what to do with them.

7

Programming with NASM / Re: [Solved] short jump with relative offset

« Last post by bfr on May 10, 2019, 09:04:01 AM »

Thanks for clarifying, I didn't fully appreciate how much work NASM was doing and that this would be interfering with that.

Since the size of the jump is sensitive to optimization, I've switched to using labels. And I've got a much clearer idea of how this all works, thanks to you and Frederico. Much appreciated!

8

Programming with NASM / Re: short jump with relative offset

« Last post by ig on May 10, 2019, 08:52:48 AM »

I'd put it this way - you are "interfering" with nasm's job (you are doing part of the compilation yourself and trying to make it accept your computation of the offset as part of its internal work).

If you want to force a specific (pre-computed, pre-compiled) instruction into the code, you can just use

Code: [Select]

db 75h, 20h- and you'll have the short "jne" instruction jumping forward by 20h bytes (bypassing nasm altogether for that instruction).

Or, use the $+0x20 expression - so that nasm knows that you are binding the target to the current address; that's basically what you are looking for. Pure "jne 0x20" is, IMHO, just bad syntax - meaning something different from what you want.

9

Programming with NASM / Re: short jump with relative offset

« Last post by bfr on May 09, 2019, 09:40:35 PM »

Ah, I see, that makes a lot of sense. So the only way to produce a short relative jump instruction is to jump to a nearby explicit address, or to use an offset relative to RIP. There's no way to write the short relative jump explicitly and have NASM interpret it as such? Thanks very much!

10

Programming with NASM / Re: short jump with relative offset

« Last post by fredericopissarra on May 09, 2019, 01:43:50 PM »

Notice NASM will optimize your code by default (-Ox, multipass optimization), so, instructions as:

Code: [Select]

mov rax,0Will be encoded as

Code: [Select]

mov eax,0Without the REX prefix... If you want your code to not be optimized, use -O0 option.

ALL jumps are relative (to RIP), including CALL and JMP instructions, except when absolute jumps are explicit made or indirect ones... In optimized compilation, NASM will try to select shorter instructions, so your conditional jump will use a signed byte offset.

To use an explicit value is dangerous because of optimization. But it seems NASM is wise enough to recalculate it...