A Persistent File System
-
@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.
-
@Gothon Thank you for taking your time to share this 👍. I will definitively need some daylight and a tee to absorb this properly.
-
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.
-
@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.
The share code for the "Image File Editor Preview" is: 7VK73CYH9L (live) -
This does a lot of things really well. Clearly a lot of work has gone into this, and the result is impressive! :)
-
@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?
-
@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.
-
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 : )
-
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
- 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 functionFS_SetFAT(Ref FS, H, B, Next)
and can be easily fixed by manually adding theref
to that function.
- 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.
- Missing
-
@gothon The ID codes listed here don't work anymore. It says project not found when I enter the code
-
@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) -
great! now make a operating system (sarcasm), this is really impressive and WOW you made a image editor?!