2024-03-16 16:25:48 +00:00
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="generator" content="TempleOS V5.03">
2024-03-23 15:41:41 +00:00
<meta name="viewport" content="width=device-width">
2024-03-16 16:25:48 +00:00
<link rel="stylesheet" href="/style/templeos.css">
<script src="/script/templeos.js"></script>
<style type="text/css">
.cF0{color:#000000;background-color:#ffffff;}
.cF1{color:#0000aa;background-color:#ffffff;}
.cF2{color:#00aa00;background-color:#ffffff;}
.cF3{color:#00aaaa;background-color:#ffffff;}
.cF4{color:#aa0000;background-color:#ffffff;}
.cF5{color:#aa00aa;background-color:#ffffff;}
.cF6{color:#aa5500;background-color:#ffffff;}
.cF7{color:#aaaaaa;background-color:#ffffff;}
.cF8{color:#555555;background-color:#ffffff;}
.cF9{color:#5555ff;background-color:#ffffff;}
.cFA{color:#55ff55;background-color:#ffffff;}
.cFB{color:#55ffff;background-color:#ffffff;}
.cFC{color:#ff5555;background-color:#ffffff;}
.cFD{color:#ff55ff;background-color:#ffffff;}
.cFE{color:#ffff55;background-color:#ffffff;}
.cFF{color:#ffffff;background-color:#ffffff;}
</style>
</head>
<body>
2024-03-23 13:40:50 +00:00
<pre style="font-family: courier, monospace; font-size: 10pt;">
2024-03-16 16:25:48 +00:00
<a name="l1"></a><span class=cF5> Decisions Making TempleOS Simple
<a name="l2"></a></span><span class=cF0>
<a name="l3"></a>Everybody is obsessed, Jedi mind-tricked, by the notion that when you scale-up,
<a name="l4"></a>it doesn't get bad, it gets worse. They automatically think things are going to
<a name="l5"></a>get bigger. Guess what happens when you scale down? It doesn't get good, it
<a name="l6"></a>gets better!
<a name="l7"></a>
<a name="l8"></a>I limited it to 100,000 lines of code, forever! I never need a linker or make
<a name="l9"></a>utility and I can use small labels.
<a name="l10"></a>
<a name="l11"></a>People mock Bill Gates for, "640K should be enough." I say, "2Gig for code
<a name="l12"></a>should be enough." The same people who mock Bill Gates are probably just like
<a name="l13"></a>the black woman who sued for a trillion dollars.
<a name="l14"></a>
<a name="l15"></a>My Dad worked on converting the Titan missile to the Gemini Mission rocket. It
<a name="l16"></a>had to be "man-rated". You can bet that everything got an order of magnitude
<a name="l17"></a>more complexity and documentation. My vision is a souped-up C64, not a 1970's
<a name="l18"></a>mainframe; a kayak, not a Titanic.
<a name="l19"></a>
<a name="l20"></a>Linux is a semi-tractor -- you need professional drivers for 20 gears. Linux
<a name="l21"></a>has file permissions. Common people are hurt by file permissions.
<a name="l22"></a>
<a name="l23"></a>Windows is a car.
<a name="l24"></a>
<a name="l25"></a>TempleOS is a motorcycle -- if you lean-over too far, a motorcycle will crash.
<a name="l26"></a>Don't do that! There are no side air bags on a motorcycle. DOS and C64 had no
<a name="l27"></a>memory protections and ran in ring-0, with no security. This saves an order of
<a name="l28"></a>magnitude complexity.
<a name="l29"></a>
<a name="l30"></a>Linux and Windows are general purpose operating systems. They attempt to do any
<a name="l31"></a>task you want. TempleOS cherry-picks tasks and is designed to do the same
<a name="l32"></a>things a C64 did. This saves and order of magnitude complexity. For example,
2024-03-23 13:40:50 +00:00
<a name="l33"></a>the </span><a href="/Wb/Doc/RedSea.DD.HTML#l1"><span class=cF4>RedSea</span></a><span class=cF0> file system allocates just contiguous files -- you load and save
2024-03-16 16:25:48 +00:00
<a name="l34"></a>whole files at once. A benefit is this allows compression. Also, TempleOS does
<a name="l35"></a>not do networking or multimedia. In theory, memory will fragment with lots of
<a name="l36"></a>big files. The system would fall to pieces with multimedia, but God said
<a name="l37"></a>640x480 16 color is a permanent covenant like circumcision.
<a name="l38"></a>
<a name="l39"></a>A three bttn mouse is like a leg you cannot put weight on. TempleOS just does
<a name="l40"></a>hardware everybody has, with no divergent code bases for each machine's custom
<a name="l41"></a>hardware. There is one graphics driver instead of 50 for different GPUs. This
<a name="l42"></a>saves an order of magnitude complexity and makes for a delightful API, so
<a name="l43"></a>developer's code is not like a frayed rope end.
<a name="l44"></a>
<a name="l45"></a>
<a name="l46"></a>
<a name="l47"></a>* Everything runs in kernel, </span><span class=cF2>ring 0</span><span class=cF0>, mode.
<a name="l48"></a>
<a name="l49"></a>* </span><span class=cF2>One memory map</span><span class=cF0> for all tasks on all cores with virtual addresses set equ to
<a name="l50"></a>physical, just as though paging is not used.
<a name="l51"></a>
<a name="l52"></a>* One platform -- </span><a href="http://en.wikipedia.org/wiki/Amd64#AMD64"><span class=cF4>x86_64</span></a><span class=cF0> PC's, no 32-bit support.
<a name="l53"></a>
<a name="l54"></a>* No security or cryptography.
<a name="l55"></a>
<a name="l56"></a>* No networking.
<a name="l57"></a>
<a name="l58"></a>* Least (greatest) common denominator hardware support. Mostly, one driver for
<a name="l59"></a>each device class. I can't be in the business of different drivers.
<a name="l60"></a>Compatibility is the greatest challenge for PC operating systems. Disk code
<a name="l61"></a>does not use interrupts, avoiding compatibility risks. </span><span class=cF2>PS/2</span><span class=cF0> keyboard/mouse is
<a name="l62"></a>used instead of </span><span class=cF2>USB</span><span class=cF0>, also more compatible.
<a name="l63"></a>
<a name="l64"></a>* </span><span class=cF2>640x480</span><span class=cF0> 16 colors. Updates whole scrn at </span><span class=cF2>30 fps</span><span class=cF0>, optimized for full scrn
<a name="l65"></a>games where </span><span class=cF2>InvalidRectangle</span><span class=cF0>s are counter-productive.
<a name="l66"></a>
<a name="l67"></a>* One font, 8x8. Text and graphic layers done in software with text normally on
<a name="l68"></a>an 8x8 grid. It can run in Text mode if graphic initialization fails.
<a name="l69"></a>
<a name="l70"></a>* Compiler extends all values to 64-bit when fetched and does only 64-bit
<a name="l71"></a>computations intermediately. Assembler has minimal 16-bit support, good enough
<a name="l72"></a>for compiling boot loaders.
<a name="l73"></a>
<a name="l74"></a>* No object files. Use </span><span class=cF2>JIT</span><span class=cF0>.
<a name="l75"></a>
<a name="l76"></a>* Whole files are processed almost exclusively, allowing compression.
<a name="l77"></a>
2024-03-23 13:40:50 +00:00
<a name="l78"></a>* </span><a href="/Wb/Doc/HolyC.DD.HTML#l1"><span class=cF4>One language</span></a><span class=cF0> and compiler for command-line, scripts, songs, automations and
2024-03-16 16:25:48 +00:00
<a name="l79"></a>code.
<a name="l80"></a>
<a name="l81"></a>* One editor/word processor/browser for the command-line window, source code,
<a name="l82"></a>documentation browser, dialog forms.
<a name="l83"></a>
<a name="l84"></a>* No child windows. One window per task. Bttns are widgets, not child windows.
<a name="l85"></a> There are child tasks, however.
<a name="l86"></a>
<a name="l87"></a>* No distinction between </span><span class=cF2>thread</span><span class=cF0>, </span><span class=cF2>process</span><span class=cF0> or </span><span class=cF2>task</span><span class=cF0>.
<a name="l88"></a>
2024-03-23 13:40:50 +00:00
<a name="l89"></a>* The </span><a href="/Wb/Kernel/Sched.HC#l1"><span class=cF4>Scheduler</span></a><span class=cF0> is for home systems. It is not preemptiove. Disk requests are
2024-03-16 16:25:48 +00:00
<a name="l90"></a>not broken-up, so sharing is bad. It's wonderfully simple.
<a name="l91"></a>
2024-03-23 13:40:50 +00:00
<a name="l92"></a>* </span><a href="/Wb/Doc/MultiCore.DD.HTML#l1"><span class=cF4>MultiCore</span></a><span class=cF0> is done </span><span class=cF2>master/slave</span><span class=cF0>, instead of </span><span class=cF2>SMP</span><span class=cF0>. </span><span class=cF2>Core0</span><span class=cF0> applications explicitly
2024-03-16 16:25:48 +00:00
<a name="l93"></a>assigns jobs. Locks are present allowing multicore file, heap, and hardware
<a name="l94"></a>access, though.
<a name="l95"></a>
<a name="l96"></a>* </span><span class=cF4><u>Sound</u></span><span class=cF0> has single-voice 8-bit signed MIDI-like samples.
<a name="l97"></a>
<a name="l98"></a>* All tasks have a heap and a sym table. Scope is that of environment vars in
<a name="l99"></a>other operating systems. As text is typed at the command line or you run
<a name="l100"></a>programs by </span><span class=cF2>#include</span><span class=cF0>ing them, the syms go in the table. If a sym is not found,
<a name="l101"></a>the parent task's table is checked. The father of all tasks has the API syms
<a name="l102"></a>you'll need waiting in it's table. No need to </span><span class=cF2>#include</span><span class=cF0> headers.
<a name="l103"></a>
<a name="l104"></a>* No need for namespaces -- scoping occurs automatically based on task symbol
2024-03-23 13:40:50 +00:00
<a name="l105"></a>table hierarchy with the </span><a href="/Wb/Doc/Glossary.DD.HTML#l171"><span class=cF4>Adam Task</span></a><span class=cF0>'s symbol system-wide global.
2024-03-16 16:25:48 +00:00
<a name="l106"></a>
2024-03-23 13:40:50 +00:00
<a name="l107"></a>* Sometimes, I </span><a href="/Wb/Doc/CutCorners.DD.HTML#l1"><span class=cF4>cut corners</span></a><span class=cF0> in the interest of keeping the code beautiful.
2024-03-16 16:25:48 +00:00
</span></pre></body>
</html>
