flat assembler
Message board for the users of flat assembler.
Index
> Main > hello everone.this is fasm complie boot.asm error |
Author |
|
DimonSoft 19 Aug 2018, 19:05
You’re writing 16-bit code in that place. In 16-bit real mode address can only be 32 bits (16 bits for segment index, 16 bits for offset). Your jump uses the 0x90000 constant which is outside 16-bit integer range and thus cannot be encoded in this mode.
See 2.1.6 in FASM.pdf for description of pword that might help here. Never tried it though since I find using 32-bit encodings in 16-bit mode (i.e. mixing 16 and 32 bits) a bit weird. P.S. Note also that you have some redundant instructions in your code like, say, jnc followed by two jc’s. |
|||
19 Aug 2018, 19:05 |
|
kerr 20 Aug 2018, 13:31
DimonSoft wrote: You’re writing 16-bit code in that place. In 16-bit real mode address can only be 32 bits (16 bits for segment index, 16 bits for offset). Your jump uses the 0x90000 constant which is outside 16-bit integer range and thus cannot be encoded in this mode. If you compile with NASM, it's fine, but CR0 can't run virtual machine here. _________________ I hope we will be good friends. |
|||
20 Aug 2018, 13:31 |
|
DimonSoft 20 Aug 2018, 15:25
kerr wrote: If you compile with NASM, it's fine, but CR0 can't run virtual machine here. I don’t see how a control register can “run virtual machine”. My guess is that NASM just truncates the constant silently. Which is a bad behaviour. And this may explain why something goes wrong in runtime. |
|||
20 Aug 2018, 15:25 |
|
kerr 22 Aug 2018, 14:27
DimonSoft wrote:
I mean that the virtual machine was wrong when it ran to CR0. _________________ I hope we will be good friends. |
|||
22 Aug 2018, 14:27 |
|
DimonSoft 22 Aug 2018, 18:08
kerr wrote:
How did the “wrong” state manifest itself? |
|||
22 Aug 2018, 18:08 |
|
kerr 23 Aug 2018, 02:51
DimonSoft wrote:
A critical error has occurred while running the virtual machine and machine execution has been stopped. _________________ I hope we will be good friends. |
|||
23 Aug 2018, 02:51 |
|
DimonSoft 23 Aug 2018, 07:08
So, why are you sure it was caused by access to CR0, not by the JMP?
|
|||
23 Aug 2018, 07:08 |
|
kerr 25 Aug 2018, 13:58
DimonSoft wrote: So, why are you sure it was caused by access to CR0, not by the JMP? I found it through debugging. _________________ I hope we will be good friends. |
|||
25 Aug 2018, 13:58 |
|
DimonSoft 25 Aug 2018, 17:01
kerr wrote:
There seems to be nothing wrong with access to CR0. I think you should double-check what you really see. Does VBox stand for VirtualBox? I don’t remember it to have built-in debugger. |
|||
25 Aug 2018, 17:01 |
|
kerr 06 Sep 2018, 16:41
DimonSoft wrote:
is windbag + vbox found it _________________ I hope we will be good friends. |
|||
06 Sep 2018, 16:41 |
|
DimonSoft 06 Sep 2018, 18:29
kerr wrote:
Found some time to give your code a try. A few notes… 1. The hlt instruction inside print procedure seems strange. 2. I’ve already mentioned the duplication of jc instruction. It is used after print procedure for some reason. I wouldn’t rely on FLAGS being preserved by a BIOS call due to lots of buggy BIOSes out there plus your implementation might change later to some piece of code that would overwrite FLAGS. 3. Base address of your kernel code and data segments is set to 0xC0000000 but the code you load is somewhere near 0x90000. Changing the base to zero makes it work right (although you’ll see an exception soon after your protected mode code starts to execute). No problems with writing to CR0 are seen in Bochs. Maybe your toolset lies to you. |
|||
06 Sep 2018, 18:29 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.