OSDev.org

Hi guys

I am currently writing a Pascal OS. The problem is I have run into a problem that frustrated me so much that I rewrote all my code. I was using Brans Kernel Dev tutorial and converting it to Pascal.

The problem is that sti AND IRET functions do not return to the code that executed them. I first though it was a stack problem but enlarging that never helped. I then removed all drivers and Paging so my kernel was left with a console, keyboard, timer, ISRs, GDT, IDT. It works on BOCHS perfectly but it doesn't work on my PC. I was wondering if I could ask some who has experience in pascal if they could either send me their copies of those implementations (for comparison only) or if they could see if they can find the error in my code.

Thanks

Could you send, here, a full floppy image of your OS with drivers etc and a simple "error" command that would generate the STI and IRET? I will test it on two computers and three emulators if you like.

I think PASCAL procedure has stack frame like this I don't know if there is an interrupt in pascal like C
e.g void interrupt foo(){;}

but the problem may be around stack frame not in stack size
if you use procedure to generate interrupt

CAN you post that crashed-part of your kernel

Cheers
Ahmad T. Dajani

STI and IRET? Do you mean INT and IRET?

No INT works fine. I mean STI and IRET. you see after i do It never executes what comes after the end, which is the rest of the kernel. If I put an int 55 (Calls my ignore int function) after sti then the int executes but it still does not return to the code after the end; my kernel code and bin file can be obtained from http://code.google.com/p/gizmicos/downloads/list

Use Bootable.exe to install Boot1.bin to the boot sector of a floppy. Then copy Kernel.bin and Loader.bin to the Floppy.

@Inflater: Please check if they work and let me know. If they work you should see a blank screen with a Blue header saying Gizmic OS 0.02. I know it works on Bochs.

Just wondering if anyone has tested this yet?

System123 wrote:No INT works fine. I mean STI and IRET. you see after i do

Code: Select all

asm
sti
end;

It never executes what comes after the end, which is the rest of the kernel. If I put an int 55 (Calls my ignore int function) after sti then the int executes but it still does not return to the code after the end;

It sounds to me like you enable interrupts, then an interrupt fires, and you get stuck in your interrupt handler.

I thought so too but when I run it in bochs no int fires. I used the debugger to check. If I forget the iret at the end of my ignore int function then it returns properly and contiues executing until an int fires. Which is correct. However my sti function never returns even if no IRQ's are installed. I have tried everything I can think of to find the problem

Well, have you single-stepped through the STI function in bochs, to see where execution's going?

Yes I have. But like I said everything works correctly in bochs. it does sti and then it carries on executing like its eant to. There are no errors or obscure interrupts firing.

Hi,

If something works on Bochs but not on real hardware, I always wonder whether it is to do with an uninitialised variable - a loop counter? Something in the IDT creation or PIC remapping code?

It could be that your real PC has a device which is causing an interrupt that Bochs does not have. Unfortunately, I have no Pascal experience and the error could be anywhere (not too helpful, I know!).

Could you perhaps find out what interrupt is firing by printing something during your ISR (or even print to the COM port if you have the correct hardware)? What about other emulators - try Qemu or VPC and see if it replicates your Bochs or real hardware experience.

I can guarantee that STI by itself is not causing a lockup.

Cheers,
Adam

Hello , you may read a source of TORO http://toro.sourceforge.net, version 1.1.3 has a full Interruption manager , you can use it to compare wit your source , Toro 0.03 has a complete interruption manager but in 64 bits amd processor. Be careful if you are declaring a procedures as
procedure handler;interrupt;
in last version of FPC this head is ignore , and opcode of IRET is bad , you must write an opcode directly in assembler statement.

Saludos.

Thanks I will have a look through it all again. I am sure it is just something small and stupid