What is the CS and IP after the jump far?

Are you sure you are not supposed to have the base0 as 0x1FE instead of 0x1FE0? The address calculation will take that base shift it left by 4 and then add the offset. Looks like you are preshifting it in the GDT.

vladstamate wrote:

What is the CS and IP after the jump far?

Are you sure you are not supposed to have the base0 as 0x1FE instead of 0x1FE0? The address calculation will take that base shift it left by 4 and then add the offset. Looks like you are preshifting it in the GDT.

Yes. I'm sure it is supposed to be pre-shifted. If it's not preshifted, it ends up in the wrong location immediately after the jump. I've tested this already in the DOSBox Debugger.
If it is pre-shfited, it ends up in the CORRECT location immediately after the jump. However, the moment it tries to execute the next line of code (which is itself not a JMP instruction) it magically does another jump somewhere else, and of course the program crashes after that.

So still, nobody has given my code a thorough look-over? I need somebody to tell me what's wrong with it.

Try stackoverflow. At least there's a reward in virtual points for looking at other people's buggy code 😉

ripa wrote:

Try stackoverflow. At least there's a reward in virtual points for looking at other people's buggy code 😉

I doubt that most people even know about old DOS stuff like this. DOS exclusive forums like vogons is my only hope.
Please, just look over my code. I've got a sense that I'm VERY close to the correct code, as it's already mostly doing what it should (and may even simply be an issue involving the difference between DOS Box, and real DOS computers). So I'm guessing I'm only going to need to make a few tweaks. Can you please look over my code and tell me what's wrong with it?

Few questions:

1) How are you debugging this code? Are you using DOS debug.exe? Can you single step the code?
2) If you are single stepping, or at least put a breakpoint at the code AFTER the jmp far, can you show us what the debugger thinks it is at that line of code (including the address)?Try -u command.

im relatively certain that you cannot view in debug a transition from real to prot mode; i can tell you that for me it was the GDT definition that caused the most trouble - copying sample GDT from wiki might help?

Yes I know you cannot single step the code between mov cr0. ax and the end of the jmp. Because INT 3 will not work due to IDT not working properly. I was hoping he can put a breakpoint AFTER that.

But yes, your advice is good, trying an unmodified example known to work first is a good idea.

You could also try debugging in VirtualBox or some other VM:
https://www.virtualbox.org/manual/ch12.html#ts_debugger

didnt dosbox have some slow stepping mode? or was that bochs maybe? simics certainly does but its commercial i wouldnt even know if it can be had still

regarding the debuggin: i believe theres another problem: after the switch the code that actually outputs the values in registers etc might not work anymore? it is not adjusted to the new memory addressing scheme in my understanding; maybe im wrong here? ill admit i stopped doing this stuff shortly after reaching simple prot mode functionality;

ripa wrote:

You could also try debugging in VirtualBox or some other VM:
https://www.virtualbox.org/manual/ch12.html#ts_debugger

sexy find! wil lthis work with the system debugger only or can all/most debuggers connect like that?

I'm not sure what you mean and I haven't used VirtualBox debugger myself, but I suggested a VM debugger because it shouldn't have any limitations w.r.t debugging transitions between CPU modes because it doesn't rely on patching the code like INT3.

From where did you get the value 0x1FE0? It's not correct, at least for the DOSBox that I'm using. In my copy, it's 0x1950, and then the Loop label is reached.

In any case, what you need is
Mov eax, cs
Shl eax, 4
Mov [], eax ; wherever you have the hard-coded value

When I was playing with this kind of stuff I found the bochs debugger more useful than DOSBox's.

peterferrie wrote:

From where did you get the value 0x1FE0? It's not correct, at least for the DOSBox that I'm using. In my copy, it's 0x1950, and then the Loop label is reached.

its not documented as a stale value, so one should never assume the value but rather calculate it;

;Switch into 32bit protected mode by doing a far jump
jmp 0x0008:FinalizeProtMode

Shouldn't it be

1jmp dword 8:FinalizeProtMode

?

If I remember correctly, you need to fill all 32 bits of EIP, so the jump instruction should have 0x65 prefix to force 32-bit addressing. Otherwise you're writing only to IP, which is low 16 bits of EIP, and when the 32-bit mode kicks in, garbage in high 16 bits of EIP results in "misjump".

Or so I think.

;Switch into 16bit protected mode mov eax,cr0 or eax,1 mov cr0,eax […]
Show full quote

;Switch into 16bit protected mode
mov eax,cr0
or eax,1
mov cr0,eax

This is not "switching into 16bit protected mode", this is enabling protection. Whether it will be 16 or 32-bit depends solely on the segment you're jumping to in the very next instruction.

The jump is not the problem, the code is already correct.
The problem is the hard-coded value, which should be calculated by the "shl,4" code that I showed.