OSDev.org

• - The system will only switch back to real mode if the program's start address is under 0x8000. I thought I was not working with a 1:1 page, but after identity paging the first 0x100000 bytes, I still get the same result.
  - Bochs will throw different errors depending on what the start address and what sp is set to after switching to real mode: the closest I've gotten was the start address at 0x6000 and sp at 0x9000. However, any interrupt made to 0x10 after interrupts are restored will switch the VGA mode to 13h under Bochs, and has no result under VirtualBox. I assume this is because it's executing random code.

theseankelly wrote:Not an expert on the topic, but here's a stab at it:

In real mode, you have access to 32bit memory, but only have a 16 bit IP register. So if you try going to real mode with IP set to a 32bit address, it's going to go to the instruction at the address in the lower 16 bits -- explains why you see random instructions being executed.
[edit] just re-read your post and see that the above probably doesn't apply to what you're doing [/edit]


Also, double check the memory map for low memory as there are some restrictions as to where you can load things. Make sure what you're loading fits and doesn't start overriding EBDA and video, etc
http://wiki.osdev.org/Memory_Map_%28x86%29

RobertF wrote:- The system will only switch back to real mode if the program's start address is under 0x8000. I thought I was not working with a 1:1 page, but after identity paging the first 0x100000 bytes, I still get the same result.
- Bochs will throw different errors depending on what the start address and what sp is set to after switching to real mode: the closest I've gotten was the start address at 0x6000 and sp at 0x9000. However, any interrupt made to 0x10 after interrupts are restored will switch the VGA mode to 13h under Bochs, and has no result under VirtualBox. I assume this is because it's executing random code.

RobertF wrote:The Real Mode wiki page notes that sp should be set so that the program doesn't interfere with it—this confuses me.

turdus wrote:That's absolutely normal behavior in real mode. You have 64k segments, addressed by segment registers. I'm quite sure you didn't set ss, so it's 0, thus creates a memory window at 0-65535. Because offsets are signed values, you can use -32767..+32768 (that is 8000h in hex).
No wonder your code acts strange if you put your stack outside of the window, the pointer will be truncated and you address a different part of memory.
Solutions:
1. put your stack in the window, like before your code at 800h or 600h. It's quite common, although provides a small stack only (which should be more than enough by the way) because 4FFh is BIOS area that should not be messed up. Most boot loaders do this (stack at 800h, growing downwards, code at 800h, growing upwards).
2. set up cs (for your code), ds (for your data) and ss (for the stack), and you'll have 3 different (maybe overlapping) 64k windows.

And read this: http://wiki.osdev.org/Segmentation

RobertF wrote:No good; putting the stack inside the window still gives me errors (and sometimes I get an invalid opcode interrupt, depending on whether I test it in VirtualBox or Bochs). I've also tried setting up ds and ss (since I read that you can't modify cs, and when I do, bochs complains) for different 64K windows, but that didn't solve the problem either.

I've also remapped the PIC to its original offsets like Chandra suggested but that didn't work, either.

ret

RobertF wrote:mov sp, 0x600

lidt [RealIDT]
   
   mov eax, cr0
   and eax, 0xFFFFFFFE      ; clear pe bit
   mov cr0, eax 

Chandra wrote:

RobertF wrote:mov sp, 0x600

Plain Trouble. The most likely cause of the code failure.
Hint: Reserve some static space for the stack.

RMode:
	mov sp, stack
							
	mov ax, 0			
	mov ds, ax
	mov es, ax
	mov fs, ax 
	mov gs, ax
	mov ss, ax 

	sti						; now in real mode with proper segments—done
		
	mov ah,0x0
	mov al,13h				; 40x25 text mode 
	int 0x10
[section .bss]
stack:
	resb 0x600

RobertF wrote: What I changed (along with your other suggestions):

Code: Select all

RMode:
	mov sp, stack
							
	mov ax, 0			
	mov ds, ax
	mov es, ax
	mov fs, ax 
	mov gs, ax
	mov ss, ax 

	sti						; now in real mode with proper segments—done
		
	mov ah,0x0
	mov al,13h				; 40x25 text mode 
	int 0x10
[section .bss]
stack:
	resb 0x600

I feel like I'm missing something very very simple here.

[section .bss]
             resb 0x600   
stack:

theseankelly wrote:Also I'm a little confused as to why everyone thinks the stack is the problem. I agree it will be eventually, but the code shown that's failing doesn't actually use the stack yet right?

int 0x10

ret