6

I have to code for a operating system on which I can run a calculater.It is like a desktop calculater. For this I am reading the brokenthorn operating development series I have completed the second stage of bootloader The bootloader is in real mode. After this the author is explaining the protected mode. I don't want to use the protected mode. I don't have time for that. So I want to write the calculater in real mode by using bios interrupts. Is it possible? I think it can be written on the second stage of the bootloader(I am not sure.) Means I don't have to use a kernel(I am not sure). I don't know how to use BIOS interrupts to handle the keyboard. Can anybody provide me a link which will help me in this? And If anything wrong in whatevet I assumed above is wrong, please correct me.Thanks in advance.

narayanpatra
  • 5,627
  • 13
  • 51
  • 60
  • You will find [PC Interrupts][1] to be an invaluable tool. You can get it at the link for < $4.00. [1]: http://www.amazon.com/PC-Interrupts-Programmers-Reference-Third-Party/dp/0201624850 – Tergiver Nov 06 '10 at 14:58

3 Answers3

10

If you want to use high-level BIOS keyboard services, rather than handling the keyboard interrupts yourself, then INT 16h is what you want.

INT 16h with AH=00h or 10h will block waiting for a keypress (returns ASCII result in AL); use AH=01h or 11h to query whether a keypress is available first if you want to avoid blocking (returns immediately with ZF clear if a key is available, or set if not). See e.g. here, or here (or Google "INT 16h" for more).

Matthew Slattery
  • 45,290
  • 8
  • 103
  • 119
  • Pardon, good sir--any idea how to go about "handling the keyboard interrupts yourself" without the high level bios service? What are the downsides of using such high-level service? Is the performance worse? – travisjayday Aug 16 '17 at 20:45
5

You can handle IRQ 1 (mapped to interrupt 9 by the x86 controller) and read the keys from port 60h.

See http://inglorion.net/documents/tutorials/x86ostut/keyboard/.

Frédéric Hamidi
  • 258,201
  • 41
  • 486
  • 479
  • -1. It's not IRQ 9, it's IRQ 1: http://www.webopedia.com/quick_ref/IRQnumbers.asp. IRQ 9 is available for generic other devices such as PCI devices. IRQ1 is the keyboard interrupt. – Matt Jan 14 '14 at 00:46
  • @Matt, from the link in my answer: `The keyboard controller uses IRQ 1. The x86 interrupt controller maps this to interrupt 9, so receiving an IRQ from the keyboard controller has the same effect as executing int 9.` – Frédéric Hamidi Jan 14 '14 at 07:51
  • 1
    If the PIC isn't remapped and you're not using an IOAPIC, it's the same as executing INTERRUPT 9 (which is overlapped with the NPX_OVERRUN CPU exception, not the IRQ9 handler). Although the mapping between IRQs and interrupts is configurable, IRQ9 never == IRQ1. Indeed, from your own link: `The keyboard controller uses IRQ 1`. Since all OSes will remap the PIC so IRQs don't overlap CPU exceptions, your answer would be better to just say that the keyboard uses IRQ1. – Matt Jan 14 '14 at 13:56
  • @Matt, you have a point, IRQ 1 is indeed mapped to interrupt 9 but not to IRQ 9. I tried to clarify that in my answer. Thanks for the heads-up :) – Frédéric Hamidi Jan 14 '14 at 14:06
3

Minimal GAS boot sector BIOS example

When you enter a character, it gets printed to the screen.

main.S

.code16
.global _start
_start:
cli

/* Set SS and SP as they may get used by BIOS calls. */
xor %ax, %ax
mov %ax, %ss
mov $0x0000, %sp

/* Get input to %al */
mov $0x00, %ah
int $0x16

/* Print the input from %al */
mov $0x0E, %ah
int $0x10

hlt

.org 510
.word 0xaa55

Compile and run:

as -o main.o main.S
ld --oformat binary -o main.img -Ttext 0x7C00 main.o
qemu-system-i386 -hda main.img

GitHub upstream.

Tested on Ubuntu 14.04 AMD64, Binutils 2.24, QEMU 2.0.0 and on real hardware Lenovo Thinkpad T400.

Ciro Santilli OurBigBook.com
  • 347,512
  • 102
  • 1,199
  • 985
  • Potential problem with your code is that you are assuming that you have a valid stack segment(SS) and stack pointer(SP). BIOS interrupts require stack space so it would be good practice to setup a valid `SS` and `SP` prior to issuing BIOS calls. You can't really rely on the state of segment registers by the time the BIOS jumps to your code loaded from the boot sector. The emulated and VM environments are often kind to leave things in a valid state, but on some real hardware that isn't always the case. – Michael Petch Sep 20 '15 at 18:00
  • @MichaelPetch thanks for the info! I will look into it. What should I set them to? For `SP`, any memory high above 0x7C00 is fine, or is there a better more specific value? `SS` to 0 I suppose. – Ciro Santilli OurBigBook.com Sep 20 '15 at 18:07
  • Anything that is usable is fine but I generally stay away from anything less than 0x0000:0x1000 and below. You could put the stack segment just below 0x0000:0x7C00 (Usually what I have done in the past) – Michael Petch Sep 20 '15 at 18:09
  • 1
    @MichaelPetch OK! Found that question at: http://stackoverflow.com/questions/10598802/which-value-should-be-used-for-sp-for-booting-process – Ciro Santilli OurBigBook.com Sep 20 '15 at 18:11