mu/baremetal
Kartik Agaram 0518944e37 7491 - baremetal: draw ASCII text to screen 2021-01-09 18:29:04 -08:00
..
101screen.subx 7470 2020-12-29 21:17:03 -08:00
102keyboard.subx 7486 - primitive for reading keys 2021-01-09 10:39:12 -08:00
103grapheme.subx 7490 - baremetal: draw a grapheme to screen 2021-01-09 18:28:14 -08:00
313index-bounds-check.subx 7491 - baremetal: draw ASCII text to screen 2021-01-09 18:29:04 -08:00
400.mu 7490 - baremetal: draw a grapheme to screen 2021-01-09 18:28:14 -08:00
401draw-text-rightward.mu 7491 - baremetal: draw ASCII text to screen 2021-01-09 18:29:04 -08:00
README.md 7489 - include GNU Unifont 2021-01-09 18:20:28 -08:00
boot.bochsrc 7461 2020-12-29 18:56:21 -08:00
boot.hex 7489 - include GNU Unifont 2021-01-09 18:20:28 -08:00
boot0.hex 7403 - baremetal/ for apps without a kernel 2020-12-26 13:30:04 -08:00
ex1.hex 7489 - include GNU Unifont 2021-01-09 18:20:28 -08:00
ex1.subx 7488 2021-01-09 13:45:41 -08:00
ex2.hex 7489 - include GNU Unifont 2021-01-09 18:20:28 -08:00
ex2.mu 7477 2020-12-30 19:25:32 -08:00
ex2.subx 7488 2021-01-09 13:45:41 -08:00
ex3.hex 7489 - include GNU Unifont 2021-01-09 18:20:28 -08:00
ex3.mu 7486 - primitive for reading keys 2021-01-09 10:39:12 -08:00
ex4.mu 7490 - baremetal: draw a grapheme to screen 2021-01-09 18:28:14 -08:00
ex5.mu 7491 - baremetal: draw ASCII text to screen 2021-01-09 18:29:04 -08:00
mu-init.subx 7469 - first working baremetal Mu program 2020-12-29 21:08:05 -08:00
vimrc.vim 7466 2020-12-29 20:29:55 -08:00

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:

  1. Lots (more than 640KB/1MB[1]) of RAM
  2. 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.
  3. 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 as our programs grow past the first 512KB of memory. Writing to random locations can damage hardware or corrupt storage devices.