Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
hi everybody,
I am writing my own OS. But i am kinda tired of writing my own display and keyboard routines cos i am a little lazy.
So once my OS is in protected mode, i am thinking of using the 'made for real mode' BIOS interrupts to do display and other misc routines. I am struck with it cos i am not finding a way to do so.
By the way my OS just boots into protected mode with just a basic IDT and GDT and a stupid kernel.
So i would be thankful if someone could help me out in using BIOS interrupts in Protected mode.
grey wolf wrote:
if you're set on it, you can drop to unreal mode briefly, call the int, then go back to pmode. it's slow, but it works.
This has a drawback in addition from being slow: you completely ignore protected-mode interrupts while being in unreal mode. in a multitasking kernel, this means that you won't be able to switch to another task while waiting for the floppy, for instance, just because the IRQ0 is delivered to real-mode handler rather than to your pmode handler...
Speaking of writing your own drivers....does anyone know of a really EASY TO USE floppy driver? It's a
sham that INT 13h is soooooo nice but we can't
use it from PMODE. I've seems that lots of small OS's
load a floppy image into RAM, then switch to pmode,
then NEVER use the floppy drive again. That's the
easy way out. I would like some ASM code that
will let me read/write sectors without worrying about
weather to turn the drive motor on/off!!
It's so funny that accessing hard drives is so simple!
Just a few OUTs and INs and you've got an LBA sector
loaded or saved.
yes, but dosnt the driver itself have to call the interrupt? or maybe im just confused on interrupts. every time a keys pressed, the kbd interrupt notiifes the processor right? through the IRQs, so how exactly woudl drivers work if interrpts are disabled?
software ints (like 13h and 16h) are real-mode code and so are unusable in pmode. the keyboard interrupt causes the CPU to call a software interrupt, which you must write your own handler for, if i understand the situation correctly.
There is only one kind of interrupt. When an interrupt happens, the handler gets called. End of story.
Interrupts can come from one of two places: software or hardware. Software interrupts are generated by the INT instruction; hardware interrupts come from the hardware (obviously). Software interrupts are usable from both real and protected mode: for example, the BIOS and DOS API sets are accesses through software interrupts. NT and Linux also use interrupts in their core system calls, although they are wrapped by user-mode routines.
Interrupt requests (IRQs: 0 to 15) from the hardware are mapped to CPU interrupt numbers (0 to 255) by the Programmable Interrupt Controller (PIC). The IRQ number depends on the hardware in use, whereas the interrupt number depends on the IRQ and on how the PIC is set up. It's a bad idea to have hardware and software interrupts going to the same CPU interrupt number.
This floppy driver handles the floppy drive controller interrupt (IRQ 6). It does not use any software interrupts, since (on the software side) it is programmed using normal function calls.
hey anybody has any info on how DOS (with BIOS int) programs run without any problem in Windoze series of OS.
is it doing something like this? it goes like copying the whole first 1MB somewhere in memory before going in the protected mode. Then go into the protected mode. whenver a bios int is called this 1MB is loaded as a V86 segment and executed with help of DOS as a V86 monitor. ???
anubis wrote:
Hi,
firstly thanks all for the replies.
hey anybody has any info on how DOS (with BIOS int) programs run without any problem in Windoze series of OS.
hum, if you wipe the real-mode interrupt vector table of a DOS box, windows 9x gets hung ... i would *not* callthis "any problem".
but this is roughly how it goes: creating a mapping of 1st megabyte (usually with copy-on-write protection and using it in v86 mode
