237 lines
17 KiB
HTML
Executable File
237 lines
17 KiB
HTML
Executable File
<!DOCTYPE html>
|
|
<html lang="en">
|
|
<head>
|
|
<meta charset="UTF-8">
|
|
<meta name="generator" content="TempleOS V5.03">
|
|
<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>
|
|
<pre style="font-family: courier, monospace; font-size: 10pt;">
|
|
<a name="l1"></a><span class=cF5> The Standard TempleOS PC</span><span class=cF0>
|
|
<a name="l2"></a>
|
|
<a name="l3"></a>All desktop PCs will have 8-channel OCTART super-simple high speed serial ports
|
|
<a name="l4"></a>to replace USB. They are simpler because the driver is as simple as old school </span><span class=cF4>
|
|
<a name="l5"></a></span><a href="/Wb/Doc/Comm.HC#l1"><span class=cF4>RS232 Serial</span></a><span class=cF0>, they have no USB end-points and they have no USB human interface
|
|
<a name="l6"></a>device reports. Computer mice will all have exactly two bttns and one wheel.
|
|
<a name="l7"></a>Game controllers will all be the standard deluxe </span><a href="http://www.gamestop.com/pc/accessories/steam-controller/121865"><span class=cF0>game console controllers</span></a><span class=cF0> that
|
|
<a name="l8"></a>are popular today. It will have 8 big TX and 8 big RX fifos that allow flow
|
|
<a name="l9"></a>control characters to jump the queue. It should be locked-down to as few
|
|
<a name="l10"></a>options as possible, like 8-1-N only, although hardware may use a USB frame, not
|
|
<a name="l11"></a>an RS232, so stop bits might not be relevant. Perhaps, just two baud rates --
|
|
<a name="l12"></a>high and low speed are needed. Low speed is good for slow microcontrollers and
|
|
<a name="l13"></a>allows longer cable length. Keyboard, mouse and game controller can be low
|
|
<a name="l14"></a>speed.
|
|
<a name="l15"></a>
|
|
<a name="l16"></a>The USB creators banned generic devices, requiring a signed, certified driver
|
|
<a name="l17"></a>for everything! That's no good. We allow any device and will communicate,
|
|
<a name="l18"></a>generically, using a serial terminal program like the old school HyperTerminal,
|
|
<a name="l19"></a>XTalk or Telnet.
|
|
<a name="l20"></a>
|
|
<a name="l21"></a>A mouse packet interface should be similar to this:
|
|
<a name="l22"></a>
|
|
<a name="l23"></a> TX: <ENTER>
|
|
<a name="l24"></a> RX: X:+3 Y:+0 Wheel:+0 LB:OFF RB:OFF
|
|
<a name="l25"></a> TX: <ENTER>
|
|
<a name="l26"></a> RX: X:+0 Y:-1 Wheel:+0 LB:ON RB:OFF
|
|
<a name="l27"></a>
|
|
<a name="l28"></a>We aspire to be as simple as a Commodore 64 joystick driver:
|
|
<a name="l29"></a>
|
|
<a name="l30"></a> VAL=PEEK(56321)
|
|
<a name="l31"></a> if VAL AND 1 THEN y=y-1
|
|
<a name="l32"></a> if VAL AND 2 THEN y=y+1
|
|
<a name="l33"></a> if VAL AND 4 THEN x=x-1
|
|
<a name="l34"></a> if VAL AND 8 THEN x=x+1
|
|
<a name="l35"></a>
|
|
<a name="l36"></a>The game controller will be more complicated, but much simpler than USB. It
|
|
<a name="l37"></a>will use a standard text packet of some kind.
|
|
<a name="l38"></a>
|
|
<a name="l39"></a>On the other end, you might hook-up a thermostat microcontroller and interface
|
|
<a name="l40"></a>as a generic serial device. The microcontroller in the thermostat would have
|
|
<a name="l41"></a>something simple, not a crazy overkill ethernet connection.
|
|
<a name="l42"></a>
|
|
<a name="l43"></a> </span><span class=cF1>U8</span><span class=cF0> b;
|
|
<a name="l44"></a> </span><span class=cF1>while</span><span class=cF0> (</span><span class=cF3>TRUE</span><span class=cF0>) {
|
|
<a name="l45"></a> b=ReadU8(2); </span><span class=cF2>//Read byte from high speed serial channel 2.</span><span class=cF0>
|
|
<a name="l46"></a> </span><span class=cF2>//(Has been configured for low baud because thermostat should be slow.)</span><span class=cF0>
|
|
<a name="l47"></a> </span><span class=cF1>if</span><span class=cF0> (b==CMD_UP)
|
|
<a name="l48"></a> temperature++;
|
|
<a name="l49"></a> </span><span class=cF1>else</span><span class=cF0> </span><span class=cF1>if</span><span class=cF0> (b==CMD_DOWN)
|
|
<a name="l50"></a> temperature--;
|
|
<a name="l51"></a> }
|
|
<a name="l52"></a>
|
|
<a name="l53"></a>Super-simple block devices will replace ATA/ATAPI hard drives and
|
|
<a name="l54"></a>CD/DVD/BlueRays. Today, the industry is in flux with nonvolitile memory just
|
|
<a name="l55"></a>invented. We want a super-simple block device interface for non-volitile memory
|
|
<a name="l56"></a>and for what is currently USB memory sticks, but only if they can be made
|
|
<a name="l57"></a>without bad blocks. I don't think we want to deal with bad block memory, so
|
|
<a name="l58"></a>maybe we will not do NV-memory. The standard TempleOS desktop will require a
|
|
<a name="l59"></a>hard disk.
|
|
<a name="l60"></a>
|
|
<a name="l61"></a>There will be minimal commands: READ_BLOCK, WRITE_BLOCK, GET_CAPACITY,
|
|
<a name="l62"></a>GET_MODEL, GET_SERIAL_NUM, and EJECT.
|
|
<a name="l63"></a>
|
|
<a name="l64"></a>We want a CPU mode with virtual IO port addresses similar to how paging creates
|
|
<a name="l65"></a>virtual memory addresses. We want a 65536 word look-up table that converts
|
|
<a name="l66"></a>virtual IO port numbers to physical IO port numbers. There will be a standard
|
|
<a name="l67"></a>IO port configuration, so port numbers can be fixed in the code. We want the
|
|
<a name="l68"></a>primary hard drive on one set of ports and the primary CD/DVD/Blu-ray on another
|
|
<a name="l69"></a>set of ports. Choose a contiguous set of IO ports.
|
|
<a name="l70"></a>
|
|
<a name="l71"></a>Meanwhile, a complicated PCI interface can be designed along-side the TempleOS
|
|
<a name="l72"></a>interface for Windows and Linux. It would almost be possible to carry-on
|
|
<a name="l73"></a>separate lives, however, the super-simple serial requires getting rid of USB
|
|
<a name="l74"></a>since super-simple serial is a new hardware standard. People can add USB ports
|
|
<a name="l75"></a>with a PCI device card.
|
|
<a name="l76"></a>
|
|
<a name="l77"></a>God said He wants single-voice 8-bit signed MIDI-like sample for the sound. God
|
|
<a name="l78"></a>does not want death screams, perhaps, because God has PTSD or soldiers have
|
|
<a name="l79"></a>PTSD. (Imagine wounded on battlefields.)
|
|
<a name="l80"></a>
|
|
<a name="l81"></a>The video will be a linear frame buffer 640x480 16 color with one-byte-per-pixel
|
|
<a name="l82"></a>even though it is only 16 color with is 4-bit. Perhaps, we have a interrupt to
|
|
<a name="l83"></a>sync with the refresh.
|
|
<a name="l84"></a>
|
|
<a name="l85"></a>I am tmpted to help amateur hardware device designers by making the hardware
|
|
<a name="l86"></a>interface for the PC simple. I have fond memories of 1993, when I made a
|
|
<a name="l87"></a>wire-wrapped ISA data acquisition card which plugged into my 486 and had some
|
|
<a name="l88"></a>analog-to-digital and digital-to-analog convertors. I am not designing a bus.
|
|
<a name="l89"></a>Earlier, I said the super-simple high speed serial port replacement could be
|
|
<a name="l90"></a>USB-like in hardware as long as the software driver interface was simple like
|
|
<a name="l91"></a>old school RS232 serial ports. Requiring a complicated hardware handshake
|
|
<a name="l92"></a>raises the bar, slightly, for the lowest level hardware designers. Most people
|
|
<a name="l93"></a>will be connecting a microcontroller or something that already has a serial
|
|
<a name="l94"></a>communication design, but if it's not a problem, maybe we should keep it simple
|
|
<a name="l95"></a>at all stages. It was nice putting an oscilloscope on my serial port wires.
|
|
<a name="l96"></a>
|
|
<a name="l97"></a>The original PC had general purpose digital IO through the parallel port. That
|
|
<a name="l98"></a>was fun. I have enough battles to fight, so I'll leave being a savior to
|
|
<a name="l99"></a>hobbiest hardware engineers to somebody else.
|
|
<a name="l100"></a>
|
|
<a name="l101"></a>Digital cameras will be super-simple high speed serial, but TempleOS is forever
|
|
<a name="l102"></a>limited to 16 colors and multimedia is banned because large files being loaded
|
|
<a name="l103"></a>into memory fragments memory, so cameras are somewhat unwelcome. I have enough
|
|
<a name="l104"></a>problems without making the Brits anxious about autonomous gun turrets and
|
|
<a name="l105"></a>killer robots. The reason I say cameras will be super-simple serial is because
|
|
<a name="l106"></a>we are replacing USB ports with super-simple serial. PC's will have only
|
|
<a name="l107"></a>super-simple serial ports unless people buy a USB PCI expansion card. So, the
|
|
<a name="l108"></a>digital cameras will be super-simple serial.
|
|
<a name="l109"></a>
|
|
<a name="l110"></a>
|
|
<a name="l111"></a></span><span class=cF5> Version 1.0</span><span class=cF0>
|
|
<a name="l112"></a>
|
|
<a name="l113"></a>We will make a spec for a $8,000, perfectly standardized, cryogenically-cooled,
|
|
<a name="l114"></a>monster desktop PC. It will have 16 cores, integrated 4K graphics, and,
|
|
<a name="l115"></a>hopefully, 6 Ghz continuous operation. Perhaps, 64 Gig of RAM will be standard?
|
|
<a name="l116"></a>God said to help to poor buy them. It is pointless to have a high powered
|
|
<a name="l117"></a>machine if other people have wimpy machines and cannot run programs you write.
|
|
<a name="l118"></a>Therefore, everybody in the developed world will buy a Standard TempleOS IBM PC
|
|
<a name="l119"></a>over the next ten years, so that will be a quantity of 400 million, perhaps.
|
|
<a name="l120"></a>God said to pay the US national debt with the revenue. We will standardize
|
|
<a name="l121"></a>everything, not just the TempleOS related items. The display will be 4K (and of
|
|
<a name="l122"></a>course 640x480 16 color) and no others. Everybody gets just one monitor, unless
|
|
<a name="l123"></a>you buy special PCI cards. Everybody gets two speakers, a headphone, a mic, a
|
|
<a name="l124"></a>webcam and touch scrn. We make the audio one sample rate and one sample size,
|
|
<a name="l125"></a>but TempleOS still gets just a square wave. (HD Audio is really screwed-up and
|
|
<a name="l126"></a>requires complicated artificial intelligence, just to route output to speakers.)
|
|
<a name="l127"></a>
|
|
<a name="l128"></a>The Standard Temple IBM PC will be a full-sized tower. Perhaps, stain-glass
|
|
<a name="l129"></a>will decorate the case because God is sentimentally attached to stained-glass.
|
|
<a name="l130"></a>We should set the size at exactly 2.5 feet by 1.5 feet by 1.5 feet as in the </span><span class=cF4>
|
|
<a name="l131"></a></span><a href="http://www.biblegateway.com/passage/?search=Exodus+25:10-10&version=NIV"><span class=cF4>Exodus,25:10-10</span></a><span class=cF0> for all time. If there is extra room, make a storage shelf for
|
|
<a name="l132"></a>DVDs. We do not want a race-to-the-bottom, shrinking the size. Instead of
|
|
<a name="l133"></a>making it smaller, make it more powerful. We want to remove all cost pressure
|
|
<a name="l134"></a>from making things small. It must have a CD/DVD/Blu-ray drive. The vision is
|
|
<a name="l135"></a>CD/DVDs used for a library of games, not installed on the hard-drive. We need a
|
|
<a name="l136"></a>network connection, possibly implemented as a super-simple high speed serial
|
|
<a name="l137"></a>device. What about standard monitor and speakers? The C64's success was
|
|
<a name="l138"></a>partially due to wide spread, completely standard, hardware. I think TempleOS
|
|
<a name="l139"></a>will not do bad block devices, so we need a hard drive, not just NV-memory or
|
|
<a name="l140"></a>SSD.
|
|
<a name="l141"></a>
|
|
<a name="l142"></a>TempleOS will have the priority over Windows or Linux on hardware decisions. We
|
|
<a name="l143"></a>could make it heterogenious multicore. I think we want 16 non-hyperthreaded
|
|
<a name="l144"></a>cores. Core#0 is the only full-featured core needed. The other cores will have
|
|
<a name="l145"></a>long mode, but not some of these: real mode, protected mode, ring-3, paging,
|
|
<a name="l146"></a>interrupts, in/out port instructions, SSE instructions, MMX instructions.
|
|
<a name="l147"></a>
|
|
<a name="l148"></a>God said Intel should do a simulation of heat produced by gates and try
|
|
<a name="l149"></a>spreading-out the heat producing gate circuits on the chip.
|
|
<a name="l150"></a>
|
|
<a name="l151"></a>God said Linux's Wine should replace Windows. We will install a standard
|
|
<a name="l152"></a>software set-up on all Standard Temple IBM PC's.
|
|
<a name="l153"></a>
|
|
<a name="l154"></a>
|
|
<a name="l155"></a></span><span class=cF5> Usage</span><span class=cF0>
|
|
<a name="l156"></a>
|
|
<a name="l157"></a>TempleOS is primarily for user developers, like the Commodore 64 was. I created
|
|
<a name="l158"></a>a total of 50 Meg of content over ten years, so you shouldn't need much room,
|
|
<a name="l159"></a>either. The installed hard drive space should stay small because the resolution
|
|
<a name="l160"></a>is low, multimedia is banned, 3rd party libraries are banned, and applications
|
|
<a name="l161"></a>can be distributed with ISO files or DVDs.
|
|
<a name="l162"></a>
|
|
<a name="l163"></a>The ROM will have a command that copies the ROM onto the hard drive, creating
|
|
<a name="l164"></a>identical C and D partitions, so you can have fun modifying TempleOS. You will
|
|
<a name="l165"></a>have confidence you can fix it easily if you break it. It should be able to run
|
|
<a name="l166"></a>everything from just the ROM, too. You will need to specify a /Home directory
|
|
<a name="l167"></a>that is not in the ROM, but on the hard drive.
|
|
<a name="l168"></a>
|
|
<a name="l169"></a>The standard set-up will be a C primary drive and a D back-up drive. Keep the
|
|
<a name="l170"></a>size on each hard drive under 512 Meg and periodically copy all of C to D, so
|
|
<a name="l171"></a>they stay mirrored. The file manager and other programs read the entire
|
|
<a name="l172"></a>directory structures, so too many files causes problems (unbearably slow).
|
|
<a name="l173"></a>Third party software should be distributed as ISO files or DVDs, like </span><span class=cF4>
|
|
<a name="l174"></a></span><a href="https://github.com/jwhitham/frotz"><span class=cF4>TextAdventure.ISO</span></a><span class=cF0>. No 3rd party libraries are permitted because they circumvent
|
|
<a name="l175"></a>the intent of the 100,000 line of code limit which is keeping it cognatively
|
|
<a name="l176"></a>small enough to see the light at the end of the tunnel and easily master
|
|
<a name="l177"></a>everything. Therefore, 3rd party ISO files must bring all required software
|
|
<a name="l178"></a>components with them, except what is found in the TempleOS ROM.
|
|
<a name="l179"></a>
|
|
<a name="l180"></a>Having all your 3rd party software on separate DVDs or ISO files and TempleOS
|
|
<a name="l181"></a>running from a ROM, keeps it delightfully simple so you have complete
|
|
<a name="l182"></a>understanding of what is going on. You will have complete confidence and it
|
|
<a name="l183"></a>will be a joy to use. 3rd party applications can store saved data files into
|
|
<a name="l184"></a>your /Home hard drive directory.
|
|
<a name="l185"></a>
|
|
<a name="l186"></a>The Temple PC will stay unchanged for seven years at a time. The Bible speaks
|
|
<a name="l187"></a>of a seven year release in </span><a href="http://www.biblegateway.com/verse/en/Deutoronomy%2015:1"><span class=cF4>Deuteronomy,15:1</span></a><span class=cF0>. The Commodore stayed unchanged for
|
|
<a name="l188"></a>many years and people became intimately familiar with every aspect.
|
|
<a name="l189"></a></span><span class=cFA>
|
|
<a name="l190"></a></span><object width="640" height="520"><param name="movie" value="http://www.youtube.com/v/bs_jcTuwPKo"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/bs_jcTuwPKo" type="application/x-shockwave-flash" allowscriptaccess="always" width="640" height="520"></embed></object><span class=cF0>
|
|
<a name="l191"></a>
|
|
<a name="l192"></a>I thought 2.5' x 1.5' x 1.5' was ridiculously big, but it looks like it is
|
|
<a name="l193"></a>reasonable for super-cooled refrigeration systems!
|
|
<a name="l194"></a>
|
|
<a name="l195"></a>
|
|
<a name="l196"></a></span><span class=cF5> Version 2.0</span><span class=cF0>
|
|
<a name="l197"></a></span><span class=cFA>
|
|
<a name="l198"></a></span><center><img src="http://i.imgur.com/zUdfEqy.jpg" width="640" height="500" alt=""></center><span class=cF0>
|
|
<a name="l199"></a>
|
|
<a name="l200"></a>The Standard Temple IBM PC V2.0 will be released seven years after V1.0. Each
|
|
<a name="l201"></a>unit will have a full, uncut, silicon wafer. V2.0 will be sold, unchanged, for
|
|
<a name="l202"></a>seven more years, like a Commodore 64.
|
|
<a name="l203"></a></span><span class=cF8>
|
|
<a name="l204"></a>* "Commodore 64" is a trademark owned by Polabe Holding NV.
|
|
<a name="l205"></a>* "Linux" is a trademark owned by Linus Torvalds.
|
|
<a name="l206"></a>* "Windows" is a trademark owned by MicroSoft Corp.</span><span class=cF0>
|
|
</span></pre></body>
|
|
</html>
|