TempleOSCDV4.08.ISO

Doc/FAQ.TXT

@@ -39,11 +39,11 @@ $ID,2$The refresh rate is $TX,"30",D="WINMGR_FPS"$ frames-per-second.  That is h
 $ID,-2$$TR,"How does a task own the speaker?"$
 $ID,2$No task or application has a lock on the speaker so apps will interfere with each other.
 $ID,-2$$TR,"Why does it leak memory?"$
-$ID,2$TempleOS allocs mem as more items are displayed in the window.  Also, TempleOS allocs mem for code as it is compiled at the cmd line.  If you $FG,2$#include$FG$ a file twice, it allocs more mem for it.  If you have a 50,000 line program with each line taking twenty bytes on a machine with 1 Gig, you could $FG,2$#include$FG$ it a thousand times if it had no data or graphics and no other use of mem.  If it bothers you, hit $FG,2$<CTRL-ALT-x>$FG$ and $FG,2$<CTRL-ALT-e>, $FG$periodically, to kill and recreate the task$FG$.  Use the pop-up flag on macros in your $LK,"PersonalMenu",A="FI:::Home/PersonalMenu.TXT"$ to spawn new tasks, run applications and free the applications when they are finished.  Small mem chunks stick to the task when they are freed until it is killed.  The only way to get in trouble is allocating multiple Meg chunks and freeing them.  These can only be reused if the same size gets alloced again.  Use $LK,"HeapLog",A="MN:HeapLog"$(), $LK,"HeapLogAddrRep",A="MN:HeapLogAddrRep"$() and $LK,"HeapLogSizeRep",A="MN:HeapLogSizeRep"$() to see who alloced mem and didn't free it.  See $LK,"MemOverview",A="FI:::/Doc/MemOverview.TXT"$.
+$ID,2$TempleOS allocs mem as more items are displayed in the window.  Also, TempleOS allocs mem for code as it is compiled at the cmd line.  If you $FG,2$#include$FG$ a file twice, it allocs more mem for it.  If you have a 50,000 line program with each line taking twenty bytes on a machine with 1 Gig, you could $FG,2$#include$FG$ it a thousand times if it had no data or graphics and no other use of mem.  If it bothers you, hit $FG,2$<CTRL-ALT-x>$FG$ and $FG,2$<CTRL-ALT-t>, $FG$periodically, to kill and recreate the task$FG$.  Use the pop-up flag on macros in your $LK,"PersonalMenu",A="FI:::Home/PersonalMenu.TXT"$ to spawn new tasks, run applications and free the applications when they are finished.  Small mem chunks stick to the task when they are freed until it is killed.  The only way to get in trouble is allocating multiple Meg chunks and freeing them.  These can only be reused if the same size gets alloced again.  Use $LK,"HeapLog",A="MN:HeapLog"$(), $LK,"HeapLogAddrRep",A="MN:HeapLogAddrRep"$() and $LK,"HeapLogSizeRep",A="MN:HeapLogSizeRep"$() to see who alloced mem and didn't free it.  See $LK,"MemOverview",A="FI:::/Doc/MemOverview.TXT"$.
 $ID,-2$$TR,"Why do I get a memory leak when editing big files?"$
 $ID,2$The editor periodically takes a snap-shot of the document for $FG,2$UNDO$FG$ and this looks like a memory leak.
 $ID,-2$$TR,"Why is it in text mode?"$
-$ID,2$TempleOS runs in $FG,2$VGA 640x480 16 color$FG$ graphics mode, not text mode.  It changes to this mode with a $LK,"BIOS call",A="FF:::/Kernel/KStart.CPP,INT 0x10"$ while in real-mode before it switches to 64-bit mode.  The text is $LK,"drawn by hand",A="MN:GrUpdateTextFG"$.  See $LK,"::/Kernel/Font8x8.CPP"$.  If graphics mode fails, it falls-back on text mode.  You can force text mode with an $LK,"Kernel config",A="FI:::/Kernel/KCfg.CPP"$ option.
+$ID,2$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$$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?"$