<a name="l5"></a></span><a href="/Wb/Doc/Comm.HC.HTML#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="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="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.
