| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
What I have so far is crap. Roll baremetal/boot.hex back to commit 7673.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
No handler yet, just initialization.
Bochs boots up; Qemu gets into a reboot loop.
Unlike the keyboard where I did the minimum necessary for Qemu, here I
am blindly copying something alleged to work on "real hardware." Makes
no difference to the failure modes I'm seeing.
Even in this tiny endeavor I see the abyss open up. Poke bytes at some
sequence of ports, read back bytes from some sequence ports; it's like
sending out prayers.
|
| | |
|
| | |
|
| |
|
|
| |
Make some room for a mouse handler.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Somehow everything worked with this bug.
|
| | |
|
| |
|
|
| |
Yup, a single read suffices. Might not work on real hardware, but YAGNI.
|
| |
|
|
|
| |
Holy crap, perhaps the limitations of int 13h were all a mirage. I just
needed to initialize the stack.
|
| |
|
|
|
| |
Another attempt at reorganizing how I read disks. Everything continues
to work in Qemu, but Bochs still doesn't love me.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Oh, stupid mistake in segmented address calculation. Now Qemu's working
again everywhere. Bochs is again broken everywhere. But I think we're
getting closer. I think Bochs's BIOS implementation for reading sectors
has two interacting constraints:
- Can't write to more than 0x10000 bytes past segment register.
- Can't write across segment alignment boundaries.
Qemu only cares about the first.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While baremetal has been working with Qemu, it's been broken with Bochs
since commit 7547, where we started reading more than 63 sectors (1
track) from disk.
Good to know that Bochs simulates native hardware with so much
verisimilitude!
Unfortunately things aren't fixed yet. The current state:
- Qemu - - Bochs -
ex2.hex never switches modes works
ex2.subx never switches modes works
ex2.mu never switches modes fails unit tests
It sucks that Bochs doesn't have strictly superior verisimilitude
compared to Qemu :(
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Still in progress. Known bugs:
* Cursor management is broken. Every line currently seems to leave
behind a shadow cursor.
* No shift-key support yet, which means no addition or multiplication.
(This app doesn't have division yet.)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far we've drawn a space implicitly at the cursor. Now I allow drawing
an arbitrary grapheme when drawing the cursor. But the caller has to
specify what to draw. (The alternative would be for layer 103 to
track every single grapheme on screen along with its color and any other
future attributes, just to be able to paint and unpaint the background
for a single character.)
I've modified existing helpers for drawing multiple graphemes to always
clear the final cursor position after they finish drawing. That seems
reasonable for terminal-like applications. Applications that need to
control the screen in a more random-access manner will need to track the
grapheme at the cursor for themselves.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I spent over a week agonizing over this.
* I had to come to terms with the fact that I don't really know how to
make pixel graphics testable. ASCII art on a pixel by pixel basis feels
inhuman. Just focus on text mode for now.
* I had to set aside the problem of non-English family languages.
Languages like Arabic that can stack complex graphemes together likely
can't be fixed-width. But I don't know enough at the moment to solve for
them.
* I spent a while trying to juggle two cursors, one invisible output
cursor for tracking the most recent print, and one visible one that's
just a hint to the user of what the next keystroke will do. But it looks
like I can fold both into a single cursor. Drawing things updates the
location of the cursor but doesn't display it. Explicitly moving the
cursor displays it, but future drawing can overwrite the cursor.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Don't assume screen dimensions.
|
| |
|
|
| |
Both issues of commit 7531 fixed.
|