PDA

View Full Version : Open discussion about features to implement in FAT32/16 file system.



Kye
07-06-2009, 07:42 AM
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,

heater
07-06-2009, 08:10 AM
What's with this read/write byte/word/long? I want 128, 256, 512... bytes at a time. You know, I have this thing about emulating old disk drive hardware.

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.

Dr_Acula
07-06-2009, 08:16 AM
That would be absolutely brilliant!

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

Kye
07-06-2009, 09:44 AM
@Heater

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) (http://forums.parallax.com/member.php?u=54943)

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,

Dr_Acula
07-06-2009, 09:49 AM
Heater, our posts crossed so not sure if you will read an edit on my post - so apologies for making this a new post.

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...

Dr_Acula
07-06-2009, 10:14 AM
Kye, that all sounds very logical. (crossed posts again - so I'll probably double post. It is all so exciting though!!)

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

Kye
07-06-2009, 10:58 AM
For remounting, the way I have it is the only safe way - I believe. I can get the card's information, but it makes little difference if the card were pulled out and then pushed back in. Thus I made it so that any error causes a need to remount.

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

heater
07-06-2009, 02:06 PM
Kye: Good point re:access times.
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.

Dr_Acula
07-06-2009, 02:16 PM
Yes Heater, I agree it probably is a bit of a dream at the moment to talk to dos files.

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

heater
07-06-2009, 02:31 PM
Yep. I'd love to be able to do away with the need for contiguous disk image file blocks. All it needs is a nice fast seek routine.

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.

Cluso99
07-06-2009, 06:20 PM
Hi Kye,
Your work is fantastic http://forums.parallax.com/images/smilies/smile.gif

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 (http://forums.parallax.com/showthread.php?p=786418), RamBlade (http://forums.parallax.com/showthread.php?p=810753), TwinBlade (http://forums.parallax.com/showthread.php?p=806697),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427)) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

heater
07-06-2009, 07:46 PM
Clusso: "so I am quite happy to demand the files be contiguous."

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.

Cluso99
07-06-2009, 08:58 PM
Sorry, I used "demand" to mean that the program I use requires the user to set the file up initially as a contiguous file. That means that I require they set it up this way to use the program because my access demands this, because it does not verify this, it assumes it. I didn't ask Kye to support this, mearely explaining what I use - and I would consider it to be an overhead not worthy of the space in his code.

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 http://forums.parallax.com/images/smilies/smile.gif and thanks Kye for your other contributions http://forums.parallax.com/images/smilies/smile.gif
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 (http://forums.parallax.com/showthread.php?p=786418), RamBlade (http://forums.parallax.com/showthread.php?p=810753), TwinBlade (http://forums.parallax.com/showthread.php?p=806697),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427)) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

Post Edited (Cluso99) : 7/6/2009 1:03:37 PM GMT

heater
07-06-2009, 09:11 PM
Sorry Cluso for reading you wrongly there. All seems well then.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Kye
07-06-2009, 10:57 PM
I'm sorry, I have no idea about CPM.

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,

Kye
07-06-2009, 11:00 PM
Are there only 3 other people on this forum?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Dr_Acula
07-06-2009, 11:11 PM
Yep, only 3.

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

Kye
07-07-2009, 01:36 AM
I have no clue. I'm just creating a file system. if you want to use it for cp/m go right ahead.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

jazzed
07-07-2009, 01:48 AM
Yep only 3 http://forums.parallax.com/images/smilies/wink.gif

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 :)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Oldbitcollector (Jeff)
07-07-2009, 06:46 AM
Kye said...
Are there only 3 other people on this forum?


We're here... :)

Looking forward to playing with your released code!

OBC

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?

Visit the: The Propeller Pages (http://www.warrantyvoid.us/tiki-index.php?page=Propeller) @ Warranty Void.

RossH
07-07-2009, 06:57 AM
@Kye,

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 (http://forums.parallax.com/showthread.php?p=795326)

Kye
07-07-2009, 07:10 AM
My driver follows the cluster chain very easily in essentially one line of code. You guys won't need to edit anything in my driver. It will all work very easily for you the fastest way possible.

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,

RossH
07-07-2009, 07:20 AM
@Kye,

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 :)

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 (http://forums.parallax.com/showthread.php?p=795326)

SciNemo
07-07-2009, 07:53 AM
This is all very exciting. Glad to know I have giants here to stand on http://forums.parallax.com/images/smilies/lol.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Not the fish.
sites.google.com/site/bitwinproject/ (http://sites.google.com/site/bitwinproject/)

Cluso99
07-07-2009, 02:30 PM
Kye - this is exciting http://forums.parallax.com/images/smilies/smile.gif

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 (http://forums.parallax.com/showthread.php?p=786418), RamBlade (http://forums.parallax.com/showthread.php?p=810753), TwinBlade (http://forums.parallax.com/showthread.php?p=806697),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427)) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

Kye
07-07-2009, 10:43 PM
Okay guys, how should I handle file writing and appending.

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,

mpark
07-07-2009, 10:49 PM
I don't think "append mode" means what you think it does. Append means to add at the end.

Mike Green
07-07-2009, 10:52 PM
Dr_Acula,
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.

Cluso99
07-07-2009, 10:58 PM
Kye: I think mpark is correct. You just need to support append at the end of the file. Insert is what you do to add o the middle of a file and I think this is too complex tobother with, certainly at the mment anyway.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), RamBlade (http://forums.parallax.com/showthread.php?p=810753), TwinBlade (http://forums.parallax.com/showthread.php?p=806697),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427)) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

Kye
07-07-2009, 10:59 PM
Okay, by append mode I mean overwrite/append mode·you can write stuff anyware you want into the file and also add stuff to the end.

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

Kye
07-07-2009, 11:02 PM
Mmm, okay, I could drop file seek support then for writing. That would greatly simplfy things.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

heater
07-07-2009, 11:25 PM
Kye: "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."

So what if I close the file? Is it not so that normally I would expect to be able to:
Open an existing file for write.
Seek into the middle of it somewhere.
Write something.

That something does not make the file any bigger immediately rather it just overwrites what is already in the file at that position. So if I close the file now it is the same size it was when I opened it.

Now if I continue writing stuff eventually I have replaced all of the file beyond my original seek position.
Continue writing more and the file starts to get bigger.

Presumably you know the size of the original file, you know the seek position, you know how much gets written, so you know the file size at all times.

In the Unix world whenever you open a file for append, you can ONLY write to the end of the file, no matter where you seek. Seek will not move the pointer for a write.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

ericball
07-08-2009, 12:05 AM
Requirements for my Z-machine interpreter:

Random read/write block/sector access within an existing file. Block/sector append to a new file. Two files opened simultaneously (i.e. read block/sector from one -> write block/sector to second) OpenDir / NextFile / Delete Ability to strip out unneeded routines (e.g. byte read/append, text helper functions) Minimum memory footprint (i.e. no file data buffering, just meta data buffering) ObEx/MIT License

I can probably roll my own, but if someone else is willing to do the heavy lifting...



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: http://forums.parallax.com/showthread.php?p=800114
NTSC & PAL templates: http://forums.parallax.com/showthread.php?p=803904

Kye
07-08-2009, 01:46 AM
@ericball

I won't give you multiple files open at once. It will be easy to extend my driver hower to supprt that. But to support two files open at once you will need to make all the functions take stream arguments that point to about 6 longs which control the funtions.

Its actually very easy to modify my driver to support multiple files open at once. But, for my first release and the ones essentially I'm concerened about I will only support one file open at a time.

You would have to change almost every funtion though so it takes a pointer. (Here's the thing however, I'm building this driver for entry level programers, high schoolers and maybe middle school kids, maybe even college. Not professionals. So I don't want them to worry about pointer when they don't need to.)

So, ericball, you'll get 1,2,4,5,6,7.

...

@heater

Good point, I was thinking mainly about if you wanted to resize the file. Lets say shrink it. But I think there's no way to offer that capability. I'm also guessing the way you shrink a file is simply to delete it and make a new one.

So, I'll do it your way heater. Thanks, for helping me get out of my own confusion.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Post Edited (Kye) : 7/7/2009 5:51:30 PM GMT

jazzed
07-08-2009, 03:15 AM
Not being able to have two open files at a time is a problem; I'll wait for the release with that feature.
Guess it would be good to see the file-system shake out beta bugs first anyway.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

Kye
07-08-2009, 03:44 AM
Well, I could make two sets of pointers. But then you also need a second buffer.... and you'll pretty much need to copy every variable and make every function take a pointer to those variable or that "structure" or variables.

I really don't want to do that work. But I'll post an explination on how to do it. You would need dat section with space allocated for every variable that controls file/folder acess. Then you would need to change each function so it accepts a pointer to a dat section and make sure each variable refrence is replace with a byte[], word[], or long[] thingy and an offset·to acess the variable.

Then you could have as many files open at once. It will just take you a few day's worth of work renaming all te functions and changing everything. No real thinking required.

...

- 90% done. Just need to slim down newfile/newfolder creation. Put in FAT32 support and make the auto switcher work, and get the format rountine working.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

jazzed
07-08-2009, 03:55 AM
You can't use an array of objects for all that work ?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

rokicki
07-08-2009, 04:16 AM
Actually, fsrw is pretty much set up for that to work (an array of File objects living on top of a single FileSystem object).
I just never did the work to complete it. But if you look at the source, the variables are all split appropriately. It just
needs the appropriate massaging.

This is something we plan for the very near future in fsrw. Sorry it's not in there yet.

Kye
07-08-2009, 04:52 AM
If you would like to do that rokicki then you can. I would reconmend that you try that on the source I'm about to present.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Kye
07-08-2009, 04:55 AM
Wait,

THAT'S RIGHT JAZZED. YOU COULD JUST MAKE ANOTHER COPY OF THE OBJECT. I FORGOT SPIN COULD DO THAT!!!

Wow, I never though that feature of spin would be useful!!!

Okay, then you can have as many files as you want.

Since the block driver rountine does not return until you're finished, you would need to do nothing at all.

The system I have setup then will allow you to have multiple files with multiple copies of the object.

The block driver I have only process on request at a time and is in spin, so everything will switch right for you.

Of course you'll need a second spin processor for the second block driver. But as long as there is only one processor running the top level code there will be no problems.

...

Well, then my driver has support for multiple files at a time.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Post Edited (Kye) : 7/7/2009 9:01:01 PM GMT

ericball
07-08-2009, 05:59 AM
The one caution with multiple files via a separate object for each is you should never have multiple files open for write simultaneously - or you risk having write-after-write conflicts in the FAT.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: http://forums.parallax.com/showthread.php?p=800114
NTSC & PAL templates: http://forums.parallax.com/showthread.php?p=803904

rokicki
07-08-2009, 06:21 AM
Not in my implementation, you won't.

Of course, I will not do your locking for you---if you try to access the file system from different cogs, I'm not going to manage
that for you. You'll have to do your object locking yourself.

But multiple files in one cog, or properly locked, will not cause any write-after-write or other issues on any shared structures.

jazzed
07-08-2009, 06:47 AM
I'm afraid I'll be avoiding any multiple COG access even with "spin locks" :)
The risk of trashing the underlying SDIO protocol is too high. The SDIO driver has to be singleton doesn't it ?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve


Propalyzer: Propeller PC Logic Analyzer (http://www.brouhaha.com/~sdenson/Propalyzer)
http://forums.parallax.com/showthread.php?p=788230 (http://forums.parallax.com/showthread.php?p=788230)

rokicki
07-08-2009, 07:12 AM
Yeah, the SDIO layer and the filesystem layer both have to be singleton. But the files themselves do not need to be.

With singleton SDIO and filesystem, and with the appropriate locking (in this case it would have to be at the
filesystem layer), there should be no chance of trashing the filesystem/SDIO.

But of course I've got to get multiple files working before I even think about multiple cogs.

Dr_Acula
07-08-2009, 09:35 AM
Thanks Mike for the explanation re femto basic. Like the triblade, it seems there are some programs around that need contiguous files and so Kye's work could be very useful, as all you would need to do is just send an object the name of the file and not worry about where the records came from.

I might need to go back and reread some posts re append, as we may be talking at cross purposes. My understanding is that Append adds to the end. When you go to record n in a file and overwrite that, that is called Random Access.

So three types of write:
1) Write an entire file (and overwrite the old version if it exists)
2) Write n bytes onto the end of a file (Append) and adjust the filesize accordingly.
3) Overwrite n bytes in the middle of a file at an arbitrary position - Random Access (and the file size stays exactly the same).

I must say that with all the programming I've done, I've only ever needed to use option 1). I tend to build a file in an array and append to the array and modify it, and then do a quick open/write entire array/close all at once. It means I never have problems with multiple files open. But that is just my personal programming style (which evolved back in the days of floppy drives when reading/writing to a disk took longer than reading/writing to an array in memory).

Kye, how complicated are options 2 and 3 to code? If they are too hard...

Post Edited (Dr_Acula (James Moxham)) : 7/8/2009 1:51:23 AM GMT

Kye
07-08-2009, 10:02 AM
Very easy.

1: First delete the file, then make a new file, then open it in write mode, then write to it.

2: First, open a file in write mode, call file seek with a position greater or equal to the file size, then write to it.

3: First open a file in write mode, call file seek to where you want to go, then write to it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Sapieha
07-08-2009, 10:10 AM
Hi Kye.

On 1.

One posiblity to.
Rename file and open it for READ.
OPEN Second file for WRITE.
COPY from 1 to 2 to position You will start write Yours buffer. WRITE buffer and READ rest of 1 and Write to 2.
Delate Renamed file.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.


Sapieha

Cluso99
07-08-2009, 01:13 PM
Yes, there are only 3 operations normally required and are covered best by James. I will only require item 3 and will control this by low level.

Maybe I may need to add code to verify the file is contiguous at the start. Then I will just use low level sector read/write access directly to the file. CPM already has it's own file system, and I am seeing the benefit of keeping it that way. If I need to allow other programs access to individual files within the "CPM file" or to the "FAT16/32 files" I can do that later.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), RamBlade (http://forums.parallax.com/showthread.php?p=810753), TwinBlade (http://forums.parallax.com/showthread.php?p=806697),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427)) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

Peter Verkaik
07-08-2009, 03:12 PM
I have been following this thread with great interest.
There are 3 layers involved here I think.
The top layer which provides the functions open, close, read, write, seek, tell, filesize etc.
These should be independant of the used format (FAT16,FAT32 or other).
The bottom layer that does the actual sector read and write to the (disk) device.
The middle layer that determines how sectors are employed. This differs on what
format is used.

For minimum memory footprint and fastest random access files should have contiguous sectors.
FAT16/32 cannot guarantee that, even if you ever have only 1 file open. If you append to
a file, and later append to another file, you cannot append to the first file later and guarantee
its sectors are still contiguous.

So I keep thinking, why not define a Propeller File System (.PFS file) which is a contiguous
file, prepared by a small windows app, WinPFS, much like WinZIP.
You can guarantee all files within the .PFS file are contiguous by demanding a maximum filesize
upon file creation. Files that only need to be read by Propeller can be marked READ-ONLY
and have set the maximum filesize equal to actual filesize.
Newly written files (by Propeller) allocate all sectors upon creation necessary for the maximum filesize.
This guarantees all sectors are contiguous. Deleting files could be just marked as deleted, to prevent
gaps in the list of free sectors, or really release the sectors so they can be reused for files
with a maximum filesize smaller or equal to the deleted file.

Perhaps this is something to discuss in another thread so this thread can focus
on Kye's implementation.

regards peter

m.r.b.
07-08-2009, 07:32 PM
I have already had a play with patching FSRW·... and have added the following features...

** Limited directory support (Make Directory, Change directory)
** Media information (total drive size, and free space available)
** File information (Bytecount of file, and drive allocation units actually used!!)
** Pointer seek (Relative to current position, and absolute file position indexing)
** Pointer tell
** Note read mode is now actually read+ mode(Read with random pointer seek access, if required)

This is still only FAT16 though!! Please see attached file. I can't really see the point of going to FAT32!


Hope this helps... Mathew

Kye
07-08-2009, 08:35 PM
Thanks mathew.

Is pointer tell needed? I'm not sure.

Um, okay, for CPM, why are contigous files needed and why do you need to do low level stuff? (The low level functions will be private but you can make them public.) The point of the file system driver is to handle all that stuff steamlessly for you.

It honestly requires only one extra read to get the next cluster. Its literally an opteration that works in constant time and is very fast.

Mmm, maybe I'm missing something.

...

As for media tye information. I can dig up a whole bunch of stuff. But I'm not sure if I should bother letting you access it because its not really that useful. Maybe total empty space left.

What would you like for this? I have acess to the card's CSD registers which give all information about the card and the file system info.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

heater
07-08-2009, 09:07 PM
Kye: "for CPM, why are contiguous files needed and why do you need to do low level stuff?"

Perhaps we don't need this for CP/M or other OS emulations any more, lets see:

1. Originally I had no FAT code in the Z80 emulator. I wanted as much space for Z80 RAM in HUB as possible. Besides I reasoned, I have CP/M file system why do I want FAT as well?. And why would I want to slow things down by going through a whole pile of Spin file system code?

2. With the arrival of XMM in made sense to use HUB space for FAT and make life a heck of lot easier for users. Writing a disk image as a FAT file from your PC is much better than raw writing the image to an SD.

3. BUT there was no seek in the FAT drivers around at the time. Is there now? I'm out of touch.

4. So the only way to go is have a contiguous disk image file, find which block it starts at and then use low level access to blocks from then on. As implemented by Cluso.

So what is the actual requirement here:

1. User can write a disk image file to SD FAT file system from his PC. It may end up fragmented.
2. Emulator can open the image file for read/write.
3. Emulator can seek to any offset within the image file at random as required by CP/M sector accesses.
4. Emulator can then read/write that block.
5. Emulator never needs to grow/shrink the file.
6. Would be nice if all written sectors are actually written immediately so that nothing is lost if close never happens.
6. Items 3) and 4) should be as fast as possible:)

