about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* 7528 - heap allocatorKartik Agaram2021-01-164-4/+843
|
* 7527Kartik Agaram2021-01-162-0/+3
|
* 7526Kartik Agaram2021-01-1616-0/+14
|
* 7525Kartik Agaram2021-01-162-1/+37
| | | | | | 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-156-4/+21
| | | | | | | | | | | | | | | | | | | | 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-156-5/+750
| | | | | | | | 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.
* 7520Kartik Agaram2021-01-1425-686/+970
|
* .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-133-10/+10
|
* 7513Kartik Agaram2021-01-132-63/+59
|
* 7512 - stale .ctagsKartik Agaram2021-01-139-72/+72
|
* 7511Kartik Agaram2021-01-133-248/+417
|
* 7510 - baremetal: a game of snakeKartik Agaram2021-01-132-0/+107
|
* 7509Kartik Agaram2021-01-1322-148/+762
|
* 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
|
* 7506Kartik Agaram2021-01-122-0/+46
|
* 7505Kartik Agaram2021-01-122-18/+18
|
* 7504Kartik Agaram2021-01-122-6/+300
|
* 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-123-4/+4
|
* 7498Kartik Agaram2021-01-116-94/+181
|
* 7497Kartik Agaram2021-01-113-236/+82
|
* 7496Kartik Agaram2021-01-111-0/+4
|
* 7495Kartik Agaram2021-01-111-1/+1
|
* 7494Kartik Agaram2021-01-0923-300/+1991
|
* 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
|