Turns out we just need a null handler at offset 8 rather than offset 9.
If the keyboard handler is indeed at offset 9 as
https://alex.dzyoba.com/blog/os-interrupts says (I don't understand
why), then the clock handler's at offset 8, which makes sense.
Ok, we're back at the reset loop. Let's keep going; maybe having a decent
keyboard handler will fix it.
The bug I fixed here was caused by misunderstanding what m16&32 mean in
the Intel manual. It's still a regular regmem operand that uses all of
the ModR/M byte (which can be interpreted in 16-bit mode, adding to the
complication). It's just constrained to not allow direct addressing (mod 00).
I needed to better internalize the format of the instruction set references
at the start of Volume 2, Chapter 3.
I'm now back at the state of commit 7382 (including 7376). The existing
print to screen surprisingly seems to work without reset-looping, but when
I step through I notice that the lidt isn't doing what I expect.
Desired: at address 0x7cce, the processor executes:
0f 01 1e 00 7f # lidt ds:*idt_descriptor
Observed: at address 0x7cce, the processor executes:
0f 01 1e # lidt ds:*esi
As a result the next instruction is:
00 7f fb
So the `fb` isn't interpreted to enable interrupts. So the problem of commit
7376 is latent.
Past this point the instruction stream is lined up again, and everything
occurs as it should. Purely by chance.
I fully expect all hell to break loose again, like it did in commit 7376,
once I debug the lidt encoding. There's still something I don't understand
about enabling interrupts. Perhaps I need to fill in more entries in the
table.
Turns out we only had access to 50% of RAM so far. Closing my nose and
moving right along..
Though this _does_ give me practice interacting with ports. That'll be
handy for the keyboard.
Snapshot: first draft of a boot image that switches to 32-bit mode as quickly
as possible (~70 bytes)
Doesn't work yet. Gets stuck in an infinite reset loop.
Kartik Agaram