TempleOSCDV4.10.ISO
This commit is contained in:
Terry A. Davis authored and minexew committed
1 parent
c5954d3371
commit
9206246147
181 files changed
+4468
-4313
No files matched your search
Binary file not shown.
+32
-1
@@ -2,7 +2,38 @@ $WW,1$$FG,5$$TX+CX,"Change Log"$$FG$
|
||||
|
||||
Use $LK,"R",A="MN:R"$() to rename if I change a label.
|
||||
|
||||
$IV,1$----07/07/16 00:41:12----$IV,0$
|
||||
$IV,1$----08/08/16 08:32:26----$IV,0$
|
||||
|
||||
$IV,1$----07/17/16 13:03:12----$IV,0$
|
||||
* Improved $LK,"DocOpt",A="MN:DocOpt"$().
|
||||
|
||||
$IV,1$----07/17/16 03:23:53----$IV,0$
|
||||
* Improved $LK,"::/Demo/Games/RawHide.CPP"$.
|
||||
|
||||
$IV,1$----07/15/16 10:11:10----$IV,0$
|
||||
* $BK,1$TempleOS version 4.10 Released$BK,0$
|
||||
* Improved $LK,"::/Demo/Games/EagleDive.CPP"$.
|
||||
|
||||
$IV,1$----07/15/16 05:17:24----$IV,0$
|
||||
* Created $LK,"CDevGlbls",A="MN:CDevGlbls"$.uncached_alias.
|
||||
* Added 1 Gig page table support.
|
||||
|
||||
$IV,1$----07/13/16 17:21:19----$IV,0$
|
||||
* Added $LK,"::/Demo/MultiCore/RateCores.CPP"$.
|
||||
|
||||
$IV,1$----07/09/16 08:46:36----$IV,0$
|
||||
* Changed scoring in $LK,"::/Demo/Games/EagleDive.CPP"$.
|
||||
* Replaced many $FG,2$"%Q"$FG$ with $FG,2$"%$$Q"$FG$.
|
||||
* Fixed $FG,2$'\x24'$FG$.
|
||||
* Added $FG,2$'\d'$FG$ for $FG,2$'$$'$FG$.
|
||||
|
||||
$IV,1$----07/08/16 14:30:19----$IV,0$
|
||||
* $LK,"R",A="MN:R"$("root","head");
|
||||
* Fixed $FG,2$REP_STOSB$FG$ and $LK,"MemSet",A="MN:MemSet"$() for 64-bit.
|
||||
|
||||
$IV,1$----07/07/16 07:21:03----$IV,0$
|
||||
* $LK,"DocRead",A="MN:DocRead"$() changes to file's dir so relative filenames work.
|
||||
* Added AppStore to website with Supplemental #1 ISO for download.
|
||||
|
||||
$IV,1$----07/06/16 23:45:30----$IV,0$
|
||||
* Fixed multicore bug in $LK,"Sprite3",A="MN:Sprite3"$().
|
||||
|
||||
+1
-1
@@ -44,7 +44,7 @@ I, $FG,2$Terry A. Davis$FG$, wrote all $TX,"121,193",D="DD_TEMPLEOS_LOC"$ lines
|
||||
|
||||
*) I hired an artist, Cody Rigby, for $$3,000 worth of pixel art.
|
||||
|
||||
*) Erik van der Karbargenbok made $LK,"TempleBot",A="PI:::/Linux/TempleBot",HTML="http://www.templeos.org/Wb/Home/Downloads/Bin/TempleBot.html"$.
|
||||
*) Erik van der Karbargenbok made $LK,"TempleBot",A="PI:::/Linux/TempleBot",HTML="http://www.templeos.org/Wb/Home/Sup1/Sup1Bin/TempleBot.html"$.
|
||||
|
||||
*) The random number generator is from Donald Knuth in the wikipedia entry for $TX,"Linear_congruential_generator",HTML="http://en.wikipedia.org/wiki/Linear_congruential_generator"$.
|
||||
|
||||
|
||||
@@ -23,6 +23,8 @@ $LK,"::/Kernel/BlkDev/DskCluster.CPP"$ :152 All the cluster operations become bl
|
||||
|
||||
* VMware and others must list TempleOS as an official 64-bit operating system.
|
||||
|
||||
* VMware needs to support more than 16 cores.
|
||||
|
||||
* Until super-simple block devices are available, hard disk should be placed at IDE primary master 1F0/3F6 and CD/DVD/Blu-ray should be placed at the IDE secondary master 170/376.
|
||||
$LK,"/Kernel/BlkDev/DskATAId.CPP",A="FI:::/Kernel/BlkDev/DskATAId.CPP"$ :286 lines to figure-out I/O ports is gone.
|
||||
$LK,"/Kernel/PCIBIOS.CPP",A="FI:::/Kernel/PCIBIOS.CPP"$ :290 could be eliminated, but maybe we will keep it so people can play with PCI devices.
|
||||
|
||||
@@ -66,6 +66,7 @@ $LK,"::/Demo/ExtendedChars.CPP"$
|
||||
$LK,"::/Demo/TimeIns.CPP"$
|
||||
$LK,"::/Demo/Snd/WaterFowl.CPP"$
|
||||
$MA-X+PU,"::/Apps/Psalmody/Examples",LM="Cd(\"::/Apps/Psalmody/Examples\");Dir;View;\n"$
|
||||
$LK,"::/Demo/MultiCore/RateCores.CPP"$
|
||||
$LK,"::/Demo/MultiCore/MPPrint.CPP"$
|
||||
$LK,"::/Demo/Graphics/PredatorPrey.CPP"$
|
||||
$LK,"::/Demo/Graphics/Cartesian.CPP"$
|
||||
|
||||
@@ -139,7 +139,7 @@ $ID,2$Used for forms. Use $FG,2$<CTRL-l>$FG$ to help you generate the DolDoc co
|
||||
|
||||
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.CPP,&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$$FG$. $LK,"DocForm",A="MN:DocForm"$() will automatically reset the raw type to the value from the $LK,"HolyC",A="FI:::/Doc/HolyC.TXT"$ $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"$().
|
||||
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.TXT"$ $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.TXT"$ $FG,2$class$FG$ member's $FG,2$fmtstr$FG$ meta-data for $LK,"DocForm",A="MN:DocForm"$(). See $LK,"::/Demo/DolDoc/Form.CPP"$.
|
||||
|
||||
|
||||
+4
-4
@@ -3,7 +3,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.TXT"$.
|
||||
$ID,-2$$TR,"Shouldn't it be GNU/TempleOS?"$
|
||||
$ID,2$TempleOS executes no code not written by me at any time except for a few $FG,2$BIOS$FG$ calls for configuration. I even wrote boot-loaders, so I do not need $LK,"Grub",A="FI:::/Doc/Grub.TXT"$. See $LK,"::/Doc/Credits.TXT"$.
|
||||
$ID,2$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.TXT"$.
|
||||
$ID,-2$$TR,"Don't you use GNU's gcc?"$
|
||||
$ID,2$TempleOS was written from scratch, starting with $FG,2$TASM$FG$ long ago, launching from real-mode DOS. Now, there is no $FG,2$Linux$FG$ or $FG,2$GNU$FG$ or any other code in TempleOS. Yes, I wrote the compiler from scratch. See $LK,"::/Doc/Credits.TXT"$.
|
||||
$ID,-2$$TR,"Why do you dual boot?"$
|
||||
@@ -43,7 +43,7 @@ $ID,2$TempleOS allocs mem as more items are displayed in the window. Also, Temp
|
||||
$ID,-2$$TR,"Why do I get a memory leak when editing big files?"$
|
||||
$ID,2$The editor periodically takes a snap-shot of the document for $FG,2$UNDO$FG$ and this looks like a memory leak.
|
||||
$ID,-2$$TR,"Why is it in text mode?"$
|
||||
$ID,2$TempleOS runs in $FG,2$VGA 640x480 16 color$FG$ graphics mode, not text mode. It changes to this mode with a $LK,"BIOS call",A="FF:::/Kernel/KStart.CPP,INT 0x10"$ while in real-mode before it switches to 64-bit mode. The text is $LK,"drawn by hand",A="MN:GrUpdateTextFG"$. See $LK,"::/Kernel/FontStd.CPP"$. If graphics mode fails, it falls-back on text mode. You can force text mode with an $LK,"Kernel config",A="FI:::/Kernel/KCfg.CPP"$ option.
|
||||
$ID,2$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.CPP,INT 0x10"$ while in real-mode before it switches to 64-bit mode. The text is $LK,"drawn by hand",A="MN:GrUpdateTextFG"$. See $LK,"::/Kernel/FontStd.CPP"$. If graphics mode fails, it falls-back on text mode. You can force text mode with an $LK,"Kernel config",A="FI:::/Kernel/KCfg.CPP"$ option.
|
||||
$ID,-2$$TR,"Where is the kernel memory?"$
|
||||
$ID,2$TempleOS identity-maps all memory, all the time. It is like paging is not used. There is no special kernel $FG,2$high half$FG$ memory space. TempleOS is ring-0-only, so everything is kernel, even user programs. There is a special task called $FG,2$Adam$FG$ and he doesn't die, so his heap never gets freed. That's as close to $FG,2$kernel memory$FG$ as it gets. All code goes in the lowest 2 Gig of addresses, known as the $LK,"Code Heap",A="FF:::/Doc/Glossary.TXT,Code and Data Heaps"$, so that the $FG,2$REL32$FG$ addressing mode can be used. See $LK,"MemOverview",A="FI:::/Doc/MemOverview.TXT"$.
|
||||
$ID,-2$$TR,"Why does it run code from stack addresses?"$
|
||||
@@ -55,9 +55,9 @@ $ID,2$The stack does not grow, so do not do deep recursion. In theory, memory g
|
||||
$ID,-2$$TR,"How do I set the PATH?"$
|
||||
$ID,2$There is no $FG,2$PATH$FG$. You do not enter filenames at the command-line and expect them to run. You enter C-like code. $LK,"Get Started Here",A="FI:::/Doc/CmdLineOverview.TXT"$.
|
||||
$ID,-2$$TR,"How do I boot it with Grub?"$
|
||||
$ID,2$If you use $LK,"Grub",A="FI:::/Doc/Grub.TXT"$, you $FG,2$chain-load$FG$ like Windows. See $LK,"Boot",A="FI:::/Doc/Boot.TXT"$. You can use the TempleOS boot-loader. $LK,"Master-Boot-Loader-Stage1",A="FI:::/Adam/Opt/Boot/BootMHD.CPP"$, $LK,"Master-Boot-Loader-Stage2",A="FI:::/Adam/Opt/Boot/BootMHD2.CPP"$, $LK,"Partition-Boot-Loader",A="FI:::/Adam/Opt/Boot/BootHD.CPP"$, $LK,"CD-DVD-Boot-Loader",A="FI:::/Adam/Opt/Boot/BootDVD.CPP"$.
|
||||
$ID,2$If you use Grub, you $FG,2$chain-load$FG$ like Windows. See $LK,"Boot",A="FI:::/Doc/Boot.TXT"$. You can use the TempleOS boot-loader. $LK,"Master-Boot-Loader-Stage1",A="FI:::/Adam/Opt/Boot/BootMHD.CPP"$, $LK,"Master-Boot-Loader-Stage2",A="FI:::/Adam/Opt/Boot/BootMHD2.CPP"$, $LK,"Partition-Boot-Loader",A="FI:::/Adam/Opt/Boot/BootHD.CPP"$, $LK,"CD-DVD-Boot-Loader",A="FI:::/Adam/Opt/Boot/BootDVD.CPP"$.
|
||||
$ID,-2$$TR,"How do I get Kernel.BIN to boot?"$
|
||||
$ID,2$The boot-loaders must be patched by you running $LK,"BootHDIns",A="MN:BootHDIns"$() or $LK,"BootMHDIns",A="MN:BootMHDIns"$(). Those will write the block address into the boot-loader because the boot-loaders do not navigate file systems to find the $LK,"Stage2",A="FI:::/Kernel/KStart.CPP"$ if you relocate it.
|
||||
$ID,2$The boot-loaders must be patched by you running $LK,"BootHDIns",A="MN:BootHDIns"$() or $LK,"BootMHDIns",A="MN:BootMHDIns"$(). Those will write the block address into the boot-loader because the boot-loaders do not navigate file systems to find the $LK,"Stage2",A="FI:::/Kernel/KStart16.CPP"$ if you relocate it.
|
||||
$ID,-2$$TR,"Why is there some 16-Bit code?"$
|
||||
$ID,2$TempleOS is 64-bit. Like all PC operating systems, the boot-loader starts in 16-bit real-mode. TempleOS calls a few $FG,2$BIOS$FG$ info routines, switches to VGA-640x480x4bit, switches to 32-bit, then, 64-bit mode. There is an odd thing called a $FG,2$$TX,"PCI BIOS",HTML="http://www.o3one.org/hwdocs/bios_doc/pci_bios_21.pdf"$$FG$ which is 32-bit used for $FG,2$PCI$FG$ config space access. TempleOS calls $LK,"that",A="FI:::/Kernel/PCIBIOS.CPP"$ a couple times. It must temporarily drop-out-of 64-bit mode for that and stop multi-tasking.
|
||||
$ID,-2$$TR,"Why are you pushing 32-bit values on the stack?"$
|
||||
|
||||
+2
-4
@@ -49,7 +49,7 @@ $FG,2$Elem$FG$ Element
|
||||
$FG,2$Equ$FG$ Equal
|
||||
$FG,2$Evt$FG$ Event
|
||||
$FG,2$Exe$FG$ Execute
|
||||
$FG,2$Ext$FG$ Extern, Extended
|
||||
$FG,2$Ext$FG$ Extern, Extended, Extract
|
||||
$FG,2$Feat$FG$ Feature
|
||||
$FG,2$FG$FG$ Foreground
|
||||
$FG,2$Fmt$FG$ Format
|
||||
@@ -94,7 +94,7 @@ $FG,2$ODE$FG$ Ordinary Differential Equation
|
||||
$FG,2$Opt$FG$ Option, Optimize
|
||||
$FG,2$Paren$FG$ Parenthesis
|
||||
$FG,2$Pix$FG$ Pixel
|
||||
$FG,2$$FG,2$Pkg$FG$ Package
|
||||
$FG,2$Pkg$FG$ Package
|
||||
$FG,2$Poly$FG$ Polygon
|
||||
$FG,2$Pos$FG$ Position
|
||||
$FG,2$Pow$FG$ Power
|
||||
@@ -255,8 +255,6 @@ $ID,-2$$TR,"Gs"$
|
||||
$ID,2$The CPU GS segment reg. This reg points to the current core's $LK,"CCPU",A="MN:CCPU"$.
|
||||
$ID,-2$$TR,"Heap"$
|
||||
$ID,2$Programs can dynamically request chunks of memory alloced from a $FG,2$heap$FG$ using $LK,"MAlloc",A="MN:MAlloc"$(). They must $LK,"Free",A="MN:Free"$() it when finished. Ptrs are used to refer to the chunk. The $FG,2$heap$FG$ is dynamically alloced mem.
|
||||
$ID,-2$$TR,"Root"$
|
||||
$ID,2$The base of a binary tree or the head of a queue is the $FG,2$root$FG$. (I don't like the word $FG,2$head$FG$.)
|
||||
$ID,-2$$TR,"Join"$
|
||||
$ID,2$When two parts of a program have a common low-level routine, that routine is often labeled SomethingJoin.
|
||||
$ID,-2$$TR,"user_data"$
|
||||
|
||||
@@ -1,23 +0,0 @@
|
||||
$FG,5$$TX+CX,"The Grub Master Bootloader"$$FG$
|
||||
|
||||
$WW,1$Here are my $FG,2$grub.cfg$FG$ file entries for my TempleOS partitions. I don't have the patience to do it correctly and GRUB obfuscates. Chain loading is just the normal way an operating system like Windows boots. They do drives, zero-based, and partitions on drives, one-based. They call traditional partitioning a "msdos" partition and I presume, if there is a new way to partition drives, it has a new name.
|
||||
|
||||
In addition to a Windows and a Linux partition, I have a Primary TempleOS $FG,2$'D'$FG$, Backup TempleOS $FG,2$'E'$FG$ and a Transfer $FG,2$'I'$FG$ partition for transferring between Windows and TempleOS. "hd0" is 1st hard drive, zero-based numbering. "msdos1" is partition #1, traditional msdos partitioning. I keep $FG,2$'D'$FG$, $FG,2$'E'$FG$, and $FG,2$'I'$FG$ ident by frequently copying all files and I use $FG,2$'I'$FG$ to transfer files. They only need to be a couple Gig in size. Every time I copy files, use $LK,"BootHDIns",A="MN:BootHDIns"$() to $LK,"MakeAll",A="MN:MakeAll"$ and prepare the partition $LK,"boot sector",A="FI:::/Adam/Opt/Boot/BootHD.CPP"$ for chainloading by patching the new block address and size of $FG,2$Kernel.BIN.C$FG$.
|
||||
|
||||
menuentry "TempleOS D" {
|
||||
insmod chain
|
||||
set root=(hd0,msdos1)
|
||||
chainloader +1
|
||||
}
|
||||
|
||||
menuentry "TempleOS E" {
|
||||
insmod chain
|
||||
set root=(hd0,msdos5)
|
||||
chainloader +1
|
||||
}
|
||||
|
||||
menuentry "TempleOS I" {
|
||||
insmod chain
|
||||
set root=(hd1,msdos5)
|
||||
chainloader +1
|
||||
}
|
||||
+3
-3
@@ -198,11 +198,11 @@ $FG$$ID,-2$
|
||||
$FG,2$^$FG$
|
||||
$FG,2$|$FG$
|
||||
$FG,2$+$FG$,$FG,2$-$FG$
|
||||
$FG,2$$FG,2$<$FG$,$FG,2$>$FG$,$FG,2$<=$FG$,$FG,2$>=$FG$
|
||||
$FG,2$<$FG$,$FG,2$>$FG$,$FG,2$<=$FG$,$FG,2$>=$FG$
|
||||
$FG,2$==$FG$,$FG,2$!=$FG$
|
||||
$FG,2$&&$FG$
|
||||
$FG,2$$FG,2$^^$FG$
|
||||
$FG,2$||$FG$$FG$
|
||||
$FG,2$^^$FG$
|
||||
$FG,2$||$FG$
|
||||
$FG,2$=$FG$,$FG,2$<<=$FG$,$FG,2$>>=$FG$,$FG,2$*=$FG$,$FG,2$/=$FG$,$FG,2$&=$FG$,$FG,2$|=$FG$,$FG,2$^=$FG$,$FG,2$+=$FG$,$FG,2$-=$FG$
|
||||
|
||||
* You can use $LK,"Option",A="MN:Option"$($LK,"OPTf_WARN_PAREN",A="MN:OPTf_WARN_PAREN"$,ON) to find unnecessary parentheses in code.
|
||||
|
||||
+1
-1
@@ -34,7 +34,7 @@ $ID,2$This command is used to copy files onto a hard drive partition from the CD
|
||||
$ID,-2$4) $LK,"BootHDIns",A="MN:BootHDIns"$($FG,2$'D'$FG$)
|
||||
$ID,2$This command recompiles the source code on a drive and writes to the $UL,1$drive's$UL,0$ boot record. You'll need to reenter the $LK,"Mount",A="MN:Mount"$ information so it can be stored in the kernel.
|
||||
|
||||
$ID,-2$5) Use Linux's $LK,"Grub",A="FI:::/Doc/Grub.TXT"$ or TempleOS' $LK,"BootMHDIns",A="MN:BootMHDIns"$($FG,2$'D'$FG$)
|
||||
$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.
|
||||
|
||||
|
||||
+11
-8
@@ -1,6 +1,6 @@
|
||||
$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 ident 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.
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
@@ -14,7 +14,7 @@ See $LK,"MemRep",A="MN:MemRep"$() and $LK,"::/Demo/MemDemo.CPP"$.
|
||||
|
||||
$FG,5$$TX+CX,"Single System-wide Mem Map"$
|
||||
|
||||
$FG,2$ 0x00$TX,"00007C00",D="DD_KERNEL"$- 0x00$TX,"000347DF",D="DD_KERNEL_END"$$FG$
|
||||
$FG,2$ 0x00$TX,"00007C00",D="DD_KERNEL"$- 0x00$TX,"00035F3F",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,10 +29,10 @@ $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,"001835FF",D="DD_SYS_FIXED_AREA_END"$$FG$
|
||||
$ID,2$$LK,"CSysFixedArea",A="MN:CSysFixedArea"$ for page tables and misc. $TX,"128 Gig",D="DD_MEM_MAPPED_SPACE_GIG"$ of address space mapped.
|
||||
$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.
|
||||
$ID,-2$
|
||||
$FG,2$ 0x00$TX,"00183600",D="DD_SYS_HEAP_BASE"$- 0x00$TX,"3FFE3DFF",D="DD_SYS_HEAP_LIMIT"$$FG$
|
||||
$FG,2$ 0x00$TX,"00203800",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$
|
||||
@@ -42,11 +42,14 @@ $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.
|
||||
$ID,-2$
|
||||
$FG,2$ 0x0080000000-~0x00DFFFFFFF$FG$
|
||||
$FG,2$ 0x0100000000-~0x$TX,"1FFFFFFFFF",D="DD_MEM_MAPPED_SPACE_END"$$FG$
|
||||
$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,"1FFFFFFFFF",D="DD_MEM_MAPPED_SPACE_END"$$FG$$FG$
|
||||
$ID,2$64-bit devices are alloced with $LK,"Mem64DevAlloc",A="MN:Mem64DevAlloc"$() counting bwd from $TX,"128 Gig",D="DD_MEM_MAPPED_SPACE_GIG"$, but no PCI devices are actually supported$WW,0$.
|
||||
$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$
|
||||
$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$
|
||||
|
||||
|
||||
|
||||
@@ -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,"128 Gig",D="DD_MEM_MAPPED_SPACE_GIG"$ RAM (easily increased).
|
||||
* 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"$).
|
||||
|
||||
* Internal PC Speakers.
|
||||
|
||||
|
||||
+1
-1
@@ -1,4 +1,4 @@
|
||||
$WW,1$A $LK,"CSprite",A="MN:CSprite"$ is an ordered list of $LK,"these",A="MN:SPT_END"$ elements, created with $FG,2$<CTRL-r>$FG$$FG$. Normally, they are packed together in a list and the address of the first is passed to routines.
|
||||
$WW,1$A $LK,"CSprite",A="MN:CSprite"$ is an ordered list of $LK,"these",A="MN:SPT_END"$ elements, created with $FG,2$<CTRL-r>$FG$. Normally, they are packed together in a list and the address of the first is passed to routines.
|
||||
|
||||
See $LK,"::/Demo/Graphics/SpritePlot.CPP"$, $LK,"::/Demo/Graphics/SpritePlot3D.CPP"$, $LK,"::/Demo/Graphics/SpritePut.CPP"$, $LK,"::/Demo/Graphics/SpriteRaw.CPP"$ and $LK,"SpriteMeshEd",A="MN:SpriteMeshEd"$().
|
||||
|
||||
|
||||
@@ -56,7 +56,7 @@ $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 and a webcam. 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. 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. 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.
|
||||
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.TXT"$ is what to optimize for.
|
||||
|
||||
|
||||
+46
-5
@@ -7,11 +7,45 @@ $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.TXT"$, 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,056",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.TXT"$ 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.TXT"$, 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.TXT"$ application in one line of code and can put graphics on the screen 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.TXT"$.
|
||||
|
||||
Conventional thinking is "failure is not an option" for general purpose operating systems. Since this OS is used in addition to Windows or Linux, however, failure is an option -- just use Windows or Linux if you can't do something. I cherry-pick what it will and won't do to make it maximally beautiful.
|
||||
Conventional thinking is "failure is not an option" for general purpose operating systems. Since this OS is used in addition to Windows or Linux, however, failure is an option -- just use Windows or Linux if you can't do something. I cherry-pick what it will and won't do, to make it maximally beautiful. The following applications more or less form a basis that spans the range of use that TempleOS is intended for:
|
||||
|
||||
$LK,"/Demo/Games/BattleLines.CPP",A="FI:::/Demo/Games/BattleLines.CPP"$
|
||||
$LK,"/Demo/Games/BigGuns.CPP",A="FI:::/Demo/Games/BigGuns.CPP"$
|
||||
$LK,"/Demo/Games/BlackDiamond.CPP",A="FI:::/Demo/Games/BlackDiamond.CPP"$
|
||||
$LK,"/Demo/Games/BomberGolf.CPP",A="FI:::/Demo/Games/BomberGolf.CPP"$
|
||||
$LK,"/Demo/Games/CastleFrankenstein.CPP",A="FI:::/Demo/Games/CastleFrankenstein.CPP"$
|
||||
$LK,"/Demo/Games/CharDemo.CPP",A="FI:::/Demo/Games/CharDemo.CPP"$
|
||||
$LK,"/Demo/Games/CircleTrace.CPP",A="FI:::/Demo/Games/CircleTrace.CPP"$
|
||||
$LK,"/Demo/Games/Collision.CPP",A="FI:::/Demo/Games/Collision.CPP"$
|
||||
$LK,"/Demo/Games/Digits.CPP",A="FI:::/Demo/Games/Digits.CPP"$
|
||||
$LK,"/Demo/Games/DunGen.CPP",A="FI:::/Demo/Games/DunGen.CPP"$
|
||||
$LK,"/Demo/Games/EagleDive.CPP",A="FI:::/Demo/Games/EagleDive.CPP"$
|
||||
$LK,"/Demo/Games/ElephantWalk.CPP",A="FI:::/Demo/Games/ElephantWalk.CPP"$
|
||||
$LK,"/Demo/Games/FlapBat.CPP",A="FI:::/Demo/Games/FlapBat.CPP"$
|
||||
$LK,"/Demo/Games/FlatTops.CPP",A="FI:::/Demo/Games/FlatTops.CPP"$
|
||||
$LK,"/Demo/Games/Halogen.CPP",A="FI:::/Demo/Games/Halogen.CPP"$
|
||||
$LK,"/Demo/Games/MassSpring.CPP",A="FI:::/Demo/Games/MassSpring.CPP"$
|
||||
$LK,"/Demo/Games/Maze.CPP",A="FI:::/Demo/Games/Maze.CPP"$
|
||||
$LK,"/Demo/Games/RainDrops.CPP",A="FI:::/Demo/Games/RainDrops.CPP"$
|
||||
$LK,"/Demo/Games/RawHide.CPP",A="FI:::/Demo/Games/RawHide.CPP"$
|
||||
$LK,"/Demo/Games/Rocket.CPP",A="FI:::/Demo/Games/Rocket.CPP"$
|
||||
$LK,"/Demo/Games/RocketScience.CPP",A="FI:::/Demo/Games/RocketScience.CPP"$
|
||||
$LK,"/Demo/Games/Squirt.CPP",A="FI:::/Demo/Games/Squirt.CPP"$
|
||||
$LK,"/Demo/Games/TheDead.CPP",A="FI:::/Demo/Games/TheDead.CPP"$
|
||||
$LK,"/Demo/Games/TicTacToe.CPP",A="FI:::/Demo/Games/TicTacToe.CPP"$
|
||||
$LK,"/Demo/Games/TreeCheckers.CPP",A="FI:::/Demo/Games/TreeCheckers.CPP"$
|
||||
$LK,"/Demo/Games/Varoom.CPP",A="FI:::/Demo/Games/Varoom.CPP"$
|
||||
$LK,"/Demo/Games/Wenceslas.CPP",A="FI:::/Demo/Games/Wenceslas.CPP"$
|
||||
$LK,"/Demo/Games/Whap.CPP",A="FI:::/Demo/Games/Whap.CPP"$
|
||||
$LK,"/Demo/Games/Zing.CPP",A="FI:::/Demo/Games/Zing.CPP"$
|
||||
$LK,"/Demo/Games/ZoneOut.CPP",A="FI:::/Demo/Games/ZoneOut.CPP"$
|
||||
$LK,"/Apps/Psalmody/Examples/childish.CPP",A="FI:::/Apps/Psalmody/Examples/childish.CPP"$
|
||||
$LK,"/Apps/Psalmody/Examples/night.CPP",A="FI:::/Apps/Psalmody/Examples/night.CPP"$
|
||||
$LK,"/Apps/Psalmody/Examples/prosper.CPP",A="FI:::/Apps/Psalmody/Examples/prosper.CPP"$
|
||||
|
||||
Two things to know about TempleOS are that $UL,1$tasks$UL,0$ have $LK,"MAlloc",A="MN:MAlloc"$/$LK,"Free",A="MN:Free"$ heap memory, not applications, and tasks have compiler symbol tables that persist at a scope like environment variables in other operating systems, and the symbols can include functions.
|
||||
|
||||
@@ -73,7 +107,7 @@ $FG,2$<ALT-h>$FG$ horizontally tiles windows.
|
||||
The $FG,2$ALT$FG$ keys are defined in $LK,"~/HomeKeyPlugIns.CPP"$. You can customize them.
|
||||
|
||||
$FG,2$<CTRL-ALT-t>$FG$ new terminal window.
|
||||
$FG,2$$FG,2$<CTRL-ALT-n>$FG$ switches to the next window.
|
||||
$FG,2$<CTRL-ALT-n>$FG$ switches to the next window.
|
||||
$FG,2$<CTRL-ALT-x>$FG$ kills a window.
|
||||
|
||||
$LK,"Find",A="MN:Find"$() is your best friend. There's a wrapper function called $LK,"F",A="MN:F"$() in your $FG,2$~/HomeWrappers.CPP.Z$FG$ file. Feel free to make wrapper functions for functions you use often and customize the args. By the way, $LK,"Find",A="MN:Find"$() or $LK,"R",A="MN:R"$() can be used to replace strings across multiple files. You can access $LK,"Find",A="MN:Find"$() using $FG,2$<CTRL-SHIFT-f>$FG$.
|
||||
@@ -82,14 +116,21 @@ As you browse code, use the $FG,2$AutoComplete$FG$ window to look-up functions,
|
||||
|
||||
Use the $LK,"Help & Index",A="FI:::/Doc/HelpIndex.TXT"$ or $LK,"Demo Index",A="FI:::/Doc/DemoIndex.TXT"$ to find-out what exists. Press $FG,2$<F1>$FG$ for help or use the links on your menu ($FG,2$<CTRL-m>$FG$). Also, look in the $FG,2$/Demo$FG$ or $FG,2$/Apps$FG$ directories for inspiration.
|
||||
|
||||
3rd parties can make TempleOS software. It will be distributed as $LK,"RedSea ISO Files",A="MN:RedSeaISO"$. Burn a CD/DVD, or in a $FG,2$QEMU$FG$$FG$, $FG,2$VMware$FG$ or $FG,2$VirtualBox$FG$, set your CD/DVD to point to the ISO file. Then, access the $FG,2$'T'$FG$ drive. Or, $LK,"Mount",A="MN:Mount"$() the ISO file and access the $FG,2$'M'$FG$ drive. Ideally, do not install applications such as games onto your hard drive because we wish to keep hard drive usage low, so the whole $FG,2$'C'$FG$ drive can quickly be copied to $FG,2$'D'$FG$. Also, the $LK,"FileMgr",A="MN:FileMgr"$() starts too slowly with lots of hard drive files.
|
||||
Software is distributed as $LK,"RedSea",A="FI:::/Doc/RedSea.TXT"$ ISO files. Burn a CD/DVD, or set your CD/DVD in $FG,2$QEMU$FG$, $FG,2$VMware$FG$ or $FG,2$VirtualBox$FG$ to the ISO file. Then, access the $FG,2$'T'$FG$ drive. Or, $LK,"Mount",A="MN:Mount"$() the ISO.C file and access the $FG,2$'M'$FG$ drive in TempleOS. It must be a contiguous ISO.C file, so rename it under TempleOS to ISO.C.
|
||||
|
||||
Ideally, do not install applications such as games onto your hard drive because we wish to keep hard drive usage low, so the whole $FG,2$'C'$FG$ drive can be copied quickly to $FG,2$'D'$FG$. Also, the $LK,"FileMgr",A="MN:FileMgr"$() $FG,2$<CTRL-d>$FG$ starts too slowly when there are lots of hard drive files, but that is how we want it.
|
||||
|
||||
3rd party libraries are banned, since they circumvent the 100,000 line of code limit in the $LK,"TempleOS Charter",A="FI:::/Doc/Charter.TXT"$. All applications must only depend on the core TempleOS files and whatever they bring along in the ISO. This is similar to how Commodore 64 applications only depended on the ROM.
|
||||
|
||||
Create a $LK,"RedSea",A="FI:::/Doc/RedSea.TXT"$ 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\");"$
|
||||
|
||||
$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.
|
||||
* "QEMU" is a trademark owned by Fabrice Bellard.
|
||||
* "VMware" is a trademark owned by VMware, Inc.
|
||||
* "VirtualBox" is a trademark owned by Oracle.
|
||||
$FG$$FG$
|
||||
$FG$
|
||||
Reference in new issue
Block a user