Member Avatar for MichaelSammels

Yeah, I'm stumped on this one:

I need to get user input from a keyboard, with some problems involved:

  1. I'm using an OS I created
  2. I do not have access to any standard includes
  3. I need to code the function myself
  4. I'm in protected mode

Any help would be hot.

  • 2 Contributors
  • 2 Replies
  • 119 Views
  • 14 Hours Discussion Span
  • Latest Post Latest Post by MichaelSammels

Dani AI

Generated

Brief, practical plan that fits the constraints described and answers 's question about tooling: implement an interrupt-driven PS/2 keyboard driver (preferred) or fall back to polling. Protected mode removes BIOS helpers (int 0x16), so the kernel must talk to the keyboard controller (ports 0x60/0x64), install an IRQ1 handler in the IDT, and acknowledge the PIC after each IRQ.

Minimal workflow and an example ISR stub (NASM-style):

; irq1.asm - NASM syntax, IRQ1 (keyboard) stub
global irq1_stub
extern keyboard_isr    ; C handler that consumes the scancode

irq1_stub:
    cli
    pushad
    push ds
    push es
    push fs
    push gs

    call keyboard_isr

    pop gs
    pop fs
    pop es
    pop ds
    popad

    mov al, 0x20
    out 0x20, al    ; send EOI to master PIC (IRQ1)
    sti
    iret

C-side helpers and handler sketch (GCC inline asm style):

static inline unsigned char inb(unsigned short port) {
    unsigned char val;
    asm volatile("inb %1, %0" : "=a"(val) : "Nd"(port));
    return val;
}

void keyboard_isr(void) {
    unsigned char status = inb(0x64);
    if ((status & 1) == 0) return;   /* no data */
    unsigned char scancode = inb(0x60);
    /* handle prefixes, make/break, shift/caps state, map to ASCII, enqueue */
}

Key implementation notes and troubleshooting:

  • Remap the PIC early (so IRQ vectors do not collide with CPU exceptions) and unmask IRQ1.
  • Decide which scancode set the hardware is sending. Make vs break and extended codes differ by set; handle prefix bytes (0xE0, 0xF0, etc.) and maintain modifier state (Shift/Ctrl/Alt/Caps).
  • If no interrupts fire, check IDT vector numbers vs PIC offsets, PIC masks, and that interrupts are enabled (sti). For virtual machines, ensure the emulator passes keyboard events.
  • For a C-capable build, keep most logic in C and use a small assembly stub as above. If no compiler exists, implement the whole handler in assembly and provide a ring buffer API for higher-level code.

This gives a working, maintainable path for linking a keyboard routine into a protected-mode kernel; the missing pieces are the scancode->ASCII table and the kernel-side reader API (ring buffer and syscall), which are straightforward once the handler supplies bytes.

Recommended Answers

All 2 Replies

Member Avatar for Ancient Dragon

Which those constraints all bets are off. You wrote the OS so you will have to write all the low-level stuff. Does it even support C language? A compiler? How do you run any programs in that os?

Member Avatar for MichaelSammels

I do not yet. I had the idea of writing the function in assembly, and then linking it into the kernel.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.