http://akkartik.github.io/mu/html/baremetal/vga_palette.html
To my eyes it looks like I can/should just live in the first 128 colors.
http://akkartik.github.io/mu/html/baremetal/vga_palette.html
To my eyes it looks like I can/should just live in the first 128 colors.
New 2-minute video:
https://archive.org/details/akkartik-2min-2021-01-12
You get just one fixed screen resolution: 1024x768, 256 colors. Widely available on modern machines, no drivers needed.
You get just one fixed-width bitmap font. No bold/italics, no anti-aliasing.
BUT it won't make assumptions about English and left-to-right order. I eventually want anybody to be able to customize it to their language.
Main project page: https://github.com/akkartik/mu
Mu can now render text atop baremetal x86.
Try clicking around from http://akkartik.github.io/mu/html/apps/ex5.mu.html
The boot-up machine code reads a few sectors from disk, configures a keyboard handler, and loads a bitmap font (2KB for ASCII, with the option for more).
I use GNU Unifont. I believe that means Mu is now GPL v2. So stated. IANAL and I try not to think about software IP. But a font? Copyright seems reasonable there.
Next up: a text editor!
https://github.com/akkartik/mu
All Mu really needs so far is to print to screen and read from the keyboard. Here's a 2-minute video about achieving that:
https://archive.org/details/akkartik-2min-2020-12-24
It seems such a small thing. But I needed lots of help, as you can see from the additions to my credits.
Merry Christmas to all! What a beautiful world.
Project page: https://github.com/akkartik/mu
More context: https://mastodon.social/@akkartik/104896128141863951
https://archive.org/details/akkartik-2min-2020-12-06
Long delay since my last video. Printing floating-point numbers is really hard. I'm still half-assing it.
As a follow-up to my previous post, I'm tightening focus to two threads:
Deprioritized for now:
Damn hands are acting up again. RSI. Perhaps I should give up on Advent.
Mu's compromises:
:/ Constraints I consider "temporary" are perhaps not.
Want less. — The Buddha
I seem to be settling into a pattern of solving these on alternate days. Late for one round, early for the next.
Day 4 solutions (spoiler alert):
http://akkartik.github.io/mu/html/apps/advent2020/4a.mu.html
http://akkartik.github.io/mu/html/apps/advent2020/4b.mu.html (utterly ghastly)
2.5 hours. 2 machine-code bugs found, 1 new (terribly named) library primitive added: https://github.com/akkartik/mu/commit/18d5bab2b66
Day 5 solutions:
http://akkartik.github.io/mu/html/apps/advent2020/5a.mu.html
http://akkartik.github.io/mu/html/apps/advent2020/5b.mu.html
30 minutes. No new Mu bugs found.
Project page: https://github.com/akkartik/mu
Day 2 solutions (spoiler alert): 2a 2b.
40 minutes. No new Mu bugs found, no machine-code hacking was needed.
60 minutes. Lost 11 minutes debugging a silly mistake (see commit log)
No new Mu bugs found, no machine-code hacking was needed.
Project page: https://github.com/akkartik/mu
http://akkartik.github.io/mu/html/linux/apps/advent2020/1a.mu.html Day 1 part 1 solution (don't click if you don't want to be spoiled):
Took me about 40 minutes. In the process, I had to:
We'll see how long I can keep this up. Linear scans will soon not cut it.
Day 1 part 2 (same deal, same spoiler alert, just more brute force): http://akkartik.github.io/mu/html/apps/advent2020/1b.mu.html
Part 1 took 40 minutes and part 2 took 18. Therefore I'm getting better at this.
Project page: https://github.com/akkartik/mu
https://stackoverflow.com/questions/32785998/symbol-for-bitwise-circular-shifts
Kinda surprising that there isn't a standard answer yet, given how common it is in cryptography, and how much of a workhorse it is in the ARM instruction set.