Back to real mode [SOLVED]

[Karlosoft]

@DavidCooper This is what I did. I am in real mode now, the problem is the BIOS and its interrupts. Is possible that the BIOS was using APIC and I have to disable the PIC?

@Combuster It could, but why all the other interrupt doesn't work? The pit for example is on the first irq line and has a greater priority of any other. Isn't so?

[DavidCooper]

@DavidCooper This is what I did. I am in real mode now, the problem is the BIOS and its interrupts. Is possible that the BIOS was using APIC and I have to disable the PIC?

Why would you want to disable it? The BIOS hands control to you with the PIC set up in a particular way and functioning, and it isn't going to be surprised if you call it again with the PIC in that same state. If calling the BIOS works fine when you make a BIOS call early on before you're changed anything, it should still work fine after you've changed something just so long as you've changed it back. There may be some things at some advanced level that can't be changed back, but if so, I don't know what they are - I'm sure someone else will be able to tell you if you can pin down the point where you're making a change that doesn't appear to be possible to put back properly. If something requires real mode interrupts to run every now and again to maintain its functionality, you can test that just by disabling the interrupts and running a long delay loop, but I'd be very surprised if that causes anything to fail. Switching to protected mode and back should be no different from that, even if you then run protected mode interrupts for a time in the middle, just so long as you put everything back the way it was.

You're not being very clear about this ("This is what I did. I am in real mode now..."), so perhaps you could clarify a couple of things:-

1. Do BIOS calls work properly (meaning without making the machine unstable) when the BIOS first hands control to you. I very much doubt that the answer to this question is no, because that would be a s*** BIOS.

2. Do BIOS calls go wrong (meaning that the machine becomes unstable, freezing or crashing) after you've run some of your own code to change the way the machine is set up and then to try to put it back the way it was before calling the BIOS. The answer to this is presumably yes or you wouldn't have a problem.

So, the task is to work out what is it that you're changing and then failing to put back properly when returning to real mode. Have you followed the instructions in my previous post systematically to try to find the point where something you change and then change back results in the machine becoming unstable when you next call the BIOS? If you have tried this properly and the point where it goes wrong is too fuzzy to pin down, please spell that out rather than leaving everyone guessing. Have you found a specific point before which it always works and after which it starts to go wrong? Is there a specific point after which it always goes wrong? What are the changes you've made between those points?

You or someone else may suddenly spot the bug just by staring at code, but it's just possible that it's a rare BIOS bug like the one on my netbook that requires BP and SP to hold similar values, in which case the bug may not be in your code at all. Either way, your best bet for tracking it down is to do the tests systematically to try to isolate the point or zone where the problem is triggered. It should take two days work to do that at the most, and once you've done it you should be able to provide very specific details as to what it must be that's unsettling the system, at which point someone here should be able to tell you how to fix it (or that you're doing something that can't be reversed).

[Karlosoft]

I tested the situation on three computers, my newer, my old siemens of 1994, the virtual box emulator.
The results are the following:
1) Simple real mode piece of code without BIOS interrupts worked on every computer in every place (the place are described in the next paragraph)
2) Simple real mode piece of code with BIOS interrupts failed on the emulator and on the newer computer giving the same result. Some of the functions I called will surely use the interrupts other won't. The result is the same. It works in all the situations on my old laptop

I tried to locate the call in many points of the kernel, even in some exernal modules it loads.
It never works on the emulator and on the newer pc even if I locate the call very early next the GDT init code.

The machine isn't unstable and doesn't crash. It simply doesn't call the BIOS interrupts.

I will try to change the bootloader in order to see if it is Smile Loader which calls the kernel destroying some important data. I'll try to execute a real mode program loaded from it

[DavidCooper]

I will try to change the bootloader in order to see if it is Smile Loader which calls the kernel destroying some important data. I'll try to execute a real mode program loaded from it

So you've only done the tests after your bootloader has run and the BIOS calls don't work after that. That does point the finger at your bootloader, so you need to try calling the BIOS from various points in that until you find out what it's corrupting. I assume you're doing that now. Hope you find it soon.

[Karlosoft]

I can't understand, the bootloader works. I tried to write a small program in assembly 16bit real mode. It is loaded and the bootloader jumps to it without problem. The execution is good in all the computers. Now the problem could be a piece of code coming from the C++ compiler.. I'll disassebly it to see...

[turdus]

Actually, because segment registers are 16-bit, for "mov ds,eax" the CPU only uses AX anyway, and Intel say that "mov ds,eax" is better/faster for 32-bit code because it avoids the need for the size override prefix.

You're right, but he/she uses 16 bit mode, right after label "start:" there's a "[bits 16]". So size override prefix will be needed for "mov ds,eax". But since it's executed in pmode with 32 bit code segment, the prefix could make trouble.

[Karlosoft]

Solved thank you everyone

[DavidCooper]

That's good news. Was the compiler to blame, and if so, what was it doing that caused the problem?

[Karlosoft]

The problems seem to be the GDT and the IDT. Their. When I return in real mode it seems that the segment of GDT aren't correctly loaded. I solved saving the status of both with SGDT & SIDT.
Now it works on every computer

[DavidCooper]

The problems seem to be the GDT and the IDT. Their. When I return in real mode it seems that the segment of GDT aren't correctly loaded. I solved saving the status of both with SGDT & SIDT.
Now it works on every computer

I wouldn't have thought you'd have to do that for the IDT as you're automatically going to put it back into the exact same form as it was when the BIOS first handed control to your bootsector, but I had wondered if any BIOS ever sets up a GDT for itself and expects it to be preserved. I'll need to modify my own OS to guard against that.