TempleOSCDV4.12.ISO
This commit is contained in:
Terry A. Davis authored and minexew committed
1 parent
93ca216483
commit
b84bbff6db
381 files changed
+18356
-18798
No files matched your search
+1
-1
@@ -1,4 +1,4 @@
|
||||
$FG,2$$WW,1$AutoComplete$FG$ is the $FG,7$LTGRAY$FG$ window on the right of the screen. $LK,"ACInit",A="MN:ACInit"$() collects words from all text files in subdirectories. Normally, the call to $LK,"ACInit",A="MN:ACInit"$() is in $LK,"HomeSys.HC",A="FF:~/HomeSys.HC,ACInit"$. It provides auto-complete for typing, jump-to-code and jump-to-dictionary functionality.
|
||||
$FG,2$$WW,1$AutoComplete$FG$ is the $FG,7$LTGRAY$FG$ window on the right of the scrn. $LK,"ACInit",A="MN:ACInit"$() collects words from all text files in subdirectories. Normally, the call to $LK,"ACInit",A="MN:ACInit"$() is in $LK,"HomeSys.HC",A="FF:~/HomeSys.HC,ACInit"$. It provides auto-complete for typing, jump-to-code and jump-to-dictionary functionality.
|
||||
|
||||
$FG,2$<ALT-SHIFT-A>$FG$ Closes the $FG,7$LTGRAY$FG$ AutoComplete window.
|
||||
$FG,2$<ALT-a>$FG$ Opens the $FG,7$LTGRAY$FG$ AutoComplete window.
|
||||
|
||||
@@ -1,7 +0,0 @@
|
||||
$WW,1$$FG,2$AutoFiles$FG$ are used to generate user input to automate operations. The TempleOS tour is done with an $FG,2$AutoFile$FG$. It reminds me of a Unix pipe because $FG,2$StdOut$FG$ of one gets chained into $FG,2$StdIn$FG$ of another.
|
||||
|
||||
When an $FG,2$AutoFile$FG$ runs, a child task is $LK,"Spawn",A="MN:Spawn"$()ed which intercepts real user input and generates fake input. AutoFiles are $LK,"HolyC",A="FI:::/Doc/HolyC.DD"$ programs run by the child whose stdout goes to the parent's input buffer. $LK,"Msg",A="MN:Msg"$() can be included in an $FG,2$AutoFile$FG$ to send special keys or mouse cmds to the parent. While an $FG,2$AutoFile$FG$ is running, the normal input gets diverted to the AutoFile task and can be filtered and sent back to the parent task. Unless you are driving functions which prompt for data, you can probably use an $FG,2$#include$FG$ file in place of an $FG,2$AutoFile$FG$.
|
||||
|
||||
See $LK,"::/Demo/AutoFile/AFDir.AUT"$.
|
||||
|
||||
Note: $LK,"Auto",A="MN:Auto"$("") can be used if all you need is to send ASCII characters. It differs from $LK,"AutoStr",A="MN:AutoStr"$(). You'll probably use $LK,"Auto",A="MN:Auto"$() a lot and not $LK,"AutoStr",A="MN:AutoStr"$(). With $LK,"Auto",A="MN:Auto"$(), for example, you can place answers to the prompts for recompiling the $FG,2$Kernel$FG$ module during $LK,"BootHDIns",A="MN:BootHDIns"$().
|
||||
BIN
Binary file not shown.
+53
-5
@@ -2,7 +2,55 @@ $WW,1$$FG,5$$TX+CX,"Change Log"$$FG$
|
||||
|
||||
Use $LK,"R",A="MN:R"$() to rename if I change a label.
|
||||
|
||||
$IV,1$----09/18/16 17:15:54----$IV,0$
|
||||
$IV,1$----09/29/16 11:52:04----$IV,0$
|
||||
|
||||
$IV,1$----09/29/16 10:13:14----$IV,0$
|
||||
* $BK,1$TempleOS version 4.12 Released$BK,0$
|
||||
* Added $LK,"TASKf_CMD_LINE_PMT",A="MN:TASKf_CMD_LINE_PMT"$.
|
||||
* Improved $LK,"TaskWait",A="MN:TaskWait"$().
|
||||
* Improved $LK,"DeathWait",A="MN:DeathWait"$().
|
||||
|
||||
$IV,1$----09/27/16 12:40:21----$IV,0$
|
||||
* Added $LK,"SndRst",A="MN:SndRst"$().
|
||||
* Got rid of crappy reverb in $LK,"::/Apps/Psalmody/PsalmodyMain.HC"$.
|
||||
|
||||
$IV,1$----09/27/16 11:09:25----$IV,0$
|
||||
* Improved $LK,"::/Misc/OSTestSuite.HC"$.
|
||||
* Fixed bug in $LK,"EdCharIns",A="MN:EdCharIns"$() printing $$ cmds.
|
||||
* Added $LK,"FUF_JUST_DD",A="MN:FUF_JUST_DD"$ and $LK,"FILEMASK_DD",A="MN:FILEMASK_DD"$.
|
||||
|
||||
$IV,1$----09/27/16 01:05:52----$IV,0$
|
||||
* Improved $LK,"::/Doc/MemOverview.DD"$.
|
||||
* Got rid of $FG,4$::/Demo/Lectures/Mem$FG$.
|
||||
* Made filename paths relative to document location in DolDoc links.
|
||||
* $LK,"R",A="MN:R"$("Temp","Tmp");
|
||||
|
||||
$IV,1$----09/26/16 00:44:42----$IV,0$
|
||||
* Added CloseAssault and OverRun to $LK,"::/Apps/ToTheFront/ToTheFront.HC"$.
|
||||
|
||||
$IV,1$----09/22/16 07:53:20----$IV,0$
|
||||
* Improved $LK,"::/Demo/Graphics/Box.HC"$.
|
||||
* Improved $LK,"::/Demo/Graphics/SpritePlot3D.HC"$.
|
||||
|
||||
$IV,1$----09/21/16 17:09:40----$IV,0$
|
||||
* Fixed bug in $LK,"::/Demo/Games/BomberGolf.HC"$.
|
||||
|
||||
$IV,1$----09/20/16 15:57:30----$IV,0$
|
||||
* $LK,"R",A="MN:R"$("Screen","Scrn");
|
||||
* $LK,"R",A="MN:R"$("WinMgrSync","$LK,"Refresh",A="MN:Refresh"$");
|
||||
* $LK,"R",A="MN:R"$("InDbg","$LK,"DbgMode",A="MN:DbgMode"$");
|
||||
* Improved $LK,"::/Doc/Boot.DD"$.
|
||||
|
||||
$IV,1$----09/20/16 07:31:52----$IV,0$
|
||||
* $LK,"R",A="MN:R"$("DAT","DATA");
|
||||
* $LK,"R",A="MN:R"$("Auto","In");
|
||||
* $LK,"R",A="MN:R"$("AutoStr","InStr");
|
||||
* $LK,"R",A="MN:R"$("AutoFile","InFile");
|
||||
* $LK,"R",A="MN:R"$("AUT","IN");
|
||||
* $LK,"R",A="MN:R"$("GRA","GR");
|
||||
|
||||
$IV,1$----09/18/16 20:40:44----$IV,0$
|
||||
* Added $LK,"::/Doc/WhyNotMore.DD"$.
|
||||
|
||||
$IV,1$----09/18/16 12:52:03----$IV,0$
|
||||
* $BK,1$TempleOS version 4.11 Released$BK,0$
|
||||
@@ -146,7 +194,7 @@ $IV,1$----05/07/16 08:55:59----$IV,0$
|
||||
* $BK,1$TempleOS version 4.06 Released$BK,0$
|
||||
|
||||
$IV,1$----05/03/16 19:26:45----$IV,0$
|
||||
* Made $LK,"FunSegFind",A="MN:FunSegFind"$() search all hash tables when $LK,"IsDbg",A="MN:IsDbg"$.
|
||||
* Made $LK,"FunSegFind",A="MN:FunSegFind"$() search all hash tables when $LK,"IsDbgMode",A="MN:IsDbgMode"$.
|
||||
* Added missiles to $LK,"::/Apps/X-Caliber/X-Caliber.HC"$.
|
||||
* Fixed bug in $LK,"D3Unit",A="MN:D3Unit"$().
|
||||
|
||||
@@ -216,7 +264,7 @@ $IV,1$----03/19/16 09:15:11----$IV,0$
|
||||
$IV,1$----03/19/16 06:22:36----$IV,0$
|
||||
* Fixed $LK,"UAsm",A="MN:Ui"$() bug.
|
||||
* Got rids of $FG,4$ICF_A1_FIRST$FG$.
|
||||
* Cleaned-up compiler $LK,"REGG_CLOBBERED",A="MN:REGG_CLOBBERED"$ and $LK,"REGG_STK_TEMP",A="MN:REGG_STK_TEMP"$.
|
||||
* Cleaned-up compiler $LK,"REGG_CLOBBERED",A="MN:REGG_CLOBBERED"$ and $LK,"REGG_STK_TMP",A="MN:REGG_STK_TMP"$.
|
||||
|
||||
$IV,1$----03/18/16 09:53:33----$IV,0$
|
||||
* Made $LK,"SpriteEd",A="MN:SpriteEd"$() sel foreground elem.
|
||||
@@ -258,7 +306,7 @@ $IV,1$----02/01/16 21:01:15----$IV,0$
|
||||
* Made multicore more professional.
|
||||
|
||||
$IV,1$----02/01/16 06:02:41----$IV,0$
|
||||
* Moved $LK,"Mem2Meg.HC",A="FI:::/Demo/Lectures/Mem/Mem2Meg.HC"$ out of kernel.
|
||||
* Moved Sup1CodeScraps/Mem/Mem2Meg.HC out of kernel.
|
||||
|
||||
$IV,1$----01/31/16 04:07:50----$IV,0$
|
||||
* Fixed scheduler, so doesn't idle so high.
|
||||
@@ -325,7 +373,7 @@ $IV,1$----01/12/16 19:17:12----$IV,0$
|
||||
|
||||
$IV,1$----01/12/16 10:06:18----$IV,0$
|
||||
* $BK,1$TempleOS version 4.01 Released$BK,0$
|
||||
* Standardized drive letters. Your $LK,"Auto",A="MN:Auto"$() config scripts for compiling the kernel with $LK,"BootHDIns",A="MN:BootHDIns"$() must be changed.
|
||||
* Standardized drive letters. Your $LK,"In",A="MN:In"$() config scripts for compiling the kernel with $LK,"BootHDIns",A="MN:BootHDIns"$() must be changed.
|
||||
* Added $LK,"CCF_QUESTION_HELP",A="MN:CCF_QUESTION_HELP"$.
|
||||
|
||||
$IV,1$----01/11/16 00:04:38----$IV,0$
|
||||
|
||||
+1
-1
@@ -8,7 +8,7 @@ ASCII #5 is the cursor location in a saved file.
|
||||
ASCII #28 is $FG,2$<SHIFT-ESC>$FG$.
|
||||
ASCII #31 is a $FG,2$<SHIFT-SPACE>$FG$.
|
||||
|
||||
TempleOS ASCII is 8-bit instead of 7-bit, so it also uses the range from 128-255. Press $FG,2$<CTRL-ALT-a>$FG$ to see shapes for 128-255. Technically, $FG,2$<CTRL-ALT-a>$FG$ are $LK,"screen codes",A="HI:TextBase Layer"$.
|
||||
TempleOS ASCII is 8-bit instead of 7-bit, so it also uses the range from 128-255. Press $FG,2$<CTRL-ALT-a>$FG$ to see shapes for 128-255. Technically, $FG,2$<CTRL-ALT-a>$FG$ are $LK,"scrn codes",A="HI:TextBase Layer"$.
|
||||
|
||||
A $FG,2$Key$FG$ is typically specified with a scan code. TempleOS scan codes contain the key value in the lowest $FG,2$U8$FG$, and flags in the upper 3 bytes. See $LK,"Scan Code Flags",A="MN:SCF_CTRL"$ and $LK,"Scan Codes",A="MN:SC_INS"$.
|
||||
|
||||
|
||||
+3
-3
@@ -31,7 +31,7 @@ $ID,-5$
|
||||
|
||||
* 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,"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.
|
||||
* 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,223",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.
|
||||
|
||||
@@ -55,14 +55,14 @@ $ID,-5$
|
||||
|
||||
* $FG,2$100% open source$FG$ with all source included.
|
||||
|
||||
* Documents are not for printing. They're dynamic, intended for the screen.
|
||||
* Documents are not for printing. They're dynamic, intended for the scrn.
|
||||
|
||||
* Just one 8x8 fixed-width font. $FG,4$No Unicode, just Extended ASCII$FG$. Other countries can make their own versions. The versions should be just for one language and platform.
|
||||
|
||||
* $FG,4$No multimedia$FG$. Sounds and images will be primarily calculated in real-time, not fetched from storage.
|
||||
|
||||
$FG,8$
|
||||
* "Commodore 64" was a trademark owned by Commodore Business Machines.
|
||||
* "Commodore 64" is a trademark owned by Polabe Holding NV.
|
||||
* "The Simpsons" is a trademark owned by Fox.
|
||||
* "Windows" is a trademark owned by MicroSoft Corp.
|
||||
$FG$
|
||||
|
||||
@@ -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.DD"$ compiler as you type. A stmt outside a function executes immediately. Remember to add a semicolon.$WW,1$
|
||||
The cmd line feeds into the $LK,"HolyC",A="FI:::/Doc/HolyC.DD"$ compiler line-by-line 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.
|
||||
|
||||
@@ -24,7 +24,7 @@ Drives are specified with a letter. The boot drive is specified with a '$FG,2$:
|
||||
|
||||
The drive can be specified in a $LK,"Cd",A="MN:Cd"$() command as in:
|
||||
|
||||
>$FG,2$Cd("B:/Temp");$FG$ B drive
|
||||
>$FG,2$Cd("B:/Tmp");$FG$ B drive
|
||||
>$FG,2$Cd("::/Demo");$FG$ Boot drive
|
||||
|
||||
The home directory is specified with a $FG,2$'~'$FG$.
|
||||
@@ -39,4 +39,4 @@ You can place macros in your $LK,"PersonalMenu",A="FI:~/PersonalMenu.DD"$ for $L
|
||||
|
||||
$LK,"Cmd Line Routines",A="HI:Cmd Line (Typically)"$
|
||||
|
||||
$MA-X+PU,"Take Tour",LM="User(\"Cd(\\\"::/Misc/Tour\\\");;AutoFile(\\\"Tour\\\");\n\");"$
|
||||
$MA-X+PU,"Take Tour",LM="User(\"Cd(\\\"::/Misc/Tour\\\");;InFile(\\\"Tour\\\");\n\");"$
|
||||
+1
-1
@@ -1,6 +1,6 @@
|
||||
$WW,1$$FG,5$$TX+CX,"Credits"$$FG$
|
||||
|
||||
I, $FG,2$Terry A. Davis$FG$, wrote all $TX,"120,264",D="DD_TEMPLEOS_LOC"$ lines of TempleOS over the past $TX,"13.1",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! It is public domain, not GPL.
|
||||
I, $FG,2$Terry A. Davis$FG$, wrote all $TX,"119,996",D="DD_TEMPLEOS_LOC"$ lines of TempleOS over the past $TX,"13.2",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! It is public domain, not GPL.
|
||||
|
||||
*) $LK,"::/Kernel/FontStd.HC"$, is taken from $FG,4$$TX,"FreeDOS",HTML="http://www.freedos.org"$$FG$. It's public domain.
|
||||
|
||||
|
||||
+1
-1
@@ -1,2 +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.
|
||||
$WW,1$Use $FG,2$%p$FG$ to print a pointer with FunSeg+Offset or use $FG,2$%P$FG$ to print a link to a FunSeg+Offset.
|
||||
|
||||
+3
-3
@@ -8,7 +8,7 @@ $WW,1$$FG,5$$TX+CX,"Debugging Overview"$$FG$
|
||||
|
||||
* I use $LK,"progress1",A="MN:progress1"$-$LK,"progress4",A="MN:progress4"$ for debugging because they show on the wallpaper. They're just global int vars.
|
||||
|
||||
* You can use $LK,"AdamLog",A="MN:AdamLog"$() to send text to the Adam task window. It works like $LK,"Print",A="MN:Print"$(). I never use that. Instead, I use $LK,"RawPrint",A="MN:RawPrint"$().
|
||||
* You can use $LK,"AdamLog",A="MN:AdamLog"$() to send text to the $LK,"Adam Task",A="FF:::/Doc/Glossary.DD,Adam Task"$ window. It works like $LK,"Print",A="MN:Print"$(). I never use that. Instead, I use $LK,"RawPrint",A="MN:RawPrint"$().
|
||||
|
||||
* $LK,"D",A="MN:D"$(), $LK,"DocD",A="MN:DocD"$(), $LK,"RawD",A="MN:RawD"$() to do 16 column hex dump mem with numbering from zero. With $LK,"DocD",A="MN:DocD"$ the values are updated continually and you can alter mem by editing.
|
||||
|
||||
@@ -20,9 +20,9 @@ $WW,1$$FG,5$$TX+CX,"Debugging Overview"$$FG$
|
||||
|
||||
* $LK,"ClassRep",A="MN:ClassRep"$() and the dynamic version $LK,"ClassRepD",A="MN:ClassRepD"$() can be used to dump structures.
|
||||
|
||||
* $LK,"Prof",A="MN:Prof"$() and $LK,"ProfRep",A="MN:ProfRep"$() provide code profiling. See $LK,"::/Demo/AutoFile/AFProfile.AUT"$ (This is an $LK,"AutoFile",A="FF:::/Doc/Glossary.DD,AutoFile"$.)
|
||||
* $LK,"Prof",A="MN:Prof"$() and $LK,"ProfRep",A="MN:ProfRep"$() provide code profiling. See $LK,"::/Demo/InFile/INProfile.IN"$ (This is an $LK,"InFile",A="FF:::/Doc/Glossary.DD,InFile"$.)
|
||||
|
||||
* Use $LK,"RawPrint",A="MN:RawPrint"$() to print debug info bypassing the window framework. You pass these routines a count in milliseconds for how long it should be displayed. You can use $LK,"Raw",A="MN:Raw"$($FG,2$TRUE$FG$) to make all output bypass the window framework. The $FG,2$WinMgr$FG$ runs on $FG,2$core0$FG$ and will overwrite raw text from other cores when it updates the screen.
|
||||
* Use $LK,"RawPrint",A="MN:RawPrint"$() to print debug info bypassing the window framework. You pass these routines a count in milliseconds for how long it should be displayed. You can use $LK,"Raw",A="MN:Raw"$($FG,2$TRUE$FG$) to make all output bypass the window framework. The $FG,2$WinMgr$FG$ runs on $FG,2$Core0$FG$ and will overwrite raw text from other cores when it updates the scrn.
|
||||
|
||||
* Use $LK,"SysDbg",A="MN:SysDbg"$() to set a flag which you can read with $LK,"IsSysDbg",A="MN:IsSysDbg"$() when you wish to trigger some debug activity. It's just a handy simple flag, nothing fancy.
|
||||
|
||||
|
||||
+2
-2
@@ -17,7 +17,7 @@ $LK,"::/Kernel/BlkDev/DskCluster.HC"$ :152 All the cluster operations become blk
|
||||
|
||||
* VMware needs to support ATAPI CD/DVD/Blu-ray disk burning, directly to real hardware.
|
||||
|
||||
* VMware has a bug stretching 640x480 16 color to full screen.
|
||||
* VMware has a bug stretching 640x480 16 color to full scrn.
|
||||
|
||||
* VMware PC speaker's distortion is a good idea, but it is too much for hymns. VMware should make an adjustment for distortion and an adjustment for reverb.
|
||||
|
||||
@@ -44,7 +44,7 @@ $LK,"::/Kernel/Mem/PageTables.HC"$ :135 lines to identity-map gets eliminated.
|
||||
|
||||
* We do not want UTF, just 8-bit characters. $FG,2$<CTRL-ALT-f>$FG$ toggles between Cyrillic and Std Fonts. We need the twelve window $LK,"TextBorder",A="MN:TextBorder"$ characters added to the VGA font 0x02-0x0D. Japan, China and Korea must switch 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.DD"$. They are blemish free, unlike $TX,"BMP files",HTML="http://en.wikipedia.org/wiki/BMP_file_format"$.
|
||||
* Microsoft Paint and Linux's Gimp must support TempleOS $LK,"GR Files",A="FI:::/Doc/GRFiles.DD"$. 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.HC"$, too.
|
||||
|
||||
|
||||
+4
-4
@@ -2,7 +2,7 @@ $FG,5$$TX+CX,"TempleOS Demo Index"$$FG$
|
||||
|
||||
$WW,1$These are arranged in increasing order of difficulty, more or less. This can be used as a tutorial if you start at the beginning and work your way fwd.
|
||||
|
||||
$FG,2$<SPACE>$FG$ to edit a file and $FG,2$F5$FG$ to run it.
|
||||
$FG,2$<SPACE>$FG$ to edit a file and $FG,2$<F5>$FG$ to run it.
|
||||
|
||||
$LK,"::/Doc/HelloWorld.DD"$
|
||||
|
||||
@@ -33,7 +33,7 @@ $LK,"::/Demo/Games/Digits.HC"$
|
||||
$LK,"::/Demo/Progress.HC"$ //has some ASM, just ignore
|
||||
$LK,"::/Demo/Graphics/Symmetry.HC"$
|
||||
$LK,"::/Demo/Graphics/Blot.HC"$
|
||||
$LK,"::/Demo/Graphics/ScreenCapture.HC"$
|
||||
$LK,"::/Demo/Graphics/ScrnCapture.HC"$
|
||||
$LK,"::/Demo/Graphics/EdSprite.HC"$
|
||||
$LK,"::/Demo/PullDownMenu.HC"$
|
||||
$LK,"::/Demo/Graphics/Palette.HC"$
|
||||
@@ -56,7 +56,7 @@ $LK,"::/Demo/Graphics/SpritePlot3D.HC"$
|
||||
$LK,"::/Demo/Graphics/Balloon.HC"$
|
||||
$LK,"::/Demo/Graphics/RotateTank.HC"$
|
||||
$LK,"::/Demo/Games/Wenceslas.HC"$
|
||||
$LK,"::/Demo/ScreenCodes.HC"$
|
||||
$LK,"::/Demo/ScrnCodes.HC"$
|
||||
$LK,"::/Demo/Graphics/PanText.HC"$
|
||||
$LK,"::/Demo/Graphics/CharAnimation.HC"$
|
||||
$LK,"::/Demo/Games/Maze.HC"$
|
||||
@@ -152,7 +152,7 @@ $MA-X+PU,"::/Apps/Logic",LM="Cd(\"::/Apps/Logic\");Dir;View;\n"$
|
||||
$MA-X+PU,"::/Demo/Lectures",LM="Cd(\"::/Demo/Lectures\");Dir;View;\n"$
|
||||
$MA-X+PU,"::/Apps/Budget",LM="Cd(\"::/Apps/Budget\");Dir;View;\n"$
|
||||
$ID,-2$$TR,"TempleOS Specific"$
|
||||
$ID,2$$MA-X+PU,"::/Demo/AutoFile",LM="Cd(\"::/Demo/AutoFile\");Dir;View;\n"$
|
||||
$ID,2$$MA-X+PU,"::/Demo/InFile",LM="Cd(\"::/Demo/InFile\");Dir;View;\n"$
|
||||
$LK,"::/Demo/Print.HC"$
|
||||
$LK,"::/Demo/SubIntAccess.HC"$
|
||||
$LK,"::/Demo/ParenWarn.HC"$
|
||||
|
||||
@@ -113,7 +113,7 @@ Examples: <CTRL-t> to see
|
||||
5)$LK,"File find link searching for 5th 'CTRL'",A="FF:::/Kernel/KernelA.HH,CTRL:5"$
|
||||
6)$LK,"Manual page link",A="MN:Print"$
|
||||
7)$LK,"File line num link",A="FL:::/Kernel/KernelA.HH,200"$
|
||||
8)$LK,"File anchor link -- <CTRL-t> to see anchor after you click",A="FA:::/Kernel/KEnd.HC,Independent HeapCtrl Example"$
|
||||
8)$LK,"File anchor link -- <CTRL-t> to see anchor after you click",A="FA:::/Kernel/Mem/PageTables.HC,ExpandHeap"$
|
||||
9)$LK,"Bible Link",A="BF:Acts,2:3"$ The chapter:verse actually just does a text search.
|
||||
10) $LK,"Help Index Link",A="HI:Doc"$.
|
||||
11) $LK,"Address Link",A="AD:0x12000"$.
|
||||
@@ -149,9 +149,9 @@ The default raw data type for the $FG,2$$$LS...$$$FG$ command is $FG,2$RT=I64$FG
|
||||
$ID,-2$$TR,"MA Macro"$
|
||||
$ID,2$A left macro arg, $FG,2$LM=""$FG$, will send text when the left mouse is clicked.
|
||||
|
||||
A left auto string, $FG,2$+LA$FG$, flag will cause text to be sent to $LK,"AutoStr",A="MN:AutoStr"$() instead of $LK,"Auto",A="MN:Auto"$(). An AutoStr runs code. Literal text is in quotes and messages are sent with $LK,"Msg",A="MN:Msg"$(). See $MA-X+PU,LM="Dir(\"::/Demo/AutoFile\");View;"$.
|
||||
A left in string, $FG,2$+LIS$FG$, flag will cause text to be sent to $LK,"InStr",A="MN:InStr"$() instead of $LK,"In",A="MN:In"$(). An InStr runs code. Literal text is in quotes and messages are sent with $LK,"Msg",A="MN:Msg"$(). See $MA-X+PU,LM="Dir(\"::/Demo/InFile\");View;"$.
|
||||
|
||||
Macro's are usually in your $LK,"~/PersonalMenu.DD"$ and have the '$FG,2$+X$FG$' flag set by $LK,"default",A="MN:DocInit"$. Adding '$FG,2$-X$FG$' prevents the usual $FG,2$<ESC>$FG$ from being sent (which exits the PersonalMenu screen). Note: When you click a macro on the cmd line, it will go to the bottom and execute unless you cancel the $FG,2$<ESC>$FG$ with a '$FG,2$-X$FG$'.
|
||||
Macro's are usually in your $LK,"~/PersonalMenu.DD"$ and have the '$FG,2$+X$FG$' flag set by $LK,"default",A="MN:DocInit"$. Adding '$FG,2$-X$FG$' prevents the usual $FG,2$<ESC>$FG$ from being sent (which exits the PersonalMenu scrn). Note: When you click a macro on the cmd line, it will go to the bottom and execute unless you cancel the $FG,2$<ESC>$FG$ with a '$FG,2$-X$FG$'.
|
||||
$ID,-2$$TR,"MU Menu Value"$
|
||||
$ID,2$A left expression arg, $FG,2$LE=<Exp>$FG$, will return a number when clicked with the left mouse.
|
||||
|
||||
@@ -204,13 +204,13 @@ $ID,2$A PopUp flag on a $FG,2$MA$FG$ will cause the cmds to run in a new task, a
|
||||
$ID,-2$$TR,"+C Collapsed"$
|
||||
$ID,2$A collapsed flag on a $FG,2$TR$FG$ entry will cause it to start collapsed. A $FG,2$-C$FG$ flag will make it start open.
|
||||
$ID,-2$$TR,"+X <ESC> (Exit)"$
|
||||
$ID,2$The exit flag will cause a $FG,2$$$MA...$$$FG$ macro to send an $FG,2$<ESC>$FG$ before running to exit the PersonalMenu screen and return to the cmd prompt. Actually, the default $FG,2$$$MA...$$$FG$ has an exit flag set so you add a $FG,2$-X$FG$ to turn-off $FG,2$ESC$FG$, for a $FG,2$+PU$FG$ pop-up macro. If an entry is already at the cmd prompt, the $FG,2$+X$FG$ will movement to the bottom of the window.
|
||||
$ID,2$The exit flag will cause a $FG,2$$$MA...$$$FG$ macro to send an $FG,2$<ESC>$FG$ before running to exit the PersonalMenu scrn and return to the cmd prompt. Actually, the default $FG,2$$$MA...$$$FG$ has an exit flag set so you add a $FG,2$-X$FG$ to turn-off $FG,2$ESC$FG$, for a $FG,2$+PU$FG$ pop-up macro. If an entry is already at the cmd prompt, the $FG,2$+X$FG$ will movement to the bottom of the window.
|
||||
$ID,-2$$TR,"+Q <SHIFT-ESC> (Abort Quit)"$
|
||||
$ID,2$A quit flag is similar to a $FG,2$+X$FG$ except a $FG,2$<SHIFT-ESC>$FG$ instead of an $FG,2$<ESC>$FG$ to exit.
|
||||
$ID,-2$$TR,"+Z Zero"$
|
||||
$ID,2$A zero flag on a $FG,2$HX$FG$ entry will cause the offset from zero. A $FG,2$-X$FG$ will show the actual memory addr. By default, $FG,2$HX$FG$ has the zero flag set.
|
||||
$ID,-2$$TR,"+RD Refresh Data"$
|
||||
$ID,2$The Refresh Data flag on a $FG,2$DA$FG$ or a $FG,2$CB$FG$ makes the value on the screen updated continuously.
|
||||
$ID,2$The Refresh Data flag on a $FG,2$DA$FG$ or a $FG,2$CB$FG$ makes the value on the scrn updated continuously.
|
||||
$ID,-2$$TR,"+UD Update Data"$
|
||||
$ID,2$The Update Data flag on a $FG,2$DA$FG$ or a $FG,2$CB$FG$ makes the value in the $LK,"CDocEntry",A="MN:CDocEntry"$ updated when keys are typed on it.
|
||||
$ID,-2$$TR,"+TC Tag CallBack"$
|
||||
|
||||
+4
-4
@@ -33,9 +33,9 @@ $ID,2$Files with names ending in $FG,2$.Z$FG$ are individually compressed using
|
||||
$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,"BootHDIns",A="MN:BootHDIns"$() to compile the kernel and compiler. The rest is $LK,"JIT Compiled",A="FF:::/Doc/Glossary.DD,JIT Compile Mode"$ during boot. See $LK,"::/StartOS.HC"$.
|
||||
$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.DD,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.DD,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$TempleOS does not use object files or a linker. $LK,"AOT Compile Mode",A="FF:::/Doc/Glossary.DD,AOT Compile Mode"$ is used to directly create flat binary files, $LK,"::/Kernel.BIN.C",A="FI:::/Kernel/Kernel.PRJ"$ and $LK,"::/Compiler/Compiler.BIN",A="FI:::/Compiler/Compiler.PRJ"$ with no object files and linking.$FG$ $LK,"JIT Compile Mode",A="FF:::/Doc/Glossary.DD,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="WINMGR_FPS"$ frames-per-second. That is how often TempleOS updates screen mem. It is not syncronized to the hardware.
|
||||
$ID,2$The refresh rate is $TX,"30",D="WINMGR_FPS"$ frames-per-second. That is how often TempleOS updates scrn 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?"$
|
||||
@@ -45,9 +45,9 @@ $ID,2$The editor periodically takes a snap-shot of the document for $FG,2$UNDO$F
|
||||
$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/KStart16.HC,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/FontStd.HC"$. If graphics mode fails, it falls-back on text mode. You can force text mode with an $LK,"Kernel config",A="FI:::/Kernel/KCfg.HC"$ 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.DD,Code and Data Heaps"$, so that the $FG,2$REL32$FG$ addressing mode can be used. See $LK,"MemOverview",A="FI:::/Doc/MemOverview.DD"$.
|
||||
$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 2Gig of addresses, known as the $LK,"Code Heap",A="FF:::/Doc/Glossary.DD,Code and Data Heaps"$, so that the $FG,2$REL32$FG$ addressing mode can be used. See $LK,"MemOverview",A="FI:::/Doc/MemOverview.DD"$.
|
||||
$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.DD,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$TempleOS puts all code in the lowest 2Gig, known as the $LK,"Code Heap",A="FF:::/Doc/Glossary.DD,Code and Data Heaps"$, so that the $FG,2$REL32$FG$ addressing mode can be used. TempleOS is 64-bit, but $FG,2$2Gig$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$ insts because it never needs to change out of ring-0, even running user programs. Calls are always $FG,2$CALL REL32$FG$ insts.
|
||||
$ID,-2$$TR,"How do you fault-in stack?"$
|
||||
|
||||
+2
-2
@@ -28,7 +28,7 @@
|
||||
|
||||
* $FG,2$Graphics in source code$FG$, no resource files, $FG,2$graphic sprite editor$FG$. $FG,2$<CTRL-r>$FG$
|
||||
|
||||
* $FG,2$64-bit pointers$FG$. All memory, even more than 4 Gig, can be directly accessed by all tasks on all cores at all times.
|
||||
* $FG,2$64-bit pointers$FG$. All memory, even more than 4Gig, can be directly accessed by all tasks on all cores at all times.
|
||||
|
||||
* $FG,2$Ring-0-only$FG$. Highest CPU privileged mode at all times. No off-limits insts. No time lost changing modes or address maps. Switches tasks in half a microsecond.
|
||||
|
||||
@@ -38,7 +38,7 @@
|
||||
|
||||
* Auto-completion, jump-to-source tool called $FG,2$AutoComplete$FG$ with Dictionary.
|
||||
|
||||
* Window Manager. Pan screen with $FG,2$<CTRL-LeftDrag>$FG$. Zoom screen on mouse cursor with $FG,2$<CTRL-ALT-z>$FG$/$FG,2$<CTRL-ALT-SHIFT-Z>$FG$.
|
||||
* Window Manager. Pan scrn with $FG,2$<CTRL-LeftDrag>$FG$. Zoom scrn on mouse cursor with $FG,2$<CTRL-ALT-z>$FG$/$FG,2$<CTRL-ALT-SHIFT-Z>$FG$.
|
||||
|
||||
* File Manager, $FG,2$<CTRL-d>$FG$.
|
||||
|
||||
|
||||
+2
-2
@@ -1,13 +1,13 @@
|
||||
$WW,1$$FG,5$$TX+CX,"File Manager"$$FG$
|
||||
|
||||
$FG,2$<SHIFT CURSOR>$FG$
|
||||
$ID,2$Sel files.
|
||||
$ID,2$Select files.
|
||||
$ID,-2$
|
||||
$FG,2$<CTRL-y> or <DELETE>$FG$
|
||||
$ID,2$Delete file or tree.
|
||||
$ID,-2$
|
||||
$FG,2$<CTRL-c> or <CTRL-INS>$FG$
|
||||
$ID,2$Copy sel files to clipboard.
|
||||
$ID,2$Copy select files to clipboard.
|
||||
$ID,-2$
|
||||
$FG,2$<CTRL-v> or <SHIFT-INS>$FG$
|
||||
$ID,2$Paste clipboard.
|
||||
|
||||
+3
-2
@@ -4,7 +4,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$"/Demo/*.BMP*;*.GR*"$FG$ BaseDir: $FG,2$/Demo$FG$ Mask: $FG,2$*.BMP*$FG$ | $FG,2$*.GR*$FG$
|
||||
$FG,2$"/*.DD*;!*/Bible*"$FG$ BaseDir: $FG,2$Root$FG$ Mask: $FG,2$*.DD*$FG$ but not $FG,2$*/Bible*$FG$
|
||||
|
||||
See $LK,"FilesFindMatch",A="MN:FilesFindMatch"$().
|
||||
@@ -18,9 +18,10 @@ Flags are either text or int values.
|
||||
$LK,"FUF_JUST_FILES",A="MN:FUF_JUST_FILES"$ $FG,2$+F$FG$ just files (Flattens trees)
|
||||
$LK,"FUF_CLUSTER_ORDER",A="MN:FUF_CLUSTER_ORDER"$ $FG,2$+O$FG$ sort by cluster (move head one direction)
|
||||
$LK,"FUF_JUST_TXT",A="MN:FUF_JUST_TXT"$ $FG,2$+T$FG$ just text files : $LK,"FILEMASK_TXT",A="MN:FILEMASK_TXT"$
|
||||
$LK,"FUF_JUST_DD",A="MN:FUF_JUST_DD"$ $FG,2$+$$$FG$ just $LK,"DolDoc",A="FI:::/Doc/DolDocOverview.DD"$ files : $LK,"FILEMASK_DD",A="MN:FILEMASK_DD"$
|
||||
$LK,"FUF_JUST_SRC",A="MN:FUF_JUST_SRC"$ $FG,2$+S$FG$ just src files : $LK,"FILEMASK_SRC",A="MN:FILEMASK_SRC"$
|
||||
$LK,"FUF_JUST_AOT",A="MN:FUF_JUST_AOT"$ $FG,2$+A$FG$ just aot files : $LK,"FILEMASK_AOT",A="MN:FILEMASK_AOT"$
|
||||
$LK,"FUF_JUST_JIT",A="MN:FUF_JUST_JIT"$ $FG,2$+J$FG$ just jit files : $LK,"FILEMASK_JIT",A="MN:FILEMASK_JIT"$
|
||||
$LK,"FUF_JUST_GRA",A="MN:FUF_JUST_GRA"$ $FG,2$+G$FG$ just graphic files : $LK,"FILEMASK_GRA",A="MN:FILEMASK_GRA"$
|
||||
$LK,"FUF_JUST_GR",A="MN:FUF_JUST_GR"$ $FG,2$+G$FG$ just graphic files : $LK,"FILEMASK_GR",A="MN:FILEMASK_GR"$
|
||||
|
||||
See $LK,"ST_FILE_UTIL_FLAGS",A="MN:ST_FILE_UTIL_FLAGS"$ when used in calling program taking text flags.
|
||||
@@ -1,4 +1,4 @@
|
||||
$WW,1$GRA graphics files are 8-bits-per-pixels but only 4-bits of color, with transparency and no palette. Compression is the standard TempleOS$FG$ LZW compression.
|
||||
$WW,1$GR graphics files are 8-bits-per-pixels but only 4-bits of color, with transparency and no palette. Compression is the standard TempleOS$FG$ LZW compression.
|
||||
$HL,1$
|
||||
#define DCF_COMPRESSED 1 //This is the only saved flag.
|
||||
#define DCF_PALETTE 2
|
||||
@@ -32,7 +32,7 @@ CBGR48 gr_palette_std[16]={
|
||||
0x555555555555,0x55555555FFFF,0x5555FFFF5555,0x5555FFFFFFFF,
|
||||
0xFFFF55555555,0xFFFF5555FFFF,0xFFFFFFFF5555,0xFFFFFFFFFFFF};
|
||||
|
||||
class GRAFile
|
||||
class GRFile
|
||||
{
|
||||
I32 width;
|
||||
I32 width_internal; //Rounded-up to multiple of 8.
|
||||
@@ -42,4 +42,4 @@ class GRAFile
|
||||
U8 body[];
|
||||
};$HL,0$
|
||||
|
||||
See $LK,"DCSave",A="MN:DCSave"$(), $LK,"GRAWrite",A="MN:GRAWrite"$(), $LK,"DCLoad",A="MN:DCLoad"$(), and $LK,"GRARead",A="MN:GRARead"$().
|
||||
See $LK,"DCSave",A="MN:DCSave"$(), $LK,"GRWrite",A="MN:GRWrite"$(), $LK,"DCLoad",A="MN:DCLoad"$(), and $LK,"GRRead",A="MN:GRRead"$().
|
||||
+30
-16
@@ -121,6 +121,7 @@ $FG,2$Rst$FG$ Reset
|
||||
$FG,2$Rot$FG$ Rotation
|
||||
$FG,2$Rx$FG$ Receive
|
||||
$FG,2$Sched$FG$ Sceduler
|
||||
$FG,2$Scrn$FG$ Screen
|
||||
$FG,2$Sec$FG$ Second, Secondary
|
||||
$FG,2$Sect$FG$ Sector
|
||||
$FG,2$Sel$FG$ Select, Selected
|
||||
@@ -139,23 +140,27 @@ $FG,2$Sync$FG$ Synchronization
|
||||
$FG,2$Sys$FG$ System
|
||||
$FG,2$Tbl$FG$ Table
|
||||
$FG,2$Term$FG$ Terminal
|
||||
$FG,2$Tmp$FG$ Temporary
|
||||
$FG,2$Tri$FG$ Triangle
|
||||
$FG,2$Tx$FG$ Transmit
|
||||
$FG,2$UAsm$FG$ Unassemble
|
||||
$FG,2$Val$FG$ Value
|
||||
$FG,2$Var$FG$ Variable
|
||||
$FG,2$Vect$FG$ Vector
|
||||
$FG,2$Vis$FG$ Visible
|
||||
$FG,2$Vol$FG$ Volume
|
||||
$FG,2$Win$FG$ Window
|
||||
$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$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.
|
||||
|
||||
Since there is not friendly disk sharing and all tasks have the same address map, it might be accurate to call TempleOS, "multi-thread/single-process". You run a single application process on $FG,2$Core0$FG$ and it can create threads on the same core or others. If you run multiple processes, it should be safe, but one process will wait until another completely finishes a long disk access.
|
||||
$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.HC"$. 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$This is Adam, as in Adam and Eve, the parent of all tasks. Adam is immortal. The adam task is created at start-up and appears in the small window at the top beneath the user terminal windows. Since the Adam task is immortal, on Adam's heap go all memory objects which you don't want destroyed by any single task's death. When created, Adam runs the file $LK,"::/StartOS.HC"$. 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 are immortal.
|
||||
$ID,-2$$TR,"Seth Tasks"$
|
||||
$ID,2$In the Bible, $LK,"Seth",A="BF:Genesis,4:25"$$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$Core0$FG$ is also its $FG,2$Seth$FG$ task.
|
||||
$ID,-2$$TR,"Code and Data Heaps"$
|
||||
$ID,2$TempleOS uses the asm $FG,2$CALL$FG$ inst, exclusively, and that inst is limited to calling routines $FG,2$+/-2 Gig$FG$ from the current code location. To prevent out-of-range issues, I decided to separate code and data, placing all code within the lowest $FG,2$2 Gig$FG$ of memory, addresses $FG,2$00000000$FG$-$FG,2$7FFFFFFF$FG$. The compiler and $LK,"Load",A="MN:Load"$()er alloc memory from the code heap to store code and glbl vars, unless the compiler option $LK,"OPTf_GLBLS_ON_DATA_HEAP",A="MN:OPTf_GLBLS_ON_DATA_HEAP"$ is used. When programs call $LK,"MAlloc",A="MN:MAlloc"$() is from the data heap, which in not limited in size, except by physical RAM memory. You can alloc from any heap in any task at any time on any core, even making $LK,"independent",A="MN:Mem512Alloc"$ heaps.
|
||||
$ID,2$TempleOS uses the asm $FG,2$CALL$FG$ inst, exclusively, and that inst is limited to calling routines $FG,2$+/-2Gig$FG$ from the current code location. To prevent out-of-range issues, I decided to separate code and data, placing all code within the lowest $FG,2$2Gig$FG$ of memory, addresses $FG,2$00000000$FG$-$FG,2$7FFFFFFF$FG$. The compiler and $LK,"Load",A="MN:Load"$()er alloc memory from the code heap to store code and glbl vars, unless the compiler option $LK,"OPTf_GLBLS_ON_DATA_HEAP",A="MN:OPTf_GLBLS_ON_DATA_HEAP"$ is used. When programs call $LK,"MAlloc",A="MN:MAlloc"$() is from the data heap, which in not limited in size, except by physical RAM memory. You can alloc from any heap in any task at any time on any core, even making $LK,"independent",A="MN:Mem512Alloc"$ heaps.
|
||||
$ID,-2$$TR,"Parent, Child and PopUp Tasks"$
|
||||
$ID,2$Often a task will $LK,"Spawn",A="MN:Spawn"$() or $LK,"PopUp",A="MN:PopUp"$() a task as a helper. The helper is known as a child Task, though you can $LK,"Spawn",A="MN:Spawn"$ a task and assign it a different parent... like $FG,2$Adam$FG$. Links are kept as to who's whose child, so when one task is $LK,"Kill",A="MN:Kill"$()ed the child helper tasks die, too. You can get a report of current system tasks with $LK,"TaskRep",A="MN:TaskRep"$(). There is just one window per task, so child tasks are needed for pop-ups.
|
||||
$ID,-2$$TR,"HolyC"$
|
||||
@@ -165,7 +170,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, 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,"BootHDIns",A="MN:BootHDIns"$() 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,"BootHDIns",A="MN:BootHDIns"$() which calls $LK,"MakeAll",A="MN:MakeAll"$() where $LK,"::/Kernel.BIN.C",A="FI:::/Kernel/Kernel.PRJ"$ and $LK,"::/Compiler/Compiler.BIN",A="FI:::/Compiler/Compiler.PRJ"$ 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"$
|
||||
@@ -174,15 +179,24 @@ $ID,-2$$TR,"Drive/Partition"$
|
||||
$ID,2$There is no distinction between $FG,2$drive$FG$ or $FG,2$partition$FG$. They are specified with a single letter from $FG,2$A$FG$-$FG,2$Z$FG$.
|
||||
|
||||
'$FG,2$:$FG$' is the boot drive.
|
||||
'$FG,2$~$FG$' is the home drive.
|
||||
|
||||
The letters are reserved for different uses.
|
||||
|
||||
$FG,2$A$FG$-$FG,2$B$FG$ are RAM drives.
|
||||
$FG,2$C$FG$-$FG,2$L$FG$ are ATA hard drives.
|
||||
$FG,2$M$FG$-$FG,2$P$FG$ are ISO file read drives.
|
||||
$FG,2$Q$FG$-$FG,2$S$FG$ are ISO file write drives.
|
||||
$FG,2$T$FG$-$FG,2$Z$FG$ are ATAPI CD/DVD drives.
|
||||
|
||||
For commands taking a drive letter as an argument, char $FG,2$0$FG$ is the current drive.
|
||||
$ID,-2$$LK,"AutoFile",A="HI:AutoFile"$
|
||||
$LK,"Bt, Bts, Btr, Btc, BEqu",A="HI:Bit"$
|
||||
$ID,-2$$LK,"Bt, Bts, Btr, Btc, BEqu",A="HI:Bit"$
|
||||
$LK,"Define",A="HI:Define"$
|
||||
$LK,"DolDoc",A="FI:::/Doc/DolDocOverview.DD"$
|
||||
$LK,"Editor Link Types",A="MN:LK_FILE"$
|
||||
$LK,"files_find_mask",A="FI:::/Doc/FileUtils.DD"$
|
||||
$LK,"Hash Table",A="HI:Hash"$
|
||||
$LK,"InFile",A="HI:InFile"$
|
||||
$LK,"RedSea File System",A="FI:::/Doc/RedSea.DD"$
|
||||
$LK,"Sprite",A="HI:Graphics/Sprite"$
|
||||
$TR,"CLI, STI, PUSHFD, POPFD"$
|
||||
@@ -196,7 +210,7 @@ $ID,2$$FG,5$*.???.Z$FG$
|
||||
These files are automatically compressed or uncompresses files when read or written.
|
||||
$FG,5$*.???.C$FG$
|
||||
Contiguous files--NOT compressed.
|
||||
$FG,5$*.DD.Z;*.DD;*.LOG.Z;*.LOG$FG$
|
||||
$FG,5$*.DD.Z;*.DD$FG$
|
||||
Text Files
|
||||
$FG,5$*.HC.Z;*.HC$FG$
|
||||
HolyC src files. The default HolyC compiler type is $FG,2$.HC.Z$FG$.
|
||||
@@ -208,21 +222,21 @@ $FG,5$*.MAP.Z;*.MAP$FG$
|
||||
Compiler "map" files
|
||||
$FG,5$*.BIN.Z;*.BIN.C;*.BIN$FG$
|
||||
Binary executable files, created by $LK,"Cmp",A="MN:Cmp"$() and read by $LK,"Load",A="MN:Load"$().
|
||||
$FG,5$*.DAT.Z;*.DAT$FG$
|
||||
$FG,5$*.DATA.Z;*.DATA$FG$
|
||||
Data files
|
||||
$FG,5$*.ISO$FG$
|
||||
CD/DVD image file--ISO9660.
|
||||
$FG,5$*.AUT.Z;*.AUT$FG$
|
||||
$FG,2$AutoFile$FG$ Basically a HolyC program whose stdout goes to the input of a task when $LK,"AutoFile",A="MN:AutoFile"$() is called.
|
||||
$FG,5$*.GRA.Z;*.GRA$FG$
|
||||
$FG,5$*.IN.Z;*.IN$FG$
|
||||
$FG,2$InFile$FG$ Basically a HolyC program whose stdout goes to the input of a task when $LK,"InFile",A="MN:InFile"$() is called.
|
||||
$FG,5$*.GR.Z;*.GR$FG$
|
||||
Graphics file
|
||||
|
||||
$LK,"FILEMASK_TXT",A="MN:FILEMASK_TXT"$
|
||||
$LK,"FILEMASK_SRC",A="MN:FILEMASK_SRC"$
|
||||
$LK,"FILEMASK_AOT",A="MN:FILEMASK_AOT"$
|
||||
$LK,"FILEMASK_JIT",A="MN:FILEMASK_JIT"$
|
||||
$LK,"FILEMASK_GRA",A="MN:FILEMASK_GRA"$
|
||||
$ID,-2$$TR-C,"Naming Convention"$
|
||||
$LK,"FILEMASK_GR",A="MN:FILEMASK_GR"$
|
||||
$ID,-2$$TR,"Naming Convention"$
|
||||
$ID,2$Since there are no $FG,2$namespaces$FG$ and I don't plan to implement name spaces, I highly recommend putting a 2-3 character module code prefix on syms. e.g. $FG,2$WS$FG$, $FG,2$Doc$FG$, $FG,2$Lex$FG$
|
||||
|
||||
$FG,5$ALL_CAPS$FG$
|
||||
@@ -260,5 +274,5 @@ $ID,2$When two parts of a program have a common low-level routine, that routine
|
||||
$ID,-2$$TR,"user_data"$
|
||||
$ID,2$Many operating system structures have space set aside for you to store values. You are on your own managing these with multiple applications and libraries.
|
||||
$ID,-2$$TR,"Multicore Core0/CoreAP"$
|
||||
$ID,2$Core0, has the $FG,2$Adam task$FG$, and it is the master. The $FG,2$application processors$FG$ have an executive $FG,2$Seth tasks$FG$ and are the slave processors. Only $FG,2$core0$FG$ tasks can have windows and can launch applications. Slave cores are used if the application explicitly $LK,"Spawn",A="MN:Spawn"$s() a task or $LK,"JobQue",A="MN:JobQue"$() a job on them.
|
||||
$ID,2$Core0, has the $LK,"Adam Task",A="FF:::/Doc/Glossary.DD,Adam Task"$$FG$, and it is the master. The $FG,2$application processors$FG$ have an executive $LK,"Seth Tasks",A="FF:::/Doc/Glossary.DD,Seth Tasks"$ and are the slave processors. Only $FG,2$Core0$FG$ tasks can have windows and can launch applications. Slave cores are used if the application explicitly $LK,"Spawn",A="MN:Spawn"$s() a task or $LK,"JobQue",A="MN:JobQue"$() a job on them.
|
||||
$ID,-2$
|
||||
Binary file not shown.
+3
-3
@@ -14,7 +14,7 @@ $FG,2$/Compiler$FG$ The compiler module src code is found here. The compiler is
|
||||
|
||||
$FG,2$/Adam$FG$ The non-kernel part of the operating system is found here. It is $FG,2$JIT$FG$ compiled during boot. The $LK,"Adam Task",A="FF:::/Doc/Glossary.DD,Adam Task"$ is the father of all tasks, like Adam and Eve.
|
||||
|
||||
$FG,2$/0000Boot$FG$ Boot files go here. Stage 2 of the TempleOS hard drive master boot loader, the old hard drive master boot record which is just blk#0, and the CD/DVD $FG,2$0000Kernel.BIN.C$FG$ file go here. ASCII $FG,2$0000$FG$ is near the top, alphabetically, in case you use $TX,"MagicISO",HTML="http://www.magiciso.com"$.
|
||||
$FG,2$/0000Boot$FG$ Boot files go here. Stage 2 of the TempleOS hard drive master boot loader, the old hard drive master boot record which is just blk#0, and the CD/DVD $LK,"0000Kernel.BIN.C",A="FI:::/Kernel/Kernel.PRJ"$ file go here. ASCII $FG,2$0000$FG$ is near the top, alphabetically, in case you use $TX,"MagicISO",HTML="http://www.magiciso.com"$.
|
||||
|
||||
|
||||
|
||||
@@ -28,7 +28,7 @@ $LK,"~/PersonalNotes.DD"$ a personal note file viewed with the $FG,2$<CTRL-SHIFT
|
||||
|
||||
$LK,"~/MakeHome.HC"$ a file compiled by the $LK,"Adam Task",A="FF:::/Doc/Glossary.DD,Adam Task"$ during $LK,"StartOS",A="FF:::/StartOS.HC,MakeHome"$.
|
||||
|
||||
$FG,4$~/Home*$FG$ Copy $FG,2$Home*$FG$ files from the root into $FG,2$~$FG$ and customize them. These files are invoked when the adam task starts-up.
|
||||
$FG,4$~/Home*$FG$ Copy $FG,2$Home*$FG$ files from the root into $FG,2$~$FG$ and customize them. These files are invoked when the $LK,"Adam Task",A="FF:::/Doc/Glossary.DD,Adam Task"$ starts-up.
|
||||
|
||||
$LK,"~/DoOnce.HC"$ a file invoked at the start-up of the first user. Customize this!
|
||||
|
||||
@@ -46,7 +46,7 @@ $FG,5$$TX+CX,"Application Policies"$$FG$
|
||||
|
||||
* Place user data in a subdirectory of $FG,2$/Home$FG$, preferably naming the subdirectory the same as the $FG,2$/Apps$FG$ subdirectory. Or, place data in the $FG,2$Registry.HC.Z$FG$ file. See $LK,"::/Demo/RegistryDemo.HC"$.
|
||||
|
||||
* If the app needs files in the $FG,2$/Home$FG$ directory, make an $FG,2$/Apps$FG$ file called $FG,2$Install.HC.Z$FG$ or $FG,2$Install.AUT.Z$FG$ to create the $FG,2$/Home$FG$ subdirectory.
|
||||
* If the app needs files in the $FG,2$/Home$FG$ directory, make an $FG,2$/Apps$FG$ file called $FG,2$Install.HC.Z$FG$ or $FG,2$Install.IN.Z$FG$ to create the $FG,2$/Home$FG$ subdirectory.
|
||||
|
||||
|
||||
|
||||
|
||||
Binary file not shown.
+2
-2
@@ -97,7 +97,7 @@ public U0 GrPrint(CDC *dc,I64 x,I64 y,U8 *fmt,...)
|
||||
...
|
||||
|
||||
GrPrint(gr.dc,(GR_WIDTH-10*FONT_WIDTH)>>1,(GR_HEIGHT-FONT_HEIGHT)>>1,
|
||||
"Score:%4d",score); //Print score in the center of the screen.
|
||||
"Score:%4d",score); //Print score in the center of the scrn.
|
||||
...
|
||||
|
||||
$WW,1$$FG$$ID,-2$
|
||||
@@ -168,7 +168,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/Mem/PageTableEntries.HC"$.
|
||||
* $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,"IRQKbd",A="MN:IRQKbd"$().
|
||||
|
||||
* 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.
|
||||
|
||||
|
||||
@@ -0,0 +1,7 @@
|
||||
$WW,1$$FG,2$InFiles$FG$ are used to generate user input to automate operations. The TempleOS tour is done with an $FG,2$InFile$FG$. It reminds me of a Unix pipe because $FG,2$StdOut$FG$ of one gets chained into $FG,2$StdIn$FG$ of another.
|
||||
|
||||
When an $FG,2$InFile$FG$ runs, a child task is $LK,"Spawn",A="MN:Spawn"$()ed which intercepts real user input and generates fake input. InFiles are $LK,"HolyC",A="FI:::/Doc/HolyC.DD"$ programs run by the child whose stdout goes to the parent's input buffer. $LK,"Msg",A="MN:Msg"$() can be included in an $FG,2$InFile$FG$ to send special keys or mouse cmds to the parent. While an $FG,2$InFile$FG$ is running, the normal input gets diverted to the InFile task and can be filtered and sent back to the parent task. Unless you are driving functions which prompt for data, you can probably use an $FG,2$#include$FG$ file in place of an $FG,2$InFile$FG$.
|
||||
|
||||
See $LK,"::/Demo/InFile/INDir.IN"$.
|
||||
|
||||
Note: $LK,"In",A="MN:In"$("") can be used if all you need is to send ASCII characters. It differs from $LK,"InStr",A="MN:InStr"$(). You'll probably use $LK,"In",A="MN:In"$() a lot and not $LK,"InStr",A="MN:InStr"$(). With $LK,"In",A="MN:In"$(), for example, you can place answers to the prompts for recompiling the $FG,2$Kernel$FG$ module during $LK,"BootHDIns",A="MN:BootHDIns"$().
|
||||
+1
-1
@@ -1,6 +1,6 @@
|
||||
$WW,1$"Input Ptr" is the mouse. In the future, might be joystick or pad.
|
||||
|
||||
$LK,"ip.pos.x",A="MN:ip"$ and $LK,"ip.pos.y",A="MN:ip"$ can be used to access the x and y coordinates of the input ptr. They are relative to the screen, not window. These can be used if you don't want to use msg passing. $LK,"ip.pos.z",A="MN:ip"$ is the wheel.
|
||||
$LK,"ip.pos.x",A="MN:ip"$ and $LK,"ip.pos.y",A="MN:ip"$ can be used to access the x and y coordinates of the input ptr. They are relative to the scrn, not window. These can be used if you don't want to use msg passing. $LK,"ip.pos.z",A="MN:ip"$ is the wheel.
|
||||
|
||||
$LK,"ip.pos_text.x",A="MN:CIPStateGlbls"$ and $LK,"ip.pos_text.y",A="MN:CIPStateGlbls"$ are the text column and row of the input ptr. See $LK,"::/Demo/Games/Maze.HC"$.
|
||||
|
||||
|
||||
+4
-5
@@ -2,7 +2,7 @@ $WW,1$$FG,5$$TX+CX,"Installing TempleOS"$$FG$
|
||||
|
||||
Burn a CD with software that supports ISO files. Then, boot it. It's a live CD, so you can look around with or without installing.
|
||||
|
||||
Dual booting with another operating system is the best way to use TempleOS. I only use it in a virtual machine because it won't boot natively on my machine, though. For native dual booting, you need a partition for TempleOS. Windows often comes with a restore disk that does not allow repartitioning. I recommend connecting a spare additional hard drive and using the $FG,2$BIOS$FG$ to sel which drive to boot.
|
||||
Dual booting with another operating system is the best way to use TempleOS. I only use it in a virtual machine because it won't boot natively on my machine, though. For native dual booting, you need a partition for TempleOS. Windows often comes with a restore disk that does not allow repartitioning. I recommend connecting a spare additional hard drive and using the $FG,2$BIOS$FG$ to select which drive to boot.
|
||||
|
||||
The $LK,"::/Misc/OSInstall.HC"$ script will automate much of this. It runs if you boot the CD/DVD-ROM.
|
||||
|
||||
@@ -26,7 +26,7 @@ $ID,-2$
|
||||
$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.DD"$ 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$.
|
||||
$BK,1$WARNING:$BK,0$ If you are upgrading, be sure not to lose the file, $FG,2$/0000Boot/OldMBR.BIN.C$FG$.
|
||||
|
||||
$ID,-2$3) $LK,"CopyTree",A="MN:CopyTree"$($FG,2$"T:/"$FG$,$FG,2$"D:/"$FG$)
|
||||
$ID,2$This command is used to copy files onto a hard drive partition from the CD/DVD. Use the drive letter of the partition in place of $FG,2$'D'$FG$.
|
||||
@@ -36,13 +36,12 @@ $ID,2$This command recompiles the source code on a drive and writes to the $UL,1
|
||||
|
||||
$ID,-2$5) Use Linux's Grub or TempleOS' $LK,"BootMHDIns",A="MN:BootMHDIns"$($FG,2$'D'$FG$)
|
||||
$ID,2$
|
||||
The $LK,"BootMHDIns",A="MN:BootMHDIns"$() 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,"BootMHDIns",A="MN:BootMHDIns"$() command places a boot loader on a drive. It saves the old master boot record to $FG,2$/0000Boot/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.
|
||||
Delete $FG,2$/0000Boot/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$/0000Boot/OldMBR.BIN.C$FG$ onto a system with a non-TempleOS boot loader.
|
||||
|
||||
If you have anti-virus software, it might object to having a different master boot record.
|
||||
$ID,-2$
|
||||
|
||||
$FG,8$
|
||||
* "Windows" is a trademark owned by MicroSoft Corp.
|
||||
* "Linux" is a trademark owned by Linus Torvalds.
|
||||
|
||||
+1
-1
@@ -5,7 +5,7 @@ $LK,"KeyDevAdd",A="MN:KeyDevAdd"$() defines a putkey device with a priority. "D
|
||||
Priority Handler
|
||||
---------- ---------
|
||||
$FG,2$0x20000000$FG$ $LK,"MyPutKey",A="MN:MyPutKey"$() user handler
|
||||
$FG,2$0x40000000$FG$ $LK,"KDInputFilterPutKey",A="MN:KDInputFilterPutKey"$() for $LK,"Auto",A="MN:Auto"$(), $LK,"AutoStr",A="MN:AutoStr"$(), and $LK,"AutoFile",A="MN:AutoFile"$() handling.
|
||||
$FG,2$0x40000000$FG$ $LK,"KDInputFilterPutKey",A="MN:KDInputFilterPutKey"$() for $LK,"In",A="MN:In"$(), $LK,"InStr",A="MN:InStr"$(), and $LK,"InFile",A="MN:InFile"$() handling.
|
||||
$FG,2$0x60000000$FG$ $LK,"KDRawPutKey",A="MN:KDRawPutKey"$() nonwindowed direct to video mem debug output.
|
||||
$FG,2$0x80000000$FG$ $LK,"KDDocPutKey",A="MN:KDDocPutKey"$() standard document cmds
|
||||
|
||||
|
||||
+28
-14
@@ -1,20 +1,22 @@
|
||||
$WW,1$$FG,5$$TX+CX,"Memory Overview"$$FG$
|
||||
|
||||
Paging is practically not used. 64-bit mode requires paging, however, so it is identity-mapped, virtual identical to physical. All tasks on all cores use the same page table map, just as though all addresses are physical addresses. 2 Meg page table entries are used. Nothing swaps to disk. You can adjust $LK,"MEM_MAPPED_SPACE",A="MN:MEM_MAPPED_SPACE"$ for more RAM.
|
||||
Paging is practically not used. 64-bit mode requires paging, however, so it is identity-mapped, virtual identical to physical. All tasks on all cores use the same page table map, just as though all addresses are physical addresses. 2Meg or 1Gig page table entries are used. Nothing swaps to disk. You can adjust $LK,"MEM_MAPPED_SPACE",A="MN:MEM_MAPPED_SPACE"$ for more RAM.
|
||||
|
||||
In TempleOS, the lowest 2 Gig of memory is called the $FG,2$code heap$FG$. TempleOS's compiler always uses 32-bit signed relative JMP & CALL insts because 64-bit CALLs take two insts. With signed +/- 32-bit values, code can only call a function within 2 Gig distance. Therefore, TempleOS keeps all code in the lowest 2 Gig memory addresses including what would normally be called "the kernel". Two Gig is plenty for code, don't worry.
|
||||
In TempleOS, the lowest 2Gig of memory is called the $FG,2$code heap$FG$. TempleOS's compiler always uses 32-bit signed relative JMP & CALL insts because 64-bit CALLs take two insts. With signed +/- 32-bit values, code can only call a function within 2Gig distance. Therefore, TempleOS keeps all code in the lowest 2Gig memory addresses including what would normally be called "the kernel". Two Gig is plenty for code, don't worry.
|
||||
|
||||
You can create new, independent heaps using $LK,"HeapCtrlInit",A="MN:HeapCtrlInit"$(). Then, use the $LK,"CHeapCtrl",A="MN:CHeapCtrl"$ as the 2nd arg to $LK,"MAlloc",A="MN:MAlloc"$(). See $LK,"HeapLog",A="MN:HeapLog"$() for an example.
|
||||
|
||||
Memory alloced by a task will be freed when the task is killed.
|
||||
Memory alloced by a task will be freed when the task is killed. The $LK,"Adam Task",A="FF:::/Doc/Glossary.DD,Adam Task"$ is a task that never dies. His memory is like kernel memory in other operating systems. See $LK,"ACAlloc",A="MN:ACAlloc"$(), $LK,"AMAlloc",A="MN:AMAlloc"$(), $LK,"AMAllocIdent",A="MN:AMAllocIdent"$() and $LK,"AStrNew",A="MN:AStrNew"$().
|
||||
|
||||
Eventually, memory will become fragmented, requiring a reboot.
|
||||
All of the regular page tables are marked, "cached". When accessing hardware, however, you need uncached page table. The lowest 4Gig of addresses have an alias used to access hardware located toward the top of mapped space. It is currently at $FG,2$0x$TX,"3F00000000",D="DD_UNCACHED_ALIAS"$$FG$ but can change if $LK,"MEM_MAPPED_SPACE",A="MN:MEM_MAPPED_SPACE"$ is adjusted. See $LK,"dev.uncached_alias",A="FF:::/Kernel/KEnd.HC,dev.uncached_alias"$.
|
||||
|
||||
During an extended powered-on session of TempleOS, in theory, memory will become fragmented, requiring a reboot. It has never happened to me.
|
||||
|
||||
See $LK,"MemRep",A="MN:MemRep"$() and $LK,"::/Demo/MemDemo.HC"$.
|
||||
|
||||
$FG,5$$TX+CX,"Single System-wide Mem Map"$
|
||||
|
||||
$FG,2$ 0x00$TX,"00007C00",D="DD_KERNEL"$- 0x00$TX,"00035F3F",D="DD_KERNEL_END"$$FG$
|
||||
$FG,2$ 0x00$TX,"00007C00",D="DD_KERNEL"$- 0x00$TX,"0003654F",D="DD_KERNEL_END"$$FG$
|
||||
$ID,2$Kernel module, placed here by the boot-loader, $LK,"BOOT_RAM_BASE",A="MN:BOOT_RAM_BASE"$.
|
||||
$ID,-2$
|
||||
$FG,2$ 0x00$TX,"00096600",D="DD_BOOT_HIGH_LOC_DVD"$- 0x00$TX,"00096FFF",D="DD_BOOT_HIGH_LOC_DVD_END"$$FG$
|
||||
@@ -29,14 +31,14 @@ $ID,-2$
|
||||
$FG,2$ 0x00000A0000- 0x00000BFFFF$FG$
|
||||
$ID,2$VGA graphics mem, marked as write-through cache in $LK,"text",A="MN:text"$.vga_alias.
|
||||
$ID,-2$
|
||||
$FG,2$ 0x00$TX,"00100000",D="DD_SYS_FIXED_AREA_BASE"$- 0x00$TX,"002037FF",D="DD_SYS_FIXED_AREA_END"$$FG$
|
||||
$ID,2$$LK,"CSysFixedArea",A="MN:CSysFixedArea"$ for page tables and misc. $TX,"256 Gig",D="DD_MEM_MAPPED_SPACE_GIG"$ of address space mapped.
|
||||
$FG,2$ 0x00$TX,"00100000",D="DD_SYS_FIXED_AREA_BASE"$- 0x00$TX,"002035FF",D="DD_SYS_FIXED_AREA_END"$$FG$
|
||||
$ID,2$$LK,"CSysFixedArea",A="MN:CSysFixedArea"$ for page tables and misc. $TX,"256Gig",D="DD_MEM_MAPPED_SPACE_GIG"$ of address space mapped.
|
||||
$ID,-2$
|
||||
$FG,2$ 0x00$TX,"00203800",D="DD_SYS_HEAP_BASE"$- 0x00$TX,"7FFFFFFF",D="DD_SYS_HEAP_LIMIT"$$FG$
|
||||
$FG,2$ 0x00$TX,"00203600",D="DD_SYS_HEAP_BASE"$- 0x00$TX,"7FFFFFFF",D="DD_SYS_HEAP_LIMIT"$$FG$
|
||||
$ID,2$Code Heap mem.
|
||||
$ID,-2$
|
||||
$FG,2$ - 0x007FFFFFFF$FG$
|
||||
$ID,2$Data Heap mem. (This exists if there is less than 2 Gig of code heap.)
|
||||
$ID,2$Data Heap mem. (This exists if there is less than 2Gig of code heap.)
|
||||
$ID,-2$
|
||||
$FG,2$ 0x00E0000000- 0x00FFFFFFFF$FG$
|
||||
$ID,2$32-bit devices could alloc memory at 0xF0000000 going up, but this is wrong, since some PCs already have devices at 0xF0000000. No PCI devices are supported, so $LK,"Mem32DevAlloc",A="MN:Mem32DevAlloc"$() flaws are not an issue.
|
||||
@@ -46,15 +48,27 @@ $FG,2$ 0x0100000000-~0x$TX,"3FFFFFFFFF",D="DD_MEM_MAPPED_SPACE_END"$$FG$
|
||||
$ID,2$Data Heap mem. (The physical memory that exists in this range is data heap.)
|
||||
$ID,-2$
|
||||
$FG,2$ 0x$TX,"3F00000000",D="DD_UNCACHED_ALIAS"$- 0x$TX,"3FFFFFFFFF",D="DD_MEM_MAPPED_SPACE_END"$$FG$
|
||||
$ID,2$Uncached alias of first 4 Gig. (For 32-bit device access.)
|
||||
$ID,2$Uncached alias of first 4Gig. (For 32-bit device access.)
|
||||
$ID,-2$
|
||||
$FG,2$ - 0x$TX,"3FFFFFFFFF",D="DD_MEM_MAPPED_SPACE_END"$$FG$
|
||||
$ID,2$64-bit devices are alloced with $LK,"Mem64DevAlloc",A="MN:Mem64DevAlloc"$() counting bwd from $TX,"256 Gig",D="DD_MEM_MAPPED_SPACE_GIG"$, but no PCI devices are actually supported$WW,0$.
|
||||
$ID,2$64-bit devices are alloced with $LK,"Mem64DevAlloc",A="MN:Mem64DevAlloc"$() counting bwd from $TX,"256Gig",D="DD_MEM_MAPPED_SPACE_GIG"$, but no PCI devices are actually supported$WW,0$.
|
||||
$ID,-2$
|
||||
|
||||
|
||||
$WW,1$* Note: There is a break in the data-heap block pool. This has no effect except the obvious effect that fragmentation has on contiguous requests. I can $LK,"MAlloc",A="MN:MAlloc"$() an 8 Gig chunk on my 12 Gig machine.
|
||||
$WW,1$* Note: There is a break in the data-heap block pool. This has no effect except the obvious effect that fragmentation has on contiguous requests. I can $LK,"MAlloc",A="MN:MAlloc"$() an 8Gig chunk on my 12Gig machine. I can $LK,"MAlloc",A="MN:MAlloc"$() an 32Gig chunk on my 64Gig machine.
|
||||
|
||||
* Note: For systems with less than 2 Gig RAM, the code and data heap block pools are the same. For systems with 2-4 Gig of RAM, the code heap is 1/4 of the total. See $LK,"BlkPoolsInit",A="MN:BlkPoolsInit"$().
|
||||
* Note: For systems with less than 2Gig RAM, the code and data heap block pools are the same. For systems with 2-4Gig of RAM, the code heap is 1/4 of the total. See $LK,"BlkPoolsInit",A="MN:BlkPoolsInit"$().
|
||||
|
||||
* See $LK,"Independent HeapCtrl Example",A="FA:::/Kernel/KEnd.HC,Independent HeapCtrl Example"$.
|
||||
|
||||
|
||||
$FG,5$$TX+CX,"History"$$FG$
|
||||
|
||||
In 2003, I wanted to make a no-paging ring-0-only 64-bit operating system for super speed with simplicity and full access. With paging, every memory request requires 5 accesses -- it must access the address itself, 4K, 2Meg, 1Gig, and 512Gig page tables, but the CPU's translation look-aside buffer mostly removes the penalty for using paging. So, I did not want to use paging, but long mode requires it. I did the next best thing -- I identity-mapped everything and achieved the simplicity I was after with subtle performance boosts, not wasting time changing address maps. And, I look forward to the day I command Intel to make an optimized no-paging long mode.
|
||||
|
||||
I needed VGA A0000-BFFFF memory to be write-through and 0xE0000000-0xFFFFFFFF to be uncached for various devices. All 64-bit computers allow stopping address translation at 2Meg page size, not using 4K. I wanted to use 2Meg for everything because it's faster, with one less level of page tables. I had to make A0000-BFFFF write-through, though, so I could not use 2Meg size on the lowest page. I did the lowest 2Meg area as 4K pages. I also unmapped the first 4K to cause a fault when dereferencing NULL.
|
||||
|
||||
In 2016, I came-up with an alternate idea. I double mapped the lowest memory with an alias that was uncached. Accessing the lowest 2Meg area directly was cached but the alias I created up at the $LK,"top of address space",A="MN:MEM_MAPPED_SPACE"$ was uncached. Unfortunately, I could no longer boast of the simplicity of identity mapping everything. Since many of my users are familiar with A0000-BFFFF, it is actually pretty seriously unfortunate that they cannot use the easy-to-understand numbers of A0000-BFFFF, but must access the relocated alias location. See $LK,"text.vga_alias",A="FF:::/Kernel/KEnd.HC,text.vga_alias"$. I also no longer cause a fault when dereferencing NULL.
|
||||
|
||||
Then, I switched to 1Gig page sizes. For the lowest 4Gig, I set-up an alias up at the $LK,"top of address space",A="MN:MEM_MAPPED_SPACE"$. Not all computers support 1Gig page tables, however, so I also support 2Meg.
|
||||
|
||||
My original plan was to allow changing the page tables as needed, so I had code for taking control of 2Meg pages and marking them uncached or whatever. When I did a HDAudio driver, I requested some 32-bit address space as uncached. Today, all of the first 4Gig can be accessed without caching at the $LK,"dev.uncached_alias",A="FF:::/Kernel/KEnd.HC,dev.uncached_alias"$.
|
||||
+1
-1
@@ -1,4 +1,4 @@
|
||||
$WW,1$A pull-down menu appears when you move the mouse to the top of the screen. Menus are created with $LK,"MenuPush",A="MN:MenuPush"$(), $LK,"MenuFilePush",A="MN:MenuFilePush"$(), $LK,"MenuNew",A="MN:MenuNew"$() or $LK,"MenuFile",A="MN:MenuFile"$() and assigned to $FG,4$Fs->cur_menu$FG$. The format is:
|
||||
$WW,1$A pull-down menu appears when you move the mouse to the top of the scrn. Menus are created with $LK,"MenuPush",A="MN:MenuPush"$(), $LK,"MenuFilePush",A="MN:MenuFilePush"$(), $LK,"MenuNew",A="MN:MenuNew"$() or $LK,"MenuFile",A="MN:MenuFile"$() and assigned to $FG,4$Fs->cur_menu$FG$. The format is:
|
||||
|
||||
$FG,2$
|
||||
File
|
||||
|
||||
+3
-3
@@ -2,11 +2,11 @@ $WW,1$TempleOS does master-slave multicore instead of SMP. $FG,2$Core0$FG$ is t
|
||||
|
||||
There are multicore safe locks for file access and heap allocations, however, so TempleOS is symmetrical in some sense. See $LK,"::/Demo/MultiCore/LoadTest.HC"$.
|
||||
|
||||
Only tasks on $FG,2$core0$FG$ can have windows, but other cores can help render them.
|
||||
Only tasks on $FG,2$Core0$FG$ can have windows, but other cores can help render them.
|
||||
|
||||
Each core has an executive $FG,2$seth task$FG$ which is the father of all tasks on that core. Adam is the seth task on core 0.
|
||||
Each core has an executive $LK,"Seth Task",A="FF:::/Doc/Glossary.DD,Seth Tasks"$ which is the father of all tasks on that core. $LK,"Adam",A="FF:::/Doc/Glossary.DD,Adam Task"$ is the $LK,"Seth Task",A="FF:::/Doc/Glossary.DD,Seth Tasks"$ on $FG,2$Core0$FG$.
|
||||
|
||||
You give a job to a seth task with $LK,"JobQue",A="MN:JobQue"$() and get the res with $LK,"JobResGet",A="MN:JobResGet"$(). You spawn a task on another core with $LK,"Spawn",A="MN:Spawn"$().
|
||||
You give a job to a $LK,"Seth Task",A="FF:::/Doc/Glossary.DD,Seth Tasks"$ with $LK,"JobQue",A="MN:JobQue"$() and get the res with $LK,"JobResGet",A="MN:JobResGet"$(). You spawn a task on another core with $LK,"Spawn",A="MN:Spawn"$().
|
||||
|
||||
Note: You must use the $FG,2$LOCK$FG$ asm prefix when changing shared structures in a multicore environment. The $LK,"LBts",A="MN:LBts"$(), $LK,"LBtr",A="MN:LBtr"$() and $LK,"LBtc",A="MN:LBtc"$() insts have $FG,2$LOCK$FG$ prefixes. The compiler has a $FG,2$lock{}$FG$ feature but it doesn't work well. See $LK,"::/Demo/MultiCore/Lock.HC"$.
|
||||
|
||||
|
||||
+1
-1
@@ -2,7 +2,7 @@ $WW,1$$FG,5$$TX+CX,"Compiler Options"$$FG$
|
||||
|
||||
Use $LK,"Option",A="MN:Option"$(). You might need to do $FG,2$#exe {Option();}$FG$.
|
||||
|
||||
$LK,"OPTf_GLBLS_ON_DATA_HEAP",A="MN:OPTf_GLBLS_ON_DATA_HEAP"$ without this option, global vars are placed in the code heap which is limited to 2 Gig. In $FG,2$AOT$FG$ modules, global vars take-up room in the $FG,2$.BIN$FG$ file, so you might want to use this option, instead. You might wish to turn it on and off around specific vars. A disadvantage of data heap global vars in $FG,2$AOT$FG$ modules is they can't be initialized.
|
||||
$LK,"OPTf_GLBLS_ON_DATA_HEAP",A="MN:OPTf_GLBLS_ON_DATA_HEAP"$ without this option, global vars are placed in the code heap which is limited to 2Gig. In $FG,2$AOT$FG$ modules, global vars take-up room in the $FG,2$.BIN$FG$ file, so you might want to use this option, instead. You might wish to turn it on and off around specific vars. A disadvantage of data heap global vars in $FG,2$AOT$FG$ modules is they can't be initialized.
|
||||
|
||||
$LK,"OPTf_EXTERNS_TO_IMPORTS",A="MN:OPTf_EXTERNS_TO_IMPORTS"$ and $LK,"OPTf_KEEP_PRIVATE",A="MN:OPTf_KEEP_PRIVATE"$ are strange options, you'll never need. They're to allow the same header file for $FG,2$Kernel$FG$ to act as $FG,2$extern$FG$s when compiling itself and $FG,2$import$FG$s when compiled by $FG,2$AOT$FG$ modules.
|
||||
|
||||
|
||||
+7
-7
@@ -56,16 +56,16 @@ $LK,"MStrPrint",A="MN:MStrPrint"$(U8 *fmt,...) is like $LK,"StrPrint",A="MN:StrP
|
||||
|
||||
$LK,"CatPrint",A="MN:CatPrint"$(U8 *_dst,U8 *fmt,...) concatenates a formated string.
|
||||
|
||||
$LK,"Auto",A="MN:Auto"$(U8 *fmt,...) sends text to the current task's input buffer.
|
||||
$LK,"AutoStr",A="MN:AutoStr"$(U8 *fmt,...) sends text of an $LK,"AutoFile",A="FF:::/Doc/Glossary.DD,AutoFile"$ to the keyboard stream of the current TASK but can also do mouse cmds.
|
||||
$LK,"In",A="MN:In"$(U8 *fmt,...) sends text to the current task's input buffer.
|
||||
$LK,"InStr",A="MN:InStr"$(U8 *fmt,...) sends text of an $LK,"InFile",A="FF:::/Doc/Glossary.DD,InFile"$ to the keyboard stream of the current TASK but can also do mouse cmds.
|
||||
|
||||
$LK,"XTalk",A="MN:XTalk"$(CTask *task,U8 *fmt,...) and text to another task's input buffer.
|
||||
$LK,"XTalkStr",A="MN:XTalkStr"$(CTask *task,U8 *fmt,...) sends text of an $LK,"AutoFile",A="FF:::/Doc/Glossary.DD,AutoFile"$ to the keyboard stream of another TASK but can also do mouse cmds.
|
||||
$LK,"XTalkStr",A="MN:XTalkStr"$(CTask *task,U8 *fmt,...) sends text of an $LK,"InFile",A="FF:::/Doc/Glossary.DD,InFile"$ to the keyboard stream of another TASK but can also do mouse cmds.
|
||||
|
||||
$LK,"DocPrint",A="MN:DocPrint"$(CDoc *doc,U8 *fmt,...) sends text to a document. You can buffer to a Doc and save it, providing the functionality of $FG,2$fprintf$FG$. See $LK,"::/Demo/Dsk/FPrintF.HC"$.
|
||||
|
||||
$LK,"Adam",A="MN:Adam"$(U8 *fmt,...) sends text to the adam task to be compiled and run.
|
||||
$LK,"AdamLog",A="MN:AdamLog"$(U8 *fmt,...) and $LK,"AdamErr",A="MN:AdamErr"$(U8 *fmt,...) send text to the adam task to be displayed.
|
||||
$LK,"Adam",A="MN:Adam"$(U8 *fmt,...) sends text to the $LK,"Adam Task",A="FF:::/Doc/Glossary.DD,Adam Task"$ to be compiled and run.
|
||||
$LK,"AdamLog",A="MN:AdamLog"$(U8 *fmt,...) and $LK,"AdamErr",A="MN:AdamErr"$(U8 *fmt,...) send text to the $LK,"Adam Task",A="FF:::/Doc/Glossary.DD,Adam Task"$ to be displayed.
|
||||
|
||||
$LK,"StreamPrint",A="MN:StreamPrint"$(U8 *fmt,...) sends text to the stream of code being compiled and must reside in a $FG,2$#exe{}$FG$ blk.
|
||||
|
||||
@@ -75,9 +75,9 @@ $LK,"TextPrint",A="MN:TextPrint"$(CTask *task,I64 x,I64 y,I64 attr,U8 *fmt,...)
|
||||
|
||||
$LK,"ExePrint",A="MN:ExePrint"$(U8 *fmt,...) compiles and execute a string. Note: It returns the res of the last executed expression.
|
||||
|
||||
$LK,"AFPrint",A="MN:AFPrint"$(I64 ms,U8 *fmt,...) $LK,"PutChars",A="MN:PutChars"$()s one at a time with a delay.
|
||||
$LK,"InPrint",A="MN:InPrint"$(I64 ms,U8 *fmt,...) $LK,"PutChars",A="MN:PutChars"$()s one at a time with a delay.
|
||||
|
||||
$LK,"RawPrint",A="MN:RawPrint"$(I64 ms,U8 *fmt,...) sends direct to screen memory, bypassing window manager.
|
||||
$LK,"RawPrint",A="MN:RawPrint"$(I64 ms,U8 *fmt,...) sends direct to scrn memory, bypassing window manager.
|
||||
|
||||
$LK,"User",A="MN:User"$(U8 *fmt,...) Spawns a user and execute a string on start-up.
|
||||
|
||||
|
||||
+1
-1
@@ -1,4 +1,4 @@
|
||||
$WW,1$The profiler records where the CPU was executing when the $TX,"1000 Hz",D="DD_JIFFY_HZ"$ timer interrupt occured, so you can learn where time is spent.
|
||||
$WW,1$The profiler records where the CPU was executing when the $TX,"1000Hz",D="DD_JIFFY_HZ"$ timer interrupt occured, so you can learn where time is spent.
|
||||
|
||||
Use the $LK,"Prof",A="MN:Prof"$() depth argument to record a hit in the N routines which called the current routine, as well.
|
||||
|
||||
|
||||
+1
-1
@@ -10,7 +10,7 @@ $FG,5$Supported Hardware$FG$
|
||||
|
||||
* Most$FG$ keyboards and mice.
|
||||
|
||||
* Minimum $TX,"512 Meg",D="DD_MEM_MIN_MEG"$ RAM; Maximum $TX,"256 Gig",D="DD_MEM_MAPPED_SPACE_GIG"$ RAM ($LK,"easily increased",A="MN:MEM_MAPPED_SPACE"$).
|
||||
* Minimum $TX,"512Meg",D="DD_MEM_MIN_MEG"$ RAM; Maximum $TX,"256Gig",D="DD_MEM_MAPPED_SPACE_GIG"$ RAM ($LK,"easily increased",A="MN:MEM_MAPPED_SPACE"$).
|
||||
|
||||
* Internal PC Speakers.
|
||||
|
||||
|
||||
+72
-72
@@ -1,120 +1,120 @@
|
||||
$PURPLE$$TX+CX,"Scoping and Linkage"$$FG$
|
||||
$FG,5$$TX+CX,"Scoping and Linkage"$$FG$
|
||||
$WW,1$
|
||||
$LK,"JIT Compile Mode",A="FF:::/Doc/Glossary.DD,JIT Compile Mode"$ makes use of the current task's hash sym table and its parent tasks' tables. It fetches syms from parent tasks' tables if not found locally in the current task's table and it places new syms in the current task's table. Conceptually, syms are at the scope of environment vars in other operating systems.
|
||||
|
||||
When a sym is placed into a table, older syms with ident names will be overshadowed if they exist. Duplicates are not allowed in many cases, especially in asm blks. Dupicates are allowed, by design in other cases, so that you can repeatedly $GREEN$#include$FG$ the same file from the cmd line while developing it. Or, so you can repeatedly declare a function with a standard name, like $GREEN$DrawIt()$FG$. This case might occur when the $GREEN$adam task$FG$ is starting-up loading-in many little utilities.
|
||||
When a sym is placed into a table, older syms with ident names will be overshadowed if they exist. Duplicates are not allowed in many cases, especially in asm blks. Dupicates are allowed, by design in other cases, so that you can repeatedly $FG,2$#include$FG$ the same file from the cmd line while developing it. Or, so you can repeatedly declare a function with a standard name, like $FG,2$DrawIt()$FG$. This case might occur when the $LK,"Adam Task",A="FF:::/Doc/Glossary.DD,Adam Task"$$FG$ is starting-up loading-in many little utilities.
|
||||
|
||||
$GREEN$extern$FG$ binds a new $LK,"HTT_FUN",A="MN:HTT_FUN"$ or $LK,"HTT_GLBL_VAR",A="MN:HTT_GLBL_VAR"$ sym to an existing sym of the same name if it exists in the sym table (just in just-in-time code). It also can be used to generate a fwd reference.
|
||||
$FG,2$extern$FG$ binds a new $LK,"HTT_FUN",A="MN:HTT_FUN"$ or $LK,"HTT_GLBL_VAR",A="MN:HTT_GLBL_VAR"$ sym to an existing sym of the same name if it exists in the sym table (just in just-in-time code). It also can be used to generate a fwd reference.
|
||||
|
||||
$GREEN$import$FG$ binds a new $LK,"HTT_FUN",A="MN:HTT_FUN"$ or $LK,"HTT_GLBL_VAR",A="MN:HTT_GLBL_VAR"$ sym to a sym of the same name imported from the task's sym table at $LK,"Load",A="MN:Load"$() time. If no sym exists to bind to at $LK,"Load",A="MN:Load"$() time, the code using this sym will be left incomplete until the sym is defined.
|
||||
$FG,2$import$FG$ binds a new $LK,"HTT_FUN",A="MN:HTT_FUN"$ or $LK,"HTT_GLBL_VAR",A="MN:HTT_GLBL_VAR"$ sym to a sym of the same name imported from the task's sym table at $LK,"Load",A="MN:Load"$() time. If no sym exists to bind to at $LK,"Load",A="MN:Load"$() time, the code using this sym will be left incomplete until the sym is defined.
|
||||
|
||||
$WW,1$
|
||||
$GREEN$_extern$FG$ binds a new $LK,"HTT_FUN",A="MN:HTT_FUN"$ or $LK,"HTT_GLBL_VAR",A="MN:HTT_GLBL_VAR"$ sym to an existing sym, of a $BK,1$different$BK,0$ name. It must exists in the sym table. Basically, this binds C to asm.
|
||||
$FG,2$_extern$FG$ binds a new $LK,"HTT_FUN",A="MN:HTT_FUN"$ or $LK,"HTT_GLBL_VAR",A="MN:HTT_GLBL_VAR"$ sym to an existing sym, of a $BK,1$different$BK,0$ name. It must exists in the sym table. Basically, this binds C to asm.
|
||||
|
||||
$GREEN$_import$FG$ binds a new $LK,"HTT_FUN",A="MN:HTT_FUN"$ or $LK,"HTT_GLBL_VAR",A="MN:HTT_GLBL_VAR"$ sym to a sym, of a $BK,1$different$BK,0$ name imported from the task's sym table at $LK,"Load",A="MN:Load"$() time. If no sym exists to bind to at $LK,"Load",A="MN:Load"$() time, the code using this sym will be left incomplete until the sym is defined. Basically, this binds C to asm from elsewhere.
|
||||
$FG,2$_import$FG$ binds a new $LK,"HTT_FUN",A="MN:HTT_FUN"$ or $LK,"HTT_GLBL_VAR",A="MN:HTT_GLBL_VAR"$ sym to a sym, of a $BK,1$different$BK,0$ name imported from the task's sym table at $LK,"Load",A="MN:Load"$() time. If no sym exists to bind to at $LK,"Load",A="MN:Load"$() time, the code using this sym will be left incomplete until the sym is defined. Basically, this binds C to asm from elsewhere.
|
||||
|
||||
|
||||
$WW,0$$PURPLE$Ahead of Time Compilation$FG$
|
||||
$GREEN$G$FG$lobalScope/$GREEN$F$FG$unctionScope
|
||||
| $GREEN$C$FG$odeHeap/$GREEN$D$FG$ataHeap/$GREEN$S$FG$tack/$GREEN$R$FG$egister
|
||||
| | TaskHashEntry:Export$GREEN$S$FG$ysSym/$GREEN$D$FG$efine/$GREEN$F$FG$unction/$GREEN$C$FG$lass
|
||||
| | | UsageScope: $GREEN$M$FG$odule/$GREEN$A$FG$smLocal/Asm$GREEN$B$FG$lk/$GREEN$T$FG$askAndChildren/$GREEN$F$FG$unction
|
||||
| | | |UsageScope: $GREEN$G$FG$lbl/Asm$GREEN$L$FG$ocal/$GREEN$R$FG$emainder/$GREEN$g$FG$lblThisBlkAndRemainder
|
||||
| | | || $GREEN$S$FG$taticVarInit/$GREEN$D$FG$ynamicVarInitAllowed/$GREEN$N$FG$oInitAllowed
|
||||
$WW,0$$FG,5$Ahead of Time Compilation$FG$
|
||||
$FG,2$G$FG$lobalScope/$FG,2$F$FG$unctionScope
|
||||
| $FG,2$C$FG$odeHeap/$FG,2$D$FG$ataHeap/$FG,2$S$FG$tack/$FG,2$R$FG$egister
|
||||
| | TaskHashEntry:Export$FG,2$S$FG$ysSym/$FG,2$D$FG$efine/$FG,2$F$FG$unction/$FG,2$C$FG$lass
|
||||
| | | UsageScope: $FG,2$M$FG$odule/$FG,2$A$FG$smLocal/Asm$FG,2$B$FG$lk/$FG,2$T$FG$askAndChildren/$FG,2$F$FG$unction
|
||||
| | | |UsageScope: $FG,2$G$FG$lbl/Asm$FG,2$L$FG$ocal/$FG,2$R$FG$emainder/$FG,2$g$FG$lblThisBlkAndRemainder
|
||||
| | | || $FG,2$S$FG$taticVarInit/$FG,2$D$FG$ynamicVarInitAllowed/$FG,2$N$FG$oInitAllowed
|
||||
| | | || | Are dups allowed within the namespace? A dup overshadows the original.
|
||||
| | | || | $GREEN$D$FG$upsAllowed/$GREEN$N$FG$oDups/NoDupsBut$GREEN$P$FG$ad/$GREEN$W$FG$arningUnlessClosedOut
|
||||
| | | || | $FG,2$D$FG$upsAllowed/$FG,2$N$FG$oDups/NoDupsBut$FG,2$P$FG$ad/$FG,2$W$FG$arningUnlessClosedOut
|
||||
|
||||
asm export $GREEN$label::$FG$ G C S MG N
|
||||
asm $GREEN$label:$FG$ G C MG N
|
||||
asm local $GREEN$@@label:$FG$ G C AL N
|
||||
asm $GREEN$IMPORT label;$FG$ G C MR N
|
||||
asm export $GREEN$label::$FG$ F C S BG N
|
||||
asm $GREEN$label:$FG$ F C BG N
|
||||
asm local $GREEN$@@label:$FG$ F C AL N
|
||||
asm $GREEN$IMPORT label;$FG$ F C BR N
|
||||
C goto $GREEN$label:$FG$ F C FG N
|
||||
asm export $FG,2$label::$FG$ G C S MG N
|
||||
asm $FG,2$label:$FG$ G C MG N
|
||||
asm local $FG,2$@@label:$FG$ G C AL N
|
||||
asm $FG,2$IMPORT label;$FG$ G C MR N
|
||||
asm export $FG,2$label::$FG$ F C S BG N
|
||||
asm $FG,2$label:$FG$ F C BG N
|
||||
asm local $FG,2$@@label:$FG$ F C AL N
|
||||
asm $FG,2$IMPORT label;$FG$ F C BR N
|
||||
C goto $FG,2$label:$FG$ F C FG N
|
||||
|
||||
$GREEN$#define$FG$ x MR D
|
||||
$FG,2$#define$FG$ x MR D
|
||||
function G C S MR D
|
||||
var F R FR N
|
||||
var F S FR N
|
||||
$GREEN$static$FG$ var F C FR D N
|
||||
$FG,2$static$FG$ var F C FR D N
|
||||
var G C S MR D D
|
||||
var G D MR N D
|
||||
$GREEN$class$FG$ G MR D
|
||||
$FG,2$class$FG$ G MR D
|
||||
class member G MR P
|
||||
$GREEN$extern class$FG$ G MR D
|
||||
$GREEN$extern$FG$ function G C MR W
|
||||
$GREEN$import$FG$ function G C MR D
|
||||
$GREEN$import$FG$ var G C MR D
|
||||
$GREEN$_extern$FG$ function G C MR D
|
||||
$GREEN$_extern$FG$ var G C MR D
|
||||
$GREEN$_import$FG$ function G C MR D
|
||||
$GREEN$_import$FG$ var G C MR D
|
||||
$FG,2$extern class$FG$ G MR D
|
||||
$FG,2$extern$FG$ function G C MR W
|
||||
$FG,2$import$FG$ function G C MR D
|
||||
$FG,2$import$FG$ var G C MR D
|
||||
$FG,2$_extern$FG$ function G C MR D
|
||||
$FG,2$_extern$FG$ var G C MR D
|
||||
$FG,2$_import$FG$ function G C MR D
|
||||
$FG,2$_import$FG$ var G C MR D
|
||||
|
||||
|
||||
$PURPLE$Just in Time Compilation$FG$
|
||||
$GREEN$G$FG$lobalScope/$GREEN$F$FG$unctionScope
|
||||
| $GREEN$C$FG$odeHeap/$GREEN$D$FG$ataHeap/$GREEN$S$FG$tack/$GREEN$R$FG$egister
|
||||
| | TaskHashEntry:Export$GREEN$S$FG$ysSym/$GREEN$D$FG$efine/$GREEN$F$FG$unction/$GREEN$C$FG$lass
|
||||
| | | UsageScope: $GREEN$M$FG$odule/$GREEN$A$FG$smLocal/Asm$GREEN$B$FG$lk/$GREEN$T$FG$askAndChildren/$GREEN$F$FG$unction
|
||||
| | | |UsageScope: $GREEN$G$FG$lbl/Asm$GREEN$L$FG$ocal/$GREEN$R$FG$emainder/$GREEN$g$FG$lblThisBlkAndRemainder
|
||||
| | | || $GREEN$S$FG$taticVarInit/$GREEN$D$FG$ynamicVarInitAllowed/$GREEN$N$FG$oInitAllowed
|
||||
$FG,5$Just in Time Compilation$FG$
|
||||
$FG,2$G$FG$lobalScope/$FG,2$F$FG$unctionScope
|
||||
| $FG,2$C$FG$odeHeap/$FG,2$D$FG$ataHeap/$FG,2$S$FG$tack/$FG,2$R$FG$egister
|
||||
| | TaskHashEntry:Export$FG,2$S$FG$ysSym/$FG,2$D$FG$efine/$FG,2$F$FG$unction/$FG,2$C$FG$lass
|
||||
| | | UsageScope: $FG,2$M$FG$odule/$FG,2$A$FG$smLocal/Asm$FG,2$B$FG$lk/$FG,2$T$FG$askAndChildren/$FG,2$F$FG$unction
|
||||
| | | |UsageScope: $FG,2$G$FG$lbl/Asm$FG,2$L$FG$ocal/$FG,2$R$FG$emainder/$FG,2$g$FG$lblThisBlkAndRemainder
|
||||
| | | || $FG,2$S$FG$taticVarInit/$FG,2$D$FG$ynamicVarInitAllowed/$FG,2$N$FG$oInitAllowed
|
||||
| | | || | Are dups allowed within the namespace? A dup overshadows the original.
|
||||
| | | || | $GREEN$D$FG$upsAllowed/$GREEN$N$FG$oDups/NoDupsBut$GREEN$P$FG$ad/$GREEN$W$FG$arningUnlessClosedOut
|
||||
| | | || | $FG,2$D$FG$upsAllowed/$FG,2$N$FG$oDups/NoDupsBut$FG,2$P$FG$ad/$FG,2$W$FG$arningUnlessClosedOut
|
||||
|
||||
asm export $GREEN$label::$FG$ G C S Tg N
|
||||
asm $GREEN$label:$FG$ G C BG N
|
||||
asm local $GREEN$@@label:$FG$ G C AL N
|
||||
asm $GREEN$IMPORT label;$FG$ G C TR N
|
||||
asm export $GREEN$label::$FG$ F C BG N
|
||||
asm $GREEN$label:$FG$ F C BG N
|
||||
asm local $GREEN$@@label:$FG$ F C AL N
|
||||
asm $GREEN$IMPORT label;$FG$ F C BR N
|
||||
C goto $GREEN$label:$FG$ F C FG N
|
||||
asm export $FG,2$label::$FG$ G C S Tg N
|
||||
asm $FG,2$label:$FG$ G C BG N
|
||||
asm local $FG,2$@@label:$FG$ G C AL N
|
||||
asm $FG,2$IMPORT label;$FG$ G C TR N
|
||||
asm export $FG,2$label::$FG$ F C BG N
|
||||
asm $FG,2$label:$FG$ F C BG N
|
||||
asm local $FG,2$@@label:$FG$ F C AL N
|
||||
asm $FG,2$IMPORT label;$FG$ F C BR N
|
||||
C goto $FG,2$label:$FG$ F C FG N
|
||||
|
||||
$GREEN$#define$FG$ x D TR D
|
||||
$FG,2$#define$FG$ x D TR D
|
||||
function G C F TR D
|
||||
var F R FR N
|
||||
var F S FR N
|
||||
$GREEN$static$FG$ var F C FR D N
|
||||
$FG,2$static$FG$ var F C FR D N
|
||||
var G C G TR D D
|
||||
var G D G TR S D
|
||||
$GREEN$class$FG$ G C TR D
|
||||
$FG,2$class$FG$ G C TR D
|
||||
class member G TR P
|
||||
$GREEN$extern class$FG$ G C TR D
|
||||
$GREEN$extern$FG$ function G C F TR W
|
||||
$GREEN$extern$FG$ var G C G TR D
|
||||
$GREEN$extern$FG$ var G D G TR D
|
||||
$GREEN$_extern$FG$ function G C F TR D
|
||||
$GREEN$_extern$FG$ var G C G TR D
|
||||
$FG,2$extern class$FG$ G C TR D
|
||||
$FG,2$extern$FG$ function G C F TR W
|
||||
$FG,2$extern$FG$ var G C G TR D
|
||||
$FG,2$extern$FG$ var G D G TR D
|
||||
$FG,2$_extern$FG$ function G C F TR D
|
||||
$FG,2$_extern$FG$ var G C G TR D
|
||||
|
||||
$WW,1$
|
||||
* Goto labels must not have the same name as global scope objects. GoTo's are rare and I don't want to slow the compiler and add code to fix this. You will get errors if a collision happens, so it's not very dangerous, but the error message is baffling.
|
||||
|
||||
* The member names $GREEN$pad$FG$ and $GREEN$reserved$FG$ are special because multiple instances with the same name are allowed in a class.
|
||||
* The member names $FG,2$pad$FG$ and $FG,2$reserved$FG$ are special because multiple instances with the same name are allowed in a class.
|
||||
|
||||
* Use $GREEN$reg$FG$ or $GREEN$noreg$FG$ in front of local var names to override automatic reg var allocation. You can, optionally, specify a reg after the $GREEN$reg$FG$ keyword.
|
||||
* Use $FG,2$reg$FG$ or $FG,2$noreg$FG$ in front of local var names to override automatic reg var allocation. You can, optionally, specify a reg after the $FG,2$reg$FG$ keyword.
|
||||
|
||||
* Local non-reg function vars can be accessed in asm blks with $GREEN$&i[RBP]$FG$ for example.
|
||||
* Local non-reg function vars can be accessed in asm blks with $FG,2$&i[RBP]$FG$ for example.
|
||||
|
||||
* Glbl vars and functions can be accessed in asm with and $GREEN$&$FG$ as in
|
||||
$GREEN$MOV RAX,I64 [&glbl_var]
|
||||
* Glbl vars and functions can be accessed in asm with and $FG,2$&$FG$ as in
|
||||
$FG,2$MOV RAX,I64 [&glbl_var]
|
||||
CALL I32 &Fun
|
||||
CALL I32 &SYS_SYM$FG$
|
||||
|
||||
* In $GREEN$JIT$FG$ asm code, &SYS_SYM and &Fun don't need $GREEN$IMPORT$FG$.
|
||||
* In $FG,2$JIT$FG$ asm code, &SYS_SYM and &Fun don't need $FG,2$IMPORT$FG$.
|
||||
|
||||
* All offspring tasks of a task inherit syms.
|
||||
|
||||
* The $GREEN$sizeof()$FG$ and HolyC structure members can be used in asm blks.
|
||||
* The $FG,2$sizeof()$FG$ and HolyC structure members can be used in asm blks.
|
||||
|
||||
* Using $GREEN$&i$FG$ in $LK,"HolyC",A="FI:::/Doc/HolyC.DD"$ or $GREEN$i.u8[2]$FG$ on a local var, $GREEN$i$FG$, will force it to $GREEN$noreg$FG$.
|
||||
* Using $FG,2$&i$FG$ in $LK,"HolyC",A="FI:::/Doc/HolyC.DD"$ or $FG,2$i.u8[2]$FG$ on a local var, $FG,2$i$FG$, will force it to $FG,2$noreg$FG$.
|
||||
|
||||
* Using $GREEN$try$FG$/$GREEN$catch$FG$ in a function will force all local vars to $GREEN$noreg$FG$.
|
||||
* Using $FG,2$try$FG$/$FG,2$catch$FG$ in a function will force all local vars to $FG,2$noreg$FG$.
|
||||
|
||||
* An unused gap on the stk is left for $GREEN$reg$FG$ vars.
|
||||
* An unused gap on the stk is left for $FG,2$reg$FG$ vars.
|
||||
|
||||
* Note: $GREEN$static$FG$ function vars do not go on the data heap, no matter the setting of the $LK,"OPTf_GLBLS_ON_DATA_HEAP",A="MN:OPTf_GLBLS_ON_DATA_HEAP"$$FG$. They may in the future.
|
||||
* Note: $FG,2$static$FG$ function vars do not go on the data heap, no matter the setting of the $LK,"OPTf_GLBLS_ON_DATA_HEAP",A="MN:OPTf_GLBLS_ON_DATA_HEAP"$$FG$. They may in the future.
|
||||
|
||||
* $LK,"OPTf_EXTERNS_TO_IMPORTS",A="MN:OPTf_EXTERNS_TO_IMPORTS"$ will treat $GREEN$_extern$FG$ as $GREEN$_import$FG$ and $GREEN$extern$FG$ as $GREEN$import$FG$. This allows a header to be used either as a $GREEN$JIT compiled$FG$ or $GREEN$AOT compiled$FG$ header.
|
||||
* $LK,"OPTf_EXTERNS_TO_IMPORTS",A="MN:OPTf_EXTERNS_TO_IMPORTS"$ will treat $FG,2$_extern$FG$ as $FG,2$_import$FG$ and $FG,2$extern$FG$ as $FG,2$import$FG$. This allows a header to be used either as a $FG,2$JIT compiled$FG$ or $FG,2$AOT compiled$FG$ header.
|
||||
+1
-1
@@ -1,4 +1,4 @@
|
||||
$WW+H,1$$PURPLE$$TX+CX,"TempleOS V2.18",D="DD_OS_NAME_VERSION"$$FG$
|
||||
$WW+H,1$$FG,5$$TX+CX,"TempleOS V4.12",D="DD_OS_NAME_VERSION"$$FG$
|
||||
|
||||
$TX+CX,"Public Domain Operating System"$
|
||||
|
||||
|
||||
+1
-1
@@ -1 +1 @@
|
||||
$WW,1$There is one $LK,"CDoc",A="MN:CDoc"$ for the task's border: $GREEN$Fs->border_doc$FG$. There is a pair for the task's client area: $GREEN$Fs->put_doc$FG$ and $GREEN$Fs->display_doc$FG$. You can, optionally, do double buffering, otherwise $GREEN$Fs->put_doc$FG$ is the same as $GREEN$Fs->display_doc$FG$. See $LK,"::/Demo/Spy.HC"$.
|
||||
$WW,1$There is one $LK,"CDoc",A="MN:CDoc"$ for the task's border: $FG,2$Fs->border_doc$FG$. There is a pair for the task's client area: $FG,2$Fs->put_doc$FG$ and $FG,2$Fs->display_doc$FG$. You can, optionally, do double buffering, otherwise $FG,2$Fs->put_doc$FG$ is the same as $FG,2$Fs->display_doc$FG$. See $LK,"::/Demo/Spy.HC"$.
|
||||
@@ -45,7 +45,7 @@ God said He wants single audio voice for the sound. I think we want a word-size
|
||||
|
||||
The video will be a linear frame buffer 640x480 16 color with one-byte-per-pixel even though it is only 16 color with is 4-bit. Perhaps, we have a interrupt to sync with the refresh.
|
||||
|
||||
I am tempted to help amateur hardware device designers by making the hardware interface for the PC simple. I have fond memories of 1993, when I made a wire-wrapped ISA data acquisition card which plugged into my 486 and had some analog-to-digital and digital-to-analog convertors. I am not designing a bus. Earlier, I said the super-simple high speed serial port replacement could be USB-like in hardware as long as the software driver interface was simple like old school RS232 serial ports. Requiring a complicated hardware handshake raises the bar, slightly, for the lowest level hardware designers. Most people will be connecting a microcontroller or something that already has a serial communication design, but if it's not a problem, maybe we should keep it simple at all stages. It was nice putting an oscilloscope on my serial port wires.
|
||||
I am tmpted to help amateur hardware device designers by making the hardware interface for the PC simple. I have fond memories of 1993, when I made a wire-wrapped ISA data acquisition card which plugged into my 486 and had some analog-to-digital and digital-to-analog convertors. I am not designing a bus. Earlier, I said the super-simple high speed serial port replacement could be USB-like in hardware as long as the software driver interface was simple like old school RS232 serial ports. Requiring a complicated hardware handshake raises the bar, slightly, for the lowest level hardware designers. Most people will be connecting a microcontroller or something that already has a serial communication design, but if it's not a problem, maybe we should keep it simple at all stages. It was nice putting an oscilloscope on my serial port wires.
|
||||
|
||||
The original PC had general purpose digital IO through the parallel port. That was fun. I have enough battles to fight, so I'll leave being a savior to hobbiest hardware engineers to somebody else.
|
||||
|
||||
@@ -54,7 +54,7 @@ Digital cameras will be super-simple high speed serial, but TempleOS is forever
|
||||
|
||||
$FG,5$$TX+CX,"Version One"$$FG$
|
||||
|
||||
We will make a spec for a $$4,000, perfectly standardized, cryogenically-cooled, monster desktop PC. It will have 16 cores, integrated 4K graphics, and, hopefully, 6 Ghz continuous operation. Perhaps, 64 Gig of RAM will be standard? God said to help to poor buy them. It is pointless to have a high powered machine if other people have wimpy machines and cannot run programs you write. Therefore, everybody in the developed world will buy a Standard TempleOS IBM PC over the next ten years, so that will be a quantity of 400 million, perhaps. God said to pay the US national debt with the revenue. We will standardize everything, not just the TempleOS related items. The display will be 4K (and of course 640x480 16 color) and no others. Everybody gets just one monitor, unless you buy special PCI cards. Everybody gets two speakers, a headphone, a mic, a webcam and touch screen. We make the audio one sample rate and one sample size, but TempleOS still gets just a square wave. (HD Audio is really screwed-up and requires complicated artificial intelligence, just to route output to speakers.)
|
||||
We will make a spec for a $$4,000, perfectly standardized, cryogenically-cooled, monster desktop PC. It will have 16 cores, integrated 4K graphics, and, hopefully, 6 Ghz continuous operation. Perhaps, 64 Gig of RAM will be standard? God said to help to poor buy them. It is pointless to have a high powered machine if other people have wimpy machines and cannot run programs you write. Therefore, everybody in the developed world will buy a Standard TempleOS IBM PC over the next ten years, so that will be a quantity of 400 million, perhaps. God said to pay the US national debt with the revenue. We will standardize everything, not just the TempleOS related items. The display will be 4K (and of course 640x480 16 color) and no others. Everybody gets just one monitor, unless you buy special PCI cards. Everybody gets two speakers, a headphone, a mic, a webcam and touch scrn. We make the audio one sample rate and one sample size, but TempleOS still gets just a square wave. (HD Audio is really screwed-up and requires complicated artificial intelligence, just to route output to speakers.)
|
||||
|
||||
The Standard Temple IBM PC will be a full-sized tower. Perhaps, stain-glass will decorate the case because God is sentimentally attached to stained-glass. We should set the size at exactly 2.5 feet by 1.5 feet by 1.5 feet as in the $LK,"Exodus,25:10-10",A="BF:Exodus,25:10-10"$ for all time. If there is extra room, make a storage shelf for DVDs. We do not want a race-to-the-bottom, shrinking the size. Instead of making it smaller, make it more powerful. We want to remove all cost pressure from making things small. It must have a CD/DVD/Blu-ray drive. The vision is CD/DVDs used for a library of games, not installed on the hard-drive. We need a network connection, possibly implemented as a super-simple high speed serial device. What about standard monitor and speakers? The C64's success was partially due to wide spread, completely standard, hardware. I think TempleOS will not do bad block devices, so we need a hard drive, not just NV-memory or SSD.
|
||||
|
||||
@@ -81,6 +81,6 @@ $HC,"<object width=\"640\" height=\"520\"><param name=\"movie\" value=\"http://w
|
||||
|
||||
I thought 2.5' x 1.5' x 1.5' was ridiculously big, but it looks like it is reasonable for super-cooled refrigeration systems!
|
||||
$FG,8$
|
||||
* "Commodore 64" was a trademark owned by Commodore Business Machines.
|
||||
* "Commodore 64" is a trademark owned by Polabe Holding NV.
|
||||
* "Linux" is a trademark owned by Linus Torvalds.
|
||||
* "Windows" is a trademark owned by MicroSoft Corp.$FG$
|
||||
+3
-3
@@ -4,7 +4,7 @@ Everybody is obsessed, Jedi mind-tricked, by the notion that when you scale-up,
|
||||
|
||||
I limited it to 100,000 lines of code, forever! I never need a linker or make utility and I can use small labels.
|
||||
|
||||
People mock Bill Gates for, "640K should be enough." I say, "2 Gig for code should be enough." The same people who mock Bill Gates are probably just like the black woman who sued for a trillion dollars.
|
||||
People mock Bill Gates for, "640K should be enough." I say, "2Gig for code should be enough." The same people who mock Bill Gates are probably just like the black woman who sued for a trillion dollars.
|
||||
|
||||
My Dad worked on converting the Titan missile to the Gemini Mission rocket. It had to be "man-rated". You can bet that everything got an order of magnitude more complexity and documentation. My vision is a souped-up C64, not a 1970's mainframe; a kayak, not a Titanic.
|
||||
|
||||
@@ -32,7 +32,7 @@ A three button mouse is like a leg you cannot put weight on. TempleOS just does
|
||||
|
||||
* Least (greatest) common denominator hardware support. Mostly, one driver for each device class. I can't be in the business of different drivers. Compatibility is the greatest challenge for PC operating systems. Disk code does not use interrupts, avoiding compatibility risks. $FG,2$PS/2$FG$ keyboard/mouse is used instead of $FG,2$USB$FG$, also more compatible.
|
||||
|
||||
* $FG,2$640x480$FG$ 16 colors. Updates whole screen at $FG,2$30 fps$FG$, optimized for full screen games where $FG,2$InvalidRectangle$FG$s are counter-productive.
|
||||
* $FG,2$640x480$FG$ 16 colors. Updates whole scrn at $FG,2$30 fps$FG$, optimized for full scrn games where $FG,2$InvalidRectangle$FG$s are counter-productive.
|
||||
|
||||
* One font, 8x8. Text and graphic layers done in software with text normally on an 8x8 grid. It can run in Text mode if graphic initialization fails.
|
||||
|
||||
@@ -58,6 +58,6 @@ A three button mouse is like a leg you cannot put weight on. TempleOS just does
|
||||
|
||||
* All tasks have a heap and a sym table. Scope is that of environment vars in other operating systems. As text is typed at the command line or you run programs by $FG,2$#include$FG$ing them, the syms go in the table. If a sym is not found, the parent task's table is checked. The father of all tasks has the API syms you'll need waiting in it's table. No need to $FG,2$#include$FG$ headers.
|
||||
|
||||
* No need for namespaces -- scoping occurs automatically based on task symbol table hierarchy with the $FG,2$Adam task$FG$'s symbol system-wide global.
|
||||
* No need for namespaces -- scoping occurs automatically based on task symbol table hierarchy with the $LK,"Adam Task",A="FF:::/Doc/Glossary.DD,Adam Task"$$FG$'s symbol system-wide global.
|
||||
|
||||
* Sometimes, I $LK,"cut corners",A="FI:::/Doc/CutCorners.DD"$ in the interest of keeping the code beautiful.
|
||||
+1
-1
@@ -4,4 +4,4 @@ If you had a remote term and sent key $LK,"Scan Codes",A="MN:SC_INS"$, the user
|
||||
|
||||
See $LK,"Char Overview",A="FI:::/Doc/CharOverview.DD"$ and $LK,"Char Routines",A="HI:Char"$.
|
||||
|
||||
You can send characters into $FG,2$StdIn$FG$. See $LK,"Auto",A="MN:Auto"$(), $LK,"XTalk",A="MN:XTalk"$() and $LK,"AutoFile",A="HI:AutoFile"$.
|
||||
You can send characters into $FG,2$StdIn$FG$. See $LK,"In",A="MN:In"$(), $LK,"XTalk",A="MN:XTalk"$() and $LK,"InFile",A="HI:InFile"$.
|
||||
+1
-1
@@ -1,6 +1,6 @@
|
||||
$WW,1$$LK,"gr.text_base",A="MN:CGrGlbls"$ must be updated 30fps in your Fs->draw_it() callback. You probably want $LK,"GrPrint",A="MN:GrPrint"$() or just $LK,"Print",A="MN:Print"$(). The $LK,"DolDoc",A="FI:::/Doc/DolDocOverview.DD"$ code takes care of plotting text to $LK,"gr.text_base",A="MN:CGrGlbls"$.
|
||||
|
||||
Bits 0-7 8-Bit ASCII Screen Code
|
||||
Bits 0-7 8-Bit ASCII Scrn Code
|
||||
Bits 8-11 Foreground $LK,"color",A="MN:BLACK"$
|
||||
Bits 12-15 Background $LK,"color",A="MN:BLACK"$
|
||||
Bits 16-20 Signed X pos shift val
|
||||
|
||||
+6
-6
@@ -19,7 +19,7 @@ $FG,2$Merge(\"C:/*\",\"D:/*\",\"+r+d\");$FG$ to check my changes.
|
||||
|
||||
* You can use $FG,2$ans$FG$ in cmd line expressions. It holds the res the last cmd line operation. You can use the cmd prompt as a calculator by just entering expressions like $FG,2$1+2*3;$FG$. $FG,2$F64$FG$ ress can be accessed with $FG,2$ansf$FG$.
|
||||
|
||||
* Use the PullDown menu at the top of the screen to learn commands, or for finding the keyboard controls to games.
|
||||
* Use the PullDown menu at the top of the scrn to learn commands, or for finding the keyboard controls to games.
|
||||
|
||||
* You can adjust the mouse movement rate by setting global vars in your start-up file. See $LK,"mouse scale",A="FF:~/HomeLocalize.HC,mouse.scale"$.
|
||||
|
||||
@@ -29,7 +29,7 @@ $FG,2$Merge(\"C:/*\",\"D:/*\",\"+r+d\");$FG$ to check my changes.
|
||||
|
||||
* You can use $FG,2$filter_lines$FG$ in the editor text search form ($FG,2$<CTRL-f>$FG$) to temporarily display just lines near each match. A value of $FG,2$filter lines$FG$ set to $FG,2$5$FG$ will display lines within 5 lines of matches. Then, you can do another find to a different string and achieve a $FG,2$AND$FG$ search. When finished, press $FG,2$<ESC>$FG$.
|
||||
|
||||
* You can recompile and reinstall the kernel with $LK,"BootHDIns",A="MN:BootHDIns"$(). You'll probably want to make a function for recompiling that uses the $LK,"Auto",A="MN:Auto"$() function to answer the cfg questions. See my technique $LK,"Cfg Strs",A="FL:::/Demo/AcctExample/TOSCfg.HC,1"$, $LK,"Update Funs",A="FL:::/Demo/AcctExample/TOSDistro.HC,1"$.
|
||||
* You can recompile and reinstall the kernel with $LK,"BootHDIns",A="MN:BootHDIns"$(). You'll probably want to make a function for recompiling that uses the $LK,"In",A="MN:In"$() function to answer the cfg questions. See my technique $LK,"Cfg Strs",A="FL:::/Demo/AcctExample/TOSCfg.HC,1"$, $LK,"Update Funs",A="FL:::/Demo/AcctExample/TOSDistro.HC,1"$.
|
||||
|
||||
* $LK,"Scale2Mem",A="MN:Scale2Mem"$(min,max,limit=2*1024*1024*1024) can be used for cfg questions when recompiling. The $LK,"BootHDIns",A="MN:BootHDIns"$() cfg prompts accept expressions, not just numbers. The dft disk cache is $FG,2$Scale2Mem(0x80000,0x8000000)$FG$.
|
||||
|
||||
@@ -59,19 +59,19 @@ $FG,2$Merge(\"C:/*\",\"D:/*\",\"+r+d\");$FG$ to check my changes.
|
||||
|
||||
* Use $LK,"Plain",A="MN:Plain"$() to edit a plain text file. You'll need this if your file has $FG,2$$$$FG$'s. Use the $LK,"ToDolDoc",A="MN:ToDolDoc"$() utility to convert plain text to DolDoc's by doubling $FG,2$$$$FG$'s.
|
||||
|
||||
* Use $LK,"Silent",A="MN:Silent"$() to disable screen text output.
|
||||
* Use $LK,"Silent",A="MN:Silent"$() to disable scrn text output.
|
||||
|
||||
* Grab-scroll any window at any time with $FG,2${CTRL-LEFT-MOUSE-DRAG}$FG$. Null grab-scrolling with $FG,2${CTRL-RIGHT-MOUSE}$FG$.
|
||||
|
||||
* Use $FG,2$<CTRL-ALT-z>$FG$ to zoom-in and $FG,2$<CTRL-ALT-SHIFT-Z>$FG$ to zoom-out. You can scroll by moving to the edge of the window. Set $LK,"gr.continuous_scroll",A="MN:CGrGlbls"$ to $FG,2$TRUE$FG$ if you want.
|
||||
|
||||
* Use $FG,2$<CTRL-ALT-g>$FG$ and $FG,2$<CTRL-ALT-SHIFT-G>$FG$ to display a grid on the screen.
|
||||
* Use $FG,2$<CTRL-ALT-g>$FG$ and $FG,2$<CTRL-ALT-SHIFT-G>$FG$ to display a grid on the scrn.
|
||||
|
||||
* Use $FG,2$<CTRL-ALT-a>$FG$ to enter an extended ASCII char.
|
||||
|
||||
* Use $FG,2$<CTRL-ALT-f>$FG$ to toggle between $LK,"Std Font",A="FI:::/Kernel/FontStd.HC"$ and $LK,"Cyrillic Font",A="FI:::/Kernel/FontCyrillic.HC"$.
|
||||
|
||||
* Use $FG,2$<CTRL-ALT-s>$FG$ will capture the screen as a sprite on the clipboard. You can save the cmd line doc as text with $FG,2$<CTRL-a>$FG$.
|
||||
* Use $FG,2$<CTRL-ALT-s>$FG$ will capture the scrn as a sprite on the clipboard. You can save the cmd line doc as text with $FG,2$<CTRL-a>$FG$.
|
||||
|
||||
* You can save a sprite as a $FG,2$.BMP$FG$ file in $FG,2$<CTRL-r>$FG$ on the Sprite BitMap Menu.
|
||||
|
||||
@@ -131,7 +131,7 @@ $FG,2$Merge(\"C:/*\",\"D:/*\",\"+r+d\");$FG$ to check my changes.
|
||||
|
||||
* For advanced heap debugging, play with $LK,"_CFG_HEAP_DBG",A="MN:_CFG_HEAP_DBG"$. You're on your own.
|
||||
|
||||
* You can use $LK,"Type",A="MN:Type"$() to display $FG,2$.BMP$FG$ or $FG,2$.GRA$FG$ files.
|
||||
* You can use $LK,"Type",A="MN:Type"$() to display $FG,2$.BMP$FG$ or $FG,2$.GR$FG$ files.
|
||||
|
||||
* Use $LK,"Man",A="MN:Man"$() to jump to short sym name src code.
|
||||
|
||||
|
||||
+1
-1
@@ -1,5 +1,5 @@
|
||||
$WW,1$$FG,5$$TX+CX,"Upgrading TempleOS"$$FG$
|
||||
|
||||
To upgrade, you generally boot the new TempleOS CD/DVD, install on top of your drive, modify your files and set it to boot your account by executing $LK,"BootHDIns",A="MN:BootHDIns"$(). Often, your code will have to be modified to work with the new version. See $LK,"Change Log",A="FI:::/Doc/ChangeLog.DD"$. You might have to boot an alternate drive or the CD and modify your code until it boots okay.
|
||||
To upgrade, you generally boot the new TempleOS CD/DVD, install on top of your drive, modify your files and set it to boot your new $FG,2$/Kernel.BIN.C$FG$ by executing $LK,"BootHDIns",A="MN:BootHDIns"$(). Often, your code will have to be modified to work with the new version. See $LK,"Change Log",A="FI:::/Doc/ChangeLog.DD"$. You might have to boot an alternate drive or the CD and modify your code until it boots okay.
|
||||
|
||||
See the $LK,"Installing",A="FI:::/Doc/Install.DD"$ documentation.
|
||||
+5
-5
@@ -7,7 +7,7 @@ $ID,2$* Professionals doing hobby projects
|
||||
* Teenagers doing projects
|
||||
* Non-professional, older-persons projects
|
||||
$ID,-2$
|
||||
Simplicity is a goal to $LK,"keep the line count down",A="FI:::/Doc/Strategy.DD"$, so it's easy to tinker with. As it turns-out, simplicity makes it faster in some ways, too. It never switches privilege levels, never changes address maps, tends to load whole contiguous files and other, similar things which boost speed. It's only $TX,"81,125",D="DD_TEMPLEOS_LOC_OFFICIAL"$ lines of code including the kernel, the 64-bit compiler, the graphics library and all the tools. More importantly, it's designed to keep the user's line count down -- you can do a $LK,"Hello World",A="FI:::/Doc/HelloWorld.DD"$ application in one line of code and can put graphics on the screen with a three line program!
|
||||
Simplicity is a goal to $LK,"keep the line count down",A="FI:::/Doc/Strategy.DD"$, so it's easy to tinker with. As it turns-out, simplicity makes it faster in some ways, too. It never switches privilege levels, never changes address maps, tends to load whole contiguous files and other, similar things which boost speed. It's only $TX,"81,223",D="DD_TEMPLEOS_LOC_OFFICIAL"$ lines of code including the kernel, the 64-bit compiler, the graphics library and all the tools. More importantly, it's designed to keep the user's line count down -- you can do a $LK,"Hello World",A="FI:::/Doc/HelloWorld.DD"$ application in one line of code and can put graphics on the scrn with a three line program!
|
||||
|
||||
It's a kayak, not a Titanic -- it will crash if you do something wrong. You quickly reboot, however. DOS and the 8-bit home computers of the 80's worked fine without memory protection and most computers in the world -- the embedded ones -- operate without protection. The resulting simplicity of no protections is why TempleOS has value. In facts, that's the point of TempleOS. See the $LK,"TempleOS Charter",A="FI:::/Doc/Charter.DD"$.
|
||||
|
||||
@@ -81,9 +81,9 @@ TempleOS is geared toward reading and writing whole files. Since whole files ar
|
||||
|
||||
If a file is not found, "$FG,2$.Z$FG$" is added or removed and a search is done, again. There is no $FG,2$PATH$FG$, but parent directories are searched when a file is not found. This feature is especially useful for default account files.
|
||||
|
||||
The graphic resolution is poor, $FG,2$640x480 16 color$FG$, but God said it was a covenant like circumcision. Also, that's all I feel comfortable with without GPU acceleration supported. A $FG,2$1600x1200x24$FG$ bit screen takes 37 times more memory, implying 37 times the CPU power. Also, a fixed size keeps it simple with everybody machine having the same appearance. Look on the bright-side -- you won't spend as much time twiddling pixels for your game art and you'll have tons of CPU power available, especially with multicore systems.
|
||||
The graphic resolution is poor, $FG,2$640x480 16 color$FG$, but God said it was a covenant like circumcision. Also, that's all I feel comfortable with without GPU acceleration supported. A $FG,2$1600x1200x24$FG$ bit scrn takes 37 times more memory, implying 37 times the CPU power. Also, a fixed size keeps it simple with everybody machine having the same appearance. Look on the bright-side -- you won't spend as much time twiddling pixels for your game art and you'll have tons of CPU power available, especially with multicore systems.
|
||||
|
||||
TempleOS is for hobbyist programmers on single user (at a time) home computers, not mainframes or servers. The focus task is all-important so symmetrical multiprocessing is almost pointless. Why does it matter running two apps at the same time twice as fast when you really want to run one faster? You could say TempleOS does master/slave multiprocessing. The anticipated use for multicore is primarily putting graphics on the screen. Hardware graphics acceleration is not used, so this is possible. See $LK,"TempleOS MultiCore",A="FI:::/Doc/MultiCore.DD"$.
|
||||
TempleOS is for hobbyist programmers on single user (at a time) home computers, not mainframes or servers. The focus task is all-important so symmetrical multiprocessing is almost pointless. Why does it matter running two apps at the same time twice as fast when you really want to run one faster? You could say TempleOS does master/slave multiprocessing. The anticipated use for multicore is primarily putting graphics on the scrn. Hardware graphics acceleration is not used, so this is possible. See $LK,"TempleOS MultiCore",A="FI:::/Doc/MultiCore.DD"$.
|
||||
|
||||
There is no distinction between the terms $FG,2$task$FG$, $FG,2$process$FG$ or $FG,2$thread$FG$. All have a task record, $LK,"CTask",A="MN:CTask"$, pointed to by the $FG,2$FS$FG$ segment reg and are accessed with $FG,4$Fs->$FG$ while $FG,4$Gs->$FG$ points to a $LK,"CCPU",A="MN:CCPU"$ for the current CPU core. Each task can have just one window, but a task can have children with windows. (The segment regs are just used as extra regs -- there is nothing segmented about TempleOS' memory.) It is approximately the case that $FG,2$TempleOS$FG$ is multi-threading, single-processing.
|
||||
|
||||
@@ -124,12 +124,12 @@ Ideally, do not install applications such as games onto your hard drive because
|
||||
|
||||
Create a $LK,"RedSea",A="FI:::/Doc/RedSea.DD"$ ISO file with $LK,"RedSeaISO",A="MN:RedSeaISO"$(). Send an email to $TX,"tdavis@templeos.org",HTML="mailto:tdavis@templeos.org"$ if you want me to post a link to your TempleOS code in the App Store.
|
||||
|
||||
$MA-X+PU,"Take Tour",LM="User(\"Cd(\\\"::/Misc/Tour\\\");;AutoFile(\\\"Tour\\\");\n\");"$
|
||||
$MA-X+PU,"Take Tour",LM="User(\"Cd(\\\"::/Misc/Tour\\\");;InFile(\\\"Tour\\\");\n\");"$
|
||||
|
||||
$FG,8$
|
||||
* "Linux" is a trademark owned by Linus Torvalds.
|
||||
* "Windows" is a trademark owned by MicroSoft Corp.
|
||||
* "Commodore 64" was a trademark owned by Commodore Business Machines.
|
||||
* "Commodore 64" is a trademark owned by Polabe Holding NV.
|
||||
* "QEMU" is a trademark owned by Fabrice Bellard.
|
||||
* "VMware" is a trademark owned by VMware, Inc.
|
||||
* "VirtualBox" is a trademark owned by Oracle.
|
||||
|
||||
@@ -0,0 +1,32 @@
|
||||
$WW,1$$FG,5$$TX+CX,"Why Not More?"$$FG$
|
||||
|
||||
If a feature cannot be made to work correctly and consistently, professional companies usually remove the feature. Because PC hardware is so diverse, getting things to work on all people's computers is really difficult. For one thing, you practically have to own all the different hardware to write drivers for it. If a company wanted to sell a PC operating system, they would offer a warranty and, therefore, could not get away with amateur behavior. TempleOS absolutely requires 64-bit computers, so we leave behind much trouble, but plenty remains.
|
||||
|
||||
The PCI bus interface is what modern hardware uses. Before PCI, life was simple and devices used I/O ports. After studying $LK,"PCI Interrupts",A="FI:::/Demo/Lectures/PCIInterrupts.HC"$ and attempting to do a HDAudio driver, I came to realize that modern PCI devices require ten times more code and I cannot even come close to making them work on everyone's machine because with PCI devices there are several models to worry about, unlike with the older ISA bus devices which can be done with one driver.
|
||||
|
||||
Currently, I have no PCI drivers. My drivers use I/O ports and operate in ISA bus mode. At this point, I only have one driver for each type of device and it is delightfully simple that way. I have one $LK,"keyboard",A="FI:::/Kernel/SerialDev/Keyboard.HC"$ driver, one $LK,"mouse",A="FI:::/Kernel/SerialDev/Mouse.HC"$ driver, one $LK,"ATA hard drive",A="FI:::/Kernel/BlkDev/DskATA.HC"$ driver, one $LK,"ATAPI CD/DVD",A="FI:::/Kernel/BlkDev/DskATA.HC"$ driver, one $LK,"VGA 640x480 16 color",A="FI:::/Adam/Gr/GrScrn.HC"$ video driver and one $LK,"PC Speaker",A="MN:Snd"$ driver. I use the $LK,"PIT and HPET timers",A="MN:TimersInit"$ and $LK,"PIC Interrupt Controller",A="MN:IntsInit"$. I use IRQ0 for timer, IRQ1 for keyboard, and IRQ12 for mouse. If IRQ12 is not firing, I am able to poll the mouse.
|
||||
|
||||
In the CPU department, I have state of the art 64-bit $LK,"long mode",A="FI:::/Kernel/KStart64.HC"$ with $LK,"multicore",A="FI:::/Kernel/MultiProc.HC"$ support. I use the $LK,"APIC",A="MN:MPAPICInit"$ and start-up $LK,"multicore",A="MN:Core0StartMP"$ operation.
|
||||
|
||||
I have made an incredible accomplishment by getting it to work on practically everyone's computer as long as it is 64-bit and they run inside VMware, QEMU or VirtualBox.
|
||||
|
||||
Adding a USB driver would be really ugly with UHCI, EHCI, OHCI, USB1, USB2, USB3, ICH6, ICH7, ICH8, ICH9, ICH10, ICH11, ICH12, boot mode and regular mode for keyboard/mouse and a diversity of HID reports. It's hopeless. I could never offer anything but crappy, limited support and it would just add a ton of crappy code that mostly didn't work. What would I gain? Nothing. A keyboard or mouse would not be improved. Solid State USB drives would be really nice, but it's not going to happen.
|
||||
|
||||
The same story is basically true for GPUs, audio, networking and AHCI hard drive drivers. God said 640x480 16 color was a covenant like circumcision, so the video will never change, even if a $LK,"Standard PC",A="FI:::/Doc/StdTempleOSPC.DD"$ was made. If you attempt multimedia, everything will break because memory will get fragmented with huge multimedia files. Some day, if super-simple high speed serial allows networking, there will be no browser within the 100,000 line limit and, with only 16 colors, the world wide web is not tolerable. FTP and telnet might be possible, in the far distant future, if they could fit within the 100,000 line limit. Currently, there are $TX,"81,223",D="DD_TEMPLEOS_LOC_OFFICIAL"$ lines of code.
|
||||
|
||||
I don't stand a chance working on native hardware, anymore. I could install and run natively on hardware from about 2005-2010. It requires BIOS's being nice enough to write USB mode PS/2 legacy keyboard/mouse support. As it turns-out, sometimes the BIOS has PS/2 drivers but purposely disables them, just to be mean. The CIA and whole industry is trying to mess everything up, on purpose. Perhaps, at a point of sale in a store, a thief could hack a credit card machine. Therefore, the BIOS companies actually want it difficult to make drivers and purposely make it broken.
|
||||
|
||||
The ATA/ATAPI hard drives often can be run with I/O ports if you can $LK,"find them",A="FI:::/Kernel/BlkDev/DskATAId.HC"$. $FG,2$lspci -v$FG$ on Linux or system information on Windows can help you locate the SATA IO ports the hard drive and CD/DVD have. They no longer are enabled by the BIOS. It's hopeless. I'm stuck with very slow drive performance, but it works for everybody.
|
||||
|
||||
UEFI is pointless. If I am forced to run in VMware, QEMU or VirtualBox, they will always support non-UEFI mode. Without working, native hard drive and CD/DVD drivers, you can't get very far with UEFI on a native install, not to mention SecureBoot. UEFI is, first of all, redundant. If non-UEFI works in a virtual machine, supporting UEFI would only be redundant, ugly nasty code. My compiler does not create an ELF or PE format. I would have to ruin the beauty of my compiler, which would make me cry many tears.
|
||||
|
||||
God talks. It seems reasonable that I will get to make the rules for the whole industry, in the future when God is announced publically to the World.
|
||||
|
||||
I made $LK,"::/Doc/Demands.DD"$.
|
||||
|
||||
When the PC was created, they wanted flexibility because they did not know the future. Now, the industry is mature and it is time to make a 100% standard PC that everybody uses. $LK,"::/Doc/StdTempleOSPC.DD"$
|
||||
|
||||
$FG,8$
|
||||
* "QEMU" is a trademark owned by Fabrice Bellard.
|
||||
* "VMware" is a trademark owned by VMware, Inc.
|
||||
* "VirtualBox" is a trademark owned by Oracle.
|
||||
+2
-2
@@ -4,10 +4,10 @@ $LK,"DolDoc",A="::/Doc/DolDocOverview.DD"$ is a TempleOS document type.
|
||||
|
||||
$FG,2$"Expression"$FG$ a num or HolyC algebraic term with operators and HolyC syms can be entered.
|
||||
$FG,2$"Macro"$FG$ Most entries can behave like macro entries if you assign them macro strs.
|
||||
$FG,2$"AutoStr"$FG$ Like a macro except it is an $LK,"AutoFile",A="FF:::/Doc/Glossary.DD,AutoFile"$. You can't have both an autostr and macro text defined.
|
||||
$FG,2$"InStr"$FG$ Like a macro except it is an $LK,"InFile",A="FF:::/Doc/Glossary.DD,InFile"$. You can't have both an in_str and macro text defined.
|
||||
|
||||
$FG,5$Tag Text$FG$ is the text that will be displayed for the item. For links, you can leave it blank and the details of the link will be shown.
|
||||
$FG,5$Hide$FG$ means display nothing, making an entry invisible.
|
||||
$FG,5$Hide$FG$ means display nothing, making an entry invis.
|
||||
|
||||
$FG,5$Left X$FG$ relative to the left margin.
|
||||
$FG,5$Center X$FG$ relative to the horizontal center of the window.
|
||||
|
||||
+1
-1
@@ -1 +1 @@
|
||||
$WW,1$Only tasks on $FG,2$core0$FG$ can have a window and there can be only one window per task. The window Z-buffer, top-to-bottom order is determined by the order in the task queue, with the $FG,2$WinMgr$FG$ on the bottom. A task can have child task popup windows.
|
||||
$WW,1$Only tasks on $FG,2$Core0$FG$ can have a window and there can be only one window per task. The window Z-buffer, top-to-bottom order is determined by the order in the task queue, with the $FG,2$WinMgr$FG$ on the bottom. A task can have child task popup windows.
|
||||
Reference in new issue
Block a user