about summary refs log tree commit diff stats
path: root/baremetal
Commit message (Collapse)AuthorAgeFilesLines
* 7528 - heap allocatorKartik Agaram2021-01-164-4/+843
|
* 7527Kartik Agaram2021-01-162-0/+3
|
* 7525Kartik Agaram2021-01-161-1/+35
| | | | | | Bring back runtime support for bounds-checking arrays. Again, the error messages kinda suck, because I can't yet print integers. But something is better than nothing.
* 7524 - bring back some abort messagesKartik Agaram2021-01-153-6/+33
| | | | | | | | | | | Our infrastructure for displaying errors is far more rudimentary in baremetal. Many ways things can go wrong. But making the attempt seems better than not. I'm also making some effort to keep it easy to see what has been copied over from the top-level, by not modifying copied code to use syntax sugar and so on. It may not be an important enough reason to mix notations in a single file.
* 7523Kartik Agaram2021-01-155-4/+18
| | | | | | | | | | | | | | | | | | | | There's a dependency cycle here: - draw-grapheme (Mu) uses read-grapheme (Mu) to be unicode-aware. - read-grapheme uses read-byte (SubX). Streams are a fundamental data structure in Mu. For the Mu compiler to be able to reason about the safety of stream operations, they need to be an opaque type. All stream primitives are written in SubX. To manipulate a stream's internals we force people to reach for SubX. That way if there's no SubX code there's confidence that things are safe. - read-byte and other stream operations have unit tests, like they should. The unit tests need to print data to screen when say a test fails. To do this they use various check- functions (SubX) that take a string argument. - Printing a string to screen uses draw-grapheme (Mu). Perhaps I should maintain variants of drawing primitives that operate only on ASCII.
* 7522 - bring back a few tests in .subx filesKartik Agaram2021-01-155-5/+744
| | | | | | | | Even though baremetal has tests in SubX, they can only run in Mu programs since the test harness is currently in a Mu layer. Baremetal isn't really intended for running SubX programs at the moment. Is this a step down the slippery slope towards C compilers that I complained about in http://akkartik.name/akkartik-convivial-20200607.pdf?
* 7521 - new plan for testsKartik Agaram2021-01-1511-78/+124
| | | | | | | | | | It's not really manageable to make the fake screen pixel-oriented. Feels excessive to compare things pixel by pixel when we will mostly be writing text to screen. It'll also make expected screen assertions more difficult to manage. So I'm not sure how to make assertions about pixels for now. Instead we'll introduce fake screens at draw-grapheme.
* .Kartik Agaram2021-01-141-0/+1
|
* 7519 - baremetal: run all tests on bootKartik Agaram2021-01-136-3/+87
|
* 7518Kartik Agaram2021-01-1310-0/+19
|
* 7517Kartik Agaram2021-01-131-1/+6
|
* 7516Kartik Agaram2021-01-132-20/+11
|
* 7514Kartik Agaram2021-01-131-0/+0
|
* 7513Kartik Agaram2021-01-131-30/+28
|
* 7510 - baremetal: a game of snakeKartik Agaram2021-01-132-0/+107
|
* 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.
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-07-03 09:53:32 +0000