vladstamate wrote:For a complete system yes you do. You will need to provide things like INT 13h, INT 10h, etc. Or alternatively your OS will have […]
Show full quote
videogamer555 wrote:
So does that mean that I have to manually write 256 pieces of code (one for each interrupt, as any one could be called at any time, without warning, by the underlying system), and make sure they behave in exactly the same way as the original real-mode versions of the interupts?
For a complete system yes you do. You will need to provide things like INT 13h, INT 10h, etc. Or alternatively your OS will have to provide function calls to do what those interrupts used to do (in Linux world you have IOCTL).
videogamer555 wrote:What happens if I just disable all interrupts by using the assembly language opcode CLI? Doesn't that prevent any interrupts from ever being used?
CLI only disabled IRQs. It does not disable INT xx instruction.
I think we are all missing the big picture here. What are you trying to do? Because depending on what is your goal how you set up a system before you enter PM is wildly different.
Is there a way to prevent hardware interrupts from happening (such as preventing the CPU from responding to interrupts generated by key presses on the keyboard)? And instead put the CPU in charge of explicitly polling the keyboard (via the use of IN and OUT instructions) at points in the program where keyboard input is needed? That way I could use the IN and OUT instructions in my software directly (not depending on the underlying DOS OS do to it), and therefore I can avoid the use of INT calls, as well as avoid hardware interrupts being fired by the connected keyboard (and other input devices). Therefore I can prevent interrupts from happening that could kick the program's execution out of of its valid 32bit segment (which would otherwise crash the system). Is it possible to do this, completely disable the use of all interrupts, and instead depend on the use of IN and OUT, directly from the program itself?
As for what I plan to do. My plan is simple:
Create a COM file, who's first action when run from DOS is to switch into 32bit protected mode.
Then have it run 32bit code.
It does not have any requirement of being able to switch back into real mode (which should significantly cut down on program complexity), as I intend that program then to continue to run until the computer is powered off.
Because it doesn't have any need to exit to DOS, there's no need to keep in mind that the COM file is running within DOS. It can reuse any memory that DOS previously used for its code (it can overwrite DOS code, so I don't need to be very careful about keeping DOS in tact, which should make it easier to write the COM file without restrictions).
I don't need it to use interrupts of any kind (hardware or software), because I intend to use IN and OUT to directly communicate with any other hardware (keyboard, mouse, etc).
So completely disabling all interrupts (even more thoroughly than can be done with the CLI command) would be beneficial (don't want an interrupt to kick me out of 32bit protected mode, which could crash the system), and don't want to have to bother to write 32bit interrupt code.