| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
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.
|
|
|