logo

drewdevault.com

[mirror] blog and personal website of Drew DeVault git clone https://hacktivis.me/git/mirror/drewdevault.com.git

KnightOS-was-interesting.md (4648B)

    

  1. ---
  2. date: 2020-01-27
  3. title: KnightOS was an interesting operating system
  4. layout: post
  5. tags: [knightos]
  6. ---
  8. [KnightOS](https://knightos.org) is an operating system I started writing about
  9. 10 years ago, for Texas Instruments line of z80 calculators — the TI-73,
  10. TI-83+, TI-84+, and similar calculators are supported. It still gets the rare
  11. improvements, but these days myself and most of the major contributors are just
  12. left with starry eyed empty promises to themselves that one day they'll do one
  13. of those big refactorings we've been planning... for 4 or 5 years now.
  15. Still, it was a really interesting operating system which was working under some
  16. challenging constraints, and overcame them to offer a rather nice Unix-like
  17. environment, with a filesystem, preemptive multiprocessing *and* multithreading,
  18. assembly and C programming environments, and more. The entire system was written
  19. in handwritten z80 assembly, almost 50,000 lines of it, on a compiler toolchain
  20. we built from scratch.
  22. There was only 64 KiB of usable RAM. The kernel stored *all* of its state in
  23. 1024 bytes of statically allocated RAM. Many subsystems used overlapping parts
  24. of this memory, which was carefully planned for to avoid conflicts. The
  25. userspace memory allocator used a simple linked list for tracking allocations,
  26. to minimize the overhead of each allocation and maximize the usable space for
  27. userspace programs. There was no MMU in the sense that we have on modern
  28. computers, so any program could freely overwrite any other programs. In fact,
  29. the "userspace" task switching GUI would read the kernel's process table
  30. directly to make a list of running programs.
  32. The non-volatile storage was NOR Flash, which presents some interesting
  33. constraints. In the worst case we only had 512 KiB of storage, and even in the
  34. best case just 4MiB (this for a device released in 2013). This space was shared
  35. with the kernel, whose core code was less than 4KiB, and including high-address
  36. subsystems still clocked in at less than 16KiB. Due to the constraints of NOR
  37. Flash, a custom filesystem was designed which did all daily operations by only
  38. *resetting* bits in the underlying storage. In order to *set* any bits, we had
  39. to set the entire 64 KiB sector to 1. Overhead was also kept to a bare minimum
  40. here to maximize storage space available to users.
  42. Writing to Flash storage also renders it unreadable while the operation is in
  43. progress. The kernel normally executes directly from Flash, resident at the
  44. bottom of the memory. Therefore, in order to modify Flash, the kernel's Flash
  45. driver copies part of itself to RAM, jumps to it, and then jumps back after the
  46. operation is complete. Recall that all of the kernel's memory is statically
  47. allocated, and there's not much of it — we used only 128 bytes for the
  48. code which runs in RAM, and it's shared with some other stuff that we had to
  49. plan around. In order to meet these constraints, we employ *self modifying code*
  50. — the Flash driver copies some of itself into RAM, then pre-computes some
  51. information and *modifies* that machine code in-place before jumping to it.
  53. We also had some basic networking support. The calculator has a 2.5mm jack,
  54. similar to headphone jacks — if you had a 3.5mm adapter, we had a music
  55. player which would play MIDI or WAV files. The kernel had direct control of the
  56. voltages on the ring and tip, and had to bitbang them directly in software[^1].
  57. Based on this we built some basic networking support, which supported
  58. calculator-to-calculator and calculator-to-PC information exchange. Later models
  59. had a mini-USB controller (which, funnily enough, can also be bitbanged in
  60. software), but we never ended up writing a driver for it.
  62. [^1]: Newer hardware revisions had some support hardware which was capable of transferring a single byte without software intervention.
  64. The KnightOS kernel also includes some code which is the first time I ever wrote
  65. ["here be dragons"](https://github.com/KnightOS/kernel/blob/e257f54e021ee743306a2a4a5a152860728fb3f8/src/00/restarts.asm#L129-L130)
  66. into a comment, and I don't think I've topped it since.
  68. Despite these constraints, KnightOS is completely booted up to a useful
  69. Unix-like (with a graphical interface) faster than you can lift your finger off
  70. of the power button. The battery could last the entire semester, if you're
  71. lucky. Can the device you're reading this on claim the same?[^2]
  73. [^2]: The device I'm writing this blog post with is 3500&times; faster than my calculator, has 262,144&times; more RAM, and 2.1×10<sup>6</sup> times more storage space.
  75. <video controls src="https://yukari.sr.ht/knightos.webm"></video>