16 bit Assembly Looping

[Alboin]

Hello,

I'm reworking my boot loader, and have run into a probably simple problem. I'm working on some code to setup my long mode paging tables in real mode. (I'm using Brendan's shortcut.)

Code: Select all

mov ebx, 0x100000
mov ecx, 0x100
lp:
        mov eax, ebx
        or eax, 3
        mov dword [ecx * 8 + TABLE], eax
        sub ebx, 0x1000 
        loop lp

This is supposed to identity page the first mg of RAM for my entrance into long mode. However, it loops continuously. In the Boch's debugger, it goes from the 'mov dword' line to an iret, back to the mov dword, and likewise for infinity.

I'm not sure why Boch's is popping an iret command in there....

What am I missing?

Thanks,
Alboin

[pcmattman]

Perhaps it's one of the default interrupt handlers that Bochs installs at boot? Some of those are just dummy ISRs with only an IRET opcode, so if something is faulting in that code then you'll be pointed to a dummy ISR.

[Alboin]

That would make sense, but how could:

Code: Select all

mov dword [0x9d000], eax 

cause a fault in real mode?

[pcmattman]

That is an excellent question.

Maybe look at the bochs log and see what happens (or change the config and turn on debug mode in bochs, it'll print out in the bochs log all sorts of information about the run).

[Alboin]

Yeah, I've got the debugger compiled in and all, and I've stepped through the code. (That's how I figured out it crashes at the move.)

Bochs doesn't crash, so there's not much in the bochsout that I didn't know by stepping through. I doesn't get past the first loop.

[pcmattman]

I meant, via the config dialog box when bochs is actually running, turn on full debugging in the log for all devices. Then you can step through and when the first IRET comes up quit bochs and look at the log for any information about exceptions and the like.

[SpooK]

Hello,

I'm reworking my boot loader, and have run into a probably simple problem. I'm working on some code to setup my long mode paging tables in real mode. (I'm using Brendan's shortcut.)

Code: Select all

mov ebx, 0x100000
mov ecx, 0x100
lp:
        mov eax, ebx
        or eax, 3
        mov dword [ecx * 8 + TABLE], eax
        sub ebx, 0x1000 
        loop lp

This is supposed to identity page the first mg of RAM for my entrance into long mode. However, it loops continuously. In the Boch's debugger, it goes from the 'mov dword' line to an iret, back to the mov dword, and likewise for infinity.

Perhaps because it is performing an INT.

I'm not sure why Boch's is popping an iret command in there....

Contemplate the following...

Code: Select all

;The 32-bit Protected Mode code you wrote...
mov dword [ecx * 8 + TABLE], eax

;How it equates to the CPU in 16-bit Real Mode...
add [bx+si],al
mov [si],ax
int 0

What am I missing?

Thanks,
Alboin

[BITS 16], for starters...

[Alboin]

[BITS 16], for starters...

Don't get saucy with me mister. Besides, it's use16. (My code was just a snippet.)
...
I believe that I have discovered my error.

I failed to recall the real mode segments and such, and in due course, received an error.

Now, I have the following, and it seems to accept it.

Code: Select all

mov ax, 0x9000
mov ds, ax
mov [ds:ecx * 8 + 0xa000], eax

I've come to believe that the segment for the abs. address of 0x9a000 is 0x9000. (eg. 0x9000:0xa000) Am I correct here? (0x9000 * 16 + 0xa000 = 0x9a000)

[Combuster]

I think the underlying reason is here that you aren't in Unreal Mode and segments are limited to 64k, while your first snippet did expect that.