| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
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.)
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
A new phase for baremetal compilations. Doesn't work yet, but it passes
all its tests, so we can add it to CI.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
It's now clear that our keyboard handler doesn't trigger after the first
event.
|
|
|
|
| |
Start highlighting lines that may need to be recomputed when offsets change.
|
|
|
|
|
|
|
|
|
| |
I'm trying to read the status register, but I'm still not seeing the breakpoint
being hit a second time. (And I again ran into the Bochs bug that breakpoints
at the first instruction of an interrupt handler don't work.)
Maybe this is just a debugger issue. Let's keep going, and try to start
using the keyboard events.
|
|
|
|
| |
Fix a stale displacement.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Bugfix: 32-bit code in 16-bit mode.
Seems like it was benign, maybe.
|
|
|
|
| |
Typo.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
First keypress is detected, but we need to ack it somehow.
|
| |
|
| |
|