Implementation of SachOS(Part 05)
Greetings and welcome back to the exciting 5th step of building SachOS! My guess is that you’ve been following along with me up to this point.
I’m following the Reference Book “The little book about OS development” by Erik Helin and Adam Renberg. For this week, covering up all the previous lessons is a must!. You can Read Part 04 Below 👇
Still, we didn’t use a keyboard to input data. instead, we only used codes. The reason for this is our operating system must be able to handle keyboard inputs. After this process, we’ll be able to handle interrupts.
What is an Interrupt?
Any device or program attached to or running on our computer can send an interrupt signal, which forces our operating system to stop what it is doing and figure out what to do next.
In addition, the CPU can send interrupts due to software errors, such as when a program divides a number by zero. Assembly code instructions such as int produce interruptions as well.
The Interrupt Descriptor Table(IDT) is used to handle interrupts. For each interrupt, the IDT specifies a handler. Interrupt handlers are classified into three types:
- Task handler
- Interrupt handler
- Trap handler
The task handlers use functionality specific to the Intel version of x86. The interrupt handler disables interrupts. As a result, you can’t get an interrupt while you’re dealing with an interrupt, and vice versa with a trap handler.
Handling an Interrupt
Whenever an interrupt occurs, the CPU will push a bit of information about it onto the stack, then look up the appropriate interrupt handler in the IDT and jump to it when it appears. We can do this by using a C handler. The state of the registers, the stack state, and the interrupt number should be passed to the C handler.
So, we declare the necessary functions and structures in the “interrupts. h” file.
As stated, here is the “interrupts. c” file, which contains definitions for all previously stated functions.
Creating a Generic Interrupt Handler
For example, all interrupt handler registers must be preserved by moving them into the stack, which requires assembly code. Due to the fact that interrupt-unaware programs will anticipate its registers to remain unchanged.
This is how the interrupt handler assembly code should look.
It’s time to load the IDT
The “lidt” assembly code instruction is loaded into the IDT, and it takes the address of the first entry in the table as input. This assembly code may be used to do this.
Interrupt controller with programmability (PIC-Programmable Interrupt Controller)
The Programmable Interrupt Controller must be configured before you may use hardware interrupts (PIC). Signals from the hardware can be mapped to interrupts using the PIC. The following are some of the reasons for customizing the PIC:
Decide which interruptions you want. It’s likely that you do not want all devices to send you interrupts since you do not have the code to handle these interrupts in the first place.
It is possible to remap the interruptions. By default, the PIC utilizes interrupts 0–15 for hardware interrupts, which interfere with CPU interrupts on the host computer. There is a need to remap PIC interrupts into a different frequency range as a result.
Make sure you have the PIC set to the right mode before starting.
PIC interrupts are accepted by sending a confirmation message to the PIC. There will be no further interruptions generated by the PIC if this is not done.
This is how you may declare the functions and variables you need.
Below you’ll find the “pic. c” file that contains the definitions of the previously defined functions.
Reading Input from the Keyboard
The keyboard does not produce ASCII characters; it produces scan codes instead of ASCII characters. In a scan code, a button is both pressed and depressed at the same time. The keyboard’s data I/O port, which has the address “0x60”, may be used to read the scan code for the just-pressed button. Declare required functions and variables as shown below.
The file “keyboard.c” contains the definitions of previously defined functions.
To execute your operating system, you must now set the “Makefile” appropriately, as shown below.
In addition, the “interrupts_install_ idt” function in the “kmain.c” file must be called. You may now launch your operating system using “make run ” command and enter some keyboard inputs into it. The keyboard input is then written in the “com1.out” file, as shown below when I entered “Hello SachOS” into the input.
You can see com1.out file as this way also
Sometimes it will give an error like: “Invalid or unsupported executable format”.So It is preferable to replace “section. text:” with “section. text” in the “loader.s” file.
I believe you have a decent understanding of how to work with Interrupts and Inputs. This link will take you to my Github repository.
Thank you for reading, and I’ll see you next week for part 6 of this series.
