)
Probably yes, but you can use QEMU's built-in debugging functions to find out for sure. For example, if you run QEMU with "-d int" (and maybe also "-no-reboot" and "-accel tcg") you can check the log for exceptions leading up to a triple fault.
You can't use inline assembly to turn an ordinary function into an interrupt handler. If you want to write an OS, you'll need to write at least part of the interrupt handlers in pure assembly. (GCC has a function attribute you can use for simple bare-metal applications, but it won't work for an OS.)
Large language models are not a substitute for learning. Lucky for you, there's an entire forum and wiki right here, dedicated to helping people like you learn about OS development. And unlike the LLMs, we actually know what we're talking about.
I did that, but I couldn't understand anything it printed outProbably yes, but you can use QEMU's built-in debugging functions to find out for sure. For example, if you run QEMU with "-d int" (and maybe also "-no-reboot" and "-accel tcg") you can check the log for exceptions leading up to a triple fault.
I've added a ASM wrapper (I can't upload ASM files for some reason) and replaced the function in the "keyboard_init" function (see ), but now instead of crashing, it just doesn't print out the scancode.You can't use inline assembly to turn an ordinary function into an interrupt handler. If you want to write an OS, you'll need to write at least part of the interrupt handlers in pure assembly. (GCC has a function attribute you can use for simple bare-metal applications, but it won't work for an OS.)
I understand. I might soon enough replace all code from the AIs with code I get from here or even my own code.Large language models are not a substitute for learning. Lucky for you, there's an entire forum and wiki right here, dedicated to helping people like you learn about OS development. And unlike the LLMs, we actually know what we're talking about.
There are lots of examples of interpreting QEMU interrupt logs in various forum threads. If you want to know what your specific QEMU log means, you can post it here. Usually the interesting parts are in the last 50 or 100 lines.
Just rename it. I'm not sure why .asm isn't in the list of allowed file extensions, though.
Here's the log from QEMU (after keypress, command is qemu-system-x86_64 -kernel ./bin/kernel.bin -d int -no-reboot -accel tcg -D qemu_log.txt): Update: I've done debugging, and it seems like when I use the straight C function, it does print out the Scancode Recevived message, but the ASM wrapper doesn't.There are lots of examples of interpreting QEMU interrupt logs in various forum threads. If you want to know what your specific QEMU log means, you can post it here. Usually the interesting parts are in the last 50 or 100 lines.
Code: Select all
global ps2_keyboard_handler_wrapper
extern ps2_keyboard_handler
ps2_keyboard_handler_wrapper:
pusha
call ps2_keyboard_handler
popa
iret
Code: Select all
mov byte [0xB8000], ' 'The log shows two interrupts, one using vector 0x20 (called by you) and one using vector 0x21 (called by an external interrupt request). There are no exceptions, so presumably your code is running, but is your code supposed to be calling INT 0x20?
Your ASM wrapper doesn't clear the direction flag or align the stack (although you can usually get away without aligning the stack). Based on the QEMU log, the direction flag was already clear, so you may be running into a different bug somewhere else in your code.
Are you sure a space would be visible if it did run?
]The log shows two interrupts, one using vector 0x20 (called by you) and one using vector 0x21 (called by an external interrupt request). There are no exceptions, so presumably your code is running, but is your code supposed to be calling INT 0x20?
)Yes, or at least something in the left corner.Are you sure a space would be visible if it did run?
Why aren't you using a cross-compiler?
I would recommend always to do -Wpendantic or -Wall etc. (enable _all_ warnings) and try to ensure your compilation has no warnings at all. Usually they are there for good reason. There are rare cases that it's needed to do stuff that yields a warning, but I've not encountered any yet with my kernel stuff (I am also not so far yet...
).