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

	Commit message (Expand)	Author	Age	Files	Lines
*	6014	Kartik Agaram	2020-02-17	1	-2/+2
*	5924	Kartik Agaram	2020-01-27	1	-52/+52
*	5897 - rename comparison instructions	Kartik Agaram	2020-01-16	1	-37/+37
*	5883 - drop the `ref` keyword	Kartik Agaram	2020-01-12	1	-23/+23
*	5876 - address -> addr	Kartik Agaram	2020-01-03	1	-28/+28
*	5804	Kartik Agaram	2019-12-08	1	-71/+71
*	5794	Kartik Agaram	2019-12-06	1	-43/+43
*	5790	Kartik Agaram	2019-12-05	1	-26/+26
*	5782 - fix a widespread bug with Heap-size	Kartik Agaram	2019-11-30	1	-1/+1
*	5765	Kartik Agaram	2019-11-26	1	-3/+3
*	5715	Kartik Agaram	2019-10-26	1	-22/+17
*	5714	Kartik Agaram	2019-10-25	1	-80/+26
*	5700	Kartik Agaram	2019-10-17	1	-1/+1
*	5698	Kartik Agaram	2019-10-15	1	-69/+69
*	5675 - move helpers from subx-common into layers	Kartik Agaram	2019-09-19	1	-20/+20
*	5668 - start reorg to permit syntax sugar in layers	Kartik Agaram	2019-09-19	1	-8/+8
*	5661	Kartik Agaram	2019-09-15	1	-2/+2
*	5607	Kartik Agaram	2019-09-01	1	-2/+2
*	5600	Kartik Agaram	2019-08-31	1	-10/+12
*	5592 - switch register names to lowercase	Kartik Agaram	2019-08-26	1	-1304/+1304
*	5590	Kartik Agaram	2019-08-25	1	-1/+1
*	5589	Kartik Agaram	2019-08-25	1	-1/+1
*	parsing *(reg+disp)	Kartik Agaram	2019-08-24	1	-0/+1
*	get desugar working on the commandline	Kartik Agaram	2019-08-13	1	-1/+0
*	better error message when get aborts	Kartik Agaram	2019-08-12	1	-8/+11
*	5499	Kartik Agaram	2019-07-31	1	-1/+1
*	5485 - promote SubX to top-level	Kartik Agaram	2019-07-27	1	-0/+4787

Some apps written in SubX and Mu. Where the rest of this repo relies on a few Linux syscalls, the apps in this subdirectory interface directly with hardware. We still need the top-level and apps to build them. I'd like to eventually test these programs on real hardware, and to that end they are extremely parsimonious in the hardware they assume: 0. Lots (more than 640KB/1MB[1]) of RAM 1. Pure-graphics video mode (1024x768 pixels) in 256-color mode. At 8x8 pixels per grapheme, this will give us 160x128 graphemes. But it's still an open question if it's reasonably widely supported by modern hardware. If it isn't, I'll downsize. 2. Keyboard. Just a partial US keyboard for now. That's it: * No wifi, no networking * No multitouch, no touchscreen, no mouse * No graphics acceleration * No virtual memory, no memory reclamation Just your processor, gigabytes of RAM[1], a moderately-sized monitor and a keyboard. (The mouse should also be easy to provide.) We can't yet read from or write to disk, except for the initial load of the program. Enabling access to lots of RAM gives up access to BIOS helpers for the disk. These programs don't convert to formats like ELF that can load on other operating systems. There's also currently no code/data segment separation, just labels and bytes. I promise not to write self-modifying code. Security and sandboxing is still an open question. Most programs here assume `main` starts at address 0x9000 (7KB or 14 disk sectors past the BIOS entrypoint). See baremetal/boot.hex for details. So far the programs have only been tested in Qemu and Bochs emulators. [1] Though we might need to start thinking of [the PC memory map](https://wiki.osdev.org/Memory_Map_(x86)) as our programs grow past the first 512KB of memory. Writing to random locations can damage hardware or corrupt storage devices.