about summary refs log tree commit diff stats
path: root/baremetal
Commit message (Collapse)AuthorAgeFilesLines
...
* 7508Kartik Agaram2021-01-134-24/+47
| | | | | | This is the right way to be direction-independent. Don't save the cursor when drawing a single grapheme. Where the next char goes is just a property of the direction-oriented primitives.
* 7507 - baremetal: drawing text down then rightKartik Agaram2021-01-124-1/+204
|
* 7505Kartik Agaram2021-01-121-9/+9
|
* 7504Kartik Agaram2021-01-121-6/+17
|
* 7503 - baremetal: noodling on default VGA paletteKartik Agaram2021-01-123-0/+451
|
* 7502 - baremetal text: better interfaceKartik Agaram2021-01-122-9/+13
|
* 7501 - baremetal: draw text within a rectangleKartik Agaram2021-01-123-0/+96
|
* 7500 - baremetal: bounds-check screen space before drawingKartik Agaram2021-01-124-6/+106
|
* 7499Kartik Agaram2021-01-121-0/+0
|
* 7497Kartik Agaram2021-01-112-87/+82
|
* 7496Kartik Agaram2021-01-111-0/+4
|
* 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-093-0/+86
|
* 7489 - include GNU UnifontKartik Agaram2021-01-095-9/+252
| | | | | | | 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
|
* 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
|
* 7477Kartik Agaram2020-12-301-2/+2
|
* 7471Kartik Agaram2020-12-291-2/+2
|
* 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-294-0/+95
| | | | | 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.
* 7467Kartik Agaram2020-12-292-1/+7
|
* 7466Kartik Agaram2020-12-292-2/+2
|
* 7462 - SubX version of baremetal/ex2.subxKartik Agaram2020-12-291-0/+35
|
* 7461Kartik Agaram2020-12-296-13/+8
|
* 7460 - baremetal backend for SubXKartik Agaram2020-12-291-0/+23
|
* 7437 - baremetal: draw pixel on keyboard eventKartik Agaram2020-12-282-7/+68
| | | | | It's now clear that our keyboard handler doesn't trigger after the first event.
* 7436Kartik Agaram2020-12-272-22/+22
| | | | Start highlighting lines that may need to be recomputed when offsets change.
* 7435 - baremetal: buffer for keyboard eventsKartik Agaram2020-12-271-20/+49
| | | | | | | | | 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.
* 7434Kartik Agaram2020-12-271-1/+1
| | | | Fix a stale displacement.
* 7433 - some major layout changesKartik Agaram2020-12-272-55/+51
| | | | | | 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.
* 7432Kartik Agaram2020-12-271-5/+5
| | | | | Bugfix: 32-bit code in 16-bit mode. Seems like it was benign, maybe.
* 7431Kartik Agaram2020-12-271-1/+1
| | | | Typo.
* 7430Kartik Agaram2020-12-271-1/+1
|
* 7428Kartik Agaram2020-12-278-555/+0
|
* 7427Kartik Agaram2020-12-272-2/+2
|
* 7425 - baremetal: render the paletteKartik Agaram2020-12-271-6/+5
| | | | | It's now very obvious that we don't actually have 256 unique colors by default in 256-color graphics modes.
* 7424 - baremetal: downsize graphics resolutionKartik Agaram2020-12-274-6/+7
| | | | | | | | 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.
* 7423Kartik Agaram2020-12-271-6/+15
|
* 7422Kartik Agaram2020-12-261-2/+1
|
* 7421 - baremetal: beginnings of keyboard mapKartik Agaram2020-12-261-16/+37
| | | | First keypress is detected, but we need to ack it somehow.
* 7420Kartik Agaram2020-12-261-1/+2
|
* 7419Kartik Agaram2020-12-261-0/+1
|
* 7418 - baremetal: adjust entrypoint addressKartik Agaram2020-12-264-8/+151
| | | | | | | | | | | We need a few pages of data for the keyboard mappings. If I moved them to some later address I'd be able to keep the nice round starting address unchanged. But that seems like a superficial aesthetic concern. There's really no value in having an array of hex bytes represented in SubX rather than just raw hex. And it's better to colocate data near the handler code which uses it (and which runs instructions SubX doesn't support).
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-07-08 13:12:57 +0000