Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
PS:
- Addresses had to be fixed, since CS is nonzero in a DOS program.
- When debugging, everything goes fine until "retf". From there, it jumps to some random(?) address (f000:fff0)
ar5007eg wrote:The following NASM code makes Bochs reboot
I suggest you start with reading the error messages produced by Bochs. Then probably add an ORG 0x0100 directive.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
Oh, and since you are executing the retf with a 16-bit stack segment, the stack-size is still 2 bytes, you'll be popping the upper part of ebx as code segment.
Also, there's a good chance that the cause of the reboot is that you're already in protected mode. FreeDOS has a memory manager (Jemm386 or JemmEx, if you're using FreeDOS 1.1) that provides a protected mode environment and runs DOS in a V86-mode virtual machine. While its running, you can't do a raw switch to protected mode (by writing to CR0), but have to use DPMI or VCPI services instead.
F000:FFF0 is the address that the computer starts fetching instructions from when (re)booted. Given that you say that everything goes find until "retf", and that the immediately prior instruction is "mov cr0, eax", I'll give million to one odds that "mov cr0, eax" is causing a triple-fault for the reason described in the previous paragraph.
After putting ORG 0x100 and changing a few things it executes the "retf" instruction sucessfully, but jumps to (on my Bochs) 0x8:0x1FD5 when it should jump to 0x8:0x21FD5. When debugging, I see my "push ebx" instruction was translated to "push bx" (strangely, the opcode is still 53, not 6653). Besides, even if it were a push ebx, the "retf" instruction is poping 16-bit values, so I won't be able to jump to 0x21FD5 this way...
Any alternative in order to execute a "jmp 0x8:ebx"?
(thank you all for your comments)
@linguofreak No, I'm running with FreeDOS with the "Don't load anything" boot option on.
My problem is that I can't use this instruction, since CS is unknown (but certainly non zero). I have to calculate the linear address of "pmode" at runtime ((cs << 4) + pmode) but I'm having trouble jumping to this runtime address because it's a 32-bit value.
For any dumber assembler, you'll probably have to DB the prefixes/opcodes.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
My problem is that I can't use this instruction, since CS is unknown (but certainly non zero). I have to calculate the linear address of "pmode" at runtime ((cs << 4) + pmode) but I'm having trouble jumping to this runtime address because it's a 32-bit value.
At that distance it might trip the prefetch queue...
Besides, we already have a jmp far [address] to avoid the need for such bad tricks...
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
