In NOS, I have set up an API on INT 21 for use by the programmer/user to perform basic tasks without long and complicated code. However, as of the moment, I am having issues getting this API called from the kernel. I have done several step-throughs with Bochs, to no avail. I cannot seem to figure out what is wrong with my code. As far as I can figure out, the API's resident address in RAM (0x8000:0x0000) is getting into the IVT correctly, and the API is getting put in the correct spot, but when I perform an INT 0x21, Bochs seems to "get lost", i.e. it doesn't execute the API code, but whatever it does execute has a LOCK prefix that isn't supposed to be there and it locks up the "processor". It does this every time, I have tried swapping the values in the IVT, I've done memory dumps and the API is always at 0x8000:0x0000 like it's supposed to be. I have an issue on GitHub if you want more info: https://github.com/nkeck720/nos/issues/38
I haven't tested this on real hardware, but VirtualBox and DosBox both seem to do the same thing.
It always fails at the "test call", where I check to make sure that the API is installed correctly:
; We need to be sure that INT 21 works. Function 00 is an install
; check, and so we will call it with that value.
; If AX=5555h, we are done here.
As far as I can tell, it never makes it to the CMP instruction, and I can't tell where on earth Bochs went off to because its builtin debugger doesn't trace interrupt calls. all I get is this:
I'm at a loss here. Can someone help me out with this?
EDIT: Yes, I have made sure ES=0x0000, so in effect my code is pointing at 0x0000:0x0086 and 0x0000:0x0084 in the IVT.
_________________ It may look hard, but it won't take long if you take it one byte at a time.
Hi nkeck72, I debugged my projects using bochsdbg a lot, but the last time it was half a year ago.
When you are on int 0x21 instruction at address 1000:0150, instead of step over command n - try whether step into command s is not able to enter the interrupt handler (I do not know from my head). If unable, then this way should work:
put breakpoint at physical address 0x80000, (from my head) it is command pb 0x80000
continue execution using command c
when you hit the breakpoint you can debug your int 21h handler to catch that ugly instruction with the lock prefix
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum