<!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 "flaw" 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>* "Commodore 64" is a trademark owned by Polabe Holding NV. </span></pre></body> </html>