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.