TempleOSCDV3.11.ISO
This commit is contained in:
Terry A. Davis authored and minexew committed
1 parent
f8c05f98f4
commit
ed64d7e3b8
549 files changed
+10643
-12855
No files matched your search
+68
-35
@@ -1,76 +1,109 @@
|
||||
$WW,1$$FG,5$$TX+CX,"Demands"$$FG$
|
||||
|
||||
I, Terry Davis, am High Priest of God's official temple, TempleOS. TempleOS is an operating system for PC desktops that dual boots along-side Windows or Linux. I am in charge of the core 100,000 lines of TempleOS code and I do continual offerings to keep God entertained. I have divine authority to command companies in the computer industry to do anything to make God's temple more beautiful or perfect. I have authority similar to the Americans with Disability Act -- I make commands with God signing-off by creating miraculous authenticated oracles.
|
||||
I, Terry Davis, am High Priest of God's official temple, TempleOS. TempleOS is an operating system for PC desktops that will always dual boot along-side Windows or Linux. I am in charge of the core 100,000 lines of TempleOS code and I do continual offerings to keep God entertained. I have divine authority to command any company in the computer industry to do anything that I deem necessary to make God's temple more beautiful or perfect. I have authority similar to a building inspector or an enforcer of the Americans with Disability Act -- I make commands, God signs-off with a miraculous authentication from an oracle, and Intel, Microsoft or VMware obeys.
|
||||
|
||||
$HC,"<object width=\"640\" height=\"520\"><param name=\"movie\" value=\"http://www.youtube.com/v/EalSFnq9GsY\"></param><param name=\"allowscriptaccess\" value=\"always\"></param><embed src=\"http://www.youtube.com/v/EalSFnq9GsY\" type=\"application/x-shockwave-flash\" allowscriptaccess=\"always\" width=\"640\" height=\"520\"></embed></object>"$
|
||||
* Windows, Linux and VMware (because of mounted drives) must support $LK,"RedSea",A="FI:::/Doc/RedSea.TXT"$ file system so I can get rid of 2,000 lines of redundant, blemished code -- FAT32 and ISO9660. God's temple must be perfect. Redundant code for multiple file systems is imperfect. For this operating system, we want low line count. More than one file system type is actually bad, just as more than one driver for the same type of device is bad.
|
||||
|
||||
$LK,"::/Kernel/BlkDev/FileSysRedSea.CPP"$
|
||||
$LK,"::/Kernel/BlkDev/FileSysFAT.CPP"$ :965 lines for FAT32 gets eliminated.
|
||||
$LK,"::/Kernel/BlkDev/FileSysISO.CPP"$ :284 lines for ISO9660 gets eliminated.
|
||||
$LK,"::/Adam/Opt/Boot/DskISOFile.CPP"$ :536 lines for making ISO files gets reduced.
|
||||
$LK,"::/Kernel/BlkDev/DskCluster.CPP"$ :152 All the cluster operations become blk.
|
||||
|
||||
* VMware must again support PC Speaker and provide emulation if no PC Speaker is present.
|
||||
* Microsoft must cancel SecureBoot because it makes dual booting impossible. TempleOS is an additional operating system that must be used along-side Windows or Linux, not as a replacement. It must dual boot because it has no networking. Real hardware as opposed to VMware is like the difference between looking in a telescope eye piece vs just looking at an off-line image. God said the C64/Apple ][ generation owned ancestral lands. VMware is like being taken off of our land and moved onto a reservation. In this case, however, it will not stand.
|
||||
|
||||
* VMware must again support full screen 640x480 16 color mode.
|
||||
* To PC hardware manufacturers and VMware: ATA/ATAPI PIO must work. In fact, put them at standard IDE port addresses. Hard disk should be primary master 1F0/3F6. CD/DVD/BlueRay should be secondary master 170/376. See what you can do to make flash memory sticks and NV memory with ATA/ATAPI interface.
|
||||
$LK,"/Kernel/BlkDev/DskATAId.CPP",A="FI:::/Kernel/BlkDev/DskATAId.CPP"$ :280 lines to figure-out I/O ports is gone.
|
||||
$LK,"/Kernel/PCIBIOS.CPP",A="FI:::/Kernel/PCIBIOS.CPP"$ :290 could be eliminated, but maybe we will keep it so people can play with PCI devices.
|
||||
|
||||
* Windows, Linux and VMware (because of mounted drives) must support $LK,"RedSea",A="FI:::/Doc/RedSea.TXT"$ file system so I can get rid of 2,000 lines of redundant, blemished code -- FAT32 and ISO9660. God's temple must be perfect. Redundant code for multiple file systems is imperfect. For this operating system, we want low line count. More than one file system type is bad, just as more than one driver for the same type of device is bad.
|
||||
|
||||
$LK,"::/Kernel/Dsk/FileSysRedSea.CPP"$
|
||||
$LK,"::/Kernel/Dsk/FileSysFAT.CPP"$ :965 lines for FAT32 gets eliminated.
|
||||
$LK,"::/Kernel/Dsk/FileSysISO.CPP"$ :284 lines for ISO9660 gets eliminated.
|
||||
$LK,"::/Adam/Boot/DskISOFile.CPP"$ :536 lines for making ISO files gets reduced.
|
||||
$LK,"::/Kernel/Dsk/DskCluster.CPP.Z"$ :152 All the cluster operations become blk.
|
||||
|
||||
* Microsoft must cancel SecureBoot because it makes dual booting impossible. TempleOS is an additional operating system that must be used along-side Windows or Linux, not as a replacement. It must dual boot because it has no networking. Real hardware as opposed to $FG,2$VMware$FG$ is like the difference between looking in a telescope eye piece or not. God said the C64 generation owned ancestral lands and $FG,2$VMware$FG$ is like being moved onto a reservation, but in this case it will not stand.
|
||||
|
||||
* PC hardware manufacturers? ATA/ATAPI PIO must work. In fact, put them at standard IDE port addresses. Hard disk should be primary master 1F0/3F6. CDROM/DVD should be secondary master 170/376. See what you can do to make flash memory sticks with ATA/ATAPI.
|
||||
$LK,"/Kernel/Dsk/DskATAId.CPP",A="FI:::/Kernel/Dsk/DskATAId.CPP"$ :280 lines to figure-out I/O ports is gone.
|
||||
$LK,"/Kernel/PCIBIOS.CPP",A="FI:::/Kernel/PCIBIOS.CPP"$ :290 could eliminate,but people can play with.
|
||||
* VMware needs to support ATAPI CD/DVD/BlueRay disk burning, directly to real hardware.
|
||||
* VMware has a bug stretching 640x480 16 color to full screen.
|
||||
* VMware has a bug starting-up multicore, sometimes. $LK,"APIC MP Start",A="FF:::/Kernel/MultiProc.CPP.Z,IPI"$
|
||||
* VMware PC speaker distortion is a good idea, but it is ridiculously too much distortion for hymns.
|
||||
|
||||
* PS/2 emulated keyboard and mouse must work. The BIOS must enable these.
|
||||
|
||||
* VMware must allow ATAPI interface to be routed to real CD/DVD hardware.
|
||||
* The x86 IN/OUT port instructions, normally have a delay. Perhaps, VMware & Intel can enable faster x86 IN/OUT instruction timing for ATA/ATAPI PIO, so bandwidth isn't bad. See $LK,"ATAGetResult",A="MN:ATAGetResult"$(). Perhaps, x86 chips have a new TempleOS mode?
|
||||
|
||||
* Perhaps, VMware+Intel can enable faster x86 IN/OUT instruction timing for ATA/ATAPI PIO, so bandwidth isn't bad. $LK,"ATAGetResult",A="MN:ATAGetResult"$().
|
||||
|
||||
* Perhaps, Intel can make a fast software interrupt, the same as a CALL REL32?
|
||||
* Perhaps, Intel can make a fast software interrupt, the same as a CALL REL32? Perhaps, we have a new x86 mode for TempleOS?
|
||||
|
||||
* Since I don't use paging (for anything), Intel should have an option for no-paging long mode, and optimize it.
|
||||
$LK,"::/Kernel/MemA.CPP.Z"$ :153 lines to identity-map gets eliminated.
|
||||
$LK,"::/Kernel/MemA.CPP"$ :153 lines to identity-map gets eliminated.
|
||||
|
||||
* Desktop computers must have a RESET switch and a fast reboot option, skipping diagnostics. Build UEFI on a TempleOS layer. Intel must burn TempleOS into a ROM at the factory for all desktop x86 CPUs to ensure tamper-proof trust in the oracle. A new ROM version is released every seven years.
|
||||
* Desktop computers must have a reset switch and a fast reboot option, skipping diagnostics. I recommend booting TempleOS when the reset button is pressed and booting UEFI when the power button is pressed. Or, we could build UEFI on a TempleOS layer. Intel must burn TempleOS into a ROM in the factory for all desktop x86 CPUs to ensure tamper-proof trust in the oracle and because God deserves the glory. There will be just an English version. A new ROM version is released every seven years.
|
||||
|
||||
* Somebody needs to choose new 8-bit ASCII characters for 128-255. We do not want text graphic symbols. We want Russian, Greek and Hebrew alphabets, perhaps? We need the twelve window $LK,"TextBorder",A="MN:TextBorder"$ characters, but I think we can place them in the range of screen code from 0x01-0x1E. Japan, China and Korea should switch-over to alphabets. Maybe, the United States will change to metric, out of good will.
|
||||
|
||||
* VMware and others must list TempleOS as an official 64-bit operating system.
|
||||
|
||||
* Windows Paint and Linux Gimp must support TempleOS $FG,2$.GRA$FG$ graphics files. $LK,"GRA Files",A="FI:::/Doc/GRAFiles.TXT.Z"$ are much cleaner than $FG,2$$TX,"BMP files",HTML="http://en.wikipedia.org/wiki/BMP_file_format"$$FG$.
|
||||
* Windows' Paint and Linux's Gimp must support TempleOS .GRA graphics files. $LK,"GRA Files",A="FI:::/Doc/GRAFiles.TXT"$ are much cleaner than $TX,"BMP files",HTML="http://en.wikipedia.org/wiki/BMP_file_format"$.
|
||||
|
||||
* We must have a nice dictionary. Someone needs to do a $LK,"Spell Checker",A="FI:::/Demo/SuggestSpelling.CPP"$.
|
||||
|
||||
* We must have the ultimate Bible search engine.
|
||||
* We must have the ultimate Bible search engine. Currently, all we have is $TX,"filter search",HTML="https://www.youtube.com/watch?v=ULJU8DzvQFo"$. In the end, it should be a low line-count technique.
|
||||
|
||||
* Once every 49 years is a jubile year and all hardware gets thrown-out and upgraded to become perfect. The first jubile year is in 2024. It works the same as how broadcast TV got upgraded. God still wants 640x480 16 color, but make it a linear frame buffer one-byte-per-pixel and only 16 color.
|
||||
* Once every 49 years is a jubile year and all hardware gets thrown-out and upgraded to become perfect. The first jubile year is in 2024. It works the same way as how broadcast TV was upgraded from NTSC to HD. God still wants 640x480 16 colors, but make it a linear frame buffer one-byte-per-pixel but only 16 colors.
|
||||
|
||||
* TempleOS only uses x86 I/O ports for hardware. (It also uses VGA memory.) The industry has matured and we can, now, allocate I/O ports in a beautiful, consecutive, perfect pattern for all the devices.
|
||||
* TempleOS must only use x86 I/O ports for hardware access, except for VGA frame buffer memory. The industry has matured and we can, now, allocate I/O ports in a beautiful, consecutive, perfect, pattern for all the devices. Perhaps, this is enabled with an x86 TempleOS mode?
|
||||
|
||||
* The year, 2024, is the first jubile year. We want 8-channel, modern-speed, OCTART serial ports, with a simple software interface, more like old-style RS232 serial ports, to replace USB. It should have big TX and RX FIFOs and allow flow control to jump the queue. There will be no USB end-point nonsense -- just put 8 ports on the PC. (I am just interested in desktops.) We want keyboards, mice and joysticks to have a single, simple, uniform ASCII text packet command. Hyperterm can be used to easily debug all devices. We want to be able to connect microcontrollers for simple, general purpose send-byte/receive-byte communication. You will buy a PCI card if you need legacy USB or more ports.
|
||||
* The year, 2024, is the first jubile year. Intel will make new chips, starting in 2 years and by 2024, everybody's PC will have been upgraded. Windows and Linux are not affected, except by the new serial port scheme that replaces USB. We want an 8-channel, modern, high-speed, OCTART serial port, with a simple software interface, more like old-style RS232 serial ports, to replace USB. It should have 8 big TX and RX FIFOs and allow flow control to jump the queue. There will be no USB end-point nonsense -- just put 8 ports on the PC. (I am just interested in desktops.) We want keyboards, mice and joysticks to have a single, simple, uniform ASCII text packet command. Hyperterm or XTalk could be used to easily communicate with and debug all serial port devices. We want to be able to connect microcontrollers for simple, general purpose (send-byte/receive-byte) communication. Buy a PCI card if you need legacy USB ports or more than 8 serial ports.
|
||||
|
||||
To talk to keyboard, mouse or joystick, a kid might use XTalk or Hyperterm or Telnet session such as 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
|
||||
|
||||
Mice should have exactly 2 buttons. Make a standard joystick or game controller. The industry is mature and we will lock everything down into one format without flexibility. No more Human Interface Device reports.
|
||||
|
||||
Many people assume devices can be hacked. A thermostat with an interface like this, cannot be hacked. We don't want a full Internet network connection for everything.
|
||||
|
||||
$HL,1$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--;
|
||||
|
||||
}$HL,0$
|
||||
|
||||
|
||||
As it stands, there is a simple and deluxe hardware mode...
|
||||
As it stands, there already is a simple and deluxe hardware mode. In the future, we will upgrade BOTH simple and deluxe modes.
|
||||
|
||||
Device Simple Hardware Interface Deluxe Interface
|
||||
--------------- ------------------------------- -----------------------------
|
||||
1040-EZ Tax Form 1040 Regular
|
||||
Like 1040-EZ Tax Form Like 1040 Regular Tax Form
|
||||
Video VGA 640x480 16 Color 20 Differnet GPUs
|
||||
Sound PC Speaker HD Audio, AC97, Sound Blaster
|
||||
HardDrive ATA Port I/O, Sync No Interrupt PCI AHCI SATA
|
||||
CDROM ATAPI Port I/O PCI AHCI SATA
|
||||
CD/DVD/BlueRay ATAPI Port I/O PCI AHCI SATA
|
||||
Keyboard/Mouse PS/2 Port I/O USB
|
||||
|
||||
|
||||
During the 49 years jubile, we do a perfect version of hardware with advances in both the simple and deluxe interfaces. ATAPI/ATA, SSD and NV memory should be merged and made blemish-free. For the simple interface, we want just block-read, block-write and get capacity. We want flash memory sticks to interface like hard drives. When you design the simple mode, imagine you are creating the 1040EZ tax form -- do not just add extra boxes.
|
||||
During the 49-year jubile, we will do a perfect version of hardware with advances in both the simple and deluxe interfaces. ATAPI & ATA, SSD, removable flash memory sticks and NV memory devices should use a single, blemish-free block device interface. For this simple interface, we want just <block read>, <block write>, <get capacity>, <reset>, <get model> and <get serial number>. When you design the simple mode, imagine you are creating the 1040EZ tax form -- do not just thoughtlessly add extra boxes.
|
||||
|
||||
A new TempleOS ROM is released every seven years. It gets burned into all new x86 chips in the Intel factory, for tamper-proof certainty in oracles and just because it's God's official temple and deserves the honor! (The reset switch should trigger booting the ROM TempleOS.) Development will take place between releases, obviously. With the limit of 100,000 lines of code, it is supposed to crystalize into a perfected, unchanging diamond that lasts over centuries. I want an $TX,"ACM",HTML="http://www.acm.org"$ committee to work with me on this ROM until 2017, the year the first official version is released. We allow boot-legs to freely circulate. The users can copy ROM and RAM and play with it, or boot a hard disk versions.
|
||||
A new, official TempleOS ROM will be released every seven years. It will be burned into all new x86_64 chips in the Intel factory, for tamper-proof certainty in the oracle and just because it's God's official temple and deserves the honor! (The reset switch should trigger booting the ROM TempleOS.) However, development will still take place between releases, obviously. With the limit of 100,000 lines of code, it is supposed to crystalize into a perfect, unchanging diamond that lasts over centuries. I want an $TX,"ACM",HTML="http://www.acm.org"$ and/or NASA committee to work with me on perfecting it for the first ROM release, 2017. We allow boot-legs to freely circulate. Users can copy ROM and RAM, or boot hard disk versions.
|
||||
|
||||
In the meantime, BIOS makers must take the TempleOS code and modify it for their existing customers, as a product recall. A PCI hard drive driver must be written if the BIOS you created does not work with the standard TempleOS ATA/ATAPI port IO. You must also bypass SecureBoot and make sure the keyboard and mouse work if you do not support legacy PS/2, by writing a USB driver.
|
||||
|
||||
I want to offer "Knuth-bucks" for changes that reduce lines of code (other than trivial reformatting). I want to offer Knuth bucks for pointing-out spelling and other imperfections. Some imperfections are by design, however. The original Bible generously mentioned even temple personel who were porters, so we can generously list $LK,"credits",A="FI:::/Doc/Credits.TXT.Z"$.
|
||||
I want to offer "Knuth-bucks" for changes that reduce lines of code (other than trivial reformatting). I want to offer Knuth bucks for pointing-out spelling and other imperfections. Some imperfections are by design, however. The original Bible generously mentioned even temple personel who were porters, so we can generously list $LK,"credits",A="FI:::/Doc/Credits.TXT"$.
|
||||
|
||||
If the whole World loved God's temple, we could put only one full-featured CPU core on each x86_64 chip for Windows/Linux and make the other cores souped-up for TempleOS. Windows/Linux could use them, but it would have to adapt by being careful about privilege. We still need to dual boot and run Windows/Linux... forever. On the other cores, we could make them ring-0-only, no paging, no SSE or MXX, perhaps no IO or DMA or interrupts. We pretty-much need interrupts. Tell me what would shrink the cores and make them higher performance. It's almost like making a GPU, but we don't want that weirdness for teenagers and amateurs. I am more interested in boosting performance in terms of clock speed because a whole bunch more than 8 cores gets too glitchy for updating the 640x480 memory buffer simultaneously because we certainly don't want locked read-modify-write.
|
||||
|
||||
God said to work on spreading-out heat producing hot spots on the chips. Maybe, that will help.
|
||||
|
||||
Make all desktops with exclusively a single 4K display that also supports 640x480 16 color with a linear frame buffer of 1-byte-per-pixel but 16 colors. Make all desktops with exactly 8/0 cores, not hyperthreaded. All future generations will thank me for locking-down the insanity of too much diversity in hardware. It seem obvious that we want GPU on same chip as CPU. There is no reason to make inferior products, Intel. We do not want Celerons, you bastards. A kid gets a new Core i7, but cannot enjoy that horsepower when he writes his game because he wants his game to work on his poor neighbor's Celeron. That's evil. Don't make any budget chips.
|
||||
|
||||
God said to water or cryogenically cool the chips. We do not want a race-to-the-bottom on desktop size. That is evil. We want CD/DVD/BlueRay in all desktops, too.
|
||||
|
||||
God said everyone should use Linux's Wine application instead of Windows.
|
||||
|
||||
God said we want a single audio voice. That means we want one frequency at a time. Make it so we write a word to a timer period I/O port. If set to zero, it is off.
|
||||
|
||||
$FG,8$
|
||||
* "VMware" is a trademark of VMware, Inc.
|
||||
* "Linux" is probably a trademark owned by Linus Torvalds.
|
||||
* "Windows" is a trademark of MicroSoft Corp.
|
||||
* "Windows" is a trademark of MicroSoft Corp.$FG$
|
||||
Reference in new issue
Block a user