OSDev.org

Hey guys,

Now I have another problem and this time I've done some debugging so I have a bit of info on what's wrong. The problem is that when I leave in the keyboard functions like getch() and get_command(), it doesn't work. But if I remove those functions from the kernel code it works. Also, when debugging with keyboard functions implemented. It just loops inside the keyboard functions without returning back to the main kernel code. If I remove the getch() and get_command() from kernel_main(), then uncomment the code inside the keyboard_callback() in drivers/keyboard.c. It works but, not every key on the keyboard. For instance, every key works without shift, ctrl, alt, capslock, numlock, and scrolllock.

The code: git clone https://github.com/psimonson/boot32-barebones.git -b development
PS: I imagine that the keyboard driver is probably the culprit.

EDIT: Finally figured out why it wasn't working and fixed it. Now it works, but for some reason I cannot get the get_command() function working. Instead I have to have it all in the kernel_main() and I would like to put it in it's own function. The keyboard input I mean that in it's own function.

Thanks in advance for any help that leads to a possible solution,
Philip

psimonson1988 wrote:for some reason I cannot get the get_command() function working.

Could the problem be that you write to this buffer but you read from this buffer?

On a more fundamental level, your code doesn't seem to be designed around the idea of interrupts. You have loops to constantly check if some event has occurred (a new key press or timer tick), but these loops run even when it's not possible for the event to have happened yet. You should at least use HLT to wait for the next interrupt instead of wasting CPU power doing nothing useful. In a multitasking environment, you would yield your time slice so another task could be scheduled to do actual useful work. (You should notice a race condition here: you may receive an interrupt between checking the variable and using HLT. It's possible to avoid this race under most circumstances with careful placement of CLI and STI, although NMI can then cause problems.)

Octocontrabass wrote:

psimonson1988 wrote:for some reason I cannot get the get_command() function working.

Could the problem be that you write to this buffer but you read from this buffer?

On a more fundamental level, your code doesn't seem to be designed around the idea of interrupts. You have loops to constantly check if some event has occurred (a new key press or timer tick), but these loops run even when it's not possible for the event to have happened yet. You should at least use HLT to wait for the next interrupt instead of wasting CPU power doing nothing useful. In a multitasking environment, you would yield your time slice so another task could be scheduled to do actual useful work. (You should notice a race condition here: you may receive an interrupt between checking the variable and using HLT. It's possible to avoid this race under most circumstances with careful placement of CLI and STI, although NMI can then cause problems.)

Thanks for the reply and information, how would I change the kernel to go with interrupts (using the HLT instruction method, as it sounds easier)?

PS: The problem was not the two key_buffer variables, but they may have caused problems later on thanks for pointing it out.

psimonson1988 wrote:how would I change the kernel to go with interrupts (using the HLT instruction method, as it sounds easier)?

Add a HLT instruction in every loop where you're waiting for an interrupt to update a variable. Later, when you implement multitasking, you'll replace it with a call to your scheduler.

Well I moved the startup code to entry.c and now the get_command() function works not sure why though... but it works now. Marking as solved.

psimonson1988 wrote:not sure why though...

If you're not sure why your change fixed it, your code is probably still wrong. Perhaps you should try debugging the broken code to see what it's doing instead of making random changes.

Well here is what I did but, not sure why it fixed the kernel. I moved the void _start(void); to entry.c and removed the static linkage from the functions in kernel.c. Now what I mean, is it works... tested it in QEMU, Bochs, and VirtualBox. All run the code fine. But, I'm not really sure why that change fixed it. Would like to understand and maybe others as well.

PS: You could be right on that "It might still be wrong", though. Because when I run it on a real system, it boots all the way to the start of the video code but stops and stalls. But, that was on a damaged diskette as well. So further testing required on a real machine, with a new diskette. Which I have to wait for unfortunately.