mu - Soul of a tiny new machine. More thorough tests → More comprehensible and rewrite-friendly software → More resilient society.

	Commit message (Collapse)	Author	Age	Files	Lines
*	7743	Kartik K. Agaram	2021-02-14	1	-2/+2
\| \| \| \|	First bugfix in baremetal/shell. Already it's much easier to debug.
*	7718	Kartik K. Agaram	2021-02-11	1	-4/+4
\| \| \| \|	Bugfix in clear-screen.
*	7713	Kartik K. Agaram	2021-02-10	1	-2/+7
\|
*	7698 - starting to test-drive baremetal shell	Kartik Agaram	2021-02-07	1	-0/+9
\|
*	7696	Kartik Agaram	2021-02-07	1	-1/+0
\|
*	7694 - baremetal: asserting bg color in tests	Kartik Agaram	2021-02-07	1	-2/+5
\|
*	7693 - baremetal: pass background color everywhere	Kartik Agaram	2021-02-07	1	-4/+24
\|
*	7690	Kartik Agaram	2021-02-07	1	-5/+5
\| \| \| \|	Convert comments about magic constants into metadata.
*	7548 - baremetal: better cursor management	Kartik Agaram	2021-01-23	1	-7/+16
\|
*	7542 - baremetal: support cursor on a grapheme	Kartik Agaram	2021-01-22	1	-4/+9
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	So far we've drawn a space implicitly at the cursor. Now I allow drawing an arbitrary grapheme when drawing the cursor. But the caller has to specify what to draw. (The alternative would be for layer 103 to track every single grapheme on screen along with its color and any other future attributes, just to be able to paint and unpaint the background for a single character.) I've modified existing helpers for drawing multiple graphemes to always clear the final cursor position after they finish drawing. That seems reasonable for terminal-like applications. Applications that need to control the screen in a more random-access manner will need to track the grapheme at the cursor for themselves.
*	7538 - baremetal: screen coords in graphemes	Kartik Agaram	2021-01-22	1	-1/+2
\|
*	7537 - baremetal: start of cursor support	Kartik Agaram	2021-01-19	1	-2/+5
\|
*	7535	Kartik Agaram	2021-01-17	1	-2/+2
\|
*	7534	Kartik Agaram	2021-01-17	1	-3/+1
\| \| \| \|	Don't assume screen dimensions.
*	7529 - baremetal: fake screen	Kartik Agaram	2021-01-16	1	-5/+187
\|
*	7521 - new plan for tests	Kartik Agaram	2021-01-15	1	-0/+64
	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.