BrokenThorn Entertainment

I have started on my OS. Right now I am using the tutorials like a bible to creating it though I'm making mine totally in assembly.

Anyways I have been trying to get information from the keyboard controller buffer. Primarrily I want it to keep checking the buffer when told to, and to updating something with the strokes (i'll need a bit help on that part. HECK I'll need help on quite a bit of this) When it encounters an "ENTER" then I want it to send this cumulated something that holds the keystokes to be checked against a list of valid options.

This is what I know that I believe will be needed:
1. 0x64 is the port with the status bit
2. 0x60 contains the actual data
3. it will employ a loop that waits for and enter stroke and when that happens then it will continue
4. to get it to show what has actually been typed it will keep calling Putch32 to write it.
5. When it encounters backspace it will need to remove the last byte from the something that holds all the keystrokes

That is about all I know of what needs to be done, but how to do it I have no clue, though I did see this in tutorial 7:

WaitLoop: in al, 64h ; Get status register value
and al, 10b ; Test bit 1 of status register
jz WaitLoop ; If status register bit not set, no data is in buffer
in al, 60h ; Its set--Get the byte from the buffer (Port 0x60), and store it

I believe that it does indeed monitor the buffer and when the buffer is filled with a keystroke then stores it. At the moment I using this code have it set to loop forever waiting for a keystroke.(using that code) when it gets one then it is sent to putch32. after the print I have it jump back and wait for another charecter. Unfortunally it doesn't work.

While fooling around I took out the jz line... It compiled. But had lots of the letter u with the accent over it. When I hit a key they all turned to the # sign.

I think that it can't retrieve the status of the buffer so it is waiting forever but it can't find it. No triple fault at all it sits there as if I had told it to hlt. Could the problem be that I have a usb keyboard? Also I use MS's virtual PC to test it not Bochs. I couldn't get Bochs to work.

If you know a good tutorial or have suggestions/hints/help can you please tell me?

I've found multiple examples about remaping/reprogramming the PIC for keyboard support along with other devices. (with the added plus of taking care of exceptions if set up properly) The problem is that almost all of these tutorials are for C/C++. My kernel is in Assembly. I found one example for assembly so I guess I'll try it.

tadada wrote:I've found multiple examples about remaping/reprogramming the PIC for keyboard support along with other devices. (with the added plus of taking care of exceptions if set up properly) The problem is that almost all of these tutorials are for C/C++. My kernel is in Assembly. I found one example for assembly so I guess I'll try it.

Let us know if it works Also, do not forget to initialize the PIT before enabling hardware interrupts.

Also I use MS's virtual PC to test it not Bochs. I couldn't get Bochs to work.

Hm... Can you please elaborate here? If the code does not work in multiple envirements, it indicates a portability problem with the code that should be checked.

as for the PIT:

I have the IDT (I think) I know I have what is needed to handle the divide by zero exception the thing is I went to try it and no luck. I realised I didn't intialize the PIT . After I get that working I will go on to creating the keyboard interupt.

for the BOCHS/VIRTUAL PC thing:

It works when I don't do a stupid mistake that makes it so that the floppy becomes unbootable. I don't know what this mistake is though. I use Virtual PC simply because I know how to configure it, not Bochs. I havn't got Bochs to run but on VPC I already have my asm kernel printing green text (by choice) and booting.

must tutorials are for a C kernel. They usually have something like this to reprogram the PICS:

#define PIC1 0x20
#define PIC2 0xA0

#define ICW1 0x11
#define ICW4 0x01

/* init_pics()
* init the PICs and remap them
*/
void init_pics(int pic1, int pic2)
{
/* send ICW1 */
outb(PIC1, ICW1);
outb(PIC2, ICW1);

/* send ICW2 */
outb(PIC1 + 1, pic1); /* remap */
outb(PIC2 + 1, pic2); /* pics */

/* send ICW3 */
outb(PIC1 + 1, 4); /* IRQ2 -> connection to slave */
outb(PIC2 + 1, 2);

/* send ICW4 */
outb(PIC1 + 1, ICW4);
outb(PIC2 + 1, ICW4);

/* disable all IRQs */
outb(PIC1 + 1, 0xFF);
}

init_pics(0x20, 0x28);

The problem I'm having is switching this into assembly... Mabye I should make my first real Kernel in C (right now mine can only print lines so I don't count it as a real kernel) If I followed the tutorials correctly after this should reprogram the PICs to use my Interrupt Discriptor Table.

EDIT: I just realised that there is a tutorial here about the PICs so I gotta read it.

EDIT AGAIN: Indeed the tutorial did have an assembly version of the above code Unfortunatly it just sits there staring at me. I can seem to get it to work

The next tutorial will be up soon. The demo includes a full interface for both the PIC and the PIT. The demo itself is practically complete; tutorial might be up this week.

The pic tutorial on this site contains a small example in assembly language that might be helpful.

If I followed the tutorials correctly after this should reprogram the PICs to use my Interrupt Discriptor Table.

Yep.

*edit: I was too late I hope the assembly code is helpful

I read it but something I have done... I gets half way through loading. I have it so that it maps the PIC and then installs the IDT... It gets that far. It hangs with no triple fault. I believe it is my IDT. At the point in time when it goes to load the IDT interrupts are enabled, PIc has been remapped, GDT enabled and it is still in 16 bit mode, That is all. Something I noticed in the IDT is that interrupt zero and interrupt 1 are the same and there is no code that splits each entry (mabye Lidt nows beggining and ending of entries...). I'm going to do more reaserch. Eventually it should work.

BTW. One question. Do exception interrupts get handled specially or are they part of the IDT?

At the point in time when it goes to load the IDT interrupts are enabled, PIc has been remapped, GDT enabled and it is still in 16 bit mode, That is all.

You should disable interrupts before setting up a new IDT. Specifically if remapping the PIC. Only enable it after both having a way to trap exceptions, and handling the PIC and timer interrupt to their new interrupt entries.

Keep in mind that after overwriting idtr, you effectively change the address of the ivt in real mode. In other words, bios interrupts may not work correctly (Although you can emulate it.)

In other words: 1st disable interrupts. 2nd install idt. 3rd handle processor exceptions. 4th remap pic. 5th handle timer interrupt. 6th enable hardware interrupts. From here, you should be good to go.

tadada wrote:BTW. One question. Do exception interrupts get handled specially or are they part of the IDT?

They are handled in the idt as well. They are a special case as they are reserved exceptions (One cannot change where they are in your idt. Please see tutorial 15 for more information), and executed directly by the processor.