I've read the different modes of cpu from real to long mode. I am using protected mode to build my own kernel but i need some help regarding interrupts.

As far i as i know, one can only use interrupt while in real/unreal mode. I am really getting confused about this because according to many tutorials that i've read before, you must switch to real mode first before interrupting i/o, disks, videos and other peripherals. Does it mean that i need to switch back to real mode first before i use interrupts? Im getting confused because i dont know if switching from PM to RM and RM to PM causes crash or SLOWS down a kernel which i am avoiding to happen. Like when a applications in my OS simultaneously reads file, other one flipped page of screen buffer and the other one do other interrupts, will cpu crash when continuously switching modes? Any idea how slow is switching? or some idea to handle interupts in a protected mode kernel?

Thanks in advance

blueone: I think you are trying to run when you can't yet walk. Try to slow down and make a RM OS as a starting point. You will learn a lot about things like interrupts by doing that. Then you can progress to a PM OS. Many of the same principles will apply and you only have the incremental step of the PM layer. After that, comes the full PM 32bit drivers, they can be applied one-by-one, each device is gradually supported by a PM driver until you suddenly find you have a full PM mode OS.

However, if you really want to carry on by jumping straight to PM interrupts and others things then have a look at the DOS mode code in the fasm download. It uses unreal mode and filters the interrupts through a layer into the 16bit DOS code. Try to understand it fully before you proceed further. You will need that base knowledge to help you understand what is happening inside the CPU.

OH you again hehehe, you always respond to me fast

Yes ive just started coding a bootsector and kernel last 3 days (causes sleepless nights when i get hooked into coding kernel) and there are several things that ive knew about operating systems from MBR to multi tasking.
Frankly, i really want to make a game without relying on any program that will use VESA as its video driver, capable of reading mouse, keyboard events and reading sectors. Thats all i want but i cant get it work together. Ive coded first in RM, when ive read about VESA which can display high resolution and directly write to screen buffer, it really made me happy because i dont rely now on directdraw blahblahs until i found out you cant access 4GB addresses on it till unreal mode has enlighten my mind causes me to rewrite a kernel again. And again, the 16-bitness of it made me sad, till ive read about protected mode. Everythings okay till i found out that i cant read sectors while in protected mode which made me suffer from choosing different modes i will use in my kernel.

Can you give an advice which mode fits perfectly on my need?
Direct screen buffer access
4GB addressing space
Keyboard and mouse handling

Thank you very much~ and happy new year man~ I wait for the wonderful reply from you

If you want to rely on the BIOS to do the I/O for you then you have no choice but to use 16bit mode for that I/O. At other times, either PM or unreal will give you 4GB memory access. The only way to avoid 16bit completely is to use 32bit I/O drivers in your OS.

Ok, so does it mean i will do the switching thingys everytime i will handle the events? Ive never heard about 32bit I/O drivers regarding to kernels. Does it mean a interrupt table?

If you want to use the BIOS services then yes, they only work in 16bit mode. Sure, the GDT and IDT are the basis of the PM system. If it is done right you never have to leave PM mode. But you must use all your own 32bit code for everything like HDD, FDD, mouse, keyboard, etc.

Ooohh, do you have an idea if mode switching is SLOW or likely crash anything?

Ive read google about IDTs but im confused about what that really is. Is that a table of address to whom processor will call in case of an interrupt? I feel 80% right but i still need help if it is what i really need.

[enable a20]
[i load the idt table]
[enter PM]

mouse_handler:
draw cursor in x,y
iret

keyboard_handler:
handle keyevents
iret

Will cpu provide me the x,y coordinates in mouse handler? or ascii code in keyboard handler? where the values reside? eax, ecx or sumthing like what?

Thanks for replying!!!

You will need to study each device to learn how to do the I/O for it. They are the instructions IN and OUT. CPU won't provide you with anything except the interface to the device. It is up to you to control the device with your IN/OUT codes.

Try to do the game first,and if you find it was very easy then try to write the OS.

try to code the game before to code the os..? :-s
i think the question is not game coding or os coding...

idt, to speak human, is a table.
each element of the idt is an interupt descriptor, a 64bit structure composed by size, base, controls flieds. 8bytes or 4words or 2dwords or 1qword. that isan interrupt descriptor. 64 bit
element 0/offset 0 is int 0 ;64bit
element 1/offset 8 is int 1 ;64bit
...