What d'ya reckon?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

heater
07-08-2009, 09:12 PM
One last thing:

The CP/M emulator could have up to 16 disks a: b: c: .... each of which will be in it's own image file.
When copying between disks that means a lot of open's and closes unless we can have multiple files open.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Kye
07-08-2009, 09:16 PM
Haha, then you will be pleased because·I have that.

Flushing is not automatic though. But is done for you when you move arround. So you can technically flush a file by just seeking to a new sector or 512 bytes away from where you are at.

Open are also very fast. It only takes time to open a file when a zero length file is opened that has not been allocated.

Closes are a bit slower because the last acess date and write date is written but it only requires a read and then one write.

...

Seems like I have almost everything everybody wants. I'll need to figure out how to make one block driver support request from different objects. I guess I'll need to pass it an address vector.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Cluso99
07-08-2009, 09:32 PM
Kye, The way I am using the CPM files (as I said I create them contiguously on the pC anyway, so they only have random access reads and writes. So what I do is open each file at startup and find the first sector address on the SD. I store each file first sector address in a table. The when the emulator needs to access, say drive C and sector 5, I just add the base sector address for drive C (being 3 i.e. 2nd slot in table) to 5 and do a low level read/write. This is simple and fast.

The N8VEM group also have discussed this access method and we are pretty much in agreement that this is the way to go - have a file per disk drive under FAT. That way we can use existing file structures in CPM and keep CPM seperate to other files within FAT.

I hope this makes sense.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), RamBlade (http://forums.parallax.com/showthread.php?p=810753), TwinBlade (http://forums.parallax.com/showthread.php?p=806697),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427)) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

heater
07-08-2009, 09:43 PM
Kye: "Closes are a bit slower because the last access date and write date is written but it only requires a read and then one write."

There's the thing, if I can only have one file open at a time, as CP/M hops around drives (sector by sector of a file copy say) then for each hop a close and open needs to be done. For each close we now have a read and a write to update access time. As you see this soon ads up.

CP/M is already pretty slow at getting a directory listing whilst using sdspiqasm directly.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Dr_Acula
07-08-2009, 09:48 PM
How are you doing this Kye? Everytime we ask for something, you have it coded a few hours later! Are you doing all-nighter coding sessions with Pepsi or something? *grin*

This is going to be a really cool bit of code. For a year I've dreamed of sd card access for CP/M. There is even some assembly code around the place but every time I try to decode it my eyes glaze over. What you are coding Kye is complicated in the extreme, but you are making it simple to use and logical and that is very much appreciated.

Re Heater "I wanted as much space for Z80 RAM in HUB as possible". Yes, that was with your emulation that was in one propeller and used the propeller ram, right?

Just looking at where Cluso took it, to get the ram you need to use most of the prop pins to talk to the ram chip, so there are not enough pins for sd card (nor vga/keyboard). So it forces a design that uses at least two prop chips - one for the emulation and one for the sd card/keyboard/vga. Like the triblade. If you do that, then does that free up some code space in the sd card propeller? And thus there is plenty of space to fit Kye's code?

I think for CP/M you would only really ever need two files open - eg when copying, one for reading and one for writing. I think Kye already has that covered. So the contiguous problem is solved by Kye's code, and maybe the only thing that is an issue is the speed of reading/writing a non contiguous disk image vs a contiguous one. I wouldn't be too fussed about the speed, given this is going to be about 100x the speed of xmodem transfers I'm using at the moment.

Kye's code also solves another problem where you might copy a disk image from a PC onto a sd card, put it in an emulator, put some files on the image, move it back to the PC, copy it, rewrite a new one onto the sd card over and over and the image could end up in a different place. Much simpler if you just ask for record x in file DISK1.BIN and never have to worry where it actually is on the sd card.

Kye
07-08-2009, 09:53 PM
Yeah, writes kinda are slow, I need to fix my current block driver because the write fails alot.

Its weird because the card accomplishes the write but never sends the "all done" signal. I can't finish alpha testing until I fix that.

You can comment out an portion of the code that you would like to speed things up. Everything is written using funtion seperation so all the high level code only relies on its self. Commenting out the last few lines of file close will serve you perfectly.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

heater
07-08-2009, 09:54 PM
Dr_A: Yes that was for the one Prop emulator. But I still like to keep a one Prop and no XMM emulator for anyone with only a Demo board to try.

Ah but the Triblade does use all the pins for external RAM and also multiplexes them with an SD card interface.

Some Cluso magic there.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Dr_Acula
07-08-2009, 10:08 PM
Re "Some Cluso magic there."

Indeed, it is magic!

So - to Heater, is there room for an emulation if you move all the CP/M part into external ram, and just have the z80 emulation in the hub/cogs?

And to Kye, how much space is this brilliant magic of yours using?

Cluso99
07-08-2009, 10:11 PM
Yes James, the uSD is shares the sram pins. No need to go off ship for disk access.

Heater: for normal CPM we don't actually need to open/close the files (drives) - just low level access is all we need once we have the first sector address of each file. This is much simpler and faster and I see no need to change this. I may just add an option for validation on opening the drives to check they are contiguous, but I really think we can demand the user does this.

Currently I am using sdspiFemto without problems and this also has I2C support for the eeprom which I will not even be fitting in the RamBlade.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), RamBlade (http://forums.parallax.com/showthread.php?p=810753), TwinBlade (http://forums.parallax.com/showthread.php?p=806697),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427)) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

Cluso99
07-08-2009, 10:13 PM
Oh... I am curious - is it possible to put multiple FAT16 drives on >2GB uSD cards ?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), RamBlade (http://forums.parallax.com/showthread.php?p=810753), TwinBlade (http://forums.parallax.com/showthread.php?p=806697),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427)) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

Oldbitcollector (Jeff)
07-08-2009, 10:14 PM
Wow..

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 (http://www.warrantyvoid.us/tiki-index.php?page=Propeller) @ Warranty Void.

Cluso99
07-08-2009, 10:20 PM
Nice to see you're back from exhaustion OBC - here the expo was fantastic - congratulations :D

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), RamBlade (http://forums.parallax.com/showthread.php?p=810753), TwinBlade (http://forums.parallax.com/showthread.php?p=806697),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427)) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

heater
07-08-2009, 10:41 PM
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.

Kye
07-09-2009, 12:48 AM
Eh, that is technically easy, but an advanced feature not many people can use or understand what to do with it.

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,

Kye
07-09-2009, 01:40 AM
Great!

FAT32/FAT16 support is now opperational, and you can choose which partition on the drive to mount.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Oldbitcollector (Jeff)
07-09-2009, 01:44 AM
Cluso99 said...
Nice to see you're back from exhaustion OBC - here the expo was fantastic - congratulations :D


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 (http://www.warrantyvoid.us/tiki-index.php?page=Propeller) @ Warranty Void.

Oldbitcollector (Jeff)
07-09-2009, 01:46 AM
Kye said...
Great!

FAT32/FAT16 support is now opperational, and you can choose which partition on the drive to mount.



@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 (http://www.warrantyvoid.us/tiki-index.php?page=Propeller) @ Warranty Void.

rokicki
07-09-2009, 01:58 AM
MRB:

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.

rokicki
07-09-2009, 02:11 AM
Subdirectories:

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.

rokicki
07-09-2009, 02:37 AM
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.

Kye
07-09-2009, 06:58 AM
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.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Kye
07-09-2009, 11:39 AM
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.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Kye
07-09-2009, 11:45 AM
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.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Cluso99
07-09-2009, 11:53 AM
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:

· Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), RamBlade (http://forums.parallax.com/showthread.php?p=810753), TwinBlade (http://forums.parallax.com/showthread.php?p=806697),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427)) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

RossH
07-09-2009, 12:59 PM
Hi Kye,

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 (http://forums.parallax.com/showthread.php?p=795326)

m.r.b.
07-09-2009, 07:56 PM
Rokicki;



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

Kye
07-09-2009, 09:55 PM
Um, I can't give you my videoEngine, that's a driver I cannot share - right now atleast.

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,

RossH
07-10-2009, 08:05 AM
@Kye,

Oh - ok. I'll probably wait till there is a compilable version available.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina (http://forums.parallax.com/showthread.php?p=795326)

Kye
07-14-2009, 12:39 AM
Okay, I'm going back to work on this driver.

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,

Kye
07-14-2009, 07:25 AM
Anyone have any feed back here for me on this?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Cluso99
07-14-2009, 11:36 AM
@Kye: My post seems to have been lost.
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 (http://forums.parallax.com/showthread.php?p=786418), RamBlade (http://forums.parallax.com/showthread.php?p=810753), TwinBlade (http://forums.parallax.com/showthread.php?p=806697),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427)) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

ericball
07-14-2009, 08:35 PM
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 (http://forums.parallax.com/showthread.php?p=800114)
NTSC & PAL driver templates: Forum (http://forums.parallax.com/showthread.php?p=803904)
OnePinTVText driver: ObEx (http://obex.parallax.com/objects/480/) Forum (http://forums.parallax.com/showthread.php?p=822453)

Oldbitcollector (Jeff)
07-14-2009, 09:42 PM
Ditto!

OBC

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?

Visit the: The Propeller Pages (http://www.warrantyvoid.us/tiki-index.php?page=Propeller) @ Warranty Void.

Kye
07-15-2009, 07:43 AM
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.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Cluso99
07-15-2009, 03:37 PM
@Kye: If you cannot fit it then the less used routines could be placed in overlays - see the Tools link in my signature.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), RamBlade (http://forums.parallax.com/showthread.php?p=810753), TwinBlade (http://forums.parallax.com/showthread.php?p=806697),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427)) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

Kye
07-15-2009, 08:38 PM
Well my goal was under 6kb.

So far I've brought it down to about 900 longs. The 1300 was a vast overestimate.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Kye
07-17-2009, 11:42 AM
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.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Post Edited (Kye) : 7/17/2009 2:43:14 PM GMT

Cluso99
07-17-2009, 12:11 PM
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 http://forums.parallax.com/images/smilies/smile.gif

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp (http://forums.parallax.com/showthread.php?p=786418), RamBlade (http://forums.parallax.com/showthread.php?p=810753), TwinBlade (http://forums.parallax.com/showthread.php?p=806697),·SixBlade (http://forums.parallax.com/showthread.php?p=780033), website (http://bluemagic.biz/cluso.htm)
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator) (http://forums.parallax.com/showthread.php?p=790917)
· Prop Tools under Development or Completed (Index) (http://forums.parallax.com/showthread.php?p=753439)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index (http://forums.parallax.com/showthread.php?p=778427)) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google) (http://search.parallax.com/search?site=parallax&client=parallax&output=xml_no_dtd&proxystylesheet=parallax&proxycustom=<HOME/>&ie=&oe=&lr=)
My cruising website is: ·www.bluemagic.biz (http://www.bluemagic.biz)·· MultiBladeProp is: www.bluemagic.biz/cluso.htm (http://www.bluemagic.biz/cluso.htm)

Kye
07-18-2009, 02:35 AM
Argh...

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,

ericball
07-18-2009, 03:46 AM
Format options:

1. Quick & simple - overwrite the MBR & VBR and make one big FAT32 partition. The question is whether you can determine the size of the SD card without user input.
2. Quick Format - zero out the FAT & root directory of the current partition.
3. User specified partition & format - don't update the partition table, but use the start & length info.
4. FDISK functionality - partition table management.
5. Same as #1, but skip the partition table and format it like a giant floppy.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum (http://forums.parallax.com/showthread.php?p=800114)
NTSC & PAL driver templates: ObEx (http://obex.parallax.com/objects/483/) Forum (http://forums.parallax.com/showthread.php?p=803904)
OnePinTVText driver: ObEx (http://obex.parallax.com/objects/480/) Forum (http://forums.parallax.com/showthread.php?p=822453)

lonesock
07-18-2009, 03:55 AM
Kye said...
...
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.

To save on flash erase cycles, I'd recommend using a multiblock write, and setting the pre-erase block size.

Jonathan

P.S. You had mentioned that in your block driver the 1st write fails. Some cards I have refuse to do a write first. As long as I do a readblock right after mount, everything worked. This is fine for fsrw, as the 1st thing that happens is a read of block 0.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.

Kye
07-18-2009, 05:39 AM
@lonesock

Well, its just the first write in general always fails. But it suceeds in the data transfer. The card just never gives me the all good signal. Maybe I'm giving it too little time. I just assumed it would finish within 512 more cycles of reading in busy bytes.

@ericball

As for formating, well, I was going to try option two. I had originally tried full FDisk functionality but that its a pain in the *** when I'm trying to keep the functions simple.

So, I'm just going to take clusso99's advice and just leave it out.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Kye
07-18-2009, 05:44 AM
Okay, the first round of in house testing has been completed.
FAT16 functionality with small files works. Next I'll test FAT32 with small files. I'm not sure I can really test larger files right now however as the block driver I have isn't very great at writing alot of blocks at once.
Anway, here's the final API
The code size with the block driver is arround 1200 longs.


┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ──────────────────────────┐
│ File Engine │
│ │
│ Author: Kwabena W. Agyeman │
│ Updated: 7/10/2009 │
│ Designed For: P8X32A │
│ │
│ Copyright (c) 2009 Kwabena W. Agyeman │
│ See end of file for terms of use. │
│ │
│ Driver Info: │
│ │
│ The file engine interfaces with a secure digital flash card allowing acess to a FAT 16/32 file system. │
│ │
│ The driver, is only guaranteed and tested to work at an 80Mhz system clock or higher. The driver is designed for the P8X32A │
│ so port B will not be operational. │
│ │
│ Nyamekye, │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ──────────────────────────┘
Object "fileEngine" Interface:

PUB readCharacter
PUB writeCharacter(character)
PUB writeCharacters(characters)
PUB getCharacterPosition
PUB setCharacterPosition(position)
PUB closeFile
PUB openFile(fileName, readWrite, append)
PUB newEntry(entryName, fileOrDirectory)
PUB deleteEntry(entryName)
PUB renameEntry(entryNameToChange, entryNameToChangeTo)
PUB changeEntryAttributes(entryName, readOnlyFlag, hiddenFlag, systemFlag, archiveFlag)
PUB changeDirectory(directoryName)
PUB listSearch(entryName)
PUB listName
PUB listSize
PUB listCreationDay
PUB listCreationMonth
PUB listCreationYear
PUB listCreationSeconds
PUB listCreationMinutes
PUB listCreationHours
PUB listAccessDay
PUB listAccessMonth
PUB listAccessYear
PUB listModificationDay
PUB listModificationMonth
PUB listModificationYear
PUB listModificationSeconds
PUB listModificationMinutes
PUB listModificationHours
PUB listIsReadOnly
PUB listIsHidden
PUB listIsSystem
PUB listIsDirectory
PUB listIsArchive
PUB listReset
PUB computeCard(freeOrUsedSpace) : buffer
PUB mountCard(partition)
PUB fileEngine


3.3V


 1.8KΩ

─┻─ Data Out
3.3V


 1.8KΩ

─┻─ Clock
3.3V


 1.8KΩ

─┻─ Data In
3.3V


 1.8KΩ

─┻─ Chip Select

__________________
PUB readCharacter
32 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Reads a character from the file that is currently open for reading and advances the position by one. │
│ │
│ Has no affect if the file is open for writing, no file is open, or a card is not mounted. Returns zero. │
│ │
│ Returns the character read from the file on sucess (could be zero) and zero on failure. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
______________________________
PUB writeCharacter(character)
33 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Writes a character to the file that is currently open for writing and advances the position by one. │
│ │
│ Has no affect if the file is open for reading, no file is open, or a card is not mounted. Returns zero. │
│ │
│ Returns false on failure and true on sucess. Returns false when trying to make a file too big. │
│ │
│ Character - The character to write to the file. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
________________________________
PUB writeCharacters(characters)
37 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Writes a string of characters to the file that is currently open for writing and advances the position by string length. │
│ │
│ Has no affect if the file is open for reading, no file is open, or a card is not mounted. Returns zero. │
│ │
│ Returns false on failure and true on sucess. │
│ │
│ Characters - A pointer to a string of characters to write to the file. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
_________________________
PUB getCharacterPosition
3 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Returns the current character position within a file for reading and writing. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
___________________________________
PUB setCharacterPosition(position)
22 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Sets the current character position within a file for reading and writing. │
│ │
│ Returns true on success and false on failure. │
│ │
│ Position - A character position in the file. Set to false to go to the begining of the file and true to go to the end. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
______________
PUB closeFile
18 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Closes any previously opened files. │
│ │
│ All files opened for writing must be closed or corruption will occur. │
│ │
│ Returns true on sucess and false on failure. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
__________________________________________
PUB openFile(fileName, readWrite, append)
42 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Searches the current directory for a file and opens it for reading or writing. │
│ │
│ Closes any previously opened files. │
│ │
│ The "." and ".." entries are ignored by this function. Use "listName" to see them. │
│ │
│ Returns a pointer to the name of the entry on success or a string of zero length if not found or false on failure. │
│ │
│ FileName - The name of the file to search for and open in the current directory. │
│ ReadWrite - If true then the file is opened for writing otherwise it is opened for reading. │
│ Append - If true then the file is opened after the last byte in that file. Only for write mode. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
_________________________________________
PUB newEntry(entryName, fileOrDirectory)
41 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Creates a new entry in the current directory. │
│ │
│ List functions are not valid after calling this function. │
│ │
│ Will do nothing and return false if a file is currently open or if the card is not mounted. │
│ │
│ The "." and ".." entries are ignored by this function. Use "listName" to see them. │
│ │
│ Returns a pointer of length on success, of no length if the request could not be processed, and false on failure. │
│ │
│ EntryName - The name of the new entry to create. Must be a new unique name in the current directory. │
│ FileOrDirectory - If true then a directory is created otherwise then a file is created. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
___________________________
PUB deleteEntry(entryName)
40 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Deletes an entry in the current directory. │
│ │
│ Will do nothing and return false if a file is currently open or if the card is not mounted. │
│ │
│ The "." and ".." entries are ignored by this function. Use "listName" to see them. │
│ │
│ Returns a pointer to the name of the entry on success or a string of zero length if not found or false on failure. │
│ │
│ EntryName - The name of the entry to delete. This entry cannot be undeleted. Directories to be deleted must be empty. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
__________________________________________________ ______
PUB renameEntry(entryNameToChange, entryNameToChangeTo)
41 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Renames an entry in the current directory. │
│ │
│ List functions are not valid after calling this function. │
│ │
│ Will do nothing and return false if a file is currently open or if the card is not mounted. │
│ │
│ The "." and ".." entries are ignored by this function. Use "listName" to see them. │
│ │
│ Returns a pointer to the name of the entry on success or a string of zero length if not found or false on failure. │
│ │
│ EntryNameToChange - The name of the entry to change. Must be in the current directory. │
│ EntryNameToChangeTo - The name of the entry to change to. Must be a new unique name in the current directory. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
__________________________________________________ ______________________________________
PUB changeEntryAttributes(entryName, readOnlyFlag, hiddenFlag, systemFlag, archiveFlag)
44 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Changes the attributes of an entry in the current directory. │
│ │
│ List functions are not valid after calling this function. │
│ │
│ Will do nothing and return false if a file is currently open or if the card is not mounted. │
│ │
│ The "." and ".." entries are ignored by this function. Use "listName" to see them. │
│ │
│ Returns a pointer to the name of the entry on success or a string of zero length if not found or false on failure. │
│ │
│ EntryName - The name of the entry to change the attributes of. │
│ ReadOnlyFlag - If true then the read only file/folder flag is inverted otherwise then this is ignored. │
│ HiddenFlag - If true then the hidden file/folder flag is inverted otherwise then this is ignored. │
│ SystemFlag - If true then the system file/folder flag is inverted otherwise then this is ignored. │
│ ArchiveFlag - If true then the archive file/folder flag is inverted otherwise then this is ignored. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
___________________________________
PUB changeDirectory(directoryName)
40 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Searches for a directory in the current directory to change to and move into that directory. │
│ │
│ List functions are not valid after calling this function. │
│ │
│ Will do nothing and return false if a file is currently open or if the card is not mounted. │
│ │
│ The "." and ".." entries are ignored by this function. Use "listName" to see them. │
│ │
│ Use "." to move into the current directory. │
│ │
│ Use ".." to move into the previous directory. │
│ │
│ Returns a pointer to the name of the entry on success or a string of zero length if not found or false on failure. │
│ │
│ DirectoryName - The name of the directory to move into. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
__________________________
PUB listSearch(entryName)
36 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Searches for an entry and validates the list functions to get information about the item if found. │
│ │
│ Will do nothing and return false if a file is currently open or if the card is not mounted. │
│ │
│ The "." and ".." entries are ignored by this function. Use "listName" to see them. │
│ │
│ Returns a pointer to the name of the entry on success or a string of zero length if not found or false on failure. │
│ │
│ EntryName - The name of the entry to search for in the current directory. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
_____________
PUB listName
32 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Returns the name of the next entry and validates the list functions to get information about the item. │
│ │
│ Will do nothing and return false if a file is currently open or if the card is not mounted. │
│ │
│ Returns a pointer to the name of the entry on success or a string of zero length if not found or false on failure. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
_____________
PUB listSize
3 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Gets the size of current file or directory pointed to by "listName". Directories have no size. │
│ │
│ If a file is currently open this function will retrieve that files information. │
│ │
│ If "listName" did not succed or was not previously called the value returned is invalid. │
│ │
│ Returns the size of the file or directory in bytes. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
____________________
PUB listCreationDay
3 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Gets the creation day of the current file or directory pointed to by "listName". │
│ │
│ If a file is currently open this function will retrieve that files information. │
│ │
│ If "listName" did not succed or was not previously called the value returned is invalid. │
│ │
│ Returns the day of the file or directory. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
______________________
PUB listCreationMonth
3 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Gets the creation month of the current file or directory pointed to by "listName". │
│ │
│ If a file is currently open this function will retrieve that files information. │
│ │
│ If "listName" did not succed or was not previously called the value returned is invalid. │
│ │
│ Returns the month of the file or directory. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
_____________________
PUB listCreationYear
3 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Gets the creation year of the current file or directory pointed to by "listName". │
│ │
│ If a file is currently open this function will retrieve that files information. │
│ │
│ If "listName" did not succed or was not previously called the value returned is invalid. │
│ │
│ Returns the year of the file or directory. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
________________________
PUB listCreationSeconds
3 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Gets the creation second of the current file or directory pointed to by "listName". │
│ │
│ If a file is currently open this function will retrieve that files information. │
│ │
│ If "listName" did not succed or was not previously called the value returned is invalid. │
│ │
│ Returns the second of the file or directory. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
________________________
PUB listCreationMinutes
3 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Gets the creation minute of the current file or directory pointed to by "listName". │
│ │
│ If a file is currently open this function will retrieve that files information. │
│ │
│ If "listName" did not succed or was not previously called the value returned is invalid. │
│ │
│ Returns the minute of the file or directory. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
______________________
PUB listCreationHours
3 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Gets the creation hour of the current file or directory pointed to by "listName". │
│ │
│ If a file is currently open this function will retrieve that files information. │
│ │
│ If "listName" did not succed or was not previously called the value returned is invalid. │
│ │
│ Returns the hour of the file or directory. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
__________________
PUB listAccessDay
3 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Gets the last day of access of the current file or directory pointed to by "listName". │
│ │
│ If a file is currently open this function will retrieve that files information. │
│ │
│ If "listName" did not succed or was not previously called the value returned is invalid. │
│ │
│ Returns the day of the file or directory. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
____________________
PUB listAccessMonth
3 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Gets the last month of access of the current file or directory pointed to by "listName". │
│ │
│ If a file is currently open this function will retrieve that files information. │
│ │
│ If "listName" did not succed or was not previously called the value returned is invalid. │
│ │
│ Returns the month of the file or directory. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
___________________
PUB listAccessYear
3 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Gets the last year of access of the current file or directory pointed to by "listName". │
│ │
│ If a file is currently open this function will retrieve that files information. │
│ │
│ If "listName" did not succed or was not previously called the value returned is invalid. │
│ │
│ Returns the year of the file or directory. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
________________________
PUB listModificationDay
3 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Gets the last day of modification of the current file or directory pointed to by "listName". │
│ │
│ If a file is currently open this function will retrieve that files information. │
│ │
│ If "listName" did not succed or was not previously called the value returned is invalid. │
│ │
│ Returns the day of the file or directory. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
__________________________
PUB listModificationMonth
3 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Gets the last month of modification of the current file or directory pointed to by "listName". │
│ │
│ If a file is currently open this function will retrieve that files information. │
│ │
│ If "listName" did not succed or was not previously called the value returned is invalid. │
│ │
│ Returns the month of the file or directory. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
_________________________
PUB listModificationYear
3 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Gets the last year of modification of the current file or directory pointed to by "listName". │
│ │
│ If a file is currently open this function will retrieve that files information. │
│ │
│ If "listName" did not succed or was not previously called the value returned is invalid. │
│ │
│ Returns the year of the file or directory. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
____________________________
PUB listModificationSeconds
3 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Gets the last second of modification of the current file or directory pointed to by "listName". │
│ │
│ If a file is currently open this function will retrieve that files information. │
│ │
│ If "listName" did not succed or was not previously called the value returned is invalid. │
│ │
│ Returns the second of the file or directory. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
____________________________
PUB listModificationMinutes
3 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Gets the last minute of modification of the current file or directory pointed to by "listName". │
│ │
│ If a file is currently open this function will retrieve that files information. │
│ │
│ If "listName" did not succed or was not previously called the value returned is invalid. │
│ │
│ Returns the minute of the file or directory. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
__________________________
PUB listModificationHours
3 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Gets the last hour of modification of the current file or directory pointed to by "listName". │
│ │
│ If a file is currently open this function will retrieve that files information. │
│ │
│ If "listName" did not succed or was not previously called the value returned is invalid. │
│ │
│ Returns the hour of the file or directory. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
___________________
PUB listIsReadOnly
3 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Returns whether or not the current file or directory pointed to by "listName" is read only. │
│ │
│ If a file is currently open this function will retrieve that files information. │
│ │
│ If "listName" did not succed or was not previously called the value returned is invalid. │
│ │
│ Returns true or false. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
_________________
PUB listIsHidden
3 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Returns whether or not the current file or directory pointed to by "listName" is hidden. │
│ │
│ If a file is currently open this function will retrieve that files information. │
│ │
│ If "listName" did not succed or was not previously called the value returned is invalid. │
│ │
│ Returns true or false. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
_________________
PUB listIsSystem
3 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Returns whether or not the current file or directory pointed to by "listName" is a system file or directory. │
│ │
│ If a file is currently open this function will retrieve that files information. │
│ │
│ If "listName" did not succed or was not previously called the value returned is invalid. │
│ │
│ Returns true or false. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
____________________
PUB listIsDirectory
3 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Returns whether or not the current file or directory pointed to by "listName" is a directory. │
│ │
│ If a file is currently open this function will retrieve that files information. │
│ │
│ If "listName" did not succed or was not previously called the value returned is invalid. │
│ │
│ Returns true or false. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
__________________
PUB listIsArchive
3 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Returns whether or not the current file or directory pointed to by "listName" has been modified since the last backup. │
│ │
│ If a file is currently open this function will retrieve that files information. │
│ │
│ If "listName" did not succed or was not previously called the value returned is invalid. │
│ │
│ Returns true or false. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
______________
PUB listReset
3 Stack Longs - Ignore Return Value
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Resets the listing functions. │
│ │
│ Will do nothing and return false if a file is currently open. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
__________________________________________
PUB computeCard(freeOrUsedSpace) : buffer
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Returns the partition free space or used space in bytes. Is invalid if the card is not currently mounted. │
│ │
│ This function takes a while to execute. │
│ │
│ FreeOrUsedSpace - If false then return the free space otherwise return the used space. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
_________________________
PUB mountCard(partition)
16 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Loads and activates the SD card allowing file system access. The SD card is unmounted when an error occurs. │
│ │
│ Returns true on sucess and false on failure. │
│ │
│ Parition - Partition number to mount - between 0 and 3. The default value is partition number 0. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
_______________
PUB fileEngine
3 Stack Longs
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┐
│ Initializes the file system driver to run on a new cog. │
│ │
│ Returns the new cog's ID on sucess or -1 on failure. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ───────────────────────┘
┌───────────────────────────────────────────────── ────────────────────────────────────────────────── ──────────────────────────┐
│ TERMS OF USE: MIT License │
├───────────────────────────────────────────────── ────────────────────────────────────────────────── ──────────────────────────┤
│Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation │
│files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, │
│modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the │
│Software is furnished to do so, subject to the following conditions: │
│ │
│The above copyright notice and this permission notice shall be included in all copies or substantial portions of the │
│Software. │
│ │
│THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE │
│WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR │
│COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, │
│ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. │
└───────────────────────────────────────────────── ────────────────────────────────────────────────── ──────────────────────────┘

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Kye
07-18-2009, 05:46 AM
Oh, I guess I'll need to add block reads and writes too.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

pgbpsu
10-28-2009, 08:28 PM
Kye-

Has this code been released? I can't find it in the obex and my search abilities can not locate it on the forums. Looks like a very useful piece of software. I'm most interested in the filesize and available disk space methods.

Thanks,
Peter

Rob7
10-28-2009, 11:03 PM
Kye,
Everything you can ever want is in the engine !
Thanks, Thanks, Thanks.
When do you think it will be released ?

Kye
10-29-2009, 09:10 AM
I'm in school right now so I'm very busy, but here's the last release of the driver if you want to play arround with it.

I'll get back to this later when I have free time in December/January.



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,