I write this a long time ago (about a year ago) : https://github.com/prp-e/NanOS-old
and this code includes everything an operating system needs to communicate with a keyboard.
But, I'm sure I wrote terminal_getchar() function in a wrong way, and when I boot my operating system, and press any key from keyboard, it repeats the ">>" (shell sign) twice and stops working.
What should I do in the code?
keyboard input in C kernel
- crunch
- Member
- Posts: 81
- Joined: Wed Aug 31, 2016 9:53 pm
- Libera.chat IRC: crunch
- Location: San Diego, CA
Re: keyboard input in C kernel
I think you should spend more time reading through the wiki + documentation, and perhaps some basic tutorials/theory.
How do you expect to get keyboard input when you have no interrupt handling code?
How do you expect to get keyboard input when you have no interrupt handling code?
Some of my open-source projects:
Ext2/ELF32 bootloader
Lightweight x86 assembler, designed to be portable for osdev
Scheme in under 1000 lines of C
Ext2/ELF32 bootloader
Lightweight x86 assembler, designed to be portable for osdev
Scheme in under 1000 lines of C
Re: keyboard input in C kernel
So, it means I need to define a GDT for my OS?crunch wrote:I think you should spend more time reading through the wiki + documentation, and perhaps some basic tutorials/theory.
How do you expect to get keyboard input when you have no interrupt handling code?
- BrightLight
- Member
- Posts: 901
- Joined: Sat Dec 27, 2014 9:11 am
- Location: Maadi, Cairo, Egypt
- Contact:
Re: keyboard input in C kernel
Some of the first things in your OS's initialization code should be (in this order):Haghiri75 wrote:So, it means I need to define a GDT for my OS?
1. Load a GDT and reload all segment registers.
2. Load an IDT and install exception handlers.
3. Initialize paging and memory management.
4. Load a task state segment (TSS) -- although you can probably skip this now and do it when you support usermode.
5. Initialize the basic devices: the programmable interrupt controller, the programmable interrupt timer, and (as you're trying to do) the PS/2 controller.
You know your OS is advanced when you stop using the Intel programming guide as a reference.
Re: keyboard input in C kernel
You can do it, but it will conflict with mouse and fully load CPU, also this is VERY BAD. Port 0x60 polling, that's it.crunch wrote:I think you should spend more time reading through the wiki + documentation, and perhaps some basic tutorials/theory.
How do you expect to get keyboard input when you have no interrupt handling code?
I know it because OS365 used port polling, this is one of causes to discontinue it in start of 2016.
Developing U365.
Source:
only testing: http://gitlab.com/bps-projs/U365/tree/testing
OSDev newbies can copy any code from my repositories, just leave a notice that this code was written by U365 development team, not by you.
Source:
only testing: http://gitlab.com/bps-projs/U365/tree/testing
OSDev newbies can copy any code from my repositories, just leave a notice that this code was written by U365 development team, not by you.
- BrightLight
- Member
- Posts: 901
- Joined: Sat Dec 27, 2014 9:11 am
- Location: Maadi, Cairo, Egypt
- Contact:
Re: keyboard input in C kernel
I hardly think it's worth it to start a new OS project because something as minor as how a keyboard driver receives data.catnikita255 wrote:I know it because OS365 used port polling, this is one of causes to discontinue it in start of 2016.
You know your OS is advanced when you stop using the Intel programming guide as a reference.
-
- Member
- Posts: 1146
- Joined: Sat Mar 01, 2014 2:59 pm
Re: keyboard input in C kernel
His whole OS used to be based around polling mode drivers because he didn't know how to use interrupts; he's slowly re-writing it to use interrupts rather than polling. I don't think he means that he's discontinuing his project; I think he means that he's discontinuing the exclusive use of polling mode for his drivers and has started to re-write them to use interrupts.omarrx024 wrote:I hardly think it's worth it to start a new OS project because something as minor as how a keyboard driver receives data.catnikita255 wrote:I know it because OS365 used port polling, this is one of causes to discontinue it in start of 2016.
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.
Syntax checkup:
Wrong: OS's, IRQ's, zero'ing
Right: OSes, IRQs, zeroing
Syntax checkup:
Wrong: OS's, IRQ's, zero'ing
Right: OSes, IRQs, zeroing
Re: keyboard input in C kernel
No, no, I discontinued all OS365 in start of 2016, now I write U365.onlyonemac wrote:His whole OS used to be based around polling mode drivers because he didn't know how to use interrupts; he's slowly re-writing it to use interrupts rather than polling. I don't think he means that he's discontinuing his project; I think he means that he's discontinuing the exclusive use of polling mode for his drivers and has started to re-write them to use interrupts.omarrx024 wrote:I hardly think it's worth it to start a new OS project because something as minor as how a keyboard driver receives data.catnikita255 wrote:I know it because OS365 used port polling, this is one of causes to discontinue it in start of 2016.
Developing U365.
Source:
only testing: http://gitlab.com/bps-projs/U365/tree/testing
OSDev newbies can copy any code from my repositories, just leave a notice that this code was written by U365 development team, not by you.
Source:
only testing: http://gitlab.com/bps-projs/U365/tree/testing
OSDev newbies can copy any code from my repositories, just leave a notice that this code was written by U365 development team, not by you.