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.
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.
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.
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[noparse]/noparse, word[noparse]/noparse, or long[noparse]/noparse 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.
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.
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.
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.
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.
I'm afraid I'll be avoiding any multiple COG access even with "spin locks" [noparse]:)[/noparse]
The risk of trashing the underlying SDIO protocol is too high. The SDIO driver has to be singleton doesn't it ?
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.
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
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.
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:
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.
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!
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.
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[noparse]:)[/noparse]
What d'ya reckon?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
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.
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.
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:
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.
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.
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.
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:
Comments
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.
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
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
Guess it would be good to see the file-system shake out beta bugs first anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
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[noparse]/noparse, word[noparse]/noparse, or long[noparse]/noparse 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,
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
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.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: http://forums.parallax.com/showthread.php?p=800114
NTSC & PAL templates: http://forums.parallax.com/showthread.php?p=803904
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.
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://forums.parallax.com/showthread.php?p=788230
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.
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
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,
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
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, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
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
** 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
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,
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[noparse]:)[/noparse]
What d'ya reckon?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
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.
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,
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, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
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.
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.
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,
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.
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?
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, RamBlade, TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80), MoCog (6809)
· Search the Propeller forums (via Google)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm