| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
Make some room for a mouse handler.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was tedious for three reasons beyond the usual one of having to
track and update offsets several time while I debug:
- The Bochs troubles of the previous commit kept polluting my brain
even though they were irrelevant.
- I had to keep some changes locally to allow myself to use Bochs,
which polluted my working directory.
- I had to travel the long way to the realization that I'm not
actually initializing the stack anywhere. BIOS was starting my stack
off at 0x10000, which was promptly clobbered by my second read from
disk.
The good news: while I'm here I grow the interrupt descriptor table. So
I don't have to go through this exercise when I get back to supporting
the mouse.
|
| |
|
|
|
|
| |
Bochs is still broken, but before we can fix it we need to make some
room in the boot sector. So we'll spend a few commits reorganizing
things.
|
| |
|
|
|
|
|
| |
https://en.wikipedia.org/wiki/GNU_Unifont#The_.hex_font_format
http://unifoundry.com/unifont/index.html
Since GNU Unifont is covered under the GPL v2, so I believe is this repo.
|
| | |
|
| | |
|
| |
|
|
| |
Start highlighting lines that may need to be recomputed when offsets change.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
This works, but colors are unexpected. 0xff isn't white. Lots of colors
are black. Perhaps I need to initialize a palette.
|