| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
It's now clear that our keyboard handler doesn't trigger after the first
event.
|
|
|
|
| |
Start highlighting lines that may need to be recomputed when offsets change.
|
|
|
|
|
|
|
|
|
| |
I'm trying to read the status register, but I'm still not seeing the breakpoint
being hit a second time. (And I again ran into the Bochs bug that breakpoints
at the first instruction of an interrupt handler don't work.)
Maybe this is just a debugger issue. Let's keep going, and try to start
using the keyboard events.
|
|
|
|
| |
Fix a stale displacement.
|
|
|
|
|
|
| |
I'd missed that VBE call 0x4f01 (get video mode) can write up to 256 bytes.
Unexpected areas were getting clobbered because I wasn't reserving enough
space.
|
|
|
|
|
| |
Bugfix: 32-bit code in 16-bit mode.
Seems like it was benign, maybe.
|
|
|
|
| |
Typo.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
It's now very obvious that we don't actually have 256 unique colors by
default in 256-color graphics modes.
|
|
|
|
|
|
|
|
| |
If it's large enough that I have doubts whether my top-of-the-line Mac
is showing the bottom of the screen inside an emulator, it's too large.
This way I also feel more confident that most modern hardware will support
this graphics mode, and that these programs will work for others.
|
| |
|
| |
|
|
|
|
| |
First keypress is detected, but we need to ack it somehow.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We need a few pages of data for the keyboard mappings.
If I moved them to some later address I'd be able to keep the nice round
starting address unchanged. But that seems like a superficial aesthetic
concern. There's really no value in having an array of hex bytes represented
in SubX rather than just raw hex. And it's better to colocate data near
the handler code which uses it (and which runs instructions SubX doesn't
support).
|
| |
|
|
|
|
|
| |
This currently works on Qemu, but not on Bochs. I'm now trying to make
sense of https://wiki.osdev.org/Bochs_VBE_Extensions#Using_a_linear_frame_buffer_.28LFB.29
|
|
|
|
|
| |
0xa0000 only contains a single bank's worth of memory-mapped video RAM.
The LFB is supposed to have everything.
|
| |
|
| |
|
|
|
|
|
| |
This works, but colors are unexpected. 0xff isn't white. Lots of colors
are black. Perhaps I need to initialize a palette.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Design choice: all programs will use a graphics mode (1280x1024) with 256
colors. That should be fairly widely available. (It turns out text modes
larger than 80x25 are not widely available even among modern emulators.
Mu will need fonts sooner rather than later.)
Mu will never try to be smart and do things like autodetect your hardware.
We _will_ help you modify Mu for your hardware.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Turns out the default 8MB stack is quite enough for the programs I'm
currently running.
|
| |
|
| |
|
|
|
|
| |
Some manual tweaks to boot.hex.html
|
| |
|
|
|
|
|
| |
https://stackoverflow.com/questions/37618111/keyboard-irq-within-an-x86-kernel
is right, no need to mess with the status port at the start.
|
|
|
|
|
|
| |
I think https://stackoverflow.com/questions/37618111/keyboard-irq-within-an-x86-kernel
has more insight to provide. Among other things the comment about grub
may answer the distinction between entry 0x21 and entry 9.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Snapshot. Keyboard interrupt being triggered.
This was hard to debug until https://stackoverflow.com/questions/37618111/keyboard-irq-within-an-x86-kernel
reminded me that I'd forgotten to enable IRQ1 on port 0x21.
For a while I was confused by never hitting a breakpoint at the start of
the keyboard handler. Then I found https://sourceforge.net/p/bochs/discussion/39592/thread/5e397455
and started skipping one instruction in my breakpoint.
I still don't understand the discrepancy between some people installing
the handler at entry 9, and others installing at entry 0x21 = 33.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Looks like the reset loops stop if we create null handlers for the first
10 indexes in the IDT.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|