<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="generator" content="TempleOS V5.03">
<meta name="viewport" content="width=device-width">
<link rel="stylesheet" href="/style/templeos.css">
<script src="/script/templeos.js"></script>
<style type="text/css">
.cF0{color:#000000;background-color:#ffffff;}
.cF1{color:#0000aa;background-color:#ffffff;}
.cF2{color:#00aa00;background-color:#ffffff;}
.cF3{color:#00aaaa;background-color:#ffffff;}
.cF4{color:#aa0000;background-color:#ffffff;}
.cF5{color:#aa00aa;background-color:#ffffff;}
.cF6{color:#aa5500;background-color:#ffffff;}
.cF7{color:#aaaaaa;background-color:#ffffff;}
.cF8{color:#555555;background-color:#ffffff;}
.cF9{color:#5555ff;background-color:#ffffff;}
.cFA{color:#55ff55;background-color:#ffffff;}
.cFB{color:#55ffff;background-color:#ffffff;}
.cFC{color:#ff5555;background-color:#ffffff;}
.cFD{color:#ff55ff;background-color:#ffffff;}
.cFE{color:#ffff55;background-color:#ffffff;}
.cFF{color:#ffffff;background-color:#ffffff;}
</style>
</head>
<body>
<pre style="font-family: courier, monospace; font-size: 10pt;">
<a name="l1"></a><span class=cF5>                                  Block Chain</span><span class=cF0>
<a name="l2"></a>
<a name="l3"></a>There was a technique on the Commodore 64 where disk blocks were chained 
<a name="l4"></a>together with a block pointer at the end of each block.  This is far inferior to 
<a name="l5"></a>having a file allocation table, as in FAT32.
<a name="l6"></a>
<a name="l7"></a>The </span><a href="/Wb/Doc/RedSea.DD.HTML#l1"><span class=cF4>RedSea</span></a><span class=cF0> file system does not allow files to grow because it only has an 
<a name="l8"></a>allocation bitmap and not a FAT table.  This &quot;flaw&quot; is by design.  I am 
<a name="l9"></a>intentionally crippling this operating system, making it a toy with the wisdom 
<a name="l10"></a>that this will prevent commercialization and corruption.  The toy spirit of the 
<a name="l11"></a>operating system will be preserved going into the future.  The vision for this 
<a name="l12"></a>operating system was a modern Commodore 64, which was a fun toy.
<a name="l13"></a>
<a name="l14"></a>Doing whole file operations is the TempleOS way of doing thinks.  It is the 
<a name="l15"></a>simplest and, ironically, the fastest.  It is obnoxious in the characteristic 
<a name="l16"></a>way that TempleOS is obnoxious, flaunting massive modern resources in a way that 
<a name="l17"></a>makes old programmers protest.
<a name="l18"></a>
<a name="l19"></a>Doing whole file operations will sabotage efforts to change the 640x480 
<a name="l20"></a>resolution and violate the ban on multimedia.  When doing large, whole-file 
<a name="l21"></a>operations, immediately memory fragmentation is a serious problem, but not so 
<a name="l22"></a>for allocations in the range under a Meg (with occasional larger ones).
<a name="l23"></a>
<a name="l24"></a>The file compression scheme in TempleOS only works on whole file operations and 
<a name="l25"></a>the </span><a href="/Wb/Doc/DolDoc.DD.HTML#l1"><span class=cF4>DolDoc</span></a><span class=cF0> format cannot have text tacked onto the end, since binary data is at 
<a name="l26"></a>the end.
<a name="l27"></a>
<a name="l28"></a>I don't want to spoil fun, so of course I offer a way to get awesome performance 
<a name="l29"></a>that is, ironically, superior.  </span><a href="/Wb/Kernel/BlkDev/DskCFile.HC#l129"><span class=cF4>FBlkRead</span></a><span class=cF0>() and </span><a href="/Wb/Kernel/BlkDev/DskCFile.HC#l181"><span class=cF4>FBlkWrite</span></a><span class=cF0>() allow you to read a 
<a name="l30"></a>block offset from the start of a file.  Since files are all contiguous, this is 
<a name="l31"></a>incredibly efficient.  You just have to declare the desired file size when you 
<a name="l32"></a>create it with </span><a href="/Wb/Kernel/BlkDev/DskCFile.HC#l9"><span class=cF4>FOpen</span></a><span class=cF0>() and cannot change it.  See </span><a href="/Wb/Demo/Dsk/DataBase.HC#l1"><span class=cF4>::/Demo/Dsk/DataBase.HC</span></a><span class=cF0>.
<a name="l33"></a>
<a name="l34"></a>If you like, you are encouraged to to do raw </span><a href="/Wb/Kernel/BlkDev/DskBlk.HC#l31"><span class=cF4>BlkRead</span></a><span class=cF0>() and </span><a href="/Wb/Kernel/BlkDev/DskBlk.HC#l71"><span class=cF4>BlkWrite</span></a><span class=cF0>() directly 
<a name="l35"></a>on a drive.  Just get a pointer to a </span><a href="/Wb/Kernel/KernelA.HH#l2688"><span class=cF4>CDrv</span></a><span class=cF0> with </span><a href="/Wb/Kernel/BlkDev/DskDrv.HC#l188"><span class=cF4>Let2Drv</span></a><span class=cF0>() and you are on your 
<a name="l36"></a>way!  Your computer is supposed to be a fun toy!  You can make an entire 
<a name="l37"></a>partition used for a database, or invent a file system.
<a name="l38"></a>
<a name="l39"></a>On the whole, the </span><a href="/Wb/Doc/RedSea.DD.HTML#l1"><span class=cF4>RedSea</span></a><span class=cF0> file system with its whole-file-only limitation bring 
<a name="l40"></a>beautiful harmony.  It beautifully captures the spirit of TempleOS with 
<a name="l41"></a>simplicity and, ironic speed, since contiguous is fastest.
<a name="l42"></a>
<a name="l43"></a></span><span class=cF8>
<a name="l44"></a>* &quot;Commodore 64&quot; is a trademark owned by Polabe Holding NV.
</span></pre></body>
</html>