about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 7493Kartik Agaram2021-01-091-0/+0
|
* 7492Kartik Agaram2021-01-0910-11/+729
| | | | Port some support for unicode to baremetal.
* 7491 - baremetal: draw ASCII text to screenKartik Agaram2021-01-093-0/+41
|
* 7490 - baremetal: draw a grapheme to screenKartik Agaram2021-01-094-0/+88
|
* 7489 - include GNU UnifontKartik Agaram2021-01-098-26/+552
| | | | | | | 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.
* 7488Kartik Agaram2021-01-092-5/+3
|
* 7487Kartik Agaram2021-01-091-21/+18
|
* 7486 - primitive for reading keysKartik Agaram2021-01-093-0/+74
| | | | | It also clears keys after reading them, allowing us to read more than 16 keys.
* 7485Kartik Agaram2021-01-092-11/+13
|
* 7484Kartik Agaram2021-01-091-0/+1
|
* 7483Kartik Agaram2021-01-094-4/+4
|
* 7482Kartik Agaram2021-01-092-3/+3
|
* 7481Kartik Agaram2021-01-072-251/+259
|
* 7480 - baremetal/ex3.hex now draws multiple pixelsKartik Agaram2021-01-072-7/+15
| | | | | | | | | | 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.
* 7479Kartik Agaram2021-01-071-3/+3
|
* 7478Kartik Agaram2021-01-032-2/+2
|
* 7477Kartik Agaram2020-12-302-4/+4
|
* 7476Kartik Agaram2020-12-30188-188/+188
|
* 7475Kartik Agaram2020-12-301-7/+7
|
* 7474Kartik Agaram2020-12-291-1/+1
|
* 7473Kartik Agaram2020-12-294-1/+240
|
* 7472Kartik Agaram2020-12-292-0/+102
|
* 7471Kartik Agaram2020-12-292-2/+9
|
* 7470Kartik Agaram2020-12-291-7/+7
| | | | | | | 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.
* 7469 - first working baremetal Mu programKartik Agaram2020-12-295-0/+104
| | | | | 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.
* 7468Kartik Agaram2020-12-294-55/+59
|
* 7467Kartik Agaram2020-12-292-1/+7
|
* 7466Kartik Agaram2020-12-292-2/+2
|
* 7465Kartik Agaram2020-12-291-4/+3
|
* 7464Kartik Agaram2020-12-293-0/+178
|
* 7463Kartik Agaram2020-12-291-3/+2
|
* 7462 - SubX version of baremetal/ex2.subxKartik Agaram2020-12-293-1/+36
|
* 7461Kartik Agaram2020-12-297-13/+14
|
* 7460 - baremetal backend for SubXKartik Agaram2020-12-294-2178/+263
|
* 7459Kartik Agaram2020-12-292-102/+199
| | | | Bring baremetal variant up to date with recent changes.
* 7458Kartik Agaram2020-12-292-90/+184
| | | | Switch survey_elf to the new approach.
* 7457Kartik Agaram2020-12-282-10/+14
|
* 7456Kartik Agaram2020-12-281-2/+1
|
* 7455Kartik Agaram2020-12-281-2/+15
| | | | | | | | | | 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.
* 7454Kartik Agaram2020-12-285-341/+119
| | | | Go back to commit 7448.
* 7453Kartik Agaram2020-12-281-74/+23
| | | | | Snapshot: this approach of disambiguating /disp32 based on metadata doesn't work. The `survey` phase runs after `pack`, which gets rid of most metadata.
* 7452Kartik Agaram2020-12-284-24/+286
|
* 7451Kartik Agaram2020-12-284-20/+28
|
* 7450Kartik Agaram2020-12-282-2/+2
|
* 7449Kartik Agaram2020-12-281-0/+3
| | | | | | | | | | | | | | | | | | | | 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.)
* 7448Kartik Agaram2020-12-282-0/+18
|
* 7447Kartik Agaram2020-12-282-2/+2
|
* 7446Kartik Agaram2020-12-282-185/+0
|
* 7445Kartik Agaram2020-12-282-185/+0
|
* 7444Kartik Agaram2020-12-281-1/+1
|
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-12-24 03:16:56 +0000