249bef13d8
|
||
|---|---|---|
| .. | ||
| shell | ||
| 101screen.subx | ||
| 102keyboard.subx | ||
| 103grapheme.subx | ||
| 104test.subx | ||
| 105string-equal.subx | ||
| 106stream.subx | ||
| 108write.subx | ||
| 109stream-equal.subx | ||
| 112read-byte.subx | ||
| 113write-stream.subx | ||
| 115write-byte.subx | ||
| 117write-int-hex.subx | ||
| 118parse-hex-int.subx | ||
| 120allocate.subx | ||
| 121new-stream.subx | ||
| 123slice.subx | ||
| 124next-token.subx | ||
| 126write-int-decimal.subx | ||
| 127next-word.subx | ||
| 301array-equal.subx | ||
| 302stack_allocate.subx | ||
| 308allocate-array.subx | ||
| 309stream.subx | ||
| 310copy-bytes.subx | ||
| 311decimal-int.subx | ||
| 312copy.subx | ||
| 313index-bounds-check.subx | ||
| 314divide.subx | ||
| 400.mu | ||
| 403unicode.mu | ||
| 408float.mu | ||
| 411string.mu | ||
| 412render-float-decimal.mu | ||
| 500text-screen.mu | ||
| 501draw-text.mu | ||
| 502test.mu | ||
| 503manhattan-line.mu | ||
| 504test-screen.mu | ||
| README.md | ||
| boot.bochsrc | ||
| boot.hex | ||
| boot0.hex | ||
| ex1.hex | ||
| ex1.subx | ||
| ex2.hex | ||
| ex2.mu | ||
| ex2.subx | ||
| ex3.hex | ||
| ex3.mu | ||
| ex4.mu | ||
| ex5.mu | ||
| ex6.mu | ||
| ex7.mu | ||
| ex8.mu | ||
| life.mu | ||
| mu-init.subx | ||
| rpn.mu | ||
| vga_palette | ||
| vga_palette.c | ||
| vga_palette.png | ||
| vimrc.vim | ||
README.md
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:
- Lots (more than 640KB/1MB[1]) of RAM
- 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.
- Keyboard. Just a partial US keyboard for now. Main qwerty zone only. No number pad, no function keys, no ctrl/alt/meta/fn/super/capslck/numlck.
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.
Programs start executing at address 0x9400. See baremetal/boot.hex for details.
Mu programs always run all their automated tests first. main only runs if
there are no failing tests. See baremetal/mu-init.subx 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 as our programs grow past the first 32MB of memory. Mu doesn't yet make any attempt to understand how much RAM the underlying computer has. Also, writing to random locations can damage hardware or corrupt storage devices.