Help with capturing user input

[lurner]

Hi, just trying to find an example written in C that can capture user input and wait till any key is pressed. This is how I do it in ASM:

Code: Select all

; wait for key press
mov ah,00h	    ; BIOS Scan Keycode
int 16h			; 16h = keyboard

How can I do that in C. I guess I haven't made out really how transmitting through port in and out really work. Right now I am forcing the infinite loop with for(;;);. A working example of the above translated into C would be great.

Thanks in advance.

EDIT: I assemble with NASM and compile with DJGPP on a Win32 platform.

[Combuster]

Can't do

Protected mode unleashes the real power of your CPU, so you better get informed about it if you are considering writing an OS. However, it will prevent you from using virtually any of the BIOS interrupts (unless you have a V86 monitor).

[lurner]

Oh, well that sucks. How could I accomplish what I am doing some other way?

[JamesM]

http://www.osdev.org/wiki/PS2_Keyboard

Have fun!

EDIT: I thought I'd expand on Combuster's post.

It depends what mode you're in. If you're in real mode, and writing in C (it is possible), you can simply do:

Code: Select all

void myfunc()
{
  asm volatile("mov $0x00, %ah; int $0x16");
}

Or something. In protected mode, as combuster says, you will need to physically communicate with the keyboard.

[lurner]

JamesM, your help is therapeutic. Thank you very much!

[Dex]

You should study the code from this http://alexfru.chat.ru/epm.html#los4d
As it user's both nasm and DJGPP and as many examples.

[lurner]

Hey guys, I am having some real trouble understanding the guides. I am in Pmode and my Kernel is written in C. I think this is what I have to do to start capturing keyboard input in Pmode taking from the wiki:

1. Setup GDT, (did that in Rmode)
2. Set Up IDT, (unsure how to do this in Pmode using C)
3. PIC Remap, (I have code in C for doing this in Pmode) not tested
4. IRQ for keyboard unmasked and pointing to your future keyboard ISR (no idea)

I am trying to stay real minimal with my interface. I eventually would like to simply do stuff with an NTFS hard drive (read/write), so my interface really only needs to print some text (welcome screen which is done), wait for user to press any key, then the hard drive reading code fires (does a little reading from floppy to know where to go and either reads or writes to hard disk) and the system reboots when complete. That is it.

Could someone who has done this (just the keyboard stuff i.e., setup idt, pic remap, and irq/isr stuff) please help me to understand what I am doing, how to do it and why I am doing it? The result would be something that fulfills the list above (if completely necessary), waits for key press and moves to a function when any key is pressed.

I am sorry, I think I need baby steps. I just can not understand without working examples. sorry and thanks in advance.

[JAAman]

im assuming you already have the intel manuals?

if you dont, there is a link to the download in my signature, and on that page there is a link to a page explaining how to order hard copies (highly recommended) -- they are completely free, including shipping

these (not any tutorials or other information sites, including the wiki) should be your primary resource for anything related directly to the CPU, other sources of information are often incorrect/misleading and harder to understand

[lurner]

EDIT:

I found my answer as to how hard writing a driver to work with NTFS is going to be and I am currently looking for a new solution. I am wondering this:

If I know exactly where a file is on disk in a NTFS; such as what sector, cluster, offset, is it possible to write to that file without doing anything special as if it was the same procedure as writing to FAT16 or something like that?

I assume NTFS just makes it difficult to interpret not access data within it, right? I am not trying to read data and make it human readable or even load the file: I just want to access the offset of a file on an NTFS hard disk and overwrite the data if possible. I mean I should have access to the hard disk it isn't like NTFS says NO, right? It would just be a matter of knowing where to write. Please correct me if I am wrong.

TIA

[AndrewAPrice]

If I know exactly where a file is on disk in a NTFS; such as what sector, cluster, offset, is it possible to write to that file without doing anything special as if it was the same procedure as writing to FAT16 or something like that?

Sure, only if you want to overwrite the data in the file while keeping size the same. If you add/remove data then you may need to allocate/deallocate room on the disk which requires you to change the NTFS structures (which I have no clue how to go about doing it). Also, if a file extends beyond the "allocation unit size" (the name the Windows format tool gives them), then its contents may be scattered across the disk (you could defragment your drive to avoid this problem).

[lurner]

Yes, I have spoken about this with a colleague of mine and he also stated that fact. The file may be in different places on disk. But if I find the metadata I assume that would be the start. I could even read the $MFT and find the start I suspect! I have been studying the NTFS very closely as of late and I think that I just might have a solution to the whole NTFS trade secret, no information revealing, retardedness of it all. Money preventing the advancement of technology has always pissed me off!

[JamesM]

Did you get your IDT working? Bran's kernel dev tutorials are a good start, and the following tutorial may help you:

GDT / IDT tutorial

[lurner]

No, that is the one thing I have been slacking on doing. I have everything except that. Wow, your guide is very detailed, with sample code!! I swear that (God willing of course) if I can make a real contribution to this community it will be to the knowledge of writing and reading an NTFS disk. Thanks