Open discussion about features to implement in FAT32/16 file system.
Kye
Posts: 2,200
Hey guys,
If you read the post about how to navigate arround microsoft FAT 32 long file name patents you'll notice my post about a new file system I'm working on.
The features I plan to implement include:
Reading·a Byte - Can be extened for reading a word/long and using other libraries then reading strings.
Writing a Byte - Can be extened for·writing a word/long and using other libraries then·writing strings.
Setting read or write location within a file (all files opened for writing are opened in append mode) - file seek.
Opening a file.
Closing a file (Since everything is fully buffered all files must be closed or data will not be written to disk).
Making a new file.
Deleting a file.
Renaming a file or folder.
Changing directories.
Searching the current directory.
Listing information about files or directories.
Listing the file's name.
Listing the file's size.
Listing·last modification date/time.
Listing last acess date.
Listing·creation date/time.
Listing file attributes - and change them.
And formating the card as FAT16 or FAT32.
I have full support for file name string entry so you can be very lazy and unorthadox when entering file names and they will be handled properly.
...
Now, the file system is about %70 done as of right now, the current code size is well under 1000 longs right now.
I am opening this dicussion to talk about any other features that people would want.
I do not plan to implement long file names because of all the extra space that would be needed for the extra benifit of using them while they offering nothing of real value. (Files with long file names still need to have short file names so you can't have two files with long names that are similar).
However, I'm interested in hearing about these topics below·and any other feature that would be nice:
Is folder creation needed? It will require alot of extra code because the operation is not simple...
Is folder deletion needed? It will require alot of extra code because the operation is not simple...
...
Now for any other features that would be needed please speak up. Thank you!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
If you read the post about how to navigate arround microsoft FAT 32 long file name patents you'll notice my post about a new file system I'm working on.
The features I plan to implement include:
Reading·a Byte - Can be extened for reading a word/long and using other libraries then reading strings.
Writing a Byte - Can be extened for·writing a word/long and using other libraries then·writing strings.
Setting read or write location within a file (all files opened for writing are opened in append mode) - file seek.
Opening a file.
Closing a file (Since everything is fully buffered all files must be closed or data will not be written to disk).
Making a new file.
Deleting a file.
Renaming a file or folder.
Changing directories.
Searching the current directory.
Listing information about files or directories.
Listing the file's name.
Listing the file's size.
Listing·last modification date/time.
Listing last acess date.
Listing·creation date/time.
Listing file attributes - and change them.
And formating the card as FAT16 or FAT32.
I have full support for file name string entry so you can be very lazy and unorthadox when entering file names and they will be handled properly.
...
Now, the file system is about %70 done as of right now, the current code size is well under 1000 longs right now.
I am opening this dicussion to talk about any other features that people would want.
I do not plan to implement long file names because of all the extra space that would be needed for the extra benifit of using them while they offering nothing of real value. (Files with long file names still need to have short file names so you can't have two files with long names that are similar).
However, I'm interested in hearing about these topics below·and any other feature that would be nice:
Is folder creation needed? It will require alot of extra code because the operation is not simple...
Is folder deletion needed? It will require alot of extra code because the operation is not simple...
...
Now for any other features that would be needed please speak up. Thank you!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Comments
Long file names and directory creation/deletion I can live without.
Perhaps last access time should be optional as it means for every read there is a write to update the time. Not good for performance.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I've been playing with the uDrive and talking to it in Z80 assembly so have found out which are the important commands. I think you already have them all covered - read file, write file, erase, directory listing and change directory. File size is extremely useful as you can read a file size and then you know exactly how many bytes to read. I see you have that covered too.
Folder creation and deletion would not be that important as you can build any folder structure via a PC.
The uDrive uses a format where you get bytes in 64 byte packets and then an acknowledge byte. But I think your method would be simpler and quicker - eg set the read/write location and then start reading and writing bytes. Generally one just wants to read or write a file so you start at the beginning. But with read your could always change the pointer to somewhere in the middle of the file and read a record eg 128 bytes. And yes, files have to be closed at the end. Writing to random locations within a file - I've never needed that in code, as I tend to make lots of little text/data files rather than try to put it all into one big text data file. Heater might need this though...
Sometimes you want to read and write files one line at a time, rather than one record at a time (particularly text files). I've written some little subroutines in basic to do that. eg printline and lineinput. These just use CRLF as the end of line marker. Your code would make that very easy. I've ended up with 5 useful subroutines I use all the time - open file, lineinput, printline, close file, and filesize. There is a slight change in coding order depending on whether you get the filesize at the beginning and then read until a counter goes > that number, or whether there is an EOF flag that gets set when you try to read a byte that is 1 greater than the file size.
Addit - a question. How does it fail? eg you leave a file open then try to open a new file. Do you get an error message/flag back?
I think you have it all covered. Well done!
Post Edited (Dr_Acula (James Moxham)) : 7/6/2009 12:24:49 AM GMT
The last acess time and such is only written when the file is closed. Thus it does not degrade preformance.
And, I can add block read and write of up to 512 bytes at a time. That's actually easier that reading a byte at a time.
...
@Dr_Acula (James Moxham)
So each method returns 3 things unless I said it would just be true or false.
If the method suceeds it returns a pointer to a string (the pointer is always to the same location) what's important is that the string has length.
If the method cannot process the request because some input vector is bad it returns a pointer to a string of zero length.
if the method fails with the file system crashing (like block read and write failed) the method returns false.
So basically if it returns true it usually suceeded unless you gave it the wrong input data.
Now, it any method fails the card is automatically unmounted so that no other operation may be done. This is because there is no way to know what fails, (eg. you removed the card and put another one in). So, if anything fails you just call the mount method to remount the card (the card must be mounted also when starting the driver.)
This makes it easy to do logic on the returns inteligently and no messy aborts are used.
... Also the open file command closes any previously opened file. The driver also has a few flags to keep you from easily breaking anything. Such as all functions not relating to file read/write are disabled if a file is opened through a simple if statement.
...
Um, would EOF be needed? Since they aren't actually in the file itself. Right now I just return the last byte in the file continually if you try to read past it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
The thing is that what Kye is doing might be really really useful for CP/M emulations. CP/M has this limitation of 8Mb for the biggest hard drive you can have. Ok, I know you could have drive A-Z and get around it that way. And yes, CP/M doesn't support directories.
But with Kye's code, CP/M could read FAT files directly. I've got something similar working with the uDrive from 4dsystems, but it still isn't perfect, especially as it uses serial transfer and so files sometimes take a minute to load (at 38k).
But Kye says he has buffers. Well, with a buffer you can do all sorts of things. If we can get into the part of CP/M code that does disk I/O (which is pretty simple to do), then all you need to do is trap a few things. There are BDOS commands in assembly to open a file, close a file, write a record, read a record etc. From the CP/M point of view, you might open a file and write 128 bytes to a random location in that file then close it. Well, if Kye buffers that data, it ought to be possible to then go and read in the original file in spin/pasm, modify the 128 bytes at a random location and then save it again. Suddenly you can have access to a drive in CP/M with gigabytes of storage that are standard FAT files. I'm doing this with the UDrive and it makes file transfer much easier as you don't have to put files into a disk image first. Just put them on a sd card and then CP/M can use them. But, the uDrive is slow.
Kye's code is going to have all sorts of other applications too. It will form the basis of a DOS that will have much of the functionality of CP/M - ie the ability to load and run files, the ability to run a program that reads data off seperate text files that you can edit in notepad, and I'm sure with the prop editor, you can edit the files locally too.
Here is a bit of a crazy idea. You create a disk image with drive A that contains the boot for CP/M etc, exactly as the zicog/triblade does. But in that disk image you modify CP/M so that any BDOS calls to drive B will access all the FAT files on the sd card. I'm going to have a think about what that would look like in assembly...
Re "Now, it any method fails the card is automatically unmounted so that no other operation may be done" - yes and better to fail in a controlled way than to write rubbish data to a card and potentially corrupt it and stop other files working.
Re mounting - yes I guess you have to do that. The uDrive needs this too, so there is one more progam I called uStart which mounts the drive. I ended up putting that in an autoexec on startup so it starts up working. But if you changed cards, I suppose you need some sort of meaningful error to come back. Even Windows can get unhappy if you swap CDs half way through reads. Is there some way of detecting that a sd card has been changed? eg a unique ID number for a card? Or a directory listing and then you detect if that listing has changed?
Re EOF, well maybe we can learn something from the mistakes of the past. One mistake (IMHO) CP/M made was to use ^Z as the end of file marker. But that only applied to text files, and if you used the same marker for, say, a compiled program that had random bytes, sooner or later a ^Z would come up and it would think it was the end of the file. So no EOF marker bytes! But you can still return something similar if you already know the file size. All it needs to do is fail gracefully, eg just return an error flag/message if you try to read past the end of a file. Or just keep returning the last byte. It would only happen due to poor programming anyway as you would normally get the filesize first and then read those number of bytes. So your solution would be perfect.
The key would be to make it impossible to crash. And if you did that, it would be better than windows! And it sounds like you already have managed to do that, so this is really cool.
A question re buffers, is the max file size going to be limited by the ram inside a propeller?
Post Edited (Dr_Acula (James Moxham)) : 7/6/2009 2:34:12 AM GMT
And for buffers, I just use one 512 byte buffer to do everything. All the work is managed within the driver.
You can of course transfer data from that buffer to other data areas in the propeller chip and save that data for later, or transfer that data out to external ram.
...
Hopefully more suggetions will be one their way. Please everyone chip in if you have an idea.
Oh, and I have managed to code file/folder delete. And file folder creation.
File/folder creation takes alot of code
and..
file/folder delete is very small... but is very slow due to what operations need to go on because I am resuing code. Hopefully that will not be a problem.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Post Edited (Kye) : 7/6/2009 3:24:22 AM GMT
For our CP/M (and other) disk emulations a nice fast seek function would be useful. Currently we rely on writing CP/M (say) disk images onto newly formatted SD cards such their sectors are contiguous on the card. The emulator then finds the start block of a disk image file and uses the low level SD access routines to get to the right sectors by passing any FAT routines.
This works but is a bit clunky so a seek would be icing on the cake.
So it all sounds good to me.
Dr_A: I have often though about intercepting BDOS calls and redirecting them to DOS files. I think many people have done this in various emulators.
I have decided I will not be doing that because:
1) We can already run CP/M 3 which has the possibility of much larger disks.
2) I don't really have a need for huge files/disks under CP/M
3) I like the purity of running the original CP/M code from Digital Research
4) Following 3) means we can use SIMH AltairZ80 CP/M files unchanged without having to manage yet another CP/M version ourselves.
Which is not to say it is not an interesting thing to do.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
But Kye's routines bring a lot of things closer, as maybe you don't need the contiguous sectors any more?
From CP/M you might say "I want record 10" and from Kye's code, that might translate to "request bytes starting at 128*10=1280. Or for other sector sizes, it might be bytes at 10*512=5120.
If Kye is using 512 byte buffers, and you request bytes starting at x, and you get back 512 bytes but you only needed 128, well that doesn't really matter. So Kye's 512 buffer size would be a perfect size.
How fast is that request? And do you need to request each byte one at a time, eg sending one byte (or more) each time you want a byte? Or could you request a block of bytes, like CP/M does, where you request a block of 128, and when the subroutine finishes, there are 128 bytes sitting at a known location in memory that you can access. Block access would be faster. But then again, propeller calls to propeller subroutines may be so fast compared to sd reads that it may not matter if you are sending bytes to request bytes. Is that correct?
Post Edited (Dr_Acula (James Moxham)) : 7/6/2009 6:33:48 AM GMT
Something like:
offset := cpm_sector * 128
status := fs.seek (offset)
status := fs.read (@buffer, 128)
With whatever status return codes.
The normal negative return values for errors but positive return values for the actual number of bytes read would be great.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Your work is fantastic
As heater and Dr_Acula has said, we access the CPM disk(s) as contiguous file(s) on the SD card. I use the file access routines to locate the file(s) initially and save the first sector address of each file. Then, I just use the read/write low level routine to access blocks within the file(s). One thing that I am doing is that I only use the first 128 bytes of the 512 byte SD sector. This method is very fast, so I am quite happy to demand the files be contiguous.
One thing I added is that I had to find the first sector address of each file. I cannot recall how I did this - sdspiFemto just placed it into hub ram so I read it there.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Problem is we are in no position to demand such a thing. Perhaps Kye could provide some sort of API to force files written to be contiguous but that is of no use to us as we want to write these image files from MSDOS/Windows/Linux where we have no such control. In fact I'm sure there is no guarantee stated anywhere that what we do should work anyway.
The "clean" way to do it is with a seek to the required block of an image file. Then it does not matter if the image file is fragmented.
This suffers a performance hit so pragmatically we will probably continue to use the low level block access technique.
Ah..So what we really want to demand is that an existing contiguous file is guaranteed to remain contiguous when blocks within it are updated.
And an API function to return the first SD block of a file, for low level access.
"Demand" is such a strong word. Let's just ask nicely, pretty please, Kye.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The file(s) is a CPM file of fixed length and can be created immediately after formatting by a PC. I am assuming wear levelling is taken care of internally on the card, so if the sector is moved by the card, it is transparent to the user. Does anyone know if this assumption is correct?
I think later, it would be nice to use the whole FAT16/32 structure to store CPM files, but it is certainly not a priority. Further, without directories which we could then define as being different disk drives, placing the CPM files within the FAT16/32 system would be a backward step as we couldn't hold both CPM2 & CPM3 on the same SD card and switch between them.
Hope this explains things
I note Propeller files can already use the FAT16 structure.
P.S. I am using fixed files of 32MBytes for CPM, not that we can access all of it at this time. And I have 8 of them online at once for a possible total of 256MB. I am sure that is enough for CPM.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 7/6/2009 1:03:37 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
But the driver is built as a full featured FAt16/32 file system. So, you can make a file to be your operating system's hard drive then if you want.
...
So, the driver loads in 512 bytes at time from a file. Whenever the sector boundary is crossd the driver then loads in the next sector from the file. So, while you are inside one cluster you can seek back and forth in that cluster very easily.
However, FAT16/32 file system clusters are not contigous. That said, whenever you cross a cluster boundary the FAT must be interogated and then the new cluster is loaded up. While this is only a one extra sector read a problem still exist.
The FAT is a sigulary listed list. That said you can't go backwards. So, the seek method has to actually start at the begining of the first cluster in a file and read the FAt until it gets to where you are at. If your seeking to the same cluster your in the operation takes little time. Even better if its the same setor your in the operation takes no time. I have accelerated all my methods so that they do no work unless they need to with trigger points.
So, the driver only has one 512 byte buffer it does everything with. When its finished it will be about the same size as the current FSRW.
...
So don't fear guys, you won't need to do any low level stuff anymore. EVERYTHING is handled for you. Just use a file to act as the disk you wish to emulated and your done.
...
And for your request as long as you keeps the disk free of stuff and extra little bits the files will be mosttly contigous. The driver API will be faster that whatever you think you can come up with. I'm very good at optimizing spin code - very good.
In fact after I walk away from this code when finished I do think I'll be able to reead it anymore. Because I am doning some funky stuff with it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Re "But the driver is built as a full featured FAt16/32 file system. So, you can make a file to be your operating system's hard drive then if you want."
Kye, your code may well be the core of an operating system. What exactly are the commands in CP/M that are included? There are not very many. ERA to erase a file. DIR to list a directory. A B C etc to change drives. TYPE to dump a file to the screen. REN to rename a file. The ability to run batch files (if a file called $$$.SUB exists). That is it really. And if a command is not one of the above, then it must be the name of a .COM file, so go looking in the directory for that file and run it.
That is an operating system. All the 'extra' commands are actually programs, eg PIP (which is the same as COPY), WORDSTAR for text editing, and languages.
Dumb question here, but is it possible to run a compiled program on the propeller off an sd card? I see a lot of programs being run from eeprom, but the data on the eeprom is just a list of bytes, and these byte could exist anywhere. Is this what PropDOS does?
Post Edited (Dr_Acula (James Moxham)) : 7/6/2009 3:18:15 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
I look forward to using folders or directories but not necessarily creating them with Propeller.
I would also very much like to have "file handles" with multiple files open at once for manipulating files.
Also, I look forward to reading your PASM when you're done [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
We're here... [noparse]:)[/noparse]
Looking forward to playing with your released code!
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
I also have tackled the problem of loading contiguous vs non-contiguous files in my "generic" Catalina program loader. The way I solved it was to modify fsrw slightly to allow me to retrieve the cluster chain of a file - fsrw already had routines to do this (since they're necessary to traverse any file) but they were "private" - so I just made them "public". With this informaton, plus the cluster size, I can then then terminate fsrw and use a low level "sector" loader to load any file - even if it is non-contiguous. I can load any file into hub RAM reserving only about 1k (mostly for the single sector buffer). It would probably be possible to avoid the need even for that if I used cog ram to hold the buffer, but I don't really see the need to go that far.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
The block driver will need to be upgraded however, because it's in spin right now. But after that it will be good.
...
So my driver's nearing beta. Not sure when I'll be done however. I've tweaked the structure over 5 times now and I'm gettting tried going over every function and making sure it works.
Only things left to do however are file seek / file write / and making a new file or folder. I've already written the code structure for these three functions but it must be revised. Then I need to tweaked the structure again and take out some hard coding I used so that the driver can switch between FAT32 and FAT16 modes.
<Yawn> getting tired of looking at this code now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Great - just make sure you provide a way for external applications to retrieve the chain. When using fsrw, once I have opened a file I simply call a "nextcluster" routine which returns the current cluster and then steps to the next one in the file's cluster chain - eventually it returns an end of file indicator. As you say, it's a simple one line routine.
Also, it would be good if you kept your block driver in a separate object from the file system - this will allow porting your file system to other block devices. I'm sure someone will one day hook up a terabyte hard drive to the Propeller [noparse]:)[/noparse]
If you can handle FAT32 as well, then I look forward to using your software.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Not the fish.
sites.google.com/site/bitwinproject/
James: Yes, PropDos and PropCmd both can launch a xxxxxxxx.bin propeller binary. In fact, on bootup, it searches for autoexec.bin and launches it if present. This is one of the ways I use ZiCog - the eeprom contains propdos/propcmd.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
For example:
All files opened for reading are started at the first byte in that file. Then you can seek around in that file up to its file size.
However, for writing I open all file in append mode. That is I start the file at the first byte and read in each sector before writing it back out. While this is slower it makes sure that you have a predictable and easy to use driver format.
However, when in append mode I have no clue on how to resize the file or such because when you seek arround I don't actually know how big the file is any more.
It it weren't in append mode the file size would simple be you current byte position. When the file is closed then I could just free all clusters after that byte position. That would make writing to the file very easy.
But, then how should seeking arround work? I have never actually used file seek in a C program yet in writing or append more. I try mainly to keep my woking data in memory. So I have no clue how to approach this problem.
I am thinking however, that I should take way the ability to use file seek when writing... bu then that wouldn't be good, would it?
So, any suggestion on how this should work would be helpful.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
The low-level I/O driver used in FemtoBasic (sdspiFemto.spin) has a Spin program loader function for both EEPROM and SD cards. For SD cards, it requires that the Spin program is stored in a contiguous area of the SD card (a single extent normally) and the boot routine is passed the absolute starting address of the program on the SD card.
To run a new Spin program, FemtoBasic calls FSRW to get the starting address of the program, then calls the boot routine.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBladeProp, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I think that mode would be the most flexible.
So, I can just drop automatic resizing so that I never throw away any clusters allocated to a file. You would just need to delete the file and make a new one if you wanted to free up space.
But, the problem of file size still remains. How do I tell how big the file is after using file seek in write mode. Since you could close the file while you are in the middle of it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Post Edited (Kye) : 7/7/2009 3:06:06 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,