TempleOS V5.03 Nightly (ISO SHA-1 aed1efc)
This commit is contained in:
Terry A. Davis authored and minexew committed
1 parent
bbd014d8e9
commit
da84afbaf7
124 files changed
+3453
-3407
No files matched your search
+1
-1
@@ -39,7 +39,7 @@ $FG,2$LIST$FG$, $FG,2$NOLIST$FG$
|
||||
$FG,2$ALIGN$FG$ $FG,4$num$FG$, $FG,4$fill_byte$FG$
|
||||
Align to $FG,4$num$FG$ boundary and fill with $FG,4$fill_byte$FG$.
|
||||
|
||||
$FG,2$MODULE_ORG$FG$ $FG,4$num$FG$
|
||||
$FG,2$ORG$FG$ $FG,4$num$FG$
|
||||
Set code addr for JIT or set module $LK,"Load",A="MN:Load"$() addr -- has 16-byte $LK,"CBinFile",A="MN:CBinFile"$ header and patch table trailing.
|
||||
|
||||
$FG,2$BINFILE$FG,4$ "FileName.BIN"$FG$;
|
||||
|
||||
BIN
Binary file not shown.
+6
-4
@@ -19,7 +19,7 @@ $ID,-5$
|
||||
|
||||
* TempleOS is God's official temple. Just like Solomon's temple, this is a community focal point where offerings are made and God's oracle is consulted.
|
||||
|
||||
* God said $FG,2$640x480 16 color$FG$ graphics is a covenant like circumcision. Children will do offerings. Think of 16 colors like the Simpson's cartoons. In the future, even if one GPU were universal, we would keep 640x480 16 color and not use GPU acceleration. Graphics operations should be transparent, not hidden in a GPU.
|
||||
* God said $FG,2$640x480 16 color$FG$ graphics is a covenant like circumcision. Children will do offerings. Think of 16 colors like the Simpson's cartoons. In the future, even if one GPU were universal, we would still keep 640x480 16 color and not use GPU acceleration. Graphics operations should be transparent, not hidden in a GPU.
|
||||
|
||||
* God said to use a single-voice 8-bit signed MIDI-like sample for sound. God does not want death screams, perhaps, because God has PTSD or soldiers have PTSD. (Imagine wounded on battlefields.)
|
||||
|
||||
@@ -31,15 +31,17 @@ $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,"81,390",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,494",D="DD_TEMPLEOS_LOC"$ 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.
|
||||
|
||||
* The metric for resolving all TempleOS code governance issues is how fast the compiler compiles itself and the kernel with $LK,"BootHDIns",A="MN:BootHDIns"$(). The $LK,"HolyC",A="FI:::/Doc/HolyC.DD"$ language should be changed to optimize this metric, as I did when I changed type casting from prefix standard C to postfix $LK,"HolyC",A="FI:::/Doc/HolyC.DD"$, but we need a rule to prevent degenerating into a brainfuck language.
|
||||
|
||||
* 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.
|
||||
|
||||
* One platform. $FG,4$$TX,"x86_64",HTML="http://en.wikipedia.org/wiki/Amd64#AMD64"$$FG$ PC compatibles. Desk-tops are all we design for, but laptops can tag along.
|
||||
* It is for one platformc -- $FG,4$$TX,"x86_64",HTML="http://en.wikipedia.org/wiki/Amd64#AMD64"$$FG$ desktop PC compatibles, more like super-computers than battery efficient wimpy mobiles.
|
||||
|
||||
* All hardware access will be done through x86 IN/OUT instructions, not PCI drivers. A frame buffer for VGA is an exception.
|
||||
|
||||
* One driver for each class of device. Limited exceptions are allowed. With divergent device capabilities, it is a nightmare for user applications and what is gained? A three bttn mouse is like a leg you cannot put weight on.
|
||||
* One driver for each class of device. Limited exceptions are allowed. With divergent device capabilities, it is a nightmare for user applications and what is gained? A three buuton mouse is like a leg you cannot put weight on.
|
||||
|
||||
* $FG,2$Ring-0-only$FG$. Everything runs in kernel mode, including user applications.
|
||||
|
||||
|
||||
+1
-3
@@ -1,6 +1,6 @@
|
||||
$WW,1$$FG,5$$TX+CX,"Credits"$$FG$
|
||||
|
||||
I, $FG,2$Terry A. Davis$FG$, wrote all $TX,"119,241",D="DD_TEMPLEOS_LOC"$ lines of TempleOS over the past $TX,"13.4",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 of TempleOS over the past $TX,"13.8",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.
|
||||
|
||||
@@ -24,8 +24,6 @@ I, $FG,2$Terry A. Davis$FG$, wrote all $TX,"119,241",D="DD_TEMPLEOS_LOC"$ lines
|
||||
|
||||
*) Thanks to whoever wrote this $FG,4$$TX,"CppHtml.HC.Z",HTML="http://web.archive.org/web/20100325153025/http://home.scarlet.be/zoetrope/cpphtml.htm"$$FG$. I'm a novice on web stuff and you helped me with html. See $LK,"::/Demo/ToHtmlToTXTDemo/ToHtml.HC"$.
|
||||
|
||||
*) I used $FG,4$$TX,"MagicISO",HTML="http://www.magiciso.com"$$FG$ to burn test CD's to help me understand the ISO9660 file system format. I mostly used the $FG,4$$TX,"ISO9660",HTML="http://users.telenet.be/it3.consultants.bvba/handouts/ISO9960.html"$$FG$ spec.
|
||||
|
||||
*) I looked at bootable CD boot sects, but didn't learn anything, finding it easier to make my own.
|
||||
|
||||
*) I think I got my original PC speaker code from $FG,2$Borland C$FG$.
|
||||
|
||||
+1
-3
@@ -4,13 +4,11 @@ I, Terry Davis, am high priest of God's $FG,4$$TX,"official third temple",HTML="
|
||||
|
||||
$HC,"<object width=\"640\" height=\"520\"><param name=\"movie\" value=\"http://www.youtube.com/v/RvL7T4gIJN8\"></param><param name=\"allowscriptaccess\" value=\"always\"></param><embed src=\"http://www.youtube.com/v/RvL7T4gIJN8\" type=\"application/x-shockwave-flash\" allowscriptaccess=\"always\" width=\"640\" height=\"520\"></embed></object>"$
|
||||
|
||||
* Windows, Linux and VMware (because of mounted drives) must support $LK,"RedSea",A="FI:::/Doc/RedSea.DD"$ file system so I can get rid of 2,000 lines of redundant, blemished code -- FAT32 and ISO9660. God's temple must be perfect. Redundant code for multiple file systems is imperfect. For this operating system, we want low line count. More than one file system type is actually bad, just as more than one driver for the same type of device is bad.
|
||||
* Windows, Linux and VMware (because of mounted drives) must support $LK,"RedSea",A="FI:::/Doc/RedSea.DD"$ file system so I can get rid of 1,000 lines of redundant, blemished code -- FAT32. God's temple must be perfect. Redundant code for multiple file systems is imperfect. For this operating system, we want low line count. More than one file system type is actually bad, just as more than one driver for the same type of device is bad.
|
||||
|
||||
See $LK,"::/Kernel/BlkDev/FileSysRedSea.HC"$ and $LK,"::/Adam/Opt/Boot/DskISORedSea.HC"$.
|
||||
|
||||
$LK,"::/Kernel/BlkDev/FileSysFAT.HC"$ :974 lines for FAT32 gets eliminated.
|
||||
$LK,"::/Kernel/BlkDev/FileSysISO.HC"$ :233 lines for ISO9660 gets eliminated.
|
||||
$LK,"::/Adam/Opt/Boot/DskISO9660.HC"$ :507 lines for making ISO files.
|
||||
$LK,"::/Kernel/BlkDev/DskClus.HC"$ :152 All the clus operations become blk.
|
||||
|
||||
* Microsoft must cancel SecureBoot because it makes dual booting impossible. TempleOS is an additional operating system that must be used along-side Windows or Linux, not as a replacement. It must dual boot because it has no networking. Real hardware as opposed to VMware is like the difference between looking in a telescope eye piece vs just looking at an off-line image. God said the C64/Apple II generation owned ancestral lands. VMware is like being taken off of our land and moved onto a reservation. In this case, however, it will not stand.
|
||||
|
||||
@@ -123,7 +123,7 @@ Examples: <CTRL-t> to see
|
||||
$ID,-2$$TR,"BT Bttn"$
|
||||
$ID,2$See $LK,"::/Demo/DolDoc/MenuBttn.HC"$.
|
||||
$ID,-2$$TR,"DA Data"$
|
||||
$ID,2$Used for forms that prompt for data or just displaying a value. Use $FG,2$<CTRL-l>$FG$ to help you generate the DolDoc command text you need in your $LK,"HolyC",A="FI:::/Doc/HolyC.DD"$ $FG,2$class$FG$ member's $FG,2$fmtstr$FG$ meta-data for $LK,"DocForm",A="MN:DocForm"$(). See $LK,"::/Demo/DolDoc/Form.HC"$, $LK,"::/Demo/Dsk/DataBase.HC"$, and $LK,"::/Adam/DolDoc/DocWidgetWiz.HC"$.
|
||||
$ID,2$Used for forms that prompt for data or just displaying a value. Use $FG,2$<CTRL-l>$FG$ to help you generate the DolDoc command text you need in your $LK,"HolyC",A="FI:::/Doc/HolyC.DD"$ $FG,2$class$FG$ member's $FG,2$format$FG$ meta-data for $LK,"DocForm",A="MN:DocForm"$(). See $LK,"::/Demo/DolDoc/Form.HC"$, $LK,"::/Demo/Dsk/DataBase.HC"$, and $LK,"::/Adam/DolDoc/DocWidgetWiz.HC"$.
|
||||
|
||||
If you are not using $LK,"DocForm",A="MN:DocForm"$(), make a $FG,2$$$DA...$$$FG$ statement with $LK,"DocPrint",A="MN:DocPrint"$() and fill-in the $FG,2$->data$FG$ addr. See $LK,"task_title",A="FF:::/Adam/DolDoc/DocEd.HC,&Fs->task_title"$.
|
||||
|
||||
@@ -135,13 +135,13 @@ The default field length is $FG,2$LEN=64$FG$ characters. For U8 arrays[], $LK,"
|
||||
|
||||
The space after the first ':' in the format string marks the first valid cursor pos. See $LK,"Data Tag Width",A="FA:::/Adam/DolDoc/DocPlain.HC,DataTagWidth"$.
|
||||
$ID,-2$$TR,"CB Check Box"$
|
||||
$ID,2$Used for forms. Use $FG,2$<CTRL-l>$FG$ to help you generate the DolDoc command text you need in your $LK,"HolyC",A="FI:::/Doc/HolyC.DD"$ $FG,2$class$FG$ member's $FG,2$fmtstr$FG$ meta-data for $LK,"DocForm",A="MN:DocForm"$(). See $LK,"::/Demo/DolDoc/Form.HC"$$FG$ and $LK,"CEdFindText",A="MN:CEdFindText"$.
|
||||
$ID,2$Used for forms. Use $FG,2$<CTRL-l>$FG$ to help you generate the DolDoc command text you need in your $LK,"HolyC",A="FI:::/Doc/HolyC.DD"$ $FG,2$class$FG$ member's $FG,2$format$FG$ meta-data for $LK,"DocForm",A="MN:DocForm"$(). See $LK,"::/Demo/DolDoc/Form.HC"$$FG$ and $LK,"CEdFindText",A="MN:CEdFindText"$.
|
||||
|
||||
If you are not using $LK,"DocForm",A="MN:DocForm"$(), make a $FG,2$$$CB...$$$FG$ statement with $LK,"DocPrint",A="MN:DocPrint"$() and fill-in the $FG,2$->data$FG$ addr. See $LK,"task_title",A="FF:::/Adam/DolDoc/DocEd.HC,&Fs->task_title"$.
|
||||
|
||||
The default raw data type for the $FG,2$$$CB...$$$FG$ command is $FG,2$RT=I8$FG$ which is $FG,2$Bool$FG$. $LK,"DocForm",A="MN:DocForm"$() will automatically reset the raw type to the value from the $LK,"HolyC",A="FI:::/Doc/HolyC.DD"$ $FG,2$class$FG$ member's definition if you leave it set to the default. Or, if not using $LK,"DocForm",A="MN:DocForm"$(), specify a raw data type of $FG,2$I8$FG$, $FG,2$U8$FG$, $FG,2$I16$FG$, $FG,2$U16$FG$, $FG,2$I32$FG$, $FG,2$U32$FG$, $FG,2$I64$FG$, $FG,2$U64$FG$, or $FG,2$F64$FG$. See $LK,"DocDataFmt",A="MN:DocDataFmt"$() and $LK,"DocDataScan",A="MN:DocDataScan"$().
|
||||
$ID,-2$$TR,"LS List Widget"$
|
||||
$ID,2$Used for forms that prompt for data. You must specify a define list, $FG,2$D=""$FG$. Use $FG,2$<CTRL-l>$FG$ to help you generate the DolDoc command text you need in your $LK,"HolyC",A="FI:::/Doc/HolyC.DD"$ $FG,2$class$FG$ member's $FG,2$fmtstr$FG$ meta-data for $LK,"DocForm",A="MN:DocForm"$(). See $LK,"::/Demo/DolDoc/Form.HC"$.
|
||||
$ID,2$Used for forms that prompt for data. You must specify a define list, $FG,2$D=""$FG$. Use $FG,2$<CTRL-l>$FG$ to help you generate the DolDoc command text you need in your $LK,"HolyC",A="FI:::/Doc/HolyC.DD"$ $FG,2$class$FG$ member's $FG,2$format$FG$ meta-data for $LK,"DocForm",A="MN:DocForm"$(). See $LK,"::/Demo/DolDoc/Form.HC"$.
|
||||
|
||||
If you are not using $LK,"DocForm",A="MN:DocForm"$(), make a $FG,2$$$LS...$$$FG$ statement with $LK,"DocPrint",A="MN:DocPrint"$() and fill-in the data addr. See $LK,"task_title",A="FF:::/Adam/DolDoc/DocEd.HC,&Fs->task_title"$.
|
||||
|
||||
|
||||
+2
-2
@@ -1,7 +1,7 @@
|
||||
$WW,1$$FG,5$$TX+CX,"Frequently Asked Questions"$$FG$
|
||||
|
||||
$TR,"How come it is public domain, not GPL?"$
|
||||
$ID,2$I, $FG,2$Terry A. Davis$FG$, wrote all $TX,"118,851",D="DD_TEMPLEOS_LOC"$ lines of TempleOS over the past $TX,"12.5",D="DD_TEMPLEOS_AGE"$ years (full-time). It can run on some bare metal 64-bit PC's from about 2005-2010 with no layering, libraries, tools, modules or anything from other sources. Otherwise, you run it in a virtual machine, like $FG,2$VMware$FG$, $FG,2$QEMU$FG$ or $FG,2$VirtualBox$FG$. It is independent and stands alone. It has no networking, so it certainly doesn't call home. 100% of the src code is including on all distro's, from the kernel to the compiler to the boot loaders! See $LK,"::/Doc/Credits.DD"$.
|
||||
$ID,2$I, $FG,2$Terry A. Davis$FG$, wrote all of TempleOS over the past $TX,"13.8",D="DD_TEMPLEOS_AGE"$ years (full-time). It can run on some bare metal 64-bit PC's from about 2005-2010 with no layering, libraries, tools, modules or anything from other sources. Otherwise, you run it in a virtual machine, like $FG,2$VMware$FG$, $FG,2$QEMU$FG$ or $FG,2$VirtualBox$FG$. It is independent and stands alone. It has no networking, so it certainly doesn't call home. 100% of the src code is including on all distro's, from the kernel to the compiler to the boot loaders! See $LK,"::/Doc/Credits.DD"$.
|
||||
$ID,-2$$TR,"Shouldn't it be GNU/TempleOS?"$
|
||||
$ID,2$TempleOS executes no code not written by me at any time except for a few $FG,2$BIOS$FG$ calls for configuration. I even wrote boot-loaders, so I do not need Grub. See $LK,"::/Doc/Credits.DD"$.
|
||||
$ID,-2$$TR,"Don't you use GNU's gcc?"$
|
||||
@@ -35,7 +35,7 @@ $ID,2$TempleOS is 100% open src. All the src code is included in the distro. U
|
||||
$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, $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 scrn mem. It is not syncronized to the hardware.
|
||||
$ID,2$The refresh rate is $TX,"(30000.0/1001)",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?"$
|
||||
|
||||
+1
-1
@@ -18,7 +18,7 @@
|
||||
|
||||
* ATA PIO Hard drives, support for $FG,2$FAT32$FG$ and $LK,"RedSea",A="FI:::/Doc/RedSea.DD"$ file systems with file compression.
|
||||
|
||||
* ATAPI PIO $FG,2$CD/DVD$FG$ support with $FG,2$ISO9660$FG$ file system. Can make bootable $FG,2$ISO9660$FG$ ISO files so you can roll-your-own distro's.
|
||||
* ATAPI PIO $FG,2$CD/DVD$FG$ support with $FG,2$RedSea$FG$ file system. Can make bootable ISO files so you can roll-your-own distro's.
|
||||
|
||||
* $LK,"Partitioning",A="MN:DskPrt"$ tool, installer, $FG,2$boot loaders$FG$ for CD/DVD and hard disk.
|
||||
|
||||
|
||||
@@ -51,9 +51,6 @@ $ID,-2$
|
||||
$FG,2$'m'$FG$
|
||||
$ID,2$Make CD/DVD ISO.C file. This creates a $LK,"RedSea",A="FI:::/Doc/RedSea.DD"$ ISO file image of the dir the cursor is on. The name of the ISO file is $FG,2$$TX,"\"::/Tmp/CDDVD.ISO.C\"",D="DFT_ISO_C_FILENAME"$$FG$ $LK,"blkdev.dft_iso_c_filename",A="MN:CBlkDevGlbls"$ and can be redefined in your start-up scripts. You may wish to place it on a different drive.
|
||||
$ID,-2$
|
||||
$FG,2$'M'$FG$
|
||||
$ID,2$Make CD/DVD ISO file. This creates a ISO9660 file image of the dir the cursor is on. The name of the ISO file is $FG,2$$TX,"\"::/Tmp/CDDVD.ISO\"",D="DFT_ISO_FILENAME"$$FG$ $LK,"blkdev.dft_iso_filename",A="MN:CBlkDevGlbls"$ and can be redefined in your start-up scripts. You may wish to place it on a different drive.
|
||||
$ID,-2$
|
||||
$FG,2$'B'$FG$
|
||||
$ID,2$Burn CD/DVD ISO file. This burns a CD/DVD using the image file, $FG,2$$TX,"\"::/Tmp/CDDVD.ISO\"",D="DFT_ISO_FILENAME"$$FG$ $LK,"blkdev.dft_iso_filename",A="MN:CBlkDevGlbls"$ to the drive the cursor is on.
|
||||
$ID,-2$
|
||||
|
||||
@@ -22,7 +22,6 @@ CDDVD
|
||||
DskChg(,'c');
|
||||
MountISOC(,'i');
|
||||
MakeRedSeaISOC(,'m');
|
||||
MakeISO9660ISO(,'M');
|
||||
BurnISOFile(,'B');
|
||||
}
|
||||
|
||||
|
||||
+1
-1
@@ -235,7 +235,7 @@ $FG,5$*.BIN.Z;*.BIN.C;*.BIN$FG$
|
||||
$FG,5$*.DATA.Z;*.DATA$FG$
|
||||
Data files
|
||||
$FG,5$*.ISO$FG$
|
||||
CD/DVD image file--ISO9660.
|
||||
CD/DVD image file.
|
||||
$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$
|
||||
|
||||
Binary file not shown.
+2
-2
@@ -209,7 +209,7 @@ $FG$$ID,-2$
|
||||
|
||||
* You can use $LK,"Option",A="MN:Option"$($LK,"OPTf_WARN_DUP_TYPES",A="MN:OPTf_WARN_DUP_TYPES"$,ON) to find dup local var type stmts.
|
||||
|
||||
* With the $FG,2$#exe{}$FG$ feature in your src code, you can place programs that insert text into the stream of code being compiled. See $LK,"#exe {}",A="FF:::/Kernel/KEnd.HC,#exe {"$ for an example where the date/time and compile-time prompting for cfguration data is placed into a program. $LK,"StreamPrint",A="MN:StreamPrint"$() places text into a src program stream following the conclusion of the $FG,2$#exe{}$FG$ blk.
|
||||
* With the $FG,2$#exe{}$FG$ feature in your src code, you can place programs that insert text into the stream of code being compiled. See $LK,"#exe {}",A="FF:::/Kernel/KMain.HC,#exe {"$ for an example where the date/time and compile-time prompting for cfguration data is placed into a program. $LK,"StreamPrint",A="MN:StreamPrint"$() places text into a src program stream following the conclusion of the $FG,2$#exe{}$FG$ blk.
|
||||
|
||||
* No $FG,2$#define$FG$ functions exist (I'm not a fan)
|
||||
|
||||
@@ -223,7 +223,7 @@ $FG$$ID,-2$
|
||||
|
||||
* $FG,2$union$FG$ is more like a class, so you don't reference it with a $FG,2$union$FG$ label after you define it. Some common unions are declared in $LK,"KernelA.HH",A="MN:U16"$ for 1,2,4 and 8 byte objects. If you place a type in front of a union declaration, that is the type when used by itself. See $LK,"::/Demo/SubIntAccess.HC"$.
|
||||
|
||||
* $FG,2$class$FG$ member vars can have meta data. $FG,2$fmtstr$FG$ and $FG,2$fmtdata$FG$ are two meta data types now used. All compiler structures are saved and you can access the compiler's info about classes and vars. See $LK,"::/Demo/ClassMeta.HC"$ and $LK,"DocForm",A="MN:DocForm"$().
|
||||
* $FG,2$class$FG$ member vars can have meta data. $FG,2$format$FG$ and $FG,2$data$FG$ are two meta data types now used. All compiler structures are saved and you can access the compiler's info about classes and vars. See $LK,"::/Demo/ClassMeta.HC"$ and $LK,"DocForm",A="MN:DocForm"$().
|
||||
|
||||
* There is a keyword $FG,2$lastclass$FG$ you use as a dft arg. It is set to the class name of the prev arg. See $LK,"::/Demo/LastClass.HC"$, $LK,"ClassRep",A="MN:ClassRep"$(), $LK,"DocForm",A="MN:DocForm"$() and $LK,"::/Demo/Dsk/BlkDevRep.HC"$.
|
||||
|
||||
|
||||
+1
-1
@@ -6,7 +6,7 @@ Dual booting with another operating system is the best way to use TempleOS. I o
|
||||
|
||||
The $LK,"::/Misc/OSInstall.HC"$ script will automate much of this. It runs if you boot the CD/DVD-ROM.
|
||||
|
||||
See $LK,"Boot.DD",A="FI:::/Doc/Boot.DD"$ for an overview of booting. See $LK,"Requirements",A="FI:::/Doc/Requirements.DD"$ for supported hardware. See $LK,"Upgrading",A="FI:::/Doc/Upgrade.DD"$ if you are upgrading.
|
||||
See $LK,"Boot.DD",A="FI:::/Doc/Boot.DD"$ for an overview of booting. See $LK,"Requirements",A="FI:::/Doc/Requirements.DD"$ for supported hardware.
|
||||
|
||||
Two TempleOS partitions are highly recommended, so you can boot to a back-up and fix the primary when you work on it. Odds are, you only need a couple gigabytes for your TempleOS partitions.
|
||||
|
||||
|
||||
+3
-3
@@ -8,7 +8,7 @@ You can create new, independent heaps using $LK,"HeapCtrlInit",A="MN:HeapCtrlIni
|
||||
|
||||
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"$().
|
||||
|
||||
All of the regular page tables are marked, "cached". When accessing hardware, however, you need uncached page table. The lowest 4Gig addresses have an alias to access hardware located toward the top of mapped space, $FG,2$0x$TX,"01AA000000",D="DD_UNCACHED_ALIAS"$$FG$. See $LK,"dev.uncached_alias",A="FF:::/Kernel/KEnd.HC,dev.uncached_alias"$.
|
||||
All of the regular page tables are marked, "cached". When accessing hardware, however, you need uncached page table. The lowest 4Gig addresses have an alias to access hardware located toward the top of mapped space, $FG,2$0x$TX,"01AA000000",D="DD_UNCACHED_ALIAS"$$FG$. See $LK,"dev.uncached_alias",A="FF:::/Kernel/KMain.HC,dev.uncached_alias"$.
|
||||
|
||||
During an extended powered-on session of TempleOS, in theory, memory will become fragmented, requiring a reboot. It has never happens to me.
|
||||
|
||||
@@ -55,8 +55,8 @@ In 2003, I wanted to make a no-paging ring-0-only 64-bit operating system for su
|
||||
|
||||
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 top of address space was uncached. See $LK,"UncachedAliasAlloc",A="MN:UncachedAliasAlloc"$(). 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.
|
||||
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 top of address space was uncached. See $LK,"UncachedAliasAlloc",A="MN:UncachedAliasAlloc"$(). 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/KMain.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 top of address space. See $LK,"UncachedAliasAlloc",A="MN:UncachedAliasAlloc"$(). 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"$.
|
||||
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/KMain.HC,dev.uncached_alias"$.
|
||||
+5
-1
@@ -33,10 +33,14 @@ $FG,2$"%F"$FG$ text file by filename.
|
||||
|
||||
$FG,2$"%$$F"$FG$ $LK,"DolDoc",A="FI:::/Doc/DolDocOverview.DD"$ file in memory.
|
||||
|
||||
$FG,2$"%p"$FG$ ptr.
|
||||
$FG,2$"%p"$FG$ ptr.
|
||||
|
||||
$FG,2$"%,p"$FG$ ptr with no offset.
|
||||
|
||||
$FG,2$"%P"$FG$ link to ptr.
|
||||
|
||||
$FG,2$"%,P"$FG$ link to ptr with no offset.
|
||||
|
||||
$FG,2$"%D"$FG$ date. Pass a $LK,"CDate",A="MN:CDate"$.
|
||||
|
||||
$FG,2$"%T"$FG$ time. Pass a $LK,"CDate",A="MN:CDate"$.
|
||||
|
||||
+3
-1
@@ -39,4 +39,6 @@ To replace ISO9660, make hard-drive partition image of a measured size and copy
|
||||
|
||||
RedSea file system has no bad block table and no redundant allocation table.
|
||||
|
||||
Read $LK,"Block Chain",A="FI:::/Doc/BlkChain.DD"$ for a philosophical explaination of RedSea reasoning.
|
||||
See $LK,"Block Chain",A="FI:::/Doc/BlkChain.DD"$ for RedSea allocation bitmap discussion.
|
||||
|
||||
See $LK,"Reliability",A="FI:::/Doc/Reliability.DD"$ for RedSea reliability discussion.
|
||||
+1
-1
@@ -14,7 +14,7 @@ $FG,5$Supported Hardware$FG$
|
||||
|
||||
* Internal PC Speakers.
|
||||
|
||||
* CD/DVD-ROMs (not SCSI). ISO9660 file system.
|
||||
* CD/DVD-ROMs (not SCSI) but only RedSea file system.
|
||||
|
||||
* ATA and SATA hard drives.
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
$WW,1$$FG,5$$TX+CX,"The Standard TempleOS PC",HTML="http://www.templeos.org/Wb/Home/Web/TAD/TAD.html"$$FG$
|
||||
$WW,1$$FG,5$$TX+CX,"The Standard TempleOS PC"$$FG$
|
||||
|
||||
All desktop PCs will have 8-channel OCTART super-simple high speed serial ports to replace USB. They are simpler because the driver is as simple as old school $LK,"RS232 Serial",A="FI:::/Doc/Comm.HC"$, they have no USB end-points and they have no USB human interface device reports. Computer mice will all have exactly two bttns and one wheel. Game controllers will all be the standard deluxe $TX,"game console controllers",HTML="http://www.gamestop.com/pc/accessories/steam-controller/121865"$ that are popular today. It will have 8 big TX and 8 big RX fifos that allow flow control characters to jump the queue. It should be locked-down to as few options as possible, like 8-1-N only, although hardware may use a USB frame, not an RS232, so stop bits might not be relevant. Perhaps, just two baud rates -- high and low speed are needed. Low speed is good for slow microcontrollers and allows longer cable length. Keyboard, mouse and game controller can be low speed.
|
||||
|
||||
@@ -58,7 +58,7 @@ We will make a spec for a $$8,000, perfectly standardized, cryogenically-cooled,
|
||||
|
||||
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.
|
||||
|
||||
TempleOS will have the priority over Windows or Linux on hardware decisions. We could make it heterogenious multicore. I think we want 16 non-hyperthreaded cores. Core#0 is the only full-featured core needed. The other cores will have long mode, but not some of these: real mode, protected mode, ring-3, paging, interrupts, in/out port instructions, SSE instructions, MMX instructions. This $LK,"Graphics Job",A="FI:~/Web/TAD/GraphicsPerformance.DD"$ is what to optimize for.
|
||||
TempleOS will have the priority over Windows or Linux on hardware decisions. We could make it heterogenious multicore. I think we want 16 non-hyperthreaded cores. Core#0 is the only full-featured core needed. The other cores will have long mode, but not some of these: real mode, protected mode, ring-3, paging, interrupts, in/out port instructions, SSE instructions, MMX instructions.
|
||||
|
||||
God said Intel should do a simulation of heat produced by gates and try spreading-out the heat producing gate circuits on the chip.
|
||||
|
||||
|
||||
+3
-3
@@ -73,7 +73,7 @@ $FG,2$Merge(\"C:/*\",\"D:/*\",\"+r+d\");$FG$ to check my changes.
|
||||
|
||||
* Use $FG,2$<CTRL-ALT-s>$FG$ will capture the scrn as a sprite on the clip. 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.
|
||||
* You can save a sprite as a $FG,2$.GR$FG$ file in $FG,2$<CTRL-r>$FG$ on the Sprite BitMap Menu.
|
||||
|
||||
* You can eye-dropper colors in the $FG,2$<CTRL-r>$FG$ sprite editor by pressing $FG,2$'c'$FG$. Press $FG,2$'t'$FG$ for transparent.
|
||||
|
||||
@@ -85,7 +85,7 @@ $FG,2$Merge(\"C:/*\",\"D:/*\",\"+r+d\");$FG$ to check my changes.
|
||||
|
||||
* When using $FG,2$<CTRL-l>$FG$ to insert links in documents, you can usually leave the $FG,2$Tag Text$FG$ blank and it will be filled-in automatically based on other entries.
|
||||
|
||||
* There is a feature of the precompiler that allows code to be executed in the middle of compilation and data inserted into the compilation stream. Click here for an example: $LK,"#exe {",A="FF:::/Kernel/KEnd.HC,#exe {"$.
|
||||
* There is a feature of the precompiler that allows code to be executed in the middle of compilation and data inserted into the compilation stream. Click here for an example: $LK,"#exe {",A="FF:::/Kernel/KMain.HC,#exe {"$.
|
||||
|
||||
* If you output to the cmd line and wish to allow users to scroll around and view data, you can use $LK,"View",A="MN:View"$().
|
||||
|
||||
@@ -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$.GR$FG$ files.
|
||||
* You can use $LK,"Type",A="MN:Type"$() to display $FG,2$.GR$FG$ files.
|
||||
|
||||
* Use $LK,"Man",A="MN:Man"$() to jump to short sym name src code.
|
||||
|
||||
|
||||
+1
-1
@@ -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,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!
|
||||
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,"82,150",D="DD_TEMPLEOS_LOC"$ 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"$.
|
||||
|
||||
|
||||
+1
-1
@@ -12,7 +12,7 @@ I have made an incredible accomplishment by getting it to work on practically ev
|
||||
|
||||
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.
|
||||
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,"82,150",D="DD_TEMPLEOS_LOC"$ 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.
|
||||
|
||||
|
||||
+1
-1
@@ -28,7 +28,7 @@ $FG,5$Tree$FG$ The item will behave like a tree widget, with this as the root.
|
||||
$FG,5$Collapsed$FG$ The tree or hidden widget will begin collapsed.
|
||||
$FG,5$Define Str$FG$ will substitute a $FG,2$#define$FG$ or $LK,"DefineLoad",A="MN:DefineLoad"$() string for the tag.
|
||||
|
||||
$FG,5$Quote$FG$ Make the res suitable for including in a program, in quotes, especially $FG,2$fmtstr$FG$ entries in class definitions.
|
||||
$FG,5$Quote$FG$ Make the res suitable for including in a program, in quotes, especially $FG,2$format$FG$ entries in class definitions.
|
||||
|
||||
$FG,5$X Expression$FG$ For cursor movements, the horizontal value.
|
||||
$FG,5$Y Expression$FG$ For cursor movements, the vertical value.
|
||||
|
||||
Reference in new issue
Block a user