TempleOSCDV4.02.ISO
This commit is contained in:
Terry A. Davis authored and minexew committed
1 parent
fedf66361e
commit
1541d7328d
171 files changed
+5326
-5237
No files matched your search
Binary file not shown.
+45
-2
@@ -2,7 +2,50 @@
|
||||
|
||||
Use $LK,"R",A="MN:R"$() to rename if I change a label.
|
||||
|
||||
$IV,1$----01/12/16 16:47:54----$IV,0$
|
||||
$IV,1$----01/28/16 14:05:52----$IV,0$
|
||||
* Fixed bug in $LK,"AutoComplete",A="MN:AutoComplete"$() init.
|
||||
* Added $LK,"HeapLogSizeRep",A="MN:HeapLogSizeRep"$().
|
||||
|
||||
$IV,1$----01/27/16 20:41:54----$IV,0$
|
||||
* $BK,1$TempleOS version 4.02 Released$BK,0$
|
||||
|
||||
$IV,1$----01/27/16 06:40:46----$IV,0$
|
||||
* Added $FG,2$<F2>$FG$ macro to $LK,"TestSuite",A="FI:::/Misc/OSTestSuite.CPP"$.
|
||||
* Added compiler err for $FG,2$break;$FG$ in a subswitch preface.
|
||||
|
||||
$IV,1$----01/27/16 04:14:08----$IV,0$
|
||||
* Added $LK,"::/Demo/ToHtmlToTXTExample/HtmlGen.CPP"$ and $LK,"::/Demo/ToHtmlToTXTExample/TXTGen.CPP"$.
|
||||
* Now, $LK,"Plain",A="MN:Plain"$() doesn't save with $LK,"CH_CURSOR",A="MN:CH_CURSOR"$.
|
||||
* $LK,"R",A="MN:R"$("DOCF_PLAIN_TEXT_WITH_TABS","DOCF_PLAIN_TEXT_TABS");
|
||||
* Change $LK,"Document Links",A="FF:::/Adam/DolDoc/DocLink.CPP,AD"$ "DF:word" to "DN:word".
|
||||
* Merged documentation into $LK,"::/Doc/FAQ.TXT"$.
|
||||
|
||||
$IV,1$----01/26/16 17:51:45----$IV,0$
|
||||
* $LK,"R",A="MN:R"$("PSect","FunSeg");
|
||||
* $LK,"R",A="MN:R"$("Equal","Equ");
|
||||
* $LK,"R",A="MN:R"$("Binary","Bin");
|
||||
|
||||
$IV,1$----01/26/16 14:09:45----$IV,0$
|
||||
* Changed $LK,"DirContextNew",A="MN:DirContextNew"$(), $LK,"FilesFindMatch",A="MN:FilesFindMatch"$() and $LK,"FilesFind",A="MN:FilesFind"$() to use full_name.
|
||||
* $LK,"R",A="MN:R"$("Statement","Stmt");
|
||||
|
||||
$IV,1$----01/18/16 15:19:43----$IV,0$
|
||||
* Added except arg to $LK,"Let2BlkDev",A="MN:Let2BlkDev"$(), $LK,"BlkDevChk",A="MN:BlkDevChk"$(), $LK,"Let2Drv",A="MN:Let2Drv"$(), $LK,"DrvChk",A="MN:DrvChk"$() and $LK,"DrvIsWritable",A="MN:DrvIsWritable"$().
|
||||
|
||||
$IV,1$----01/16/16 08:20:00----$IV,0$
|
||||
* Added $LK,"DrvTextAttrGet",A="MN:DrvTextAttrGet"$().
|
||||
* Removed $FG,4$DrvTextAttrSet$FG$().
|
||||
|
||||
$IV,1$----01/15/16 00:47:31----$IV,0$
|
||||
* $LK,"KeyboardPlug-Ins '9','0'",A="FF:::/HomeKeyPlugIns.CPP,'9'"$.
|
||||
* $LK,"R",A="MN:R"$("$$$$LM,5$$$$","$$$$ID,5$$$$");
|
||||
|
||||
$IV,1$----01/15/16 00:12:02----$IV,0$
|
||||
* Added $LK,"Let2BlkDevType",A="MN:Let2BlkDevType"$().
|
||||
* Added $LK,"WIF_SELF_FOCUS",A="MN:WIF_SELF_FOCUS"$ to $LK,"::/Misc/OSInstall.CPP"$.
|
||||
* Added $FG,2$%$$F$FG$ to $LK,"Print(\"\") Fmt Strings",A="FI:::/Doc/Print.TXT"$.
|
||||
|
||||
$IV,1$----01/12/16 19:17:12----$IV,0$
|
||||
* Overhauled $LK,"Mount",A="MN:Mount"$() and $LK,"::/Kernel/KCfg.CPP"$.
|
||||
|
||||
$IV,1$----01/12/16 10:06:18----$IV,0$
|
||||
@@ -24,7 +67,7 @@ $IV,1$----01/06/16 11:01:57----$IV,0$
|
||||
|
||||
$IV,1$----01/03/16 17:15:41----$IV,0$
|
||||
* Updated $LK,"::/Misc/PCIDevices.TXT"$.
|
||||
* Added null case option. Next higher integer with "$FG,2$case:$FG$" in $FG,2$switch$FG$ statements. See $LK,"::/Demo/NullCase.CPP"$.
|
||||
* Added null case option. Next higher integer with "$FG,2$case:$FG$" in $FG,2$switch$FG$ stmts. See $LK,"::/Demo/NullCase.CPP"$.
|
||||
|
||||
$IV,1$----12/31/15 00:44:44----$IV,0$
|
||||
* Made $LK,"ASM_KEYWORD",A="FF:::/Compiler/OpCodes.TXT,ASM_KEYWORD"$s usable in HolyC outside asm{} blocks.
|
||||
|
||||
+3
-3
@@ -5,7 +5,7 @@ Why did they make Solomon's Temple? It was a direction to look, to focus on, a
|
||||
|
||||
1 Kings 6:21 (King James)
|
||||
|
||||
$LM,5$6:21 So Solomon overlaid the house within with pure gold: and he made
|
||||
$ID,5$6:21 So Solomon overlaid the house within with pure gold: and he made
|
||||
a partition by the chains of gold before the $FG,4$oracle$FG$; and he overlaid
|
||||
it with gold.
|
||||
|
||||
@@ -15,7 +15,7 @@ with gold.
|
||||
|
||||
6:23 And within the $FG,4$oracle$FG$ he made two cherubims of olive tree, each
|
||||
ten cubits high.
|
||||
$LM,0$
|
||||
$ID,-5$
|
||||
|
||||
* TempleOS is God's official temple. Just like Solomon's temple, this is a community focal point where offerings are made and God's oracle is consulted.
|
||||
|
||||
@@ -31,7 +31,7 @@ $LM,0$
|
||||
|
||||
* Low line count is the highest good, so it is easy to learn the whole thing. Users should see the light at the end of the tunnel. One file system, for example, is better than many file systems.
|
||||
|
||||
* There is a limit of 100,000 lines of code for all time, not including applications and demos. $FG,4$Code comments count$FG$, however. Currently, there are $TX,"81,048",D="DD_TEMPLEOS_LOC_OFFICIAL"$ lines of code. $FG,4$3rd party libraries are banned$FG$ because they circumvent the intent of this limit. The vision is a Commodore 64 ROM -- a fixed core API that is the only dependency of applications. Dependency on components and libraries creates a hell that is no longer blissful.
|
||||
* There is a limit of 100,000 lines of code for all time, not including applications and demos. $FG,4$Code comments count$FG$, however. Currently, there are $TX,"80,901",D="DD_TEMPLEOS_LOC_OFFICIAL"$ lines of code. $FG,4$3rd party libraries are banned$FG$ because they circumvent the intent of this limit. The vision is a Commodore 64 ROM -- a fixed core API that is the only dependency of applications. Dependency on components and libraries creates a hell that is no longer blissful.
|
||||
|
||||
* Minimal abstraction is a goal. Sheep are fools. They always respect a design that is more complicated than another. Any genius can make it complicated. Like in physics, it takes a supra-genius to make it simple.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
$WW,1$$FG,5$$TX+CX,"Command Line Overview"$$FG$
|
||||
|
||||
The cmd line feeds into the $LK,"HolyC",A="FI:::/Doc/HolyC.TXT"$ compiler as you type. A statement outside a function executes immediately. Remember to add a semicolon.$WW,1$
|
||||
The cmd line feeds into the $LK,"HolyC",A="FI:::/Doc/HolyC.TXT"$ compiler as you type. A stmt outside a function executes immediately. Remember to add a semicolon.$WW,1$
|
||||
|
||||
Look-up the function headers with $FG,2$AutoComplete$FG$ by hitting $FG,2$<CTRL-SHIFT-F1>$FG$ after typing the first few letters.
|
||||
|
||||
|
||||
@@ -1,46 +0,0 @@
|
||||
$WW,1$$FG,5$$TX+CX,"Clearing-up Confusions"$$FG$
|
||||
|
||||
* I, $FG,2$Terry A. Davis$FG$, wrote every one of the $TX,"118,706",D="DD_TEMPLEOS_LOC"$ lines of TempleOS over the past $TX,"12.2",D="DD_TEMPLEOS_AGE"$ years (full-time). It runs on bare hardware with no layering, libraries, tools, modules or anything from other sources. It's 100% independent and stands alone. It has no networking and certainly doesn't call home. Every line of TempleOS src code is including in all distro's, from the kernel to the compiler to the boot loaders. See $LK,"::/Doc/Credits.TXT"$.
|
||||
|
||||
* TempleOS does not execute code not written by me and any time except for a few $FG,2$BIOS$FG$ calls for configuration. See $LK,"::/Doc/Credits.TXT"$.
|
||||
|
||||
* TempleOS is 100% independent -- it does not access the files of your primary operating system. It will work as the only operating system on your computer.
|
||||
|
||||
* TempleOS is 100% written from scratch. There is no $FG,2$Linux$FG$ or $FG,2$GNU$FG$ or any other code in TempleOS. Yes, I wrote the compiler from scratch. (I probably need to repeat that a few times.) See $LK,"::/Doc/Credits.TXT"$.
|
||||
|
||||
* TempleOS is an operating system, not a browser. The cmd line has active links. They link to local files.
|
||||
|
||||
* TempleOS compiles, not $FG,2$interprets$FG$, and uses no $FG,2$byte code$FG$ anywhere. I use the word $FG,2$script$FG$ sometimes for stuff, but it's actually compiled.
|
||||
|
||||
* I am an evolutionist. $FG,2$Adam$FG$ is a better term for the father of all tasks than $FG,2$root$FG$ was!
|
||||
|
||||
* $LK,"Bt",A="MN:Bt"$() is $FG,2$bit test$FG$, like the $FG,2$x86$FG$ instruction, not $FG,2$bit torrent$FG$.
|
||||
|
||||
* $LK,"Fs",A="MN:Fs"$ is a segment reg, not $FG,2$file system$FG$. (It is kept pointing to the current task's record.) There is no memory segmentation -- FS and GS are used as general purpose regs, more or less.
|
||||
|
||||
* TempleOS uses a dialect of C/C++ called $LK,"HolyC",A="FI:::/Doc/HolyC.TXT"$. It is not $FG,2$PASCAL$FG$. I altered the syntax making parenthesis optional on function calls with no paramaters.
|
||||
|
||||
* $LK,"Sleep",A="MN:Sleep"$() makes a program pause. It is not hybernation for a laptop.
|
||||
|
||||
* $LK,"Yield",A="MN:Yield"$() saves the current task's regs (context) and loads in the next task.
|
||||
|
||||
* I use the term $LK,"JIT Compile Mode",A="FF:::/Doc/Glossary.TXT,JIT Compile Mode"$. This means it is compiled and executable code placed into mem, ready to be called.
|
||||
|
||||
* Files with names ending in $FG,2$.Z$FG$ are individually compressed, not encrypted. $LK,"Copy",A="MN:Copy"$() or rename them with $LK,"Move",A="MN:Move"$() to store them uncompressed.
|
||||
|
||||
* TempleOS is open src and every bit of the src code is included in the distro. Use $LK,"MakeOSDrvBootInstall",A="MN:MakeOSDrvBootInstall"$() to compile the kernel and compiler.
|
||||
|
||||
* TempleOS does not use object files or a linker.
|
||||
|
||||
* Refresh rate is how often TempleOS updates screen mem. It is not syncronized to the hardware rate. It has nothing to do with it.
|
||||
|
||||
* No application has a lock on the speaker so apps can interfere with each other and TempleOS makes speaker noise during disk access on purpose.
|
||||
|
||||
* There are no mem leaks. TempleOS alllocs mem as more items are displayed on the screen. TempleOS alllocs mem for code as it is compiled at the cmd line. If you $FG,2$#include$FG$ a file twice, it alllocs more mem for it. If you have a 50,000 line program with each line taking twenty bytes on a machine with 1 Gig, you could $FG,2$#include$FG$ it a thousand times if it had no data or graphics and no other use of mem. Code entered at the cmd line gets alloced and persists. I don't want to hear any bullshit about leaks unless you actually run-out. If it bothers you, hit $FG,2$<CTRL-ALT-x>$FG$ and $FG,2$<CTRL-ALT-e>, $FG$periodically$FG$. Use the pop-up flag on macros in your menu to spawn new tasks, run applications and free the applications when they are finished and everything will be fine. Small mem chunks stick to the task when they are freed until it is killed. The only way to get in trouble involves allocating multiple Meg chunks and freeing them. These can only be reused if the same size gets alloced again. Use $LK,"HeapLog",A="MN:HeapLog"$() and $LK,"HeapLogRep",A="MN:HeapLogRep"$() to see who alloced mem and didn't free it.
|
||||
|
||||
* The editor periodically takes a snap-shot for $FG,2$UNDO$FG$ and this looks like a memory leak.
|
||||
|
||||
|
||||
$FG,8$
|
||||
* "Linux" is probably a trademark owned by Linus Torvalds.
|
||||
$FG$
|
||||
+1
-1
@@ -40,7 +40,7 @@ $WW,1$$FG,5$$TX+CX,"Credits"$$FG$
|
||||
|
||||
20) I hired and artist, Cody Rigby, for $$3,000 worth of pixel art.
|
||||
|
||||
21) Erik van der Karbargenbok made $LK,"TempleBot",A="PI:::/Linux/TempleBot",HTML="http://www.templeos.org/Wb/Home/Wb2/Files/Bin/TempleBot.html"$.
|
||||
21) Erik van der Karbargenbok made $LK,"TempleBot",A="PI:::/Linux/TempleBot",HTML="http://www.templeos.org/Wb/Home/Downloads/Bin/TempleBot.html"$.
|
||||
|
||||
22) The random number generator is from Donald Knuth in the wikipedia entry for $TX,"Linear_congruential_generator",HTML="http://en.wikipedia.org/wiki/Linear_congruential_generator"$.
|
||||
|
||||
|
||||
@@ -0,0 +1,2 @@
|
||||
$WW,1$Use $GREEN$%p$FG$ to print a pointer with FunSeg+Offset or use $GREEN$%P$FG$ to print a link to a FunSeg+Offset.
|
||||
|
||||
+1
-1
@@ -35,7 +35,7 @@ $LK,"Trace",A="MN:Trace"$() unassembles code generated from the HolyC compiler.
|
||||
$LK,"PassTrace",A="MN:PassTrace"$() shows intermediate code coming-out after optimization. The bits ctrl which passes are displayed.
|
||||
$ID,-2$
|
||||
|
||||
* There is a heap check utility which can find leaks. Use $LK,"HeapLog",A="MN:HeapLog"$(), and $LK,"HeapLogRep",A="MN:HeapLogRep"$(). It's a really simple program which intercepts $LK,"MAlloc",A="MN:MAlloc"$() and $LK,"Free",A="MN:Free"$(). You can customize the code to find other heap issues.
|
||||
* There is a heap check utility which can find leaks. Use $LK,"HeapLog",A="MN:HeapLog"$(), $LK,"HeapLogAddrRep",A="MN:HeapLogAddrRep"$() and $LK,"HeapLogSizeRep",A="MN:HeapLogSizeRep"$(). It's a really simple program which intercepts $LK,"MAlloc",A="MN:MAlloc"$() and $LK,"Free",A="MN:Free"$(). You can customize the code to find other heap issues.
|
||||
|
||||
* You can define handler functions for $FG,2$<CTRL-ALT-letter>$FG$ keys with $LK,"CtrlAltCBSet",A="MN:CtrlAltCBSet"$(). They operate either in a interrupt environment or in the window mgr when it queues kbd msgs. You can do $LK,"Raw",A="MN:Raw"$() output. $FG,2$<CTRL-ALT-letter>$FG$ handlers take a scan_code as an arg.
|
||||
|
||||
|
||||
@@ -1,2 +0,0 @@
|
||||
$WW,1$Use $GREEN$%p$FG$ to print a pointer with PSect+Offset or use $GREEN$%P$FG$ to print a link to a PSect+Offset.
|
||||
|
||||
+23
-82
@@ -3,7 +3,6 @@ $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 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, glorious and 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.
|
||||
|
||||
* 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.
|
||||
@@ -12,98 +11,40 @@ $LK,"::/Kernel/BlkDev/DskCluster.CPP"$ :152 All the cluster operations become bl
|
||||
|
||||
* 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 II 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.
|
||||
|
||||
* To PC hardware manufacturers and VMware until we create the simple block device standard, ATA/ATAPI PIO must work. In fact, put the devices at standard IDE port addresses. Hard disk should be primary master 1F0/3F6. Desktops must have CD/DVD/BlueRay and should be placed at the 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.
|
||||
|
||||
* 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,IPI"$
|
||||
|
||||
* VMware PC speaker's distortion is a good idea, but it is too much for hymns.
|
||||
|
||||
* PS/2 emulated keyboard and mouse must work. The BIOS must enable these.
|
||||
|
||||
* 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 when doing port I/O. See $LK,"ATAGetResult",A="MN:ATAGetResult"$(). Perhaps, x86 CPU chips need a new TempleOS mode for fast IN/OUT instructions?
|
||||
|
||||
* Perhaps, a new x86 CPU mode can be made, causing fast software interrupt that do exactly what the CALL REL32 does, but with IDT indirection.
|
||||
|
||||
* Since I don't use paging (for anything), Intel should have an option for no-paging long mode, and optimize it.
|
||||
$LK,"::/Kernel/Mem/PageTables.CPP"$ :153 lines to identity-map gets eliminated.
|
||||
|
||||
* 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? I'm not an expert, but there is an alternate 8-bit ASCII Cyrillic font. Should we modify one font or have a key like the C64 that switches to an alternate font? If we modify one font, we just 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's Gimp must support TempleOS $LK,"GRA Files",A="FI:::/Doc/GRAFiles.TXT"$. They are blemish free, unlike $TX,"BMP files",HTML="http://en.wikipedia.org/wiki/BMP_file_format"$.
|
||||
* Until super simple block devices are available, hard disk should be placed at IDE primary master 1F0/3F6 and CD/DVD/BlueRay should be placed at the IDE secondary master 170/376.
|
||||
$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.
|
||||
|
||||
* We must have a nice dictionary. Someone needs to do a $LK,"Spell Checker",A="FI:::/Demo/SuggestSpelling.CPP"$.
|
||||
* Until super simple serial ports are available, PS/2 emulated keyboard and mouse must work. The BIOS must enable these.
|
||||
|
||||
* 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 when doing port I/O. See $LK,"ATAGetResult",A="MN:ATAGetResult"$(). Perhaps, x86 CPU chips need a new TempleOS mode for fast IN/OUT instructions?
|
||||
|
||||
* Perhaps, a new interrupt descriptor table entry type or a new x86 CPU mode can be made that cause fast software interrupts, doing exactly what the CALL REL32 does, but with IDT as indirection. We don't need to change privilege levels or stacks.
|
||||
|
||||
* Since I don't use paging (for anything), Intel should have an option for no-paging long mode, and optimize it!
|
||||
$LK,"::/Kernel/Mem/PageTables.CPP"$ :153 lines to identity-map gets eliminated.
|
||||
|
||||
* 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.
|
||||
|
||||
* We do not want UTF, just 8-bit characters. Somebody needs to choose new 8-bit ASCII characters for 128-255, since we do not want text graphic symbols. We want Russian, Greek or Hebrew alphabets, perhaps? I heard there is an alternate 8-bit ASCII Cyrillic font. Should we modify one font or have a key like the C64 that switches to an alternate font? I made so $FG,2$<CTRL-ALT-f>$FG$ toggles between two fonts, but did not include Cyrillic. If we modify one font, we just need the twelve window $LK,"TextBorder",A="MN:TextBorder"$ characters, but I think we can place those 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.
|
||||
|
||||
* Microsoft Paint and Linux's Gimp must support TempleOS $LK,"GRA Files",A="FI:::/Doc/GRAFiles.TXT"$. They are blemish free, unlike $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"$, too.
|
||||
|
||||
* 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 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 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. 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 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
|
||||
--------------- ------------------------------- -----------------------------
|
||||
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
|
||||
CD/DVD/BlueRay ATAPI Port I/O PCI AHCI SATA
|
||||
Keyboard/Mouse PS/2 Port I/O USB
|
||||
|
||||
|
||||
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, 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"$.
|
||||
|
||||
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.$FG$
|
||||
* "Windows" and "Paint" are trademarks of MicroSoft Corp.$FG$
|
||||
+6
-4
@@ -9,13 +9,13 @@ $LK,"::/Doc/HelloWorld.TXT"$
|
||||
$WW,0$$TR,"Games: Beginner"$
|
||||
$ID,2$$LK,"::/Demo/Graphics/NetOfDots.CPP"$
|
||||
$LK,"::/Demo/Graphics/InputPointer.CPP"$
|
||||
$LK,"::/Demo/Graphics/Lines.CPP"$
|
||||
$LK,"::/Demo/Graphics/SunMoon.CPP"$
|
||||
$LK,"::/Demo/Games/ElephantWalk.CPP"$
|
||||
$LK,"::/Demo/Graphics/LowPassFilter.CPP"$
|
||||
$LK,"::/Demo/Graphics/MathAudioDemo.CPP"$
|
||||
$LK,"::/Demo/Graphics/Lines.CPP"$
|
||||
$LK,"::/Demo/Games/TicTacToe.CPP"$
|
||||
$LK,"::/Demo/Graphics/SpritePlot.CPP"$
|
||||
$LK,"::/Demo/Games/ElephantWalk.CPP"$
|
||||
$LK,"::/Demo/Graphics/SpritePut.CPP"$
|
||||
$LK,"::/Demo/Graphics/SpritePutExt.CPP"$
|
||||
$LK,"::/Demo/Snd/ASCIIOrgan.CPP"$
|
||||
@@ -37,13 +37,13 @@ $LK,"::/Demo/Graphics/Blot.CPP"$
|
||||
$LK,"::/Demo/Graphics/ScreenCapture.CPP"$
|
||||
$LK,"::/Demo/Graphics/EdSprite.CPP"$
|
||||
$LK,"::/Demo/PullDownMenu.CPP"$
|
||||
$MA-X+PU,"::/Demo/Games/Stadium",LM="Cd(\"::/Demo/Games/Stadium\");Dir;View;\n"$
|
||||
$LK,"::/Demo/Graphics/Palette.CPP"$
|
||||
$LK,"::/Demo/Games/CircleTrace.CPP"$
|
||||
$LK,"::/Demo/Games/Halogen.CPP"$
|
||||
$LK,"::/Demo/Games/TheDead.CPP"$
|
||||
$LK,"::/Demo/Games/RainDrops.CPP"$
|
||||
$LK,"::/Demo/Snd/MorseCode.CPP"$
|
||||
$MA-X+PU,"::/Demo/Games/Stadium",LM="Cd(\"::/Demo/Games/Stadium\");Dir;View;\n"$
|
||||
$LK,"::/Demo/Graphics/Lattice.CPP"$
|
||||
$LK,"::/Demo/Graphics/Collision.CPP"$
|
||||
$LK,"::/Demo/Games/BlackDiamond.CPP"$
|
||||
@@ -125,7 +125,9 @@ $ID,2$$LK,"::/Misc/DoDistro.CPP"$
|
||||
$LK,"::/Demo/DbgDemo.CPP"$
|
||||
$LK,"::/Demo/SubSwitch.CPP"$
|
||||
$LK,"::/Demo/DateTime.CPP"$
|
||||
$LK,"::/Demo/ReverseFileExample/Reverse.CPP"$.
|
||||
$LK,"::/Demo/ReverseFileExample/Reverse.CPP"$
|
||||
$LK,"::/Demo/ToHtmlToTXTExample/HtmlGen.CPP"$
|
||||
$LK,"::/Demo/ToHtmlToTXTExample/TXTGen.CPP"$
|
||||
$LK,"::/Demo/SortFileExample/F64FileGen.CPP"$
|
||||
$LK,"::/Demo/SortFileExample/F64FileSort.CPP"$
|
||||
$LK,"::/Demo/PhoneNumWords.CPP"$
|
||||
|
||||
+95
@@ -0,0 +1,95 @@
|
||||
$WW,1$$FG,5$$TX+CX,"Frequently Asked Questions"$$FG$
|
||||
|
||||
$TR,"How come it is public domain, not GPL?"$
|
||||
$ID,2$I, $FG,2$Terry A. Davis$FG$, wrote all $TX,"118,851",D="DD_TEMPLEOS_LOC"$ lines of TempleOS over the past $TX,"12.5",D="DD_TEMPLEOS_AGE"$ years (full-time). It can run on some bare metal 64-bit PC's from about 2005-2010 with no layering, libraries, tools, modules or anything from other sources. Otherwise, you run it in a virtual machine, like $FG,2$VMware$FG$, $FG,2$QEMU$FG$ or $FG,2$VirtualBox$FG$. It is independent and stands alone. It has no networking, so it certainly doesn't call home. 100% of the src code is including on all distro's, from the kernel to the compiler to the boot loaders! See $LK,"::/Doc/Credits.TXT"$.
|
||||
$ID,-2$$TR,"Shouldn't it be GNU/TempleOS?"$
|
||||
$ID,2$TempleOS executes no code not written by me at any time except for a few $FG,2$BIOS$FG$ calls for configuration. I even wrote boot-loaders, so I do not need $LK,"Grub",A="FI:::/Doc/Grub.TXT"$. See $LK,"::/Doc/Credits.TXT"$.
|
||||
$ID,-2$$TR,"Don't you use GNU's gcc?"$
|
||||
$ID,2$TempleOS was written from scratch, starting with $FG,2$TASM$FG$ long ago, launching from real-mode DOS. Now, there is no $FG,2$Linux$FG$ or $FG,2$GNU$FG$ or any other code in TempleOS. Yes, I wrote the compiler from scratch. See $LK,"::/Doc/Credits.TXT"$.
|
||||
$ID,-2$$TR,"Why do you dual boot?"$
|
||||
$ID,2$TempleOS is 100% independent -- it does not access the files of your primary operating system and TempleOS will work as the only operating system on your computer, but it has no networking. In your off hours, you will use your other operating system.
|
||||
$ID,-2$$TR,"It has links, so is it a browser?"$
|
||||
$ID,2$TempleOS is an operating system, not a browser. $LK,"TempleOS links",A="MN:LK_FILE"$ are a special format and only link too local files and symbol source addresses.
|
||||
$ID,-2$$TR,"Where are the animated 3D icon GIFs?"$
|
||||
$ID,2$3D $LK,"Sprites",A="FI:::/Doc/Sprite.TXT"$ are stored as a mesh of triangles. There are no GIF files. It $LK,"rotates",A="MN:Mat4x4MulXYZ"$ 3D sprite objects on the fly.
|
||||
$ID,-2$$TR,"If the compiler is JIT, isn't it an interpretor?"$
|
||||
$ID,2$TempleOS compiles, doesn't $FG,2$interpret$FG$, and uses no $FG,2$byte code$FG$ anywhere. I loosely use the word $FG,2$script$FG$ sometimes, but it's actually compiled. The compiler's $LK,"optimization",A="MN:OptPass012"$ code is actually where the compiler evaluates constants to simplify them, like every optimizing compiler.
|
||||
$ID,-2$$TR,"Are you a Creationist?"$
|
||||
$ID,2$I am an evolutionist. $FG,2$Adam$FG$ is a better term for the first father of all tasks than $FG,2$root$FG$ was!
|
||||
$ID,-2$$TR,"Is 'Bt()' in the code Bit Torrent?"$
|
||||
$ID,2$$LK,"Bt",A="MN:Bt"$() is $FG,2$bit test$FG$, like the $FG,2$x86$FG$ instruction, not $FG,2$bit torrent$FG$.
|
||||
$ID,-2$$TR,"Is 'Fs->' in the code file system?"$
|
||||
$ID,2$$LK,"Fs",A="MN:Fs"$ is a segment reg, not $FG,2$file system$FG$. ($LK,"Fs",A="MN:Fs"$ is kept pointing to the current task's record.) There is no memory segmentation. It is 64-bit and flat. FS and GS are used as general purpose regs, more or less.
|
||||
$ID,-2$$TR,"Is it Pascal?"$
|
||||
$ID,2$TempleOS uses a dialect of C/C++ called $LK,"HolyC",A="FI:::/Doc/HolyC.TXT"$. It is not $FG,2$Pascal$FG$. I altered the syntax making parenthesis optional on function calls with no paramaters.
|
||||
$ID,-2$$TR,"Why doesn't Sleep() make my laptop hibernate?"$
|
||||
$ID,2$$LK,"Sleep",A="MN:Sleep"$() makes a program pause. It is not hibernation for a laptop.
|
||||
$ID,-2$$TR,"What is Yield() for in loops?"$
|
||||
$ID,2$$LK,"Yield",A="MN:Yield"$() saves the current task's regs (context) and loads in the next task. In a loop waiting for disk IO, it executes $LK,"Yield",A="MN:Yield"$() which pegs the CPU load, yet the system is responsive.
|
||||
$ID,-2$$TR,"What is JIT Compiled Mode?"$
|
||||
$ID,2$The term $LK,"JIT Compile Mode",A="FF:::/Doc/Glossary.TXT,JIT Compile Mode"$ means it compiles and executes code placed into mem, not stored on disk.
|
||||
$ID,-2$$TR,"Why do files end in .Z? Are they encrypted?"$
|
||||
$ID,2$Files with names ending in $FG,2$.Z$FG$ are individually compressed using $LK,"TempleOS Compression",A="FI:::/Kernel/Compress.CPP"$. They are not encrypted. $LK,"Copy",A="MN:Copy"$() or rename them with $LK,"Move",A="MN:Move"$() to a name without $FG,2$.Z$FG$ and they will be stored in an uncompressed form. See $LK,"TOSZ",A="FI:::/Doc/TOSZ.TXT"$ for Linux or Windows uncompress C/C++ code.
|
||||
$ID,-2$$TR,"Is it open source? How do I build it?"$
|
||||
$ID,2$TempleOS is 100% open src. All the src code is included in the distro. Use $LK,"MakeOSDrvBootInstall",A="MN:MakeOSDrvBootInstall"$() to compile the kernel and compiler. The rest is $LK,"JIT Compiled",A="FF:::/Doc/Glossary.TXT,JIT Compile Mode"$ during boot. See $LK,"::/StartOS.CPP"$.
|
||||
$ID,-2$$TR,"Where are object files? How do I link?"$
|
||||
$ID,2$TempleOS does not use object files or a linker. $LK,"AOT Compile Mode",A="FF:::/Doc/Glossary.TXT,AOT Compile Mode"$ is used to directly create flat binary files, $FG,2$/Kernel.BIN.C$FG$ and $FG,2$/Compiler/Compiler.BIN.Z$FG$ with no object files and linking.$FG$ $LK,"JIT Compile Mode",A="FF:::/Doc/Glossary.TXT,JIT Compile Mode"$ place code in memory, ready to run, with no object files or linking. Linking is done when $FG,2$BIN$FG$ modules are $LK,"Load",A="MN:Load"$()ed.
|
||||
$ID,-2$$TR,"What is the FPS refresh rate?"$
|
||||
$ID,2$The refresh rate is $TX,"30",D="WMG_FPS"$ frames-per-second. That is how often TempleOS updates screen mem. It is not syncronized to the hardware.
|
||||
$ID,-2$$TR,"How does a task own the speaker?"$
|
||||
$ID,2$No task or application has a lock on the speaker so apps will interfere with each other.
|
||||
$ID,-2$$TR,"Why does it leak memory?"$
|
||||
$ID,2$TempleOS allocs mem as more items are displayed in the window. Also, TempleOS allocs mem for code as it is compiled at the cmd line. If you $FG,2$#include$FG$ a file twice, it allocs more mem for it. If you have a 50,000 line program with each line taking twenty bytes on a machine with 1 Gig, you could $FG,2$#include$FG$ it a thousand times if it had no data or graphics and no other use of mem. If it bothers you, hit $FG,2$<CTRL-ALT-x>$FG$ and $FG,2$<CTRL-ALT-e>, $FG$periodically, to kill and recreate the task$FG$. Use the pop-up flag on macros in your $LK,"PersonalMenu",A="FI:::Home/PersonalMenu.TXT"$ to spawn new tasks, run applications and free the applications when they are finished. Small mem chunks stick to the task when they are freed until it is killed. The only way to get in trouble is allocating multiple Meg chunks and freeing them. These can only be reused if the same size gets alloced again. Use $LK,"HeapLog",A="MN:HeapLog"$(), $LK,"HeapLogAddrRep",A="MN:HeapLogAddrRep"$() and $LK,"HeapLogSizeRep",A="MN:HeapLogSizeRep"$() to see who alloced mem and didn't free it. See $LK,"MemOverview",A="FI:::/Doc/MemOverview.TXT"$.
|
||||
$ID,-2$$TR,"Why do I get a memory leak when editing big files?"$
|
||||
$ID,2$The editor periodically takes a snap-shot of the document for $FG,2$UNDO$FG$ and this looks like a memory leak.
|
||||
$ID,-2$$TR,"Why is it in text mode?"$
|
||||
$ID,2$TempleOS runs in $FG,2$VGA 640x480 16 color$FG$ graphics mode, not text mode. It changes to this mode with a $LK,"BIOS call",A="FF:::/Kernel/KStart.CPP,INT 0x10"$ while in real-mode before it switches to 64-bit mode. The text is $LK,"drawn by hand",A="MN:GrUpdateTextFG"$. See $LK,"::/Kernel/Font8x8.CPP"$. If graphics mode fails, it falls-back on text mode. You can force text mode with an $LK,"Kernel config",A="FI:::/Kernel/KCfg.CPP"$ option.
|
||||
$ID,-2$$TR,"Where is the kernel memory?"$
|
||||
$ID,2$TempleOS identity-maps all memory, all the time. It is like paging is not used. There is no special kernel $FG,2$high half$FG$ memory space. TempleOS is ring-0-only, so everything is kernel, even user programs. There is a special task called $FG,2$Adam$FG$ and he doesn't die, so his heap never gets freed. That's as close to $FG,2$kernel memory$FG$ as it gets. All code goes in the lowest 2 Gig of addresses, known as the $LK,"Code Heap",A="FF:::/Doc/Glossary.TXT,Code and Data Heaps"$, so that the $FG,2$REL32$FG$ addressing mode can be used. See $LK,"MemOverview",A="FI:::/Doc/MemOverview.TXT"$.
|
||||
$ID,-2$$TR,"Why does it run code from stack addresses?"$
|
||||
$ID,2$TempleOS puts all code in the lowest 2 Gig, known as the $LK,"Code Heap",A="FF:::/Doc/Glossary.TXT,Code and Data Heaps"$, so that the $FG,2$REL32$FG$ addressing mode can be used. TempleOS is 64-bit, but $FG,2$2 Gig$FG$ is enough for code. It actually puts global variables there, too, but you can turn that off with $LK,"OPTf_GLBLS_ON_DATA_HEAP",A="MN:OPTf_GLBLS_ON_DATA_HEAP"$. $LK,"MAlloc",A="MN:MAlloc"$() allocs higher memory.
|
||||
$ID,-2$$TR,"How does it SYSCALL?"$
|
||||
$ID,2$TempleOS doesn't use software interrupts or $FG,2$SYSCALL$FG$ instructions because it never needs to change out of ring-0, even running user programs. Calls are always $FG,2$CALL REL32$FG$ instructions.
|
||||
$ID,-2$$TR,"How do you fault-in stack?"$
|
||||
$ID,2$The stack does not grow, so do not do deep recursion. In theory, memory gets fragmented, too.
|
||||
$ID,-2$$TR,"How do I set the PATH?"$
|
||||
$ID,2$There is no $FG,2$PATH$FG$. You do not enter filenames at the command-line and expect them to run. You enter C-like code. $LK,"Get Started Here",A="FI:::/Doc/CmdLineOverview.TXT"$.
|
||||
$ID,-2$$TR,"How do I boot it with Grub?"$
|
||||
$ID,2$If you use $LK,"Grub",A="FI:::/Doc/Grub.TXT"$, you $FG,2$chain-load$FG$ like Windows. See $LK,"Boot",A="FI:::/Doc/Boot.TXT"$. You can use the TempleOS boot-loader. $LK,"Master-Boot-Loader-Stage1",A="FI:::/Adam/Opt/Boot/BootMHD.CPP"$, $LK,"Master-Boot-Loader-Stage2",A="FI:::/Adam/Opt/Boot/BootMHD2.CPP"$, $LK,"Partition-Boot-Loader",A="FI:::/Adam/Opt/Boot/BootHD.CPP"$, $LK,"CD-DVD-Boot-Loader",A="FI:::/Adam/Opt/Boot/BootDVD.CPP"$.
|
||||
$ID,-2$$TR,"How do I get Kernel.BIN to boot?"$
|
||||
$ID,2$The boot-loaders must be patched by you running $LK,"MakeOSDrvBootInstall",A="MN:MakeOSDrvBootInstall"$() or $LK,"MasterBootInstall",A="MN:MasterBootInstall"$(). Those will write the block address into the boot-loader because the boot-loaders do not navigate file systems to find the $LK,"Stage2",A="FI:::/Kernel/KStart.CPP"$ if you relocate it.
|
||||
$ID,-2$$TR,"Why is there some 16-Bit code?"$
|
||||
$ID,2$TempleOS is 64-bit. Like all PC operating systems, the boot-loader starts in 16-bit real-mode. TempleOS calls a few $FG,2$BIOS$FG$ info routines, switches to VGA-640x480x4bit, switches to 32-bit, then, 64-bit mode. There is an odd thing called a $FG,2$$TX,"PCI BIOS",HTML="http://www.o3one.org/hwdocs/bios_doc/pci_bios_21.pdf"$$FG$ which is 32-bit used for $FG,2$PCI$FG$ config space access. TempleOS calls $LK,"that",A="FI:::/Kernel/PCIBIOS.CPP"$ a couple times. It must temporarily drop-out-of 64-bit mode for that and stop multi-tasking.
|
||||
$ID,-2$$TR,"Why are you pushing 32-bit values on the stack?"$
|
||||
$ID,2$$FG,2$PUSH EAX$FG$ : All stack operations in 64-bit mode are 64-bits.
|
||||
$ID,-2$$TR,"Why are you using 32-bit instructions and not setting high 32-bits?"$
|
||||
$ID,2$$FG,2$XOR EAX,EAX$FG$ : Operations on 32-bit regs clear the high 32-bits.
|
||||
$ID,-2$$TR,"How do you use the FS and GS segment registers."$
|
||||
$ID,2$$FG,2$MOV RAX,FS:[RAX]$FG$ : FS can be set with a $FG,2$WRMSR$FG$, but displacement is RIP relative, so it's tricky to use. FS is used for the current $LK,"CTask",A="MN:CTask"$, GS for $LK,"CCPU",A="MN:CCPU"$.
|
||||
$ID,-2$$TR,"How do I set ORG for position of code?"$
|
||||
$ID,2$The compiler creates $FG,2$pos independent$FG$ code. Don't create code which is loaded at a fixed, specified location. Code in a BIN file is $FG,2$pos independent$FG$ by virtue of a table in the BIN file for patching absolute addresses.
|
||||
$ID,-2$$TR,"How are symbols loaded?"$
|
||||
$ID,2$Binary executable files have export syms which are loaded into the sym tables. The operating system $FG,2$Kernel$FG$ has such an export table. In addition, some map files are processed to provide more information on syms -- src file links. This is how the $LK,"Man",A="MN:Man"$()/$FG,2$AutoComplete$FG$ feature can find src lines.
|
||||
$ID,-2$$TR,"Why doesn't assert work?"$
|
||||
$ID,2$$FG,2$#assert$FG$ might print a message at COMPILE time, not run time.
|
||||
$ID,-2$$TR,"Why doesn't C++ public work?"$
|
||||
$ID,2$The word $FG,2$public$FG$ in $LK,"HolyC",A="FI:::/Doc/HolyC.TXT"$ does very little except allow the $LK,"Help & Index",A="FI:::/Doc/HelpIndex.TXT"$ and $LK,"Who",A="MN:Who"$() to exclude meaningless syms. If you wish a full report of public and nonpublic syms $MA-X+PU,"Click Here",LM="DocMax(1000000);Who;View;\n"$.
|
||||
$ID,-2$$TR,"How does the debugger do source debugging?"$
|
||||
$ID,2$When compilation takes place, the structures used by the compiler stick around. Data on classes can be accessed. See $LK,"ClassRep",A="MN:ClassRep"$().
|
||||
$ID,-2$$TR,"What are the ASCII 5 and ASCII 31 chars doing in my text files?"$
|
||||
$ID,2$The cursor location is stored as an $FG,2$ASCII 5$FG$ in files. $FG,2$ASCII 31$FG$ is $FG,2$SHIFT-SPACE$FG$, a character which does not get converted to tabs by space-to-tabs, $LK,"S2T",A="MN:S2T"$(). The $FG,2$ASCII 28$FG$ is $FG,2$SHIFT-ESC$FG$.
|
||||
$ID,-2$$TR,"Why is there garbage at the end of my text files?"$
|
||||
$ID,2$Binary sprite data is stored beyond the terminating $FG,2$NULL$FG$ in text files. Map files store debug src line addresses.
|
||||
$ID,-2$$TR,"Why are sprites so small?"$
|
||||
$ID,2$Sprites can be stored as vector graphics so they might take shockingly little room. They can be converted to bitmaps.
|
||||
$ID,-2$$TR,"Why don't I need to recompile /Adam and /Home files?"$
|
||||
$ID,2$If you change code in the $FG,2$/Adam$FG$ or your $FG,2$/Home$FG$ directory, you don't need to recompile, you just need to reboot because those directories get recompiled when you boot. It uses $LK,"JIT Compile Mode",A="FF:::/Doc/Glossary.TXT,JIT Compile Mode"$. There is no $FG,2$.BIN$FG$ file for $FG,2$JIT$FG$ compilation. See $LK,"::/StartOS.CPP"$.
|
||||
$ID,-2$$TR,"Why does it finds files that aren't there?"$
|
||||
$ID,2$If not found, $FG,2$.Z$FG$ is added or removed from filename and a search is done again. If a file is still not found, the parent directories are searched for a file of the same name.
|
||||
$ID,-2$
|
||||
$FG,8$
|
||||
* "Windows" is a trademark of MicroSoft Corp.
|
||||
* "Linux" is probably a trademark owned by Linus Torvalds.
|
||||
* "VMware" is a trademark of VMware, Inc.
|
||||
* "VirtualBox" is a trademark of Oracle.
|
||||
$FG$
|
||||
+1
-1
@@ -5,7 +5,7 @@ File util $LK,"FilesFind",A="MN:FilesFind"$() wildcard mask consists of a single
|
||||
|
||||
$FG,2$"/Kernel/*"$FG$ BaseDir: $FG,2$/Kernel$FG$ Mask: $FG,2$*$FG$
|
||||
$FG,2$"/Demo/*.BMP*;*.GRA*"$FG$ BaseDir: $FG,2$/Demo$FG$ Mask: $FG,2$*.BMP*$FG$ | $FG,2$*.GRA*$FG$
|
||||
$FG,2$"/*.TXT*;~*Bible*"$FG$ BaseDir: $FG,2$Root$FG$ Mask: $FG,2$*.TXT*$FG$ but not $FG,2$*Bible*$FG$
|
||||
$FG,2$"/*.TXT*;~*/Bible*"$FG$ BaseDir: $FG,2$Root$FG$ Mask: $FG,2$*.TXT*$FG$ but not $FG,2$*/Bible*$FG$
|
||||
|
||||
See $LK,"FilesFindMatch",A="MN:FilesFindMatch"$().
|
||||
|
||||
|
||||
+5
-3
@@ -45,6 +45,7 @@ $FG,2$Dsk$FG$ Disk
|
||||
$FG,2$Dst$FG$ Destination
|
||||
$FG,2$Ed$FG$ Edit, Editor
|
||||
$FG,2$Elem$FG$ Element
|
||||
$FG,2$Equ$FG$ Equal
|
||||
$FG,2$Evt$FG$ Event
|
||||
$FG,2$Exe$FG$ Execute
|
||||
$FG,2$Ext$FG$ Extern, Extended
|
||||
@@ -100,7 +101,7 @@ $FG,2$Prod$FG$ Product, Production
|
||||
$FG,2$Prof$FG$ Profile, Profiler
|
||||
$FG,2$Prs$FG$ Parse, Parser
|
||||
$FG,2$Prt$FG$ Partition
|
||||
$FG,2$PSect$FG$ Program Section
|
||||
$FG,2$FunSeg$FG$ Program Section
|
||||
$FG,2$Pt$FG$ Point
|
||||
$FG,2$Ptr$FG$ Pointer
|
||||
$FG,2$Que$FG$ Queue
|
||||
@@ -124,6 +125,7 @@ $FG,2$Srv$FG$ Servant
|
||||
$FG,2$Stat$FG$ Status, Statistic
|
||||
$FG,2$Std$FG$ Standard
|
||||
$FG,2$Stk$FG$ Stack
|
||||
$FG,2$Stmt$FG$ Statement
|
||||
$FG,2$Str$FG$ String
|
||||
$FG,2$Sym$FG$ Symbol
|
||||
$FG,2$Sync$FG$ Synchronization
|
||||
@@ -142,7 +144,7 @@ $FG,2$Wiz$FG$ Wizard
|
||||
$ID,-2$$TR,"Task/Process/Thread"$
|
||||
$ID,2$There is no distinction between $FG,2$task$FG$, $FG,2$process$FG$ or $FG,2$thread$FG$. The $FG,2$Fs$FG$ segment reg is kept pointing to the current task's $LK,"CTask",A="MN:CTask"$. There is only one window per task, and only $FG,2$core0$FG$ tasks can have windows. Each task has a code and data heap so memory is returned when it dies. Each task has a $LK,"hash",A="HI:Hash"$ symbol table.
|
||||
$ID,-2$$TR,"Adam Task"$
|
||||
$ID,2$This is Adam, as in Adam and Eve, the parent of all tasks and immortal. This task is created at start-up and appears in the small window at the top beneath the user windows. On it's heap are all memory objects which you don't want destroyed by a task's death. When created, Adam runs the file $LK,"::/StartOS.CPP"$. When start-up is finished, the adam task enters a server mode where it accepts requests from other tasks. The $LK,"Adam",A="MN:Adam"$("") routine will make Adam compile and run text src code. $FG,2$#include$FG$ statements can be sent to $LK,"Adam",A="MN:Adam"$(""), creating system-wide code and data which don't disappear when any particular task ends.
|
||||
$ID,2$This is Adam, as in Adam and Eve, the parent of all tasks and immortal. This task is created at start-up and appears in the small window at the top beneath the user windows. On it's heap are all memory objects which you don't want destroyed by a task's death. When created, Adam runs the file $LK,"::/StartOS.CPP"$. When start-up is finished, the adam task enters a server mode where it accepts requests from other tasks. The $LK,"Adam",A="MN:Adam"$("") routine will make Adam compile and run text src code. $FG,2$#include$FG$ stmts can be sent to $LK,"Adam",A="MN:Adam"$(""), creating system-wide code and data which don't disappear when any particular task ends.
|
||||
$ID,-2$$TR,"Seth Task"$
|
||||
$ID,2$$FG,2$Seth$FG$ is Adam and Eve's child. Each CPU core has an executive task called $FG,2$Seth$FG$ that is immortal. The Adam task on $FG,2$CPU#0$FG$ is also it's $FG,2$Seth$FG$ task.
|
||||
$ID,-2$$TR,"Code and Data Heaps"$
|
||||
@@ -156,7 +158,7 @@ $ID,2$$FG,2$Ahead-of-Time$FG$ compiling is conventional compilation mode. Do no
|
||||
|
||||
In $FG,2$AOT$FG$ mode, $FG,2$.PRJ$FG$ files are compiled to $FG,2$.BIN$FG$ files, skipping $FG,2$.OBJ$FG$ files. After compiling, $FG,2$.BIN$FG$ files are $LK,"Load",A="MN:Load"$()ed.
|
||||
|
||||
There is no $FG,2$main()$FG$ routine. Instead, statements outside functions are automatically executed upon loading. There is no way to unload except by killing the task. To invoke $FG,2$AOT Compiled Mode$FG$, $LK,"Cmp",A="MN:Cmp"$() is used. The $FG,2$Kernel$FG$ module and compiler are made in $FG,2$AOT$FG$ compiled mode. See $LK,"MakeOSDrvBootInstall",A="MN:MakeOSDrvBootInstall"$() which calls $LK,"MakeAll",A="MN:MakeAll"$() where $FG,2$Kernel.BIN.C$FG$ and $FG,2$Compiler.BIN.Z$FG$ are created.
|
||||
There is no $FG,2$main()$FG$ routine. Instead, stmts outside functions are automatically executed upon loading. There is no way to unload except by killing the task. To invoke $FG,2$AOT Compiled Mode$FG$, $LK,"Cmp",A="MN:Cmp"$() is used. The $FG,2$Kernel$FG$ module and compiler are made in $FG,2$AOT$FG$ compiled mode. See $LK,"MakeOSDrvBootInstall",A="MN:MakeOSDrvBootInstall"$() which calls $LK,"MakeAll",A="MN:MakeAll"$() where $FG,2$Kernel.BIN.C$FG$ and $FG,2$Compiler.BIN.Z$FG$ are created.
|
||||
$ID,-2$$TR,"JIT Compile Mode"$
|
||||
$ID,2$In $FG,2$just-in-time$FG$ mode, the compiler places code and data in memory alloced from the heap, incrementally, making them immediately ready for in-place execution. This mode is used during cmd line operations. When you $FG,2$#include$FG$ a file, it is compiled function by function and code ends-up all over in the memory, at least in the first 2Gig of memory. The $LK,"ExeFile",A="MN:ExeFile"$() routine is the same as $FG,2$#include$FG$ but can be used in programs. $LK,"ExePrint",A="MN:ExePrint"$() routine will compile and run a string.
|
||||
$ID,-2$$TR,"Compiler Intermediate Code"$
|
||||
|
||||
+3
-3
@@ -64,7 +64,7 @@ $FG,5$$TX+CX,"Programming Guidelines"$$FG$
|
||||
|
||||
* Use $FG,2$I64$FG$ instead of smaller int sizes because the compiler converts everything to 64-bit. Don't use unsigned$FG$ unless it actually breaks. A policy of signed keeps it simple so you don't have to agonize over choices.
|
||||
|
||||
$LM,5$$HL,1$U32 DistDist(U16 x1, U16 y1, U16 x2, U16 y2)
|
||||
$ID,5$$HL,1$U32 DistDist(U16 x1, U16 y1, U16 x2, U16 y2)
|
||||
{//This requires zero-extend when fetching args.
|
||||
return SqrI64(x1-x2)+SqrI64(y1-y2);
|
||||
}
|
||||
@@ -73,7 +73,7 @@ I64 DistDist(I64 x1, I64 y1, I64 x2, I64 y2)
|
||||
{
|
||||
return SqrI64(x1-x2)+SqrI64(y1-y2);
|
||||
}$HL,0$
|
||||
$LM,0$
|
||||
$ID,-5$
|
||||
* In-order, short circuit logic is assumed.
|
||||
|
||||
* Avoid boolean expression assignments. Boolean assignments don't have short circuit logic and are not compiled efficiently. The $FG,2$Bool$FG$ type is just an alias for a 1 byte signed int -- nothing forces it to $FG,2$1$FG$ or $FG,2$0$FG$. There is a $LK,"ToBool",A="MN:ToBool"$() function that will for to $FG,2$1$FG$ ot $FG,2$0$FG$, however.
|
||||
@@ -124,7 +124,7 @@ $FG,2$ PUSH RBP
|
||||
LEAVE
|
||||
RET
|
||||
$FG$
|
||||
* The args are removed from the stack with $FG,2$RET1$FG$ statements.
|
||||
* The args are removed from the stack with $FG,2$RET1$FG$ stmts.
|
||||
|
||||
$FG,2$RET1 16 //remove two args$FG$
|
||||
|
||||
|
||||
Binary file not shown.
Binary file not shown.
+8
-8
@@ -106,11 +106,11 @@ $ID,2$
|
||||
$FG,2$if (13<=age<20)
|
||||
"Teen-ager";
|
||||
$FG$$ID,-2$
|
||||
* $FG,2$switch$FG$ statements always use a jump table. Don't use them with cases with really big, sparse ranges.
|
||||
* $FG,2$switch$FG$ stmts always use a jump table. Don't use them with cases with really big, sparse ranges.
|
||||
|
||||
* Allows ranges like "$FG,2$case 4...7:$FG$" in $FG,2$switch$FG$ statements.
|
||||
* Allows ranges like "$FG,2$case 4...7:$FG$" in $FG,2$switch$FG$ stmts.
|
||||
|
||||
* A no case number causes next higher integer case in $FG,2$switch$FG$ statements. See $LK,"::/Demo/NullCase.CPP"$.
|
||||
* A no case number causes next higher integer case in $FG,2$switch$FG$ stmts. See $LK,"::/Demo/NullCase.CPP"$.
|
||||
|
||||
$ID,2$$FG,2$I64 i;
|
||||
for (i=0;i<20;i++)
|
||||
@@ -123,7 +123,7 @@ for (i=0;i<20;i++)
|
||||
case: "Eleven\n"; break; //One plus previous case.
|
||||
}$FG$$ID,-2$
|
||||
|
||||
* $FG,2$nobound_switch$FG$ can be used if you know a switch statement will not exceed the lowest or highest case values. It's a little faster because it doesn't check.
|
||||
* $FG,2$nobound_switch$FG$ can be used if you know a switch stmt will not exceed the lowest or highest case values. It's a little faster because it doesn't check.
|
||||
|
||||
* $FG,2$sub_switch_start$FG$/$FG,2$sub_switch_end$FG$ allow a new type of nested-switch control flow. (Don't goto, throw exception or return out of $FG,2$sub_switch_start$FG$ front porch area.) See $LK,"::/Demo/SubSwitch.CPP"$.
|
||||
|
||||
@@ -145,7 +145,7 @@ for (i=0;i<10;i++)
|
||||
$BG$OutPut:
|
||||
>$FG,2$Zero [One] Two [Three] Four [Five]$FG$
|
||||
$ID,-2$
|
||||
* A $FG,2$nounusedwarn$FG$ statement will suppress an unused var warning.
|
||||
* A $FG,2$nounusedwarn$FG$ stmt will suppress an unused var warning.
|
||||
|
||||
* You can have multiple member vars of a class named "$FG,2$pad$FG$" or "$FG,2$reserved$FG$", and it won't issue warnings.
|
||||
|
||||
@@ -170,7 +170,7 @@ $ID,2$$FG,2$U0 Main()
|
||||
$FG$$ID,-2$
|
||||
* $FG,2$interrupt$FG$, $FG,2$haserrcode$FG$, $FG,2$public$FG$, $FG,2$argpop$FG$ or $FG,2$noargpop$FG$ are function flags. See $LK,"::/Demo/Lectures/PageTableEntries2.CPP"$.
|
||||
|
||||
* A single quote can encompass multiple characters. $FG,2$'ABC'$FG$ is equal to $FG,2$0x434241$FG$. $LK,"PutChars",A="MN:PutChars"$() takes multiple characters.
|
||||
* A single quote can encompass multiple characters. $FG,2$'ABC'$FG$ is equ to $FG,2$0x434241$FG$. $LK,"PutChars",A="MN:PutChars"$() takes multiple characters.
|
||||
|
||||
$ID,2$$FG,2$asm {
|
||||
HELLO_WORLD::
|
||||
@@ -207,7 +207,7 @@ $FG$$ID,-2$
|
||||
|
||||
* You can use $LK,"Option",A="MN:Option"$($LK,"OPTf_WARN_PAREN",A="MN:OPTf_WARN_PAREN"$,ON) to find unnecessary parentheses in code.
|
||||
|
||||
* You can use $LK,"Option",A="MN:Option"$($LK,"OPTf_WARN_DUP_TYPES",A="MN:OPTf_WARN_DUP_TYPES"$,ON) to find dup local var type statements.
|
||||
* You can use $LK,"Option",A="MN:Option"$($LK,"OPTf_WARN_DUP_TYPES",A="MN:OPTf_WARN_DUP_TYPES"$,ON) to find dup local var type stmts.
|
||||
|
||||
* With the $FG,2$#exe{}$FG$ feature in your src code, you can place programs that insert text into the stream of code being compiled. See $LK,"#exe {}",A="FF:::/Kernel/KEnd.CPP,#exe {"$ for an example where the date/time and compile-time prompting for cfguration data is placed into a program. $LK,"StreamPrint",A="MN:StreamPrint"$() places text into a src program stream following the conclusion of the $FG,2$#exe{}$FG$ blk.
|
||||
|
||||
@@ -231,7 +231,7 @@ $FG$$ID,-2$
|
||||
|
||||
* A function is available similar to $FG,2$sizeof$FG$ which provides the offset of a member of a class. It's called $FG,2$offset$FG$. You place the class name and member inside as in $FG,2$offset(classname.membername)$FG$. It has nothing to do with 16-bit code. Both $FG,2$sizeof$FG$ and $FG,2$offset$FG$ only accept one level of member vars. That is, you can't do $FG,2$sizeof(classname.membername.submembername)$FG$.$FG$
|
||||
|
||||
* There is no $FG,2$continue$FG$ statement. Use $FG,2$goto$FG$.
|
||||
* There is no $FG,2$continue$FG$ stmt. Use $FG,2$goto$FG$.
|
||||
|
||||
* $FG,2$lock{}$FG$ can be used to apply asm $FG,2$LOCK$FG$ prefixes to code for safe multicore read-modify-write accesses. The code bracked with have $FG,2$LOCK$FG$ asm prefix's applied to relevant instructions within. It's a little shoddy. See $LK,"::/Demo/MultiCore/Lock.CPP"$.
|
||||
|
||||
|
||||
+3
-3
@@ -23,7 +23,7 @@ $BK,1$WARNING:$BK,0$ This command erases everything on a hard drive. It repart
|
||||
|
||||
$BK,1$WARNING:$BK,0$ This command doesn't play well with other operating systems. You'll need to do a $LK,"MasterBootZero",A="MN:MasterBootZero"$() to restore your drive to a state where other operating systems can partition it.
|
||||
$ID,-2$
|
||||
$ID,-2$2) $LK,"Fmt",A="MN:Fmt"$($FG,2$'D'$FG$,$FG,2$TRUE,FALSE,DVT_FAT32$FG$)
|
||||
$ID,-2$2) $LK,"Fmt",A="MN:Fmt"$($FG,2$'D'$FG$,$FG,2$TRUE,FALSE,FSt_FAT32$FG$)
|
||||
$ID,2$This command formats a drive with $FG,2$FAT32$FG$ or the $LK,"RedSea",A="FI:::/Doc/RedSea.TXT"$ file system type. Use the drive letter of the partition in place of $FG,2$'D'$FG$.
|
||||
|
||||
$BK,1$WARNING:$BK,0$ If you are upgrading, be sure not to lose the file, $FG,2$/0000Adam/Opt/Boot/OldMBR.BIN.C$FG$.
|
||||
@@ -34,9 +34,9 @@ $ID,2$This command is used to copy files onto a hard drive partition from the CD
|
||||
$ID,-2$4) $LK,"MakeOSDrvBootInstall",A="MN:MakeOSDrvBootInstall"$($FG,2$'D'$FG$)
|
||||
$ID,2$This command recompiles the source code on a drive and writes to the $UL,1$drive's$UL,0$ boot record. You'll need to reenter the $LK,"Mount",A="MN:Mount"$ information so it can be stored in the kernel.
|
||||
|
||||
$ID,-2$5) Use Linux's $LK,"Grub",A="FI:::/Doc/Grub.TXT"$ or TempleOS' $LK,"MasterBootIntall",A="MN:MasterBootIntall"$($FG,2$'D'$FG$)
|
||||
$ID,-2$5) Use Linux's $LK,"Grub",A="FI:::/Doc/Grub.TXT"$ or TempleOS' $LK,"MasterBootInstall",A="MN:MasterBootInstall"$($FG,2$'D'$FG$)
|
||||
$ID,2$
|
||||
The $LK,"MasterBootIntall",A="MN:MasterBootIntall"$() command places a boot loader on a drive. It saves the old master boot record to $FG,2$/0000Adam/Opt/Boot/OldMBR.BIN.C$FG$ and replaces it. When you boot, you will have the option of booting the old master boot record. This command can be skipped if you already have a boot loader. Be sure not to lose the copy of the old boot record, like if you reformat the drive.
|
||||
The $LK,"MasterBootInstall",A="MN:MasterBootInstall"$() command places a boot loader on a drive. It saves the old master boot record to $FG,2$/0000Adam/Opt/Boot/OldMBR.BIN.C$FG$ and replaces it. When you boot, you will have the option of booting the old master boot record. This command can be skipped if you already have a boot loader. Be sure not to lose the copy of the old boot record, like if you reformat the drive.
|
||||
|
||||
Delete $FG,2$/0000Adam/Opt/Boot/OldMBR.BIN.C$FG$ if you want to get a fresh copy of a mbr, like if installing from your own custom CD containing it's own $FG,2$/0000Adam/Opt/Boot/OldMBR.BIN.C$FG$ onto a system with a non-TempleOS boot loader.
|
||||
|
||||
|
||||
@@ -1,68 +0,0 @@
|
||||
$WW,1$$FG,5$$TX+CX,"Mysteries"$$FG$
|
||||
|
||||
* TempleOS runs in $FG,2$VGA 640x480 16 color$FG$ graphics mode, not text mode. It changes to this mode with a $LK,"BIOS call",A="FF:::/Kernel/KStart.CPP,INT 0x10"$ while in real-mode before it switches to 64-bit mode. The text is $LK,"drawn manually",A="MN:GrUpdateTextFG"$. If graphics mode fails, it falls-back on text mode. You can force text mode with an $LK,"Kernel config",A="FI:::/Kernel/KCfg.CPP"$ option.
|
||||
|
||||
* TempleOS identity-maps all memory, all the time. There is no $FG,2$high half$FG$ memory space. TempleOS is ring-0-only, so everything is kernel, even user programs. There is a special task called $FG,2$Adam$FG$ and he doesn't die, so his heap never gets freed. That's as close to $FG,2$kernel memory$FG$ as it gets.
|
||||
|
||||
* TempleOS puts all code in the lowest 2 Gig, so that $FG,2$REL32$FG$ addressing can be used. TempleOS is 64-bit, but I just thought $FG,2$2 Gig$FG$ was enough for code. It actually puts global variables there, too, but you can turn that off with $LK,"OPTf_GLBLS_ON_DATA_HEAP",A="MN:OPTf_GLBLS_ON_DATA_HEAP"$. $LK,"MAlloc",A="MN:MAlloc"$() can alloc any memory, of course.
|
||||
|
||||
* TempleOS doesn't use software interrupts or $FG,2$SYSCALL$FG$ instructions because it never needs to change out of ring-0, even running user programs. Calls are always $FG,2$CALL REL32$FG$ instructions.
|
||||
|
||||
* The stack does not grow. In theory, memory gets fragmented, too.
|
||||
|
||||
* There is no $FG,2$PATH$FG$. You do not enter filenames at the command-line and expect them to run. You enter C-like code. $LK,"Get Started Here",A="FI:::/Doc/CmdLineOverview.TXT"$.
|
||||
|
||||
* If you use $LK,"Grub",A="FI:::/Doc/Grub.TXT"$, you $FG,2$chain-load$FG$ like Windows. You can use the TempleOS boot-loader. $LK,"Master-Boot-Loader-Stage1",A="FI:::/Adam/Opt/Boot/BootMHD.CPP"$, $LK,"Master-Boot-Loader-Stage2",A="FI:::/Adam/Opt/Boot/BootMHD2.CPP"$, $LK,"Partition-Boot-Loader",A="FI:::/Adam/Opt/Boot/BootHD.CPP"$, $LK,"CD-DVD-Boot-Loader",A="FI:::/Adam/Opt/Boot/BootDVD.CPP"$.
|
||||
|
||||
* The boot-loaders must be patched by you running $LK,"MakeOSDrvBootInstall",A="MN:MakeOSDrvBootInstall"$() or $LK,"MasterBootIntall",A="MN:MasterBootIntall"$(). Those will write the block address into the boot-loader because the boot-loaders do not navigate file systems to find the $LK,"Stage2",A="FI:::/Kernel/KStart.CPP"$ if you relocate it.
|
||||
|
||||
* TempleOS is 64-bit. Like all PC operating systems, the boot-loader starts in 16-bit real-mode. TempleOS calls a few $FG,2$BIOS$FG$ info routines, switches to VGA-640x480x4bit, switches to 32-bit, then, 64-bit mode. There is an odd thing called a $FG,2$$TX,"PCI BIOS",HTML="http://www.o3one.org/hwdocs/bios_doc/pci_bios_21.pdf"$$FG$ which is 32-bit used for $FG,2$PCI$FG$ config space access. TempleOS calls $LK,"that",A="FI:::/Kernel/PCIBIOS.CPP"$ a couple times. It must temporarily drop-out-of 64-bit mode for that and stop multi-tasking.
|
||||
|
||||
* $FG,2$PUSH EAX$FG$ : All stack operations in 64-bit mode are 64-bits.
|
||||
|
||||
* $FG,2$XOR EAX,EAX$FG$ : Operations on 32-bit regs clear the high 32-bits.
|
||||
|
||||
* $FG,2$MOV RAX,FS:[RAX]$FG$ : FS can be set with a $FG,2$WRMSR$FG$, but displacement is RIP relative, so it's tricky to use. FS is used for the current $LK,"CTask",A="MN:CTask"$, GS for $LK,"CCPU",A="MN:CCPU"$.
|
||||
|
||||
* TempleOS uses $FG,2$JIT$FG$ file compression on a file-by-file basis. Files are $LK,"compressed",A="FI:::/Kernel/Compress.CPP"$, not encrypted.
|
||||
|
||||
* TempleOS has a dictionary that is shipped compressed. When you boot the first time it is uncompressed. TempleOS has a Windows utility for uncompressing. That utility needs $FG,2$Microsoft DLL$FG$ files. TempleOS does not use any libraries, modules or code from other sources -- I wrote it all from scratch and it is self-contained.
|
||||
|
||||
* There are no OBJ or EXE files. There are only two files compiled ahead-of-time -- $FG,2$Kernel.BIN.C$FG$ and $FG,2$Compiler.BIN.Z$FG$. You can delete them and recompile with $LK,"MakeOSDrvBootInstall",A="MN:MakeOSDrvBootInstall"$(). TempleOS is $TX,"119,216",D="DD_TEMPLEOS_LOC"$ lines. Roughly 50,000 is compiled AOT and 50,000 during boot $FG,2$JIT$FG$. The rest is $FG,2$JIT$FG$ demos and applications.
|
||||
|
||||
* A major difference between TempleOS and other systems is that the heap and compiler sym table are associated with tasks, not applications.
|
||||
|
||||
* There are sym(hash) tables maintained by each task. They are similar in scope to environment variables. When a symbol is not found, the parent task's symbol table is checked. All process chain back to the $FG,2$Adam$FG$ process. $FG,2$Adam$FG$ has the symbols from headers you normally $FG,2$#include$FG$ in other operating systems, so you do not need to $FG,2$#include$FG$ any headers in TempleOS.
|
||||
|
||||
* The compiler only creates $FG,2$pos independent$FG$ code. You can't create code which is loaded at a fixed, specified location. The code is pos independent by virtue of the fact that abs addresses get patched.
|
||||
|
||||
* Binary executable files have export syms which are loaded into the sym tables. The operating system $FG,2$Kernel$FG$ has such an export table. In addition, some map files are processed to provide more information on syms -- src file links. This is how the $LK,"Man",A="MN:Man"$()/$FG,2$AUTOCOMPLETE$FG$ feature can find src lines.
|
||||
|
||||
* $FG,2$#assert$FG$ might print a message at COMPILE time, not run time.
|
||||
|
||||
* The word $FG,2$public$FG$ does very little except allow the $LK,"Help & Index",A="FI:::/Doc/HelpIndex.TXT"$ and $LK,"Who",A="MN:Who"$() to exclude meaningless syms. If you wish a full report of public and nonpublic syms $MA-X+PU,"Click Here",LM="DocMax(1000000);Who;View;\n"$.
|
||||
|
||||
* When compilation takes place, the structures used by the compiler stick around. Data on classes can be accessed by code. See $LK,"ClassRep",A="MN:ClassRep"$().
|
||||
|
||||
* Filenames ending in $FG,2$.Z$FG$ are automatically compressed and uncompressed when writing to disk. File size in directory listing is the compressed size. See $LK,"::/Doc/TOSZ.TXT"$ for uncompressing from $FG,2$Linux$FG$.
|
||||
|
||||
* Some memory objects are alloced when needed and will decrease the available memory displayed. A task keeps mem objects smaller than a couple blocks in it's own separate heap when freed and these are not counted in the available system free memory, though they are free. They get returned to the system when the task is killed. To get a sense of this, compile the operating system and see the amount of mem used. Then, compile it again and far less will be alloced. This is because it is reusing the small chunks. See $LK,"Memory Overview",A="FI:::/Doc/MemOverview.TXT"$ and $LK,"Memory Routines",A="HI:Memory"$. $MA-X+PU,"Click Here",LM="MemRep;View;"$ for a $LK,"MemRep",A="MN:MemRep"$.
|
||||
|
||||
* The cursor location is stored as an $FG,2$ASCII 5$FG$ in files. $FG,2$ASCII 31$FG$ is $FG,2$SHIFT-SPACE$FG$, a character which does not get converted to tabs by space-to-tabs, $LK,"S2T",A="MN:S2T"$(). The $FG,2$ASCII 28$FG$ is $FG,2$SHIFT-ESC$FG$.
|
||||
|
||||
* Binary data is stored beyond the terminating $FG,2$NULL$FG$ in text files. Map files store debug src lines and other files store sprites.
|
||||
|
||||
* Sprites can be stored as vector graphics so they might take shockingly little room. They can be converted to bitmaps.
|
||||
|
||||
* If you change code in the $FG,2$/Adam$FG$ or your $FG,2$/Home$FG$ directory, you don't need to recompile, you just need to reboot because those directories get recompiled when you boot. It uses JIT compilation. There is no $FG,2$.BIN$FG$ file for $FG,2$JIT$FG$ compilation.
|
||||
|
||||
* If not found, $FG,2$.Z$FG$ is added or removed and a search is done again. If a file is still not found, the parent directories are searched for a file of the same name.
|
||||
|
||||
* TempleOS supports $FG,2$FAT32$FG$ and $LK,"RedSea",A="FI:::/Doc/RedSea.TXT"$ file systems. The $LK,"RedSea",A="FI:::/Doc/RedSea.TXT"$ partitions will appear as $FG,2$FAT32$FG$ to other operating systems, but will not work. Do not access the native TempleOS partitions from other operating systems. This was to fool a bootloader when I tricked it to use it's recovery partition feature.
|
||||
|
||||
* The CPU usage during disk operation expands to 99%. It polls while swapping-out. You can do other, non-disk activity during disk operations because it swaps-out a lot and task swaps take only half a microsecond, probably a hundred times faster than a typical OS. It does not break-up disk operations into small pieces for sharing, however, so the disk is lock onto that one task.
|
||||
|
||||
$FG,8$
|
||||
* "Windows" is a trademark of MicroSoft Corp.
|
||||
* "Linux" is probably a trademark owned by Linus Torvalds.
|
||||
$FG$
|
||||
+1
-1
@@ -10,7 +10,7 @@ $LK,"OPTf_WARN_UNUSED_VAR",A="MN:OPTf_WARN_UNUSED_VAR"$ warning if unused var.
|
||||
|
||||
$LK,"OPTf_WARN_PAREN",A="MN:OPTf_WARN_PAREN"$ warning if parenthesis are not needed.
|
||||
|
||||
$LK,"OPTf_WARN_DUP_TYPES",A="MN:OPTf_WARN_DUP_TYPES"$ warning if dup local var type statements.
|
||||
$LK,"OPTf_WARN_DUP_TYPES",A="MN:OPTf_WARN_DUP_TYPES"$ warning if dup local var type stmts.
|
||||
|
||||
$LK,"OPTf_NO_REG_VAR",A="MN:OPTf_NO_REG_VAR"$ forces all function local vars to the stk not regs. Applied to functions.
|
||||
|
||||
|
||||
+3
-1
@@ -29,7 +29,9 @@ $FG,2$"%h25c",'\n';$FG$ 25 new-lines.
|
||||
|
||||
$FG,2$"%h*c",25,'\n';$FG$ 25 new-lines.
|
||||
|
||||
$FG,2$"%F"$FG$ text file.
|
||||
$FG,2$"%F"$FG$ text file by filename.
|
||||
|
||||
$FG,2$"%$$F"$FG$ $LK,"DolDoc",A="FI:::/Doc/DolDocOverview.TXT"$ file in memory.
|
||||
|
||||
$FG,2$"%p"$FG$ ptr.
|
||||
|
||||
|
||||
+2
-2
@@ -20,7 +20,7 @@ A) $LK,"DocBottom",A="MN:DocBottom"$() followed by $LK,"DocClear",A="MN:DocClear
|
||||
|
||||
B) Disable window mgr button click checking with $FG,4$Fs->win_inhibit$FG$ set to mask $LK,"WIF_SELF_IP_L",A="MN:WIF_SELF_IP_L"$|$LK,"WIF_FOCUS_TASK_IP_L_D",A="MN:WIF_FOCUS_TASK_IP_L_D"$|$LK,"WIF_SELF_IP_R",A="MN:WIF_SELF_IP_R"$|$LK,"WIF_FOCUS_TASK_IP_R_D",A="MN:WIF_FOCUS_TASK_IP_R_D"$. This inhibits window mgr operations but still generates messages from button clicks.
|
||||
$ID,-2$
|
||||
* $FG,2$switch/case$FG$ statements alloc a single jump table--do not use with wide, sparse ranges of case values.
|
||||
* $FG,2$switch/case$FG$ stmts alloc a single jump table--do not use with wide, sparse ranges of case values.
|
||||
|
||||
* Don't do a $FG,2$goto$FG$ out of a $FG,2$try{}$FG$.
|
||||
|
||||
@@ -32,7 +32,7 @@ $ID,-2$
|
||||
|
||||
* The assembler's error msgs are often off by a line and undefines are cryptic.
|
||||
|
||||
* The last semicolon on the cmd line is converted to a dbl semicolon because the compiler looks ahead before doing a cmd. This normally has no negative effect, but when entering $FG,2$if$FG$ statements with $FG,2$else$FG$ clauses it presents problems.
|
||||
* The last semicolon on the cmd line is converted to a dbl semicolon because the compiler looks ahead before doing a cmd. This normally has no negative effect, but when entering $FG,2$if$FG$ stmts with $FG,2$else$FG$ clauses it presents problems.
|
||||
|
||||
* You can do a $FG,2$class$FG$ fwd reference by using $FG,2$extern$FG$ on the first declaration, but you can only do ptr references to the $FG,2$class$FG$.
|
||||
|
||||
|
||||
+2
-2
@@ -1,5 +1,5 @@
|
||||
$WW,1$$FG,5$$TX+CX,"Graphic Sprite Resource Help"$$FG$
|
||||
|
||||
A sprite is an ordered list of elements such as lines, rectangles, bitmaps and color changes. In a program's source code, you first make a sprite. Then, you insert a pointer to it.
|
||||
A sprite is an ordered list of elements such as lines, rectangles, bitmaps and color changes. In a program's source code, you first $FG,2$make a sprite$FG$ somewhere outside a function. Then, you $FG,2$insert a pointer$FG$ to the sprite as an "*elems" arg when calling $LK,"Sprite",A="MN:Sprite"$() or $LK,"Sprite3",A="MN:Sprite3"$(). See $LK,"Sprites",A="HI:Sprites"$.
|
||||
|
||||
You can create an icon on your PersonalMenu or in any document by placing a sprite with a payload of $LK,"HolyC",A="FI:::/Doc/HolyC.TXT"$ code to execute. This is a called "sprite macro". If you check "Pop-Up", it will spawn a new task and run the payload. If you have it on your PersonalMenu, you can, optionally, check "Esc" and it will exit to the cmd line shell and print the macro similar to how the Linux history works.
|
||||
You can create a $FG,2$sprite macro$FG$ on your $LK,"PersonalMenu",A="FI:::/Home/PersonalMenu.TXT"$ with a payload of $LK,"HolyC",A="FI:::/Doc/HolyC.TXT"$ source code to execute when it ESC's back to the cmd line. If you check "Pop-Up", it will spawn a new task and run the payload. A pop-up macro can be placed in any document.
|
||||
+1
-1
@@ -22,7 +22,7 @@ A three button mouse is like a leg you cannot put weight on. TempleOS just does
|
||||
|
||||
* Everything runs in kernel, $FG,2$ring 0$FG$, mode.
|
||||
|
||||
* $FG,2$One memory map$FG$ for all tasks on all cores with virtual addresses set equal to physical, just as though paging is not used.
|
||||
* $FG,2$One memory map$FG$ for all tasks on all cores with virtual addresses set equ to physical, just as though paging is not used.
|
||||
|
||||
* One platform -- $FG,4$$TX,"x86_64",HTML="http://en.wikipedia.org/wiki/Amd64#AMD64"$$FG$ PC's, no 32-bit support.
|
||||
|
||||
|
||||
+3
-5
@@ -35,7 +35,7 @@ $FG,2$Merge(\"C:/*\",\"D:/*\",\"+r+d\");$FG$ to check my changes.
|
||||
|
||||
* You can permanently disable $FG,2$AutoComplete$FG$ commenting-out $LK,"ACInit",A="FF:/Home/HomeSys.CPP,ACInit"$() in $LK,"::/Home/HomeSys.CPP",A="FF:/Home/HomeSys.CPP,ACInit"$.
|
||||
|
||||
* Boolean expressions $BK,1$not$BK,0$ in $FG,2$if$FG$ statements don't have short circuit logic and are compiled inefficiently.
|
||||
* Boolean expressions $BK,1$not$BK,0$ in $FG,2$if$FG$ stmts don't have short circuit logic and are compiled inefficiently.
|
||||
|
||||
* You can use $LK,"progress1",A="MN:progress1"$-$LK,"progress4",A="MN:progress4"$ in your programs for whatever you like. They're just global vars that are shown on the wallpaper. The original intent was to indicate how far along operations were. There's no coordination, so different apps might interfere. I use them most for debugging--just values easily viewed. See $LK,"::/Demo/Progress.CPP"$.
|
||||
|
||||
@@ -53,7 +53,7 @@ $FG,2$Merge(\"C:/*\",\"D:/*\",\"+r+d\");$FG$ to check my changes.
|
||||
|
||||
* You can use $LK,"Option",A="MN:Option"$($LK,"OPTf_WARN_PAREN",A="MN:OPTf_WARN_PAREN"$,ON) to find unnecessary parentheses in code.
|
||||
|
||||
* You can use $LK,"Option",A="MN:Option"$($LK,"OPTf_WARN_DUP_TYPES",A="MN:OPTf_WARN_DUP_TYPES"$,ON) to find unnecessary local var type statements.
|
||||
* You can use $LK,"Option",A="MN:Option"$($LK,"OPTf_WARN_DUP_TYPES",A="MN:OPTf_WARN_DUP_TYPES"$,ON) to find unnecessary local var type stmts.
|
||||
|
||||
* $LK,"Option",A="MN:Option"$($LK,"OPTf_ECHO",A="MN:OPTf_ECHO"$,ON) can be placed in $LK,"StartOS.CPP",A="FI:::/StartOS.CPP"$ to echo start-up scripts.
|
||||
|
||||
@@ -93,8 +93,6 @@ $FG,2$Merge(\"C:/*\",\"D:/*\",\"+r+d\");$FG$ to check my changes.
|
||||
|
||||
* You can reactivate $FG,2$AutoComplete$FG$ after closing it by pressing $FG,2$<CTRL-Fun Key>$FG$ or $FG,2$<ALT-w>$FG$ if you have it defined.
|
||||
|
||||
* You can set a color for different drives with $LK,"DrvTextAttrSet",A="MN:DrvTextAttrSet"$(). Place calls to this in $LK,"::/Home/HomeLocalize.CPP"$.
|
||||
|
||||
* $FG,2$<CTRL-SHIFT-T>$FG$ to toggle to/from plain text just the $LK,"CDoc",A="MN:CDoc"$ cmd under the cursor. See $LK,"::/Demo/DolDoc/TextDemo.CPP"$.
|
||||
|
||||
* If you toggle to plain text when you are working with graphics in a document, you can add duplicate entries for sprites by entering a $FG,2$$$SP...$$$FG$ cmd with the same num.
|
||||
@@ -127,7 +125,7 @@ $FG,2$Merge(\"C:/*\",\"D:/*\",\"+r+d\");$FG$ to check my changes.
|
||||
|
||||
* $LK,"cnts.time_stamp_freq",A="MN:CCntsGlbls"$ is continuously calibrated. Be careful because expressions might decrease. Take a snap-shot, like this: $FG,2$timeout=$LK,"GetTSC",A="MN:GetTSC"$+$LK,"cnts.time_stamp_freq",A="MN:CCntsGlbls"$ x seconds;$FG$ and compare against $LK,"GetTSC",A="MN:GetTSC"$(). I recommend just using $LK,"tS",A="MN:tS"$ or $LK,"cnts.jiffies",A="MN:CCntsGlbls"$.
|
||||
|
||||
* Use $LK,"HeapLog",A="MN:HeapLog"$() and $LK,"HeapLogRep",A="MN:HeapLogRep"$() to find leaks. Don't be confused by $LK,"CDoc",A="MN:CDoc"$ allocations. Those are generated when text is written to the cmd line buffer.
|
||||
* Use $LK,"HeapLog",A="MN:HeapLog"$(), $LK,"HeapLogAddrRep",A="MN:HeapLogAddrRep"$() and $LK,"HeapLogSizeRep",A="MN:HeapLogSizeRep"$() to find leaks. Don't be confused by $LK,"CDoc",A="MN:CDoc"$ allocations. Those are generated when text is written to the cmd line buffer.
|
||||
|
||||
* For advanced heap debugging, play with $LK,"_CFG_HEAP_DBG",A="MN:_CFG_HEAP_DBG"$. You're on your own.
|
||||
|
||||
|
||||
+1
-1
@@ -19,7 +19,7 @@ In other operating systems, I hated learning one language for command line scrip
|
||||
|
||||
During the boot process, many files get $LK,"compiled",A="FI:::/StartOS.CPP"$ before you have access to the command line. (Don't worry, booting takes only a couple of seconds.) All the header declarations for the operating system are compiled and are available for use in your programs without needing to $FG,2$#include $FG$them. Everything is truly compiled to native $FG,2$$TX,"x86_64",HTML="http://en.wikipedia.org/wiki/Amd64#AMD64"$$FG$ machine code, nothing is $FG,2$interpreted$FG$ and there is no $FG,2$byte code$FG$.
|
||||
|
||||
Statements at the global scope -- outside the scope of functions -- execute immediately. There is no $FG,2$main()$FG$ function. Instead, you give meaningful names to what would be $FG,2$main()$FG$ functions and you invoke them by calling them with a statement in the global scope, usually at the bottom of your file.
|
||||
Stmts at the global scope -- outside the scope of functions -- execute immediately. There is no $FG,2$main()$FG$ function. Instead, you give meaningful names to what would be $FG,2$main()$FG$ functions and you invoke them by calling them with a stmt in the global scope, usually at the bottom of your file.
|
||||
|
||||
I started with $FG,2$C$FG$ syntax, but didn't like the command line for a directory listing looking like this:
|
||||
|
||||
|
||||
Reference in new issue
Block a user