multitasking os in real mode?

[black.fish]

just a simple question: is it possible to write a multitasking os in real mode?

[Tom]

yea, (look at crazybudda.com )

but it'd be sorta outdated ( PMode is better )

PMode allows you to control all the computer, so you can make functions that stop the computer from freezing on errors.

http://my.execpc.com/CE/AC/geezer/os/

[Schol-R-LEA]

This has been an issue I've been stuggling with for a while now.

It had been my intention that LoIS be entirely a real-mode project, as it would involve less work in preparing each of the separate examples. Also, I am of the opinion that a understanding the peculiarities of how 32-bit protected mode works requires first having a grasp on the real-mode mechanisms the are meant to replace (and, to some extent, the 16-bit protected mode system that they are a modification of). Finally, despite the confusion that is usually engendered by the segmented memory model, most real-mode system mechanisms are far simpler and easier to understand than their p-mode equivalents (e.g., setting up the IVT vs. setting up an IDT).

However, while this approach works well enough for examples which can be demonstrated more or less independently from each other, or ones which building upon other simple examples - screen manipulation, adding an interrupt vector to the IVT, keyboard and mouse drivers, etc. - it presents serious problems when moving on to a completed project. I'm increasingly wondering if I should skip the later parts of LoIS entirely and move ahead to GLOAT (GRUB Loader Tutorial, a minimal 32-bit operating system meant as a continuation of the LoIS tutorials). Is it worth the trouble to do all this work in real mode, only to have to do it over again in p-mode? I'm not sure any more.

[black.fish]

One more question: I know that I can't use BIOS Interrupts in protected mode, but can I use my own interrupts? (I just wrote my own descriptor table into memory.) And: Is there any good tutorial about activating protected mode with sample sources?

black.Fish

[Tom]

The FritzOS Bootloader loads PMode, has a nessasary GDT, and loads it's C Kernel.

You can just c/p the GDT and PMode stuff from my OS.
You will also need to c/p the jmp's.
To know if you are in pmode, after setting the cr0 register, put in a jmp $
and see if the numlock key works. If if does NOT work, you are in PMODE!

[mrd]

the BIOS is mostly intended for real mode, however there are a few exceptions of BIOS routines designed for pmode.

the BIOS, on boot, installs its own interrupt handlers in the IVT (Interrupt Vector Table). the IVT is just a table containing pointers to interrupt handlers, whose base address is at 0. you can rewrite in it to point to your own handler.

when operating in protected mode, however, the IDT (Interrupt Descriptor Table) is used for interrupts. as soon as you switch the CPU to pmode, the CPU uses the IDT instead of the IVT for interrupts. the IDT is a table of descriptors, each of which contain a pointer to a handler and some flags.

[elis-cool]

Hmmn... could some one please explain to me the differences between the IVT and IDT? I was under the impression you could use the terms interchangably... also whats the GDT?

[The Legend]

IVT = Interrupt Vector Table, not really more then simply an array of addresses to jump to when the CPU hits an INT-Instruction in real mode.

IDT = Interrupt Descriptor Table, the same for protected mode, but contains an array of interrupt descriptors which are more complex.

GDT = Global Descriptor Table, contains an array of segment definitions for the CPU in PMode.

[eliscool]

So how are they more complex?

[PlayOS]

I think because an IVT entry is just an address to a handler and an IDT entry is an address, attributes and descriptor. This makes them more complex, not neccesarily harder to understand, just complex.

[Pype.Clicker]

the IVT just holds <segment:offset> pairs that will be loaded by the CPU on interrupt. you can easily reprogram an interrupt by just setting [vector]<-new_offset; [vector+2]<-new_segment (if i remember well... check the docs, i haven't work in real mode from ages)

the IDT basically hold the same kind of information, but it can deal with 3 types of entries (and thus the type is encoded in each entry):

• interrupt gate : you just define the segment & the offset according to the gate descriptor format of the GDT (thus the 32-bits offset is split in 2 parts
• trap gate : defined the same way as an interrupt gate, but it does something more with the "retry" flag, a.f.a.i.k. (i should read back Intel Manuals about it
• task gate : just give a TSS identifier and that task will be run when the interrupt occurs. this is mainly useful for panic conditions such as kernel stack overflow or task fault where a classic handler can't work because of corrupted CPU state ...