Future PC Hardware

All desktops will have 8-channel super-simple high speed serial ports. There will be no USB end-points or USB human interface device reports. Computer mice will all have two buttons and a wheel. Game controllers will all be the standard deluxe game console controllers that are popular, today. The standard Temple IBM PC will come with two game controllers. The super simple serial should be similar to old school RS232 interface in software but with modern, high speeds hardware baud rates. See Comm Port Driver. It will have 8 big TX and 8 big RX fifos and allow flow control characters to jump the queue. It should be locked-down to as few options as possible, like 8-1-N only, although hardware may use a USB frame, not an RS232, so stop bits might not be relevant. Perhaps, just two baud rates -- high and low speed are needed. Low speed is good for slow microcontrollers and allows longer cable length. Keyboard, mouse and game controller can be low speed. The USB creators banned generic devices, requiring a signed, certified driver for everything! That's no good. We allow any device and will communicate, generically, using a serial terminal program like was done with "HyperTerminal", "XTalk" or "Telnet". A mouse should be similar to this: TX: <ENTER> RX: X:+3 Y:+0 Wheel:+0 LB:OFF RB:OFF TX: <ENTER> RX: X:+0 Y:-1 Wheel:+0 LB:ON RB:OFF We aspire to be as simple as a Commodore 64 joystick driver: VAL=PEEK(56321) if VAL AND 1 THEN y=y-1 if VAL AND 2 THEN y=y+1 if VAL AND 4 THEN x=x-1 if VAL AND 8 THEN x=x+1 The game controller will be more complicated, but much simpler than USB. It will use a standard text packet of some kind. On the other end, you might hook-up a thermostat. The microcontroller in the thermostat would have something simple, not a crazy overkill ethernet connection. U8 b; while (TRUE) { b=ReadU8(2); //Read byte from high speed serial channel 2. //(Has been configured for low baud because thermostat should be slow.) if (b==CMD_UP) temperature++; else if (b==CMD_DOWN) temperature--; } Super simple block devices will replace ATA/ATAPI hard drives and CD/DVD/BlueRays. Today, the industry is in flux with nonvolitile memory just invented. We want a super simple block device interface for nonvolitile memory and for what is currently USB memory sticks, but only if they can be made without bad blocks. I don't think we want to deal with bad block memory, so maybe we will not do NV-memory. The standard TempleOS desktop will require a hard disk. There will be minimal commands: READ_BLOCK, WRITE_BLOCK, GET_CAPACITY, GET_MODEL, GET_SERIAL_NUM, and EJECT. We want a CPU mode with virtual IO ports. We want a 65536 word look-up table that converts virtual IO ports to physical IO ports. There will be a standard, so it can be fixed. We want the primary hard drive on one set of ports and the primary CD/DVD/Blu-ray on another set of ports. Choose a contiguous set of IO ports. In a PC, there are many misc IO ports: PIT, PIC and strange PS/2 port things. We design as though it is end-of-line and perfect for all time. We do not leave options for the future. Number the weird ports. Then, designate all remaining 65536 IO ports as expandable super simple serial or super simple block device. Meanwhile, a complicated PCI interface can be designed along-side the TempleOS interface for Windows and Linux. It would almost be possible to carry-on separate lives, however, the super simple serial requires getting rid of USB since it is a new hardware standard. People can make USB PCI device cards. The x86 Intel chip might need a reordered-IO-port CPU mode that you select when running TempleOS. Windows would use the current, ugly, IO port numbering. Enterting TempleOS mode will switch to a beautiful, perfectly sequential, IO port numbering. God said He wants single audio voice for the sound. I think we want a word-sized IO port for period with zero causing it to be off. The period should allow for 20Hz to 20,000 Hz. The PIT period register for PC speaker seems okay, whatever it is. The video will be a linear frame buffer 640x480 16 color with one-byte-per-pixel even though it is only 16 color. Perhaps, we have a interrupt to sync with the refresh. I am tempted to help amateur hardware device designers by making the hardware interface for the PC simple. I have fond memories of 1993, when I made a wire-wrapped ISA data acquisition card which plugged into my 486 and had some analog-to-digital and digital-to-analog convertors. I am not designing a bus. Earlier, I said the simplified high speed serial port replacement could be USB-like in hardware as long as the software driver interface was simple like old school RS232 serial ports. Requiring a complicated hardware handshake raises the bar, slightly, for the lowest level hardware designers. Most people will be connecting a microcontroller or something that already has a serial communication design, but if it's not a problem, maybe we should keep it simple at all stages. It was nice putting an oscilloscope on my serial port wires. The original PC had general purpose digital IO, out the parallel port. That was fun. I have enough battles to fight, so I'll leave being a savior to hobbiest hardware engineers to somebody else. Digital cameras will be super simple high speed serial, but TempleOS is forever limited to 16 colors and multimedia is banned because large files being loaded into memory fragments memory, so cameras are somewhat unwelcome. I have enough problems without making the Brits anxious about autonomous gun turrets and killer robots. The reason I say cameras will be simple serial is because we are replacing USB ports with simple serial. Windows/Linux will have only simple serial ports unless people buy a USB PCI expansion card. So, the digital cameras will be simple serial.

Standard Temple IBM PC

We will make a spec for a perfectly standardized, $2500, cryogenically-cooled monster desktop PC, hopefully 7 Ghz continuous operation. It is pointless for me to have a high power machine if other people have wimpy machines because they cannot run my software. Therefore, everybody in the developed world will buy one over the next ten years, so quantity of 400 million perhaps. God said to pay the US national debt. We will standardize not just the TempleOS components, the display will be 4K (and of course 640x480 16 color) and no others. Everybody gets just one monitor, unless you buy special cards. Everybody gets two speakers, a headphone, a mic and a webcam. We make the audio one sample rate and one size, but TempleOS still gets just a square wave. HD Audio is really screwed-up. It takes complicated artificial intelligence, just to route output to speakers. The Standard Temple IBM PC will be a full-sized tower. It must have a CD/DVD/Blu-ray drive. We need a network connection, possibly implemented as a super simple high speed serial device. What about standard monitor and speakers? The C64's success was partially due to wide spread, completely standard, hardware. I think TempleOS will not do bad block devices, so we need a hard drive, not just NV-memory or SSD. TempleOS will have the priority over Windows or Linux on hardware decisions. We could make it heterogenious multicore. I think we want 16 non-hyperthreaded cores. Core#0 is the only full-featured core. The other cores have long mode, but do not some of these: real mode, protected mode, ring-3, paging, interrupts, in/out port instructions, SSE instructions, MMX instructions. This Graphics Job is what we wish to optimize for. God said Intel should do a simulation of heat produced by gates and try spreading-out the heat producing gate circuits on the chip. God said Linux's Wine should replace Windows. * "Commodore 64" was a trademark of Commodore Business Machines. * "Linux" is probably a trademark owned by Linus Torvalds. * "Windows" is a trademark of MicroSoft Corp.