getting input with nasm

[DTSCode]

so here is the source code for my os:

Code: Select all

BITS 16

start:
    mov ax, 07C0h
    add ax, 288
    mov ss, ax
    mov sp, 4096

    mov ax, 07C0h
    mov ds, ax

    call Terminal

    jmp $

Terminal:
    input resd 1 ; reserved for storing the command
    call Prompt
    call GetCommand
    jmp Terminal

GetCommand:
    int 21h

Prompt:
    mov si, prompt
    call Print
    prompt db "$> ", 0

Print:
    mov ah, 0Eh

.repeat:
    lodsb
    cmp al, 0
    je .done
    int 10h
    jmp .repeat

.done:
    ret

times 510-($-$$) db 0
dw 0xAA55

my problem is, i now want to be able to get a command, or at the very least some text from the user. i have googled it but im not too sure how to get an unknown number of characters in nasm, only that it seems to require the interrupt 21h

[jnc100]

Int 21h is provided by DOS. When you are writing your own OS you do not have DOS available and so need to obtain input by other means.

One of the simplest things you can do is write a PS/2 keyboard driver and use that to get input. Note, however, that PS/2 is rapidly becoming a legacy interface (in favour of USB) and is generally emulated on modern machines and that emulation is possibly not 100% correct.

Alternatively, if you wish to rely on the BIOS you could look up int 16h with AH=0 or 10h.

Regards,
John.

[DTSCode]

thanks. i didnt know that. so if im developing this on my laptop what kind of keyboard driver should i look for?

edit: i actually decided to go with int 16h

[azblue]

There's a lot wrong with your code. For starters, the way you intermingle code and data, you're going to end up executing data. And you aren't ending your functions with a ret. For example, you have:

Code: Select all

Prompt:
    mov si, prompt
    call Print
    prompt db "$> ", 0

What you want is:

Code: Select all

prompt db "$> ", 0
Prompt:
    mov si, prompt
    call Print
    ret

Your call to dos (Int 21h) didn't load a function number; I suspect you'll make the same mistake with the keyboard interrupt. Look up Ralf Brown's Interrupt List to learn how to use the BIOS interrupts.

For keyboard input, it's better to ditch the BIOS and write a PS/2 driver; it's ridiculously easy. Run it in an emulator so you don't have to worry about whether or not it's really USB emulating PS/2; you can work on real USB support later.

[Antti]

For keyboard input, it's better to ditch the BIOS and write a PS/2 driver; it's ridiculously easy.

If you are still in real mode and using other BIOS services (like DTSCode at this point), I think it makes sense to use BIOS for keyboard input also. Of course at the point OS takes over, BIOS should be thrown away. While the BIOS is usable (at the early boot stage), why not use it? Setting PS/2 hardware when BIOS is still in charge does not sound good.

it's ridiculously easy

I have a general comment about this and I am not attacking to your writings particularly. Writing good code for handling PS/2 hardware is not "ridiculously" easy. What?! First of all, there are two options: bad code and good code. In this case, writing simple code (bad) for PS/2 is quite easy so you are not very wrong. Maybe it could be in the category "ridiculously easy" and it is not very controversial claim.

Making a good PS/2 driver is almost as hard or as easy as any other common task in operating system development where complicated algorithms are not involved. I do not think I would be totally wrong if I said that operating system development is not ridiculously easy. If we started looking at average PS/2 code, I am afraid that we would find that it is not very good. Why is that, I thought it is supposed to be easy?

With PS/2 hardware, there are things like driver interfaces, interrupt handlers, etc involved. If all this really is "ridiculously" easy to do properly, then I have underrated average coding skills.