ivt is the interrupt vector table and is ued under real mode.
real mode vectors are 4 bytes leng. composed by a segment and an offset
element 0/offset 0 is int 0 ;32bit
element 1/offset 4 is int 1 ;32bit
...

to call the function pointed to by the descriptor/vector, simple:
int xxx ; xxx is the interrupt number, (descriptor/vector)..
irqx ; irq is an insynchronous signal on a pin.

pm int and rm int are the same. only the addressing mode inside he code and the descriptor format are differents.

so, a pure hardcontrol, without memory access, int is exactly the same function under PM and RM

exemple:
;out dx,al function
int255: ;doesn't exists anywhere, just an exemple.
;eax=data to out
;edx=i/o port
out dx,al
iret

Heres some pointer, first you have interrupts in both real and pmode, But you can not use BIOS interrupts in pmode, unless you go back to realmode do the interrupt and than go back to pmode or set up a v86.

Now you say you want to use vesa for your games, right vesa need setting up in realmode, so you have 2 choosers
1. Set veas up to the mode you want in realmode on booting your OS, then stay in that mode when in pmode

2. Go back and forth to change modes.

Now once setup you can use vesa from pmode if you have vesa2 (most modern PC do ) because it need to support LFB.
Now you also need to load your game from the floppy or hdd, So again you have 2 choosers
1. load a small game from realmode using BIOS
2. Use unreal-mode to load a big game
3. Go to and from pmode to realmode to use BIOS int 13h function to load program
4. Write a pmode driver, so you can load program from pmode.

Now going to and from pmode to real mode will not slow or crash your game, as you only use it to switch modes, which if you want to switch's mode you only do it once at start of game and once at end of game, it will take less than a second.

I started by making bootable games its a good way to learn.
But as was pointed out, you should start by coding a game to work on a OS and try and code built in functions.

But to get you started have a look at CdPod my entry in the 512b compo, it demo high res vesa and pmode and basic GUI, plus CD player, that fits into the bootsector
of a floppy (less than 512bytes).
http://www.dex4u.com/ASMcompo512b/CdPod.zip
Also see Tomasz Grysztar bootable tetris game, that fits into boot sector (less than 512bytes)
http://www.dex4u.com/ASMcompo512b/TETROS.ZIP

PS: I was called ASHLEY4 when i made CdPod.

blueone: Just my personal opinion here, I've yet to be convinced that unreal mode has any advantage over PM. I think many people use it because it is a neat trick to play on the CPU. But it seems to give nothing extra that PM doesn't do and also it doesn't seem any easier or simpler to operate than PM. Indeed to enter unreal you have to first go into PM and then jump back to unreal. Just kind of makes we think "why bother"

My personal opinion is that you should not start with real mode, but go straight to protected mode. It's not at all hard if you let GRUB switch to protected mode for you.

That is not true. You can't use the BIOS interrupt when you're in protected more, but that's just one interrupt, not interrupts in general. (And of course, you can't use the DOS/Linux interrupt when you're making your own OS.)

Forget about the bootsector, it's a big waste of time if you want to write a kernel. (Of course, if you want to write a bootsector then it's not a waste of time, but it's take a long time before you get to your kernel then.)

That's all you want? I thought you wanted an operating system?

1. Setup VESA in 16-bit real mode
2. Switch to protected mode for 32-bit code with 4 gb addressing space

You don't want to do that. It's totally overkill.

Yes, but a bit more than the address. It also contains some other things like which segment that address is in (should of course be a code segment).


Load the IDT table after you entered protected mode.

Ok thanks for the replies. Regarding in the 32 bit hdd mouse and keyboard drivers, can anyone explain me a bit how i can access the sectors without 16bit ints of BIOS? Wats d use of IDT table? is it for drivers? After several articles ive read, i cant still get it out cuz i cant understand english very much. Thanks again.

i don't know exactlly, but, for the moment i seek a method to access via PIO and DMA

http://www.intel.com/design/processor/manuals/253668.pdf = volume 3A of 5 manuals. Thousands of pages!
Chapters 2 and 5 of volume 3A are the ones you need. In particular, section 2.4, which covers all four of the memory management registers, including, on page 17 of chapter 2, IDTR:
"...holds the base address and 16 bit table limit of the IDT"
IDT itself is described in section 5.10
Hope this helps a little.