Navigation

    Fuze Arena Logo
    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Popular
    • Users
    • Groups
    • Help
    • Discord

    A Persistent File System

    Work In Progress
    10
    21
    2424
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • spikey
      spikey F last edited by spikey

      @Gothon "draw the images in regular memory as an array of integers": are you referring to uploadImage()? So, you manually add ~256x256=65'536 / 2 (maybe as an average good encoding rate) = 30'000 characters by typing them into your code? and convert them to vectors (colors) to generate the image? - I think I am still missing a point. Recently I had a quick thought about converting a bitmap (as an easy format) to a vector array: to convert something like this to pass it to uploadImage() d6261e38-e0e2-4365-845c-4754b1ea4b9c-grafik.png.
      But that ends up in a lot of typing. I checked your FUZEGJ0103 jump project, but there you use the decent imagebuffer drawQuad() and to draw you use shapes. Ok, I feel like I am pestering you with questions - I will just follow your work with great interest. Congratulations, for that FAT system.

      Gothon 1 Reply Last reply Reply Quote 3
      • Gothon
        Gothon F @spikey last edited by

        @spikey No, I am not using uploadImage(). What I have is a prototype interactive drawing program so there isn't a need to have a big chunck of data in the source code.

        This is simplified but it works something like this:

        Function CPU_Plot(ImArr, Pos, ColIdx)
            int Idx = 256 * Pos.y + Pos.x
            int ByteIdx = Idx % 8
            Idx = Int(Idx / 8)
            ImArr[Idx] = bitFieldInsert(ImArr[Idx], 8 * ByteIdx, 7, ColIdx)
        Return VOID
        
        var Palette = [ white, platinum, lightGrey, silver ]
        
        int ImData[8 * 1024]
        var ImHandle =  CreateImage(256, 256, 0, Image_RGBA)
        
        // Initialize with an 8x8 checkerboard:
        SetDrawTarget(ImHandle)
        For Y = 0 To 8 Loop
            For X = 0 To 8 Loop
                int C = 2 + ((X + Y) % 2)
                CPU_Plot(ImData, {X, Y}, C)
                Plot(X + 1, Y + 1, Palatte[C])
            Repeat
        Repeat
        
        Loop
            SetDrawTarget(FrameBuffer)
            Clear(SkyBlue)
            DrawImage(ImHandle, 100, 100, 2)
            Update()
            // Do Input Handling here
        Repeat
        

        It keeps the data both in main memory and video memory and keeps them synchronized throughout the program so no explicit uploading is needed. Although I do have a function to copy the whole array to the image buffer. I use it occasionally for debugging.

        1 Reply Last reply Reply Quote 4
        • spikey
          spikey F last edited by

          @Gothon Thank you for taking your time to share this 👍. I will definitively need some daylight and a tee to absorb this properly.

          1 Reply Last reply Reply Quote 3
          • Gothon
            Gothon F last edited by Gothon

            I have re-shared an update. The download code is the same.

            The file system structure is also the same, so if you have pre-existing files, the new code should load them. However you must be careful not to overwrite the project with the new one as that would erase the files and instead only copy-paste the source code.

            This update contains the previously mentioned improvements and a new file/folder copy/paste feature.

            1 Reply Last reply Reply Quote 3
            • Gothon
              Gothon F @Gothon last edited by Gothon

              @Gothon said in A Persistent File System:

              there could be bugs I haven't found. I haven't even tested the File Table when it needs more than 1 block (at around 64kb file system size).

              As it turns out, there was a bug with the FAT when the File System reached 64kb size. I have fixed the bug and resubmitted. The fix involved moving the position of each FAT record by 1 position so previously made File Systems will not load correctly with the new code.

              I now also have the file system code working properly with my 'Image Editor' which is part of my ongoing textured 3D model editor project. I have decided that the file system is now stable enough and the image editor is complete enough to share publicly as-well. This project has a complete touchscreen enabled interface and reflects my more recent work improving the interface to the file system.

              2020081416465400-86FC867622BE2C2315A009D470F52DAE.jpg
              The share code for the "Image File Editor Preview" is: 7VK73CYH9L (live)

              1 Reply Last reply Reply Quote 13
              • PB____
                PB____ last edited by

                This does a lot of things really well. Clearly a lot of work has gone into this, and the result is impressive! :)

                1 Reply Last reply Reply Quote 3
                • vinicity
                  vinicity F @Gothon last edited by vinicity

                  @Gothon said in A Persistent File System:

                  Share Code: N5XQ3RND9L (live)

                  This is quite amazing. Any chance that you will be adding a text editor as well?

                  Gothon 1 Reply Last reply Reply Quote 0
                  • Gothon
                    Gothon F @vinicity last edited by

                    @vinicity Sorry, I am not planning on making a text editor at the moment. It would certainly make the demo much better. Although the text entry box produced by the input() command is almost a text editor by itself. If it were to just take a parameter for initial contents of the box, I could load the file contents into it and it would really seem like one. (especially if the noise it now makes in v2.15.0 is also fixed)

                    Also, I have re-shared the two programs in this thread with fixes for Fuze v2.15.0. Mostly it was just a lot of places where Ref was added to function parameters.

                    If you have a prior file-system you want to retain, be careful not to overwrite the old project with the new one, and instead only copy the source code from the new project over to the code of the old project. That way you can get the new code without overwriting the persistent file.

                    1 Reply Last reply Reply Quote 2
                    • T
                      tony7059 last edited by

                      Thanks for all your hard work! I've not programmed at that level in a long time. I can remember a book I had for C language that was dedicated to coding a GUI system... windows, menu bar, dropdown menus with hotkey options. So, you not only had the code to process these GUI components, you of course had to develop the API to manipulate things as a consumer of those services! Back in the day, memory was so cheap, and I recall there being some kind of technique that someone had used to store a multitude of texts for a relatively large program in its day. I think it had to do with base 64 and you got me thinking about this lower level stuff now, so now I have to go see if I can find information on it : )

                      1 Reply Last reply Reply Quote 1
                      • Gothon
                        Gothon F last edited by

                        I have updated these programs today. Most of the changes minor, however there are a couple of bug-fixes, including a fix for a serious bug discovered by @joyrider3774

                        1. Missing ref bug
                        • Affects the first program "File System Demo" N5XQ3RND9L not the second one "Image Editor Preview".
                        • Can cause file-system corruption if you make a file or a directory larger than one block (512 bytes) in size. Once corrupted a program may crash on startup while loading the file-system. This can be fixed by formatting the system with the FS_Format() function, however all data will be lost.
                        • Caused by the keyword ref missing from the first argument of the function FS_SetFAT(Ref FS, H, B, Next) and can be easily fixed by manually adding the ref to that function.
                        1. Floating point division inaccuracy.
                        • Affects both programs
                        • Potentially cause problems when large values are present such as file sizes as small as about 10MB (but still smaller than the design maximum of ~248MB)
                        • Fixed by replacing inaccurate floating point division with accurate integer division or equivalent bit shift operations throughout the program.
                        monkeee 1 Reply Last reply Reply Quote 6
                        • monkeee
                          monkeee F @Gothon last edited by

                          @gothon The ID codes listed here don't work anymore. It says project not found when I enter the code

                          Gothon 1 Reply Last reply Reply Quote 0
                          • Gothon
                            Gothon F @monkeee last edited by Gothon

                            @monkeee It seems that my shared programs have switched to 'private' status and changed codes. I will resubmit the programs here, so people can get them after they have been approved again.

                            The new ID codes are:
                            "File System Demo" - EPK73MQN7L
                            "Image File Editor Preview" - D5WT6MND9L
                            (live)

                            1 Reply Last reply Reply Quote 4
                            • HeyoMayo
                              HeyoMayo F last edited by HeyoMayo

                              great! now make a operating system (sarcasm), this is really impressive and WOW you made a image editor?!

                              1 Reply Last reply Reply Quote 1
                              • First post
                                Last post