Will my interrupts still work?

[PavelChekov]

I heard that Intel is droppign support for PC BIOS in favor for UEFI. Will BIOS interrupts like INT 10h(print character on screen) INT 17h(print char to printer) and INT 13h(disk control) still work in my OS?

Thx,

Ensign Checkov

[Octocontrabass]

No.

You can't use BIOS interrupts without the BIOS.

[PavelChekov]

So, how would I get get keyboard input, print to the printer, and control the hard disks (I am new to this game and writing a UNIX OS)?

[nexos]

To answer your question, UEFI provides an API different from that of the BIOS. It is designed to be called from C code, and you are given a table of function pointers when your EFI application starts. Now some clarification on the roles of these functions

When CP\M created the first BIOS in the 70's, the intent was to provide a (very) low level API that an operating system developer could build on and provide their own API that apps would use. MS-DOS used this design. It simplified OS development, and allowed hardware developers to make one driver, and then an OS and the BIOS could access this hardware. The BIOS was designed to be called from real mode, and as time progressed, Intel realized that the x86 needed more security features. So they created 16 bit protected mode. It added memory protection, a 24 bit address bus, and more. However, BIOS functions could not be called from this mode. OS developers had two options, they could, one, develop device drivers for disk, keyboard, and screen themselves, or two, drop down to real mode and call these function and then come back up to protected mode. Intel then designed 32 bit protected mode, and with the increasing need for security and stability, plus the addition of paging, OS developers started making their own drivers. If you want to write an OS with modern features, the you will need to write your own drivers. If you are doing it purely for fun, then feel free to use the BIOS. But know that it has security and stability concerns. Nowadays, the best approach is to have a bootloader enter protected mode for you and load up the kernel and do other things, and then the kernel has its own drivers. My bootloader does all this, and it is easy to make your OS loadable by it. Not to spam, but there is a link in my signature

As for UEFI, it is designed to be used at bootup and then be exited when you get to the kernel, for the same reasons described above.
Hope that make sense
Greetings,
nexos

[PavelChekov]

I am using Grub and making a sort of 64-bit version of CP/M and I already have :

Code: Select all

Print:                  ; Prints a string on screen
    lodsb               ; Grab a char from al
    cmp al, 0           ; Is it a null char?
    je .Done            ; If so, exit
    mov ah, 0Eh         ; BIOS print char
    int 10h             ; Call BIOS
    jmp Print           ; Print next char
    .Done:
        ret             ; Return to caller

I was actually just asking if INT 10h would still work on modern Intel CPU's like i7 and i9. I am trying to be as modern as possible.

PS: All the text in the command prompt is in magenta!☺

[nexos]

BIOS ints won't work in 64 bit mode.

[PavelChekov]

Then what can I use instead?

PS: I also downloaded both of those things

[nexos]

You have to write your own hard disk drivers, screen drivers, and keyboard drivers. The wiki contains info about all this, plus, with some googling, you can find info on how to write these drivers.

[thewrongchristian]

I am using Grub and making a sort of 64-bit version of CP/M ...

Just curious, what is your ultimate aim? To be able to run CP/M .COM programs? And is that 8080 CP/M or x86 CP/M?

Or to run 64-bit flat binaries that are the equivalent of a CP/M .COM file, and replicate the CP/M API?

In both cases, and because CP/M is inherently single tasking, why not do it in a single process of an existing operating system? Then, your "BIOS" calls can be just wrappers around native libc functions that read/write to disk images on the host system. That'll allow you to do the user space API for your processes, without having to provide a hardware interface.

Then once you have user space programs that run under your user mode runtime, you can then look at taking the steps to implementing the hardware features required to talk to real (or virtual hardware), with the added bonus that you'll have a ready made user space to test with.

[PavelChekov]

I am trying to write assembly procedures for the CP/M system calls:
https://www.seasip.info/Cpm/bdos.html

[PavelChekov]

I am having a ton of trouble writing a keyboard driver that will let me read a character with one function.

Have any of you already written one?


Thank you so much,

Pavel Checkov

[nexos]

I wrote one like a year ago, but I lost its code. You should look at the wiki. You should look at https://wiki.osdev.org/PS/2_Keyboard. Also, you should read about protect mode and the GDT and IDT. You will also need to understand the IO port space. You can look at https://wiki.osdev.org/Tutorials for OSDev tutorial. Note that most tutorials contain bugs though.

[PeterX]

I am trying to write assembly procedures for the CP/M system calls:
https://www.seasip.info/Cpm/bdos.html

So you want to write a CP/M ontop of 64bit UEFI, do I understand you correctly? That's an interesting idea.

As others already said, you have to write your "stuff" yourself. I mean, very fundamental things that were done by BIOS in 8bit/16bit days. So I'm not sure if this will be fun for you, because it is not as trivial as it seems (if you look at CP/M).

[PavelChekov]

Whta is that supposed to mean?

[PeterX]

Whta is that supposed to mean?

It means:
CP/M was (and is) very simple. It takes BIOS calls and creates an OS ontop of these BIOS calls.
But on UEFI you have to do some complicated coding to create a kind of BIOS yourself.