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
*	7489 - include GNU Unifont	Kartik Agaram	2021-01-09	1	-4/+247
\| \| \| \| \| \| \|	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.
*	7485	Kartik Agaram	2021-01-09	1	-8/+10
\|
*	7484	Kartik Agaram	2021-01-09	1	-0/+1
\|
*	7480 - baremetal/ex3.hex now draws multiple pixels	Kartik Agaram	2021-01-07	1	-6/+13
\| \| \| \| \| \| \| \| \| \|	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.
*	7479	Kartik Agaram	2021-01-07	1	-3/+3
\|
*	7461	Kartik Agaram	2020-12-29	1	-1/+1
\|
*	7437 - baremetal: draw pixel on keyboard event	Kartik Agaram	2020-12-28	1	-7/+11
\| \| \| \| \|	It's now clear that our keyboard handler doesn't trigger after the first event.
*	7436	Kartik Agaram	2020-12-27	1	-19/+19
\| \| \| \|	Start highlighting lines that may need to be recomputed when offsets change.
*	7435 - baremetal: buffer for keyboard events	Kartik Agaram	2020-12-27	1	-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.
*	7434	Kartik Agaram	2020-12-27	1	-1/+1
\| \| \| \|	Fix a stale displacement.
*	7433 - some major layout changes	Kartik Agaram	2020-12-27	1	-54/+50
\| \| \| \| \| \|	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.
*	7432	Kartik Agaram	2020-12-27	1	-5/+5
\| \| \| \| \|	Bugfix: 32-bit code in 16-bit mode. Seems like it was benign, maybe.
*	7431	Kartik Agaram	2020-12-27	1	-1/+1
\| \| \| \|	Typo.
*	7430	Kartik Agaram	2020-12-27	1	-1/+1
\|
*	7424 - baremetal: downsize graphics resolution	Kartik Agaram	2020-12-27	1	-2/+2
\| \| \| \| \| \| \| \|	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.
*	7422	Kartik Agaram	2020-12-26	1	-2/+1
\|
*	7421 - baremetal: beginnings of keyboard map	Kartik Agaram	2020-12-26	1	-16/+37
\| \| \| \|	First keypress is detected, but we need to ack it somehow.
*	7418 - baremetal: adjust entrypoint address	Kartik Agaram	2020-12-26	1	-4/+147
\| \| \| \| \| \| \| \| \| \| \|	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).
*	7417 - baremetal: drawing on LFB in Bochs	Kartik Agaram	2020-12-26	1	-1/+2
\|
*	7415 - baremetal: locate the linear frame buffer	Kartik Agaram	2020-12-26	1	-6/+55
\| \| \| \| \|	0xa0000 only contains a single bank's worth of memory-mapped video RAM. The LFB is supposed to have everything.
*	7414	Kartik Agaram	2020-12-26	1	-14/+14
\|
*	7413	Kartik Agaram	2020-12-26	1	-4/+4
\|
*	7411	Kartik Agaram	2020-12-26	1	-1/+1
\|
*	7404 - baremetal: first example program	Kartik Agaram	2020-12-26	1	-0/+338
	Design choice: all programs will use a graphics mode (1280x1024) with 256 colors. That should be fairly widely available. (It turns out text modes larger than 80x25 are not widely available even among modern emulators. Mu will need fonts sooner rather than later.) Mu will never try to be smart and do things like autodetect your hardware. We _will_ help you modify Mu for your hardware.