                                     Why Not More?

    If a feature cannot be made to work correctly and consistently, professional
    companies usually remove the feature.  Because PC hardware is so diverse,
    getting things to work on all people's computers is really difficult.  For one
    thing, you practically have to own all the different hardware to write drivers
    for it.  If a company wanted to sell a PC operating system, they would offer a
    warranty and, therefore, could not get away with amateur behavior.  TempleOS
    absolutely requires 64-bit computers, so we leave behind much trouble, but
    plenty remains.

    The PCI bus interface is what modern hardware uses.  Before PCI, life was simple
    and devices used I/O ports.  After studying PCI Interrupts and attempting to do
    a HDAudio driver, I came to realize that modern PCI devices require ten times
    more code and I cannot even come close to making them work on everyone's machine
    because with PCI devices there are several models to worry about, unlike with
    the older ISA bus devices which can be done with one driver.

    Currently, I have no PCI drivers.  My drivers use I/O ports and operate in ISA
    bus mode.  At this point, I only have one driver for each type of device and it
    is delightfully simple that way.  I have one keyboard driver, one mouse driver,
    one ATA hard drive driver, one ATAPI CD/DVD driver, one VGA 640x480 16 color
    video driver and one PC Speaker driver.  I use the PIT and HPET timers and
    PIC Interrupt Controller.  I use  IRQ0 for timer, IRQ1 for keyboard, and IRQ12
    for mouse.  If IRQ12 is not firing, I am able to poll the mouse.

    In the CPU department, I have state of the art 64-bit long mode with multicore
    support.  I use the APIC and start-up multicore operation.

    I have made an incredible accomplishment by getting it to work on practically
    everyone's computer as long as it is 64-bit and they run inside VMware, QEMU or
    VirtualBox.

    Adding a USB driver would be really ugly with UHCI, EHCI, OHCI, USB1, USB2,
    USB3, ICH6, ICH7, ICH8, ICH9, ICH10, ICH11, ICH12, boot mode and regular mode
    for keyboard/mouse and a diversity of HID reports.  It's hopeless.  I could
    never offer anything but crappy, limited support and it would just add a ton of
    crappy code that mostly didn't work.  What would I gain?  Nothing.  A keyboard
    or mouse would not be improved.  Solid State USB drives would be really nice,
    but it's not going to happen.

    The same story is basically true for GPUs, audio, networking and AHCI hard drive
    drivers.  God said 640x480 16 color was a covenant like circumcision, so the
    video will never change, even if a Standard PC was made.  If you attempt
    multimedia, everything will break because memory will get fragmented with huge
    multimedia files.  Some day, if super-simple high speed serial allows
    networking, there will be no browser within the 100,000 line limit and, with
    only 16 colors, the world wide web is not tolerable.  FTP and telnet might be
    possible, in the far distant future, if they could fit within the 100,000 line
    limit.  Currently, there are 80,849 lines of code.

    I don't stand a chance working on native hardware, anymore.  I could install and
    run natively on hardware from about 2005-2010.  It requires BIOS's being nice
    enough to write USB mode PS/2 legacy keyboard/mouse support.  As it turns-out,
    sometimes the BIOS has PS/2 drivers but purposely disables them, just to be
    mean.  The CIA and whole industry is trying to mess everything up, on purpose.
    Perhaps, at a point of sale in a store, a thief could hack a credit card
    machine.  Therefore, the BIOS companies actually want it difficult to make
    drivers and purposely make it broken.

    The ATA/ATAPI hard drives often can be run with I/O ports if you can find them.
    lspci -v on Linux or system information on Windows can help you locate the SATA
    IO ports the hard drive and CD/DVD have.  They no longer are enabled by the
    BIOS.  It's hopeless.  I'm stuck with very slow drive performance, but it works
    for everybody.

    UEFI is pointless.  If I am forced to run in VMware, QEMU or VirtualBox, they
    will always support non-UEFI mode.  Without working, native hard drive and
    CD/DVD drivers, you can't get very far with UEFI on a native install, not to
    mention SecureBoot.  UEFI is, first of all, redundant.  If non-UEFI works in a
    virtual machine, supporting UEFI would only be redundant, ugly nasty code.  My
    compiler does not create an ELF or PE format.  I would have to ruin the beauty
    of my compiler, which would make me cry many tears.

    God talks.  It seems reasonable that I will get to make the rules for the whole
    industry, in the future when God is announced publically to the World.

    I made ::/Doc/Demands.DD.

    When the PC was created, they wanted flexibility because they did not know the
    future.  Now, the industry is mature and it is time to make a 100% standard PC
    that everybody uses.  ::/Doc/StdTempleOSPC.DD

    * "QEMU" is a trademark owned by Fabrice Bellard.
    * "VMware" is a trademark owned by VMware, Inc.
    * "VirtualBox" is a trademark owned by Oracle.