Dr A: Yes indeed. CP/M RAM space goes out to external memory. Only the emulation PASM and Spins sits in COG/HUB.
This is what Cluso has been doing for a long time now on the TriBlade board.
We can even do banked switched memory on the TriBlade and run bank switched CP/M 3 or MP/M. I don't think Cluso has got that working yet.
I have yet to make space and time to build up my TriBlade so I'm still squezzing a small CP/M into the DemoBoard.
Clusso: Yes I know, I tend to agree with you. Using the FAT FS with seek etc may make for some simple neat code but I would be surprised if it could have the performance of going staight to the SD driver. Using the FAT API exclusively only buys us the abilty to throw fragmented disk images onto cards, but I think we can live with that.
As for multiple drives on an SD card. I would love it if the FAT driver could support partitions !
A partition for FAT and a partition for CP/M. Then I'd just dd disk images to the raw non FAT partition. Bingo no worries about fragmentation.
How about it Kye ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Is your "R+" mode read/write or is it just seekable read?
Normally seekable read is just "r" (all open files are seekable if the
underlying device supports it) and "r+" means I want to be able to
*write* after I seek if I want.
(Note also that in general you have to seek or call getpos() to
switch between reading and writing, so seeking or getpos() actually
do more than just seek; they also set things up so the next operation
can be a read *or* a write.) That's why you specify "r+" rather than
"r"; fgetpos() may have to do more work than just return the
current file offset.
MRB supports change directory so the file system always has a single implicit
default directory. He does not (as far as I can ascertain) support path names
(i.e., a/b/c). This is good because it makes the code simple and short.
So on subdirectory support, would people prefer:
1. The filesystem maintain a current directory pointer, and all files be opened
with short names, or
2. The filesystem support filenames with paths with the requisite traversals on
all opens?
This becomes a much more interesting question when you consider multiple
files; you may not want to "change directory" just to open a file that is one
level down.
On the subdirectory question, it's also an encapsulation issue.
If an object you call changes the "current directory" of the file system, without
your knowledge, then the files you created may silently "disappear". So if
an object changes the current directory it needs to put it back before it returns.
There is a middle ground of course. The file system can have a current
directory, but a "path open" layer can be created that is the only subsystem
that actually uses it. The "path open" layer would take a path name and
use the "current directory" in the file system to perform the operation on that
path that is desired (like open file, create directory, etc.), but on entrance and
on return from the path layer, the "current directory" will always be the root
directory. This way, people can have it both ways.
You guys can take on support for those features if you want. All the files and stuff are found through two functions in my code.
ListName and ListDIR.
Listname simply gets the next DIR entry in the current directory that does not have its volume ID bit set and then activates the list functions so that they can return information about the file or directory in question.
ListDIR converters user entrered file names into DIR entry names. So if you type in "stuffMuch.binary" it will become "STUFFMUCBIN" for example.
By adding long file name support to these two functions you will then be able to us long file names.
...
For paths, that would be a complex feature since you would need to do alot of string phrasing. Possible by unessary for the current software.
...
@ Tom
What are you talking about? I'm confused. I think I answered something above... not sure.
My write mode is everything overwrite/append mode at the same time. Meaning that you can write anyware you want and extened the file. However the file will not shrink. You must delete it and start over to do so.
My read mode allows you to read anyware in the file.
My seek just moves you arround in the file. Read and write have an automatic step forward but the seek function allows you to travel anyware.
...
@OldbitCollector
I'll have a alpha/beta piece of code posted sooner or later. Not sure when I'll get it done. I'm going on a family reunion on friday so I may not have internet over there. I will definately however be unable to develope and test the code as I will be without a monitor.
I may post something if I feel there's enough to test out.
Okay, everything but format is done. Most funtions have been logically tested but not actually tested.
My block driver really sucks it on writes. Seems to fail alot. I'm not sure if its my setup or the card or what. I'll have to setup a test enviorment later but not right now.
I'm posting the current alpha code now so you can take a look. Its almost ready.
...
If anyone can fix my block driver and get it working it would really be helpful so that I can test out the write functions. So far since the write command fails every now and then I do not know if everything is working.
I cannot simply use the current code for the FSRW block driver because mine is lightly different. It would be appreciated if the current code were just fixed and not a whole bunch on extra stuff was tacked on.
Hopefully, in the future a faster block driver can be made but for right now I'm using the slow spin to test everything out.
...
I'm gonna be taking a rest for the next few days. Have fun with the alpha source. Soon it will be beta ready.
Included is the alpha version of the driver and a RTC driver for the DS1307 on the I2C bus lines the propeller chip uses.
The driver has alot of testing code laying arround in the top level start function. Use this code as a refrence for what to do and change it work with your driver.
I also left the "listall" function lying there which will be your guide to figuring out how to use the list functions.
You will need to change my testing code however as I did not provide the videoEngine or libraryEngine drivers.
You will need to provide your own atoh, atoi, and video out functions.
Great work Kye. Multiple partitions are fantastic. We can house all our CPM file(s) = drive(s) in one partition and directly access into it for speed. With multiple partitions and directories (even with restrictions) the 8+3 should be fine. After all, this is NOT a (modern) PC as many have pointed out on other threads.
OBC: Just noticed my spelling mistake "here" -> "hear" OOPS! (I would rather say it was a typo but I guess you wouldn't believe that)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Not been monitoring this thread closely, but I thought I'd give it a whirl. Can you give me a pointer to the correct videoEngine.spin file you need to compile this?
The only version I can find on the forums doesn't seem to work.
Thanks,
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Technically, I have have·have mis-interpreted the definition·of R+ file access!!
My read mode supports read only... but allows the pointer to be randomly positioned anywhere within the file, where-as your original read mode was sequential access only.
2) The directory support....
You are quite correct with respect to how I navigate the directory structure.
I have included a demonstration file.
FYI, the FSRW_PLUS I patched was never really originally intended for public distribution.
It was for a college project I was assisting a freind with. (needed to log some data as daily CVS files, sorted by monthly directories, within year directories IE /2009/JUL/09TH.CVS
This file was released in the spirit of sharing and co-operation, that this forum (and the OBEX) are based around!!
So, I added the ability to write strings now and the ability to get your current position within a file.
I plan to also add the ability to get the volume ID and set the volume ID.
I also plan to add the ability to get the total disk size and get the free disk size.
...
Things to get working -> Format Card -> The block driver
...
As for volume ID, is this feature needed much? Does anyone want this feature?
I say this because it will not be entirely trival to get it working propeerly and by FAT32/16 design this feature may not always work.
Since long file names have their volume ID bit set there is a possibility that this function will not work returning the wrong volume ID name and may not be able to set the volume ID name.
I wouldn't worry too much about the Volume ID/Labels.· Stick to the basic file operations for the primary release.· If there's interest in Volume IDs/Labels, the necessary functions can be added on top of the primary release.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: Forum
OnePinTVText driver: ObExForum
I fixed the block driver finally, was due to chip select being improperlly used.
It will be a few more weeks before I'll be ready for beta. I need to optimize the current code even more as it takes about 1300 longs right now. I think I can bring it back down to a reasonable level however.
Okay, so, I've finished pretty much everything now. I just need to test all the file functions. I pretty much have every feature that you would ever need. You'll most likely want to start commenting out functions you don't need because I have so much stuff...
About 2000 lines about right now of code.
Anyway, so the last function I need to work on·is the format function. I'm not sure what to put in this funtion:
So, I can make it format the volume in FAT32 or FAT16, or I might be able to give it the intelligence to decide for itself. Which would be better?
I 'm thinking that you would pass it the partition number (0-3) and the size you want for the partition and it would then create it while being very careful. You would need to make a rough guess on the size of the partition however. But that shouldn't be a problem.
I can however add some low level functions that list the parition information and size. But the amount of code is getting quite large so I don't really want to add anything else.
Anyway, if anyone has any thoughts on this please speak up.
Kye, as I said previously, format is not a requirement for me. But I guess we may require this for multiple partitions anyway.
I think we would want to specify FAT16 or FAT32, since the purpose of multiple partitions may be for other systems which cannot cope with FAT32 and we may be fudging access from another level.
Just my thoughts. Great work
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Well after working on the format function for a while. Acutally creating the FAT16/32 file system is trival.
However, its a pain in the *** to allow the user to choose which parition they want to format and create.
Its just to much bound checking. Because you have 4 partition that could be located anyway on the volume. So I have to get the starts of each partition and size of each parition and then sort them into order. After that I would then have to find a hole of a certaint size and place the partition there.
Well... I think I'll just put a "freeALL" function that just takes an already valid FAT16 or FAT32 file system and then deletes everything on it.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Between what Matthew released at what it being discussed here,
it looks like PropDOS is in for an overhaul..
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
This is what Cluso has been doing for a long time now on the TriBlade board.
We can even do banked switched memory on the TriBlade and run bank switched CP/M 3 or MP/M. I don't think Cluso has got that working yet.
I have yet to make space and time to build up my TriBlade so I'm still squezzing a small CP/M into the DemoBoard.
Clusso: Yes I know, I tend to agree with you. Using the FAT FS with seek etc may make for some simple neat code but I would be surprised if it could have the performance of going staight to the SD driver. Using the FAT API exclusively only buys us the abilty to throw fragmented disk images onto cards, but I think we can live with that.
As for multiple drives on an SD card. I would love it if the FAT driver could support partitions !
A partition for FAT and a partition for CP/M. Then I'd just dd disk images to the raw non FAT partition. Bingo no worries about fragmentation.
How about it Kye ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I can make the mount partition method take a drive number argument. Then you could mount any partition you want. I'll do that right now actually.
...Yeah, that will be a safe feature to add because only a FAT16/32 drive will mount.The rest will all fail because they lack the BPB bootsector.
The partition will still be needed to be FAT16/32.
...
Um, file seek only has a preformance hit when you change clusters. If you keep inside of the same cluster is quite fast.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
FAT32/FAT16 support is now opperational, and you can choose which partition on the drive to mount.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Not far from the truth! The expo always wipes me out, but is totally worth it!
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
@Kye,
It's as if you guys lit two rocket boosters under the frsw project! Wow!
Do you have this code online somewhere for us to try it out?
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
Is your "R+" mode read/write or is it just seekable read?
Normally seekable read is just "r" (all open files are seekable if the
underlying device supports it) and "r+" means I want to be able to
*write* after I seek if I want.
(Note also that in general you have to seek or call getpos() to
switch between reading and writing, so seeking or getpos() actually
do more than just seek; they also set things up so the next operation
can be a read *or* a write.) That's why you specify "r+" rather than
"r"; fgetpos() may have to do more work than just return the
current file offset.
MRB supports change directory so the file system always has a single implicit
default directory. He does not (as far as I can ascertain) support path names
(i.e., a/b/c). This is good because it makes the code simple and short.
So on subdirectory support, would people prefer:
1. The filesystem maintain a current directory pointer, and all files be opened
with short names, or
2. The filesystem support filenames with paths with the requisite traversals on
all opens?
This becomes a much more interesting question when you consider multiple
files; you may not want to "change directory" just to open a file that is one
level down.
If an object you call changes the "current directory" of the file system, without
your knowledge, then the files you created may silently "disappear". So if
an object changes the current directory it needs to put it back before it returns.
There is a middle ground of course. The file system can have a current
directory, but a "path open" layer can be created that is the only subsystem
that actually uses it. The "path open" layer would take a path name and
use the "current directory" in the file system to perform the operation on that
path that is desired (like open file, create directory, etc.), but on entrance and
on return from the path layer, the "current directory" will always be the root
directory. This way, people can have it both ways.
ListName and ListDIR.
Listname simply gets the next DIR entry in the current directory that does not have its volume ID bit set and then activates the list functions so that they can return information about the file or directory in question.
ListDIR converters user entrered file names into DIR entry names. So if you type in "stuffMuch.binary" it will become "STUFFMUCBIN" for example.
By adding long file name support to these two functions you will then be able to us long file names.
...
For paths, that would be a complex feature since you would need to do alot of string phrasing. Possible by unessary for the current software.
...
@ Tom
What are you talking about? I'm confused. I think I answered something above... not sure.
My write mode is everything overwrite/append mode at the same time. Meaning that you can write anyware you want and extened the file. However the file will not shrink. You must delete it and start over to do so.
My read mode allows you to read anyware in the file.
My seek just moves you arround in the file. Read and write have an automatic step forward but the seek function allows you to travel anyware.
...
@OldbitCollector
I'll have a alpha/beta piece of code posted sooner or later. Not sure when I'll get it done. I'm going on a family reunion on friday so I may not have internet over there. I will definately however be unable to develope and test the code as I will be without a monitor.
I may post something if I feel there's enough to test out.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
My block driver really sucks it on writes. Seems to fail alot. I'm not sure if its my setup or the card or what. I'll have to setup a test enviorment later but not right now.
I'm posting the current alpha code now so you can take a look. Its almost ready.
...
If anyone can fix my block driver and get it working it would really be helpful so that I can test out the write functions. So far since the write command fails every now and then I do not know if everything is working.
I cannot simply use the current code for the FSRW block driver because mine is lightly different. It would be appreciated if the current code were just fixed and not a whole bunch on extra stuff was tacked on.
Hopefully, in the future a faster block driver can be made but for right now I'm using the slow spin to test everything out.
...
I'm gonna be taking a rest for the next few days. Have fun with the alpha source. Soon it will be beta ready.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
The driver has alot of testing code laying arround in the top level start function. Use this code as a refrence for what to do and change it work with your driver.
I also left the "listall" function lying there which will be your guide to figuring out how to use the list functions.
You will need to change my testing code however as I did not provide the videoEngine or libraryEngine drivers.
You will need to provide your own atoh, atoi, and video out functions.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
OBC: Just noticed my spelling mistake "here" -> "hear" OOPS! (I would rather say it was a typo but I guess you wouldn't believe that)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Not been monitoring this thread closely, but I thought I'd give it a whirl. Can you give me a pointer to the correct videoEngine.spin file you need to compile this?
The only version I can find on the forums doesn't seem to work.
Thanks,
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
To answer your two questions...
1) With respect to the read+ mode...
Technically, I have have·have mis-interpreted the definition·of R+ file access!!
My read mode supports read only... but allows the pointer to be randomly positioned anywhere within the file, where-as your original read mode was sequential access only.
2) The directory support....
You are quite correct with respect to how I navigate the directory structure.
I have included a demonstration file.
FYI, the FSRW_PLUS I patched was never really originally intended for public distribution.
It was for a college project I was assisting a freind with. (needed to log some data as daily CVS files, sorted by monthly directories, within year directories IE /2009/JUL/09TH.CVS
This file was released in the spirit of sharing and co-operation, that this forum (and the OBEX) are based around!!
Regards Mathew
Just replace the code there with vga_txt.
I'm just using print strings and print character functions.
You can aslo use "numbers" to get the atoi and atoh conversions.
The code lying arround is just a sample of what you should do.
I suggest just commenting all by the few intializers out and replacing the text with the standard stuff you find.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Oh - ok. I'll probably wait till there is a compilable version available.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
So, I added the ability to write strings now and the ability to get your current position within a file.
I plan to also add the ability to get the volume ID and set the volume ID.
I also plan to add the ability to get the total disk size and get the free disk size.
...
Things to get working -> Format Card -> The block driver
...
As for volume ID, is this feature needed much? Does anyone want this feature?
I say this because it will not be entirely trival to get it working propeerly and by FAT32/16 design this feature may not always work.
Since long file names have their volume ID bit set there is a possibility that this function will not work returning the wrong volume ID name and may not be able to set the volume ID name.
Should I add support for this or not?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
I have no need for Volume ID nor for formatting since I will preformat on a PC.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: Forum
OnePinTVText driver: ObEx Forum
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
It will be a few more weeks before I'll be ready for beta. I need to optimize the current code even more as it takes about 1300 longs right now. I think I can bring it back down to a reasonable level however.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
So far I've brought it down to about 900 longs. The 1300 was a vast overestimate.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
About 2000 lines about right now of code.
Anyway, so the last function I need to work on·is the format function. I'm not sure what to put in this funtion:
So, I can make it format the volume in FAT32 or FAT16, or I might be able to give it the intelligence to decide for itself. Which would be better?
I 'm thinking that you would pass it the partition number (0-3) and the size you want for the partition and it would then create it while being very careful. You would need to make a rough guess on the size of the partition however. But that shouldn't be a problem.
I can however add some low level functions that list the parition information and size. But the amount of code is getting quite large so I don't really want to add anything else.
Anyway, if anyone has any thoughts on this please speak up.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
Post Edited (Kye) : 7/17/2009 2:43:14 PM GMT
I think we would want to specify FAT16 or FAT32, since the purpose of multiple partitions may be for other systems which cannot cope with FAT32 and we may be fudging access from another level.
Just my thoughts. Great work
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Well after working on the format function for a while. Acutally creating the FAT16/32 file system is trival.
However, its a pain in the *** to allow the user to choose which parition they want to format and create.
Its just to much bound checking. Because you have 4 partition that could be located anyway on the volume. So I have to get the starts of each partition and size of each parition and then sort them into order. After that I would then have to find a hole of a certaint size and place the partition there.
Well... I think I'll just put a "freeALL" function that just takes an already valid FAT16 or FAT32 file system and then deletes everything on it.
Its kind like formating but alot less code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,