| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
Gap buffer with a more testable interface for rendering to screen.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
When I'm also checking graphemes I assume that spaces can be in other bg
colors. However, if I want to closely check the bg color for a cell with
a space in it (ahem, cursor), I have to check the color in isolation.
|
| |
|
| |
|
|
|
|
|
| |
It's bad enough that metadata comments are restricted to integer literals;
let's at least make them work on _all_ integer literals.
|
| |
|
|
|
|
| |
Convert comments about magic constants into metadata.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Metadata is always ignored. It's purely for documentation purposes. But
as long as Mu has no named constants it's starting to feel increasingly
essential.
I'm still not going to bother to add metadata to other parts of the language.
Let's see if we need them. Even though it's a little warty that the rules
vary throughout the stack:
- bare SubX: metadata everywhere
- SubX with syntax sugar: no metadata in calls or addressing-mode sigil-expressions
- Mu: metadata only for literal integers
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I spent a week on trying to support it, and I am now past the five
stages of grief.
-- Important things I read
https://web.archive.org/web/20040604041507/http://panda.cs.ndsu.nodak.edu/~achapwes/PICmicro/keyboard/atkeyboard.html
https://web.archive.org/web/20040604043149/http://panda.cs.ndsu.nodak.edu/~achapwes/PICmicro/mouse/mouse.html
https://wiki.osdev.org/index.php?title=Mouse_Input&oldid=23086#Waiting_to_Send_Bytes_to_Port_0x60_and_0x64
says command 0xa8 is optional
SaniK: https://forum.osdev.org/viewtopic.php?t=10247
recommends command 0xa8 before setting Compaq Status byte
Setting Compaq status byte before 0xa8: https://forum.osdev.org/viewtopic.php?f=1&t=19873
This thread also suggests that keeping reads from keyboard vs mouse straight
is non-trivial.
-- Where I got stuck
Following SaniK's recipe doesn't seem to work. It seems like not sending
the 0xa8 command gets us a little closer. I saw the mouse handler
trigger, but it seems to not actually happen in response to mouse
events (vector 0x74 in the interrupt descriptor table).
-- Other options that may be worth considering
USB mouse
Serial mouse
Implementing a PS/2 handler in SubX
would require somehow referring to SubX labels in this file
It seems clear that a mouse driver is complex enough to need a
higher-level language than just hex bytes. But it's _not_ clear how to
_explain_ a mouse driver. There's just a lot of random rules, historical
anecdotes, just-so stories and sheer black magic here. I'm going to try
to do without it all. Mu will be a keyboard-only computer for the
foreseeable future.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
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 :(
|
| |
|
| |
|
| |
|