| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
Port some support for unicode to baremetal.
|
| |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
| |
It also clears keys after reading them, allowing us to read more than 16
keys.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I was wrong in commit 7437 that only one keystroke was working. The problem
was just that I was getting _too_ many events. I wasn't handling key-up
events, and they were entering the buffer, and I was not skipping null
events since the circular buffer is currently considered to be null-terminated.
ex3 isn't done yet; it can only handle 16 events. Apps need to be clearing
the keyboard buffer.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
The ol' 8-byte-register-names issue strikes again. There's no way to access
the lower 8 bits of ESI.
There's still a bug in baremetal/ex2.mu; it's printing transposed somehow.
|
|
|
|
|
| |
It doesn't _quite_ do what it should, so this is more precisely the first
_buggy_ baremetal Mu program. But the tooling works, at least.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Bring baremetal variant up to date with recent changes.
|
|
|
|
| |
Switch survey_elf to the new approach.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
New approach to disambiguating /disp32 arguments: based on opcodes rather
than metadata.
I interpret /disp32 as PC-relative in a short list of instructions. Otherwise
it's absolute if it gets a label.
There should be no reason to pass labels into /disp8 or /disp16.
|
|
|
|
| |
Go back to commit 7448.
|
|
|
|
|
| |
Snapshot: this approach of disambiguating /disp32 based on metadata doesn't
work. The `survey` phase runs after `pack`, which gets rid of most metadata.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's an ambiguity in how x86 interprets disp32 fields:
- For jumps and calls they're displacements from the starting address of
the next instruction. So far so good.
- However, when the ModR/M requires them they can also be absolute addresses.
Ideally I'd take the presence of the ModR/M byte into account in interpreting
them.
However, it's easier to assume relative addressing only for labels in the
code segment.
This commit raises an error if we ever refer to labels in the code segment
in instructions with a ModR/M byte. (I'm assuming that no instruction with
a ModR/M byte will ever use a displacement without the ModR/M byte requiring
it.)
|
| |
|
| |
|
| |
|
| |
